Обсудить задачу
Уведомления

Skirbo +
Carrot quest

Изучим передачу ограниченного набора складских событий в Carrot quest, чтобы поддержка видела контекст заказа. Определим ключ пользователя и не будем отправлять лишние данные состава покупки. Для текущего уведомления и для загрузки истории выберем разные правила времени события и запуска сообщений.

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

ОперацияНаправлениеСостав и готовность
События обработки заказаSkirbo → Carrot questОбсудим в составе подключения

Задать собственные имена и минимальные атрибуты без конфликта с системными событиями; сохранить ID заказа, этап и версию в согласованной модели.

Связь с пользователемCRM продавца / сайт → адаптер Carrot questОбсудим в составе подключения

Проверить соответствие постоянного внешнего User ID и профиля; автоматическое создание при записи не использовать для исправления неизвестного клиента.

История выбранных событийCarrot quest → журнал обмена / поддержкаОбсудим в составе подключения

Читать события нужного типа с пагинацией и сопоставлять с локальной версией; история помогает расследованию, но не заменяет фактический статус WMS.

Задержка и завершение исключенияОтветственный за заказ → Carrot questОбсудим в составе подключения

Передавать отдельные подтверждённые события начала и завершения задержки; правила повторных сообщений согласовать с владельцем сценария.

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

Для интернет-магазина и фулфилмента, чья поддержка работает в Carrot quest. Передаём клиентский контекст исполнения: отгрузку, подтверждённую задержку, отмену или приёмку возврата. Carrot quest хранит событие пользователя и помогает в коммуникациях; физический склад, остаток, платежи и решение об изменении заказа сохраняют своих владельцев. Целевой сценарий — Россия, иные страны проверяются отдельно.

Как организовать обмен

Web API позволяет записывать и читать события пользователя; можно обращаться по внутреннему ID Carrot quest или по своему User ID с явным переключением режима. Собственные имена событий не должны конфликтовать с системными. Если сайт связывает авторизованного покупателя через JavaScript auth, HMAC рассчитывают на сервере. Точный токен, его права и события автоматизации проверяются в приложении продавца.

Предлагаемый порядок работы

  1. Склад фиксирует событие после реального действия, включая продавца, заказ, версию, время и ответственного. Каждое сканирование в коммуникации не отправляется.
  2. Адаптер определяет приложение Carrot quest и постоянный User ID покупателя. Заказ проверяется в границах этого продавца; совпадение телефона или имени само по себе не разрешает объединение.
  3. Событие сопоставляется со словарём проекта: своё имя, внешний ID заказа, этап и краткий контекст. Для нескольких заказов пользователя атрибуты не должны перетирать один общий статус без номера заказа.
  4. Склад продолжает физическую обработку и остаётся владельцем статуса. Адаптер записывает событие через проверенный метод и токен; выбор created согласован с тем, нужен ли запуск автосообщения.
  5. Полученный Event связывается с исходным событием и попыткой в журнале. Оператор видит контекст, а сообщение покупателю отправляется только по настроенному и допустимому сценарию.
  6. При необходимости выборочно читают события нужного типа с пагинацией и сверяют заказ/версию. Сам факт записи не отмечает заказ доставленным и не подтверждает прочтение сообщения.
  7. При ошибочном User ID или неизвестном результате запись приостанавливают. Ответственный выясняет, создан ли Event, и разрешает повтор по принятому правилу, исключающему повторное уведомление.

Практические сценарии

Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.

Контекст обращения о заказе

Задача: Дать оператору достоверный этап отгрузки и его связь с конкретным заказом.

Когда начинается: Склад подтвердил отгрузку или другой согласованный этап исполнения.

  1. Склад фиксирует событие после реального действия, включая продавца, заказ, версию, время и ответственного. Каждое сканирование в коммуникации не отправляется.
  2. Адаптер определяет приложение Carrot quest и постоянный User ID покупателя. Заказ проверяется в границах этого продавца; совпадение телефона или имени само по себе не разрешает объединение.
  3. Событие сопоставляется со словарём проекта: своё имя, внешний ID заказа, этап и краткий контекст. Для нескольких заказов пользователя атрибуты не должны перетирать один общий статус без номера заказа.
  4. Склад продолжает физическую обработку и остаётся владельцем статуса. Адаптер записывает событие через проверенный метод и токен; выбор created согласован с тем, нужен ли запуск автосообщения.
  5. Полученный Event связывается с исходным событием и попыткой в журнале. Оператор видит контекст, а сообщение покупателю отправляется только по настроенному и допустимому сценарию.
  6. При необходимости выборочно читают события нужного типа с пагинацией и сверяют заказ/версию. Сам факт записи не отмечает заказ доставленным и не подтверждает прочтение сообщения.
  7. При ошибочном User ID или неизвестном результате запись приостанавливают. Ответственный выясняет, создан ли Event, и разрешает повтор по принятому правилу, исключающему повторное уведомление.

