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

Skirbo +
NotiSend

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

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

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

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

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

Событие + клиент + адресат + переменные; API/SMTP выбираются явно.

Обратный результатNotiSend → SkirboОбсудим в составе подключения

Проверенное событие с привязкой к попытке; точные поля/подпись уточняются.

Согласованный переход на SMSSkirbo → отдельный SMS-продукт NotiSendОбсудим в составе подключения

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

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

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

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

Для продавца, уведомляющего о завершении обработки заказа, и фулфилмента с несколькими клиентами. У NotiSend отдельно представлены Email API/SMTP, SMS-интерфейсы и Telegram Gateway для кодов. Сценарий начинается с одного нужного канала; другой не включается автоматически из-за задержки результата.

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

Официальная страница разработчиков описывает транзакционные и маркетинговые email, SMTP, шаблоны, email-webhooks и отдельные SMS-интерфейсы. Точные payload, авторизация и проверка обратного события требуют чтения выбранного контракта.

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

  1. Сохранить событие, номер заказа, клиента, адресата и разрешённый результат работы.
  2. Сопоставить выбранный продукт NotiSend, отправителя и версию шаблона; выбрать API или SMTP как единственный маршрут этой попытки.
  3. Передать письмо с минимальными переменными и сохранить доступный внешний ID/подтверждение принятия.
  4. Оператор склада оставляет фактический результат самостоятельной записью; недоставка письма не отменяет выполненную работу.
  5. Вернуть в Skirbo почтовую попытку и доступные обратные события, связывая их с исходным событием заказа.
  6. Проверить подлинность и принадлежность обратного события по текущему контракту, затем надёжно записать и подтвердить обработку.
  7. При повторе webhook обновить прежнюю попытку; при отказе назначить проверку контакта и допустимости повтора.

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

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

Подтверждение завершённой обработки

Задача: Уведомить клиента по факту, который уже зафиксировал склад.

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

  1. Сохранить событие, номер заказа, клиента, адресата и разрешённый результат работы.
  2. Сопоставить выбранный продукт NotiSend, отправителя и версию шаблона; выбрать API или SMTP как единственный маршрут этой попытки.
  3. Передать письмо с минимальными переменными и сохранить доступный внешний ID/подтверждение принятия.
  4. Оператор склада оставляет фактический результат самостоятельной записью; недоставка письма не отменяет выполненную работу.
  5. Вернуть в Skirbo почтовую попытку и доступные обратные события, связывая их с исходным событием заказа.
  6. Проверить подлинность и принадлежность обратного события по текущему контракту, затем надёжно записать и подтвердить обработку.
  7. При повторе webhook обновить прежнюю попытку; при отказе назначить проверку контакта и допустимости повтора.

Результат: У выполненной работы есть отдельная, проверяемая история уведомления.

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

  • Принятое письмо не означает доставленное или прочитанное.
  • Неизвестный ID события не привязывается к заказу по одному email.

Недоставленное письмо и согласованный запасной канал

Задача: Не создавать два сообщения из-за задержки обратного результата.

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

  1. Проверить причину отказа, актуальность заказа и разрешённый контакт другого канала.
  2. Если продавец согласовал SMS, создать отдельную связанную попытку выбранного SMS-продукта с собственным результатом.
  3. Сохранить переход и причину; поздний email-результат не запускает новую цепочку.

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

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

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

Выбор канала кода и уведомления

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

Когда начинается: Продавец рассматривает Telegram Gateway вместе с уведомлениями о заказах.

  1. Отделить задачу одноразового кода от сообщения о состоянии заказа.
  2. Проверить отдельную документацию продукта кодов, назначение и привязку к действию пользователя.
  3. Для текста о заказе выбрать подтверждённый email/SMS или иной согласованный интерфейс, сохраняя отдельные события.

Результат: Код доступа и клиентское сообщение не смешиваются.

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

  • Полученный код не заменяет полномочия оператора или доказательство физической выдачи.

Частичный возврат и отмена устаревшего письма

Задача: Сообщить о фактическом этапе возврата без обещания ещё не выполненного возврата денег.

Когда начинается: Склад принял часть позиций или продавец отменил ещё не завершённое действие по заказу.

  1. Получить подтверждённое событие с номером заказа, версиями строк и фактически принятым количеством; определить клиента фулфилмента.
  2. Сопоставить адресата и шаблон NotiSend с этим этапом. Отдельно проверить разрешённость канала и отсутствие более нового события.
  3. Не передавать в API/SMTP устаревшую задачу из внутренней очереди. Уже принятому письму не приписывать возможность отзыва без подтверждённого метода.
  4. Отправить одно актуальное письмо по выбранному маршруту; сохранить связь с событием возврата и предыдущим уведомлением, если оно уже ушло.
  5. Записать доступный результат письма. Несовпадение строк или неизвестный внешний ID отправить на разбор, сохраняя фактическую приёмку склада.

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

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

  • Сообщение о принятом возврате не подтверждает возмещение денег.
  • Если прежнее письмо уже отправлено, исправление создаётся как новое осмысленное событие с согласованным текстом.

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

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

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

  • Какие события NotiSend доступны выбранному продукту и как проверяется их подлинность?
  • Кто владеет повтором и резервным каналом?
  • Telegram нужен для кода или для текста о заказе?
Перед оценкой

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

  • Выбранный email-продукт и маршрут API либо SMTP.
  • Проверенный отправитель, шаблон и контракт обратного события.
  • Правило отказа, подтверждённые контакты и допустимость резервного канала.
  • Назначить владельца согласий и отписок: разрешённость сервисного письма и рекламной подписки проверяется раздельно перед отправкой.
Границы сценария

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

  • Страница разработчиков не раскрывает схемы подписи, ID, повторов и лимитов.
  • Email, SMS/SMPP и Telegram Gateway — разные интерфейсы; поддержка одного не подтверждает другой.
  • Почтовый результат не подтверждает выдачу, платёж или приёмку возврата; условия региона уточняются.
  • Запрет email-канала не обходится сменой API на SMTP; решение о допустимом контакте принимает продавец. Перенос российских условий на другие страны требует отдельной проверки.
Стоимость и запуск

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

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

Для оценки выберите Email API или SMTP NotiSend и подготовьте пример письма, отказа и обратного события по одному складскому заказу.

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

Как узнать о недоставленном письме?

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

Что делать при повторном обратном уведомлении?

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

Можно отправить через API и SMTP одновременно для надёжности?

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

Telegram Gateway подходит для текста о готовности заказа?

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

Покупатель отписался от рекламы — можно автоматически отправить другой текст?

Сначала определяем назначение конкретного письма и проверяем ограничения канала. Сервисный повод не добавляет рекламного согласия, а смена API на SMTP не снимает запрет отправки. Неясный случай передаём ответственному продавца.

Что сообщать при частичном возврате?

Только подтверждённые складом позиции и этап возврата. Приём товара и возврат денег — разные события; уведомление об оплате отправляется после подтверждения платёжной системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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