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

Skirbo +
RED SMS

Передавать короткое сообщение, сохранять UUID и проверять его результат, разделяя клиентские сообщения и тревоги сотрудникам. Переход на звонок или другой канал требует отдельного правила.

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

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

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

ОперацияНаправлениеСостав и готовность
СообщениеSkirbo → RED SMSОбсудим в составе подключения

Событие, роль получателя и маршрут; полная схема POST проверяется до реализации.

Информация по UUIDRED SMS → SkirboОбсудим в составе подключения

Результат конкретной попытки; исходный статус и причина сохраняются.

Информация аккаунтаRED SMS → служебный контрольОбсудим в составе подключения

Только разрешённые данные client/info для разбора условий отправки, без обещания конкретных тарифов.

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

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

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

Для склада, уведомляющего покупателя о самовывозе или ответственного сотрудника об исключении. В RED SMS предусмотрены разные каналы; здесь выбирается один SMS-маршрут. Номер сообщения и адресат связываются с конкретным событием, а не с общим последним состоянием заказа.

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

Официальная HTTP-справка перечисляет POST /api/message, GET /api/message/{uuid} и GET /api/client/info. Прочитанный текст подтверждает назначение методов, но не полные тела, подпись и справочник статусов.

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

  1. Получить клиента, заказ, адресата и актуальный текст события.
  2. Сопоставить SMS-маршрут, имя отправителя и номер с клиентским аккаунтом RED SMS.
  3. Отправить через проверенный контракт /api/message, сохранить UUID и внутренний ключ попытки.
  4. Склад продолжает фактическое исполнение независимо от уведомления; факт выдачи записывается сотрудником.
  5. Вернуть в Skirbo подтверждение принятия сообщения с внешним UUID.
  6. По /api/message/{uuid} либо другому подтверждённому механизму проверить результат именно этой попытки и сохранить исходный статус.
  7. При неизвестном UUID, отказе или таймауте оставить разбор; повторное чтение результата не превращается в повторную отправку.

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

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

Сообщение и его UUID

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

Когда начинается: Подтверждённое событие склада требует SMS.

  1. Получить клиента, заказ, адресата и актуальный текст события.
  2. Сопоставить SMS-маршрут, имя отправителя и номер с клиентским аккаунтом RED SMS.
  3. Отправить через проверенный контракт /api/message, сохранить UUID и внутренний ключ попытки.
  4. Склад продолжает фактическое исполнение независимо от уведомления; факт выдачи записывается сотрудником.
  5. Вернуть в Skirbo подтверждение принятия сообщения с внешним UUID.
  6. По /api/message/{uuid} либо другому подтверждённому механизму проверить результат именно этой попытки и сохранить исходный статус.
  7. При неизвестном UUID, отказе или таймауте оставить разбор; повторное чтение результата не превращается в повторную отправку.

Результат: Событие, сообщение и результат имеют устойчивую связь.

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

  • ID сообщения не равен подтверждению доставки.
  • UUID другого аккаунта не привязывается к заказу по совпадающему телефону.

Оповещение сотрудника о складском исключении

Задача: Отделить внутреннюю тревогу от текста покупателю.

Когда начинается: На площадке обнаружена недостача или остановка обработки.

  1. Определить ответственного сотрудника по роли и текущей площадке, а не брать телефон покупателя из заказа.
  2. Сформировать короткий текст с допустимым идентификатором задачи и минимумом персональных данных.
  3. Сохранить попытку и результат; закрытие исключения требует решения сотрудника, а не доставленной SMS.

Результат: Складская проблема получает адресного ответственного.

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

  • Успешное сообщение не закрывает недостачу.
  • Смена дежурного требует обновления адресата до отправки.

Проверка готовности канала

Задача: Разобрать системную причину отказов до повторной рассылки.

Когда начинается: Несколько сообщений одного клиента не принимаются.

  1. Проверить доступную информацию аккаунта через client/info и причину ошибки выбранного метода.
  2. Остановить новые попытки этого маршрута до решения ответственного.
  3. После восстановления сверить прежние UUID и актуальность событий; повторять только по согласованному правилу.

Результат: Массовый повтор не скрывает проблему аккаунта и не дублирует доставленные SMS.

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

  • Другие каналы RED SMS не включаются автоматически вместо заблокированного маршрута.

Часть адресатов принята, часть отклонена