Результат: Поддержка связывает обращение с подтверждённым этапом конкретного заказа и видит границы достоверности.

Если возникло исключение

  • Один клиент с несколькими заказами не получает общий статус, скрывающий более ранний незавершённый заказ.
  • Неправильный внешний User ID может породить новый профиль; автоматическую запись при несопоставленном клиенте запрещают в адаптере.

Сценарий при задержке

Задача: Сообщить о значимом исключении один раз и завершить его, когда склад подтвердил решение.

Когда начинается: Ответственный признал задержку заказа и определил, что клиенту необходимо уведомление.

  1. Присвоить исключению собственную идентичность, связать его с заказом и текущей версией; повторный технический сигнал не считается новой задержкой.
  2. Передать согласованное событие начала задержки; владелец Carrot quest задаёт условия, канал и частоту сообщения с учётом разрешений клиента.
  3. После устранения причины получить подтверждение склада и передать отдельное событие завершения. Остановка будущих напоминаний проверяется в логике сценария.
  4. Если заказ отменён или возврат принят, использовать другой подтверждённый результат; не отправлять одновременно сообщение о скорой отгрузке и о завершённой отмене.

Результат: Покупатель получает понятные изменения ситуации, а поддержка видит причину и разрешение исключения.

Если возникло исключение

  • Изменение комментария к задержке не запускает повторную рассылку.
  • Ответ покупателя в чате направляется оператору и не выполняет отмену или изменение адреса на складе автоматически.

История после разрыва обмена

Задача: Восстановить полезные события для поддержки, сохранив контроль над автосообщениями.

Когда начинается: Обнаружен период пропущенных событий или выполняется первоначальное подключение.

  1. Сверить историю WMS с уже записанными событиями пользователя, проходя все нужные страницы и проверяя номер заказа.
  2. Выделить только отсутствующие подтверждённые события. Для исторической записи явно определить время created; документация указывает, что при нём автосообщения не планируются.
  3. После записи связать новые Event с исходными событиями. Если клиенту всё ещё нужно актуальное уведомление, согласовать его отдельно после проверки текущего состояния заказа и разрешений канала.
  4. Проверить результаты восстановления и случаи неизвестного пользователя; не создавать профиль автоматически без подтверждённой карты идентичности.

Результат: Оператор видит историю, а пропуск связи не превращается в серию просроченных уведомлений.

Если возникло исключение

  • Нельзя считать created обычным техническим полем времени: оно меняет поведение автосообщений.
  • Пагинация и свойство большого числового ID обрабатываются без потери точности; при необходимости свойства читают строками.

Кто управляет данными

ДанныеОтветственный источникПравило обмена
Заказ и физическое исполнениеПродавец и WMSВ Carrot quest передаётся подтверждённый контекст, а складской статус, резерв и списание остаются в WMS.
Постоянный User IDСистема регистрации / CRM продавцаНе использовать изменяемый email; связь с профилем проверяется отдельно для каждого приложения.
Контакты и разрешенияПродавец / система клиентских согласийСобытие заказа не создаёт согласие на рекламу и не отменяет отписку.
Event и коммуникационный сценарийCarrot quest и владелец автоматизацииEvent подтверждает запись; правила отправки и остановки сообщения настраивает уполномоченный владелец.
Защищённая авторизация сайтаBackend сайта продавцаHMAC для auth рассчитывается на сервере; User Auth Key не передаётся в браузер или журнал склада.
Повторы, пропуски и версияАдаптер обмена / ответственный за интеграциюЛокальная связь исходного события и Event нужна для сверки и исключения повторной коммуникации.

