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

Skirbo +
Unisender

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

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

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

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

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

Клиент, заказ, склад, версия шаблона и минимальный контакт; точные API поля проверяются.

Результат письмаUnisender → SkirboОбсудим в составе подключения

Внешний ID и доступные состояния, отдельно от факта выдачи.

Контакты / списокПродавец ↔ UnisenderОбсудим в составе подключения

Только при необходимости выбранного продукта; назначение списка и подписки согласуются отдельно.

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

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

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

Для продавца, который сообщает о готовности заказа к самовывозу, и фулфилмента, работающего с разными брендами и площадками. Рассматривается API Unisender, в котором отдельно описаны контакты, сообщения и кампании. Продукт и метод для сервисного письма нужно выбрать до настройки; маркетинговая подписка не возникает из заказа автоматически. Для sendEmail согласуется отдельный список служебных уведомлений: техническое добавление контакта в него не должно запускать рекламные цепочки. Unisender Go рассматривается отдельно.

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

Восстановленный указатель API дополнен прочитанными спецификациями sendEmail, checkEmail и webhook. Рассматривается этот путь Unisender API; для Unisender Go потребуется отдельная проверка. Прочитанная схема ещё не подтверждает права аккаунта и действующее подключение Skirbo.

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

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

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

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

Письмо о готовности к самовывозу

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

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

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

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

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

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

Контакт и подписка как разные решения

Задача: Не загружать клиентскую базу ради одного письма.

Когда начинается: Магазин передаёт новый контакт вместе с заказом.

  1. Определить минимальные данные и назначение контакта; хранить выбор каналов у продавца.
  2. Выбрать подходящий способ отправки, проверив, нужен ли вообще контакт в списке Unisender.
  3. Если список нужен, согласовать его назначение, обновление и отписку отдельно от сервисного события.

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

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

  • Изменение email не должно объединять заказы разных клиентов по одному имени.

Перенос выдачи на другой склад

Задача: Управлять новой версией сообщения после изменения площадки.

Когда начинается: Продавец согласовал перенос готового заказа.

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

Результат: Покупатель не получает два противоречащих адреса без объяснения.

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

  • Редактирование текста старой записи не меняет уже отправленное письмо.

Отмена, возврат и разбор неясной отправки

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

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

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

Результат: У каждой попытки есть объяснимая судьба; письмо о готовности не возобновляется после отмены.

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

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

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

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

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

  • Какой продукт и метод отправляют сервисное письмо без лишней кампании?
  • Какие состояния доступны и что они означают?
  • Кто отменяет устаревшие уведомления при переносе склада?
  • Кто владеет служебным списком и проверит, что добавление контакта не запускает рекламу?
  • Какой подтверждённый отправитель разрешён каждому бренду и кто остановит отправку при потере доступа?
  • Кто разбирает потерянный ответ, отписку и поздний результат после отмены или возврата заказа?
Перед оценкой

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

  • Выбранный продукт Unisender и подтверждённый метод сервисного письма.
  • Отправитель каждого бренда, адреса площадок и версия шаблона.
  • Правила актуальности события, обработки отказа и владельца рассылки.
  • Администратор продавца предоставляет серверный доступ к API; секрет хранится отдельно от карточек заказов, текста письма и журнала ошибок.
  • Владелец коммуникаций утверждает служебный список, исключает подключённые к нему рекламные цепочки и ведёт отдельные основания для маркетинга.
  • Ответственный за эксплуатацию задаёт очередь, бюджет повторов, срок актуальности и сверку результата; тарифные лимиты проверяются в своём аккаунте.
Границы сценария

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

  • Контракты sendEmail/checkEmail и webhook прочитаны; остаются проверка прав аккаунта, доступности выбранного продукта, обработки отказов и приёмка на разрешённых тестовых адресах.
  • Методы кампаний, контактов и отдельных сообщений не взаимозаменяемы; иной продукт бренда проверяется отдельно.
  • Доставка письма не подтверждает выдачу товара; география и права аккаунта уточняются по выбранному продукту.
  • Техническое наличие контакта в списке и отдельное согласие на рекламу — разные данные. Старые сценарии ниже предполагают, что служебный список не запускает маркетинг.
  • Отправленное письмо нельзя считать отозванным после отмены заказа. Проект отменяет собственную неотправленную очередь и отдельно решает, нужно ли уточняющее сообщение.
  • Полное подавление дублей сервером не установлено: уникальный ref_key не заменяет собственный журнал попыток и разбор неопределённого результата.
Стоимость и запуск

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

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

Выберите одно событие самовывоза, продукт Unisender и два склада с разными адресами — на них проверим шаблон и обработку изменений.

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

Можно отправлять письмо о готовности заказа?

Рассмотрим отдельное событие готовности и сервисный шаблон; подписка на рекламные рассылки не создаётся из складского события.

Можно использовать один шаблон для всех складов?

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

Нужно ли создавать кампанию на каждый заказ?

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

Что делать с письмом, если заказ перенесён?

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

Добавит ли sendEmail покупателя в список?

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

Можно перенести настройки Unisender Go в эту схему?

Сначала требуется отдельная проверка Go, его аккаунта, API или SMTP и событий результата. Прочитанный контракт sendEmail относится к рассматриваемому Unisender API и не доказывает те же свойства Go.

Нужно ли повторять письмо при любом ошибочном статусе?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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