Задача: Разобрать неполный результат без повторной отправки уже созданных сообщений.

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

  1. Сопоставить каждого разрешённого адресата с конкретным клиентом, событием и ролью; не объединять аккаунты разных продавцов.
  2. Для успешно созданных сообщений сохранить отдельные UUID. Ошибки сохранить у соответствующих адресатов с исходной причиной.
  3. Запрашивать результаты только созданных попыток; общее поле успеха не превращать в подтверждение доставки всей группы.
  4. Ответственный исправляет отклонённый контакт или условия маршрута, затем проверяет актуальность складского события.
  5. Новая попытка создаётся только для согласованного исправленного адресата. Поздний callback ранее принятого сообщения обновляет его собственную историю.

Результат: Каждая попытка имеет свой результат; успешная часть не рассылается повторно из-за чужой ошибки.

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

  • Складское исключение остаётся открытым до решения ответственного сотрудника.
  • Отсутствие UUID после потерянного ответа требует разбора, а не повторения всей пачки.

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

ДанныеОтветственный источникПравило обмена
Заказ, SKU и остаткиПродавец и система складаВ уведомление попадает только согласованный снимок события; сервис рассылки не меняет заказ или запас.
Складские статусы и возвратыСистема физического исполненияВыдача, приёмка возврата и результат осмотра подтверждаются складом; письмо или SMS не создаёт эти факты.
Контакт и выбор каналаCRM продавца / подтверждённый контактЗаказчик определяет адресата и назначение сообщения; сведения разных клиентов не объединяются.
ДокументыСистема, выпустившая документВ сообщении — разрешённая ссылка или согласованное вложение, а не новая юридическая версия документа.
Результат сообщенияПоставщик канала связиПринятие запроса, доставка и прочтение хранятся отдельно, если выбранный продукт их предоставляет.
Назначение сообщения, разрешение канала и отпискаПродавец; ответственный за клиентские коммуникацииДля каждого клиента раздельно хранить сервисный повод, рекламную подписку и запрет канала. Обновление заказа не создаёт рекламного согласия. Отказ от канала проверяется перед новой попыткой; спорный случай направляется ответственному без автоматического обхода запрета.

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

  • Кто получает каждое событие — покупатель или сотрудник площадки?
  • Какой статус по UUID является окончательным и какие ошибки допускают повтор?
  • Нужно ли получать обратные события или достаточно согласованной сверки по UUID?
Перед оценкой

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

  • Выбранный SMS-маршрут, отправитель и роли получателей.
  • Контракт /api/message и справочник результата по UUID.
  • Правила обработки ошибок аккаунта, резервного канала и актуальности событий.
  • Для callback согласовать фильтрацию источников, проверку аккаунта и UUID, а также авторизованную сверку сомнительных событий.
Границы сценария

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

  • HTTP-указатель не подтверждает поля запросов и механизм авторизации.
  • SMS, голосовые проверки, HLR и другие маршруты не взаимозаменяемы; текущая доступность каналов уточняется.
  • Сообщение и результат не подтверждают устранение недостачи, оплату или выдачу товара.
  • Криптографическая подпись webhook не подтверждена. Доступный callback нельзя считать доверенным только по User-Agent или известному формату.
Стоимость и запуск

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

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

Выберите один клиентский SMS-сценарий и одну внутреннюю тревогу, затем проверьте контракт отправки и чтения UUID RED SMS.

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

Можно уведомлять сотрудника вместо покупателя?

Да, рассмотрим роль получателя для каждого события, чтобы складская тревога и клиентское уведомление имели разные тексты и адресатов.

Как выбрать запасной канал при отказе?

Зададим явное правило для выбранного события и адресата; отказ SMS не будет самостоятельно запускать звонок или рассылку.

Зачем хранить UUID, если есть телефон?

На один телефон может уйти несколько разных событий. UUID нужен, чтобы поздний статус обновлял нужную попытку, а не последний заказ получателя.

Можно закрывать складскую тревогу по доставленной SMS?

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

Можно считать всю группу уведомлённой по общему успеху ответа?

Проверяем результат каждого адресата: созданные попытки сохраняются по UUID, ошибки направляются на исправление отдельно. Повтор всей группы создаст дубли для уже принятых сообщений.

Что делать с webhook для неизвестного UUID?

Сохранить его для разбора, проверить источник и аккаунт. Такой callback не связывается с последним заказом по телефону и не меняет складские статусы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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