Что обсудить перед пилотом

  • Какие этапы заказа должны видеть операторы Carrot quest и какой User ID связывает системы?
  • Какие собственные имена и атрибуты отличают заказ, задержку, отмену и возврат?
  • Какие события должны запускать автосообщения, а какие передаются с created только для истории?
  • Как проверяются права токена, принадлежность профиля продавцу и результат после тайм-аута?
  • Кто подтверждает канал, отписку и прекращение будущих сообщений после отмены?
Перед оценкой

Что нужно уточнить

  • Приложение Carrot quest продавца, утверждённый токен с нужными правами и владелец его отзыва.
  • Постоянный User ID, карта клиент/продавец/приложение, внешний ID заказа и версия события; совпадения отображаемого имени недостаточно.
  • Словарь собственных событий, допустимые атрибуты и правила отображения нескольких заказов одного покупателя.
  • Отдельное решение о передаче created для истории и о времени текущего события; тест настройки автосообщений.
  • Правила каналов, отписки и согласий, круг сотрудников с доступом, минимальный набор передаваемых данных и срок хранения журнала обмена.
Границы сценария

Что учесть заранее

  • Зарезервированные системные имена событий нельзя использовать произвольно.
  • Данные заказа следует минимизировать, особенно при наличии нескольких заказов у одного клиента.
  • Интерфейс поддержки не становится источником складского остатка.
  • Запись события по неизвестному внешнему User ID способна создать новый профиль. Ошибку сопоставления нужно остановить до записи, а не исправлять массовым созданием пользователей.
  • Передача created меняет поведение автосообщений: нельзя одновременно считать событие историческим и ожидать обычный автоматический запуск уведомления.
  • Полученный Event подтверждает запись события, но не доставку письма, согласие клиента или выполнение заказа. Идемпотентность повторной записи и конкретные условия канала требуют отдельной проверки.
Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

Выберите один этап заказа и один сценарий задержки; подготовьте обезличенную карту User ID, заказов и событий, отдельно отметив текущие сообщения и восстановление истории.

Вопросы о подключении

Передавать ли каждый шаг сканирования?

Обычно для поддержки достаточно нескольких значимых этапов. Частые технические события увеличат шум и могут многократно запустить сценарий.

Как связать заказ с посетителем сайта?

Проверим общий внешний идентификатор и правила его передачи. Совпадения только по отображаемому имени недостаточно.

Можно взять email в качестве постоянного User ID?

Если email может измениться, инструкция auth не рекомендует такой ключ. Нужен постоянный ID пользователя; сам контакт передают как отдельные данные при наличии основания.

Почему событие записано, а автосообщение не началось?

Проверьте, передан ли created: метод явно отключает планирование автосообщений при этом параметре. Затем проверьте правила сценария и канал; наличие Event не гарантирует отправку.

Можно ли безопасно повторить POST после тайм-аута?

Не следует предполагать автоматическую защиту от дублей. Сначала сверяют журнал и историю событий, затем принимают решение о повторе; точные гарантии метода нужно подтвердить отдельно.

Что происходит с неизвестным внешним User ID?

При записи события с by_user_id=true сервис может создать пользователя, а при чтении вернёт LookupError. Поэтому проверка идентичности выполняется до записи, особенно у общего склада.

Интеграция уже готова?

Изучаем возможность. Описан предлагаемый процесс обмена; готовый коннектор Skirbo, проведённый пилот и приёмка на заказах клиента не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Посмотрите другие сценарии

Весь каталог →
Ваш процесс → следующий шаг

Что хотите связать со Skirbo?

Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.

  1. Разберём задачуУточним роли, склады и операции.
  2. Проверим возможностьОпределим доступы, ограничения и состав работ.
  3. Согласуем запускОбсудим стоимость, сроки и критерии готовности.

Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.

1. Какие сервисы подключить?

До 5 сервисов в одной заявке.

Укажите роль — подскажем, какие особенности процесса описать.

2. Какие задачи решить?

Выберите от 1 до 8 задач.

Компания и объём заказов необязательно
3. Как с вами связаться?
Проверяем возможность отправки. Вы также можете подготовить запрос и передать его поддержке.
Открыть поддержку в Telegram

Копирование и переход в Telegram сами по себе не отправляют заявку.

Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.