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

Skirbo +
Chat2Desk

Рассмотрим связь обращения в Chat2Desk с заказом Skirbo. Оператор получает только разрешённые сведения о текущем этапе, задержке или принятом возврате и отвечает покупателю в его канале. Изменение заказа остаётся отдельным действием с проверкой полномочий.

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

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

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

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

Проверить источник, канал, клиента и оператора; сохранить ID сообщения/диалога и разрешённую связь с продавцом.

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

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

Ответ покупателюОператор / согласованный процесс → Chat2DeskОбсудим в составе подключения

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

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

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

Импортированная перепискаChat2Desk imported_message → история обращенияОбсудим в составе подключения

Учесть сообщения, отправленные вне чат-центра; не превращать импорт старой истории в новое обращение с автоматическим ответом.

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

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

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

Для службы поддержки магазина и фулфилмента, использующей Chat2Desk как чат-центр. Цель — быстро объяснять покупателю состояние его заказа и регистрировать запросы на изменение. Chat2Desk не назначается владельцем складского остатка, резерва, оплаты или факта возврата. Применимость каналов, доступа и размещения данных проверяется отдельно по продавцу и стране.

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

В официальных материалах описаны серверный API сообщений, вебхуки, внешние каналы, iframe и POST-запросы из операторских макросов. Для сценария можно оценить получение события обращения и ответ через API либо явный запрос оператора к разрешённой карточке заказа. Точные методы, токен, права и правила повторов берут из актуального контракта подключённого аккаунта. Старое вводное руководство не заменяет текущую схему API.

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

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

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

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

Оператор отвечает, где находится заказ

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

Когда начинается: Покупатель спрашивает о заказе в подключённом канале Chat2Desk.

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

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

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

  • Повтор одного вебхука не создаёт второй ответ.
  • Если профиль объединили или разделили, связь с заказом проверяют заново; история объединения не заменяет авторизацию.

Запрос на отмену, смену адреса или возврат

Задача: Довести обращение до ответственного, не выдавая разговор за выполненную операцию.

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

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

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

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

  • Два оператора не должны выполнить одно изменение дважды.
  • Фраза покупателя о возврате не создаёт приход товара и возврат платежа.

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

Задача: Сохранить контекст, когда сотрудник ответил напрямую в канале или история импортирована.

Когда начинается: В Chat2Desk появилось сообщение, импортированное из внешнего канала.

  1. Подписаться на доступное событие imported_message отдельно от обычных inbox/outbox и определить нужные каналы по актуальному контракту.
  2. Проверить подлинность, связать сообщение с диалогом и исходным внешним ID, сохранить его как импортированную историю с исходным временем.
  3. Исключить дубли уже полученного сообщения; не запускать новый автоматический ответ только потому, что старое сообщение импортировано.
  4. При пропуске сверить историю через согласованный API/отчёт аккаунта и вернуть оператору недостающий контекст. Только новое действующее обращение попадает в рабочую очередь.

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

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

  • Наличие inbox/outbox не гарантирует охват импорта.
  • Полученный HTML, ссылки и вложения не исполняются как команды и не меняют склад без отдельного разрешения.

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

ДанныеОтветственный источникПравило обмена
Заказ, строки, остаток и резервWMS и продавецЧат-центр получает только разрешённый статус; склад остаётся источником физического исполнения.
Клиент и связь с заказомCRM продавца / система авторизацииОбъединение диалогов Chat2Desk не подтверждает право видеть другой заказ.
Диалог, сообщение и каналChat2Desk / подключённый каналИдентификаторы используются для корреляции и истории; результат сообщения не является результатом заказа.
Права оператора и сценарий ответаВладелец поддержки продавцаОператор видит минимальный контекст и передаёт изменения уполномоченному исполнителю.
Согласия и назначение коммуникацииПродавец / владелец клиентских разрешенийСервисный ответ и рекламная рассылка оцениваются отдельно; наличие чата не даёт безусловного разрешения на рекламу.
Журнал обмена и защита от повторовАдаптер SkirboХранит связь события, запроса, версии данных и ответа; импорт отличается от нового обращения.

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

  • Какие каналы и компания Chat2Desk относятся к каждому продавцу?
  • Как оператор подтверждает принадлежность заказа и какие поля ему разрешены?
  • Используется серверный API, внешний канал или макрос с запросом контекста?
  • Как проверяются подпись, время и повтор вебхука; как восстанавливается импортированная переписка?
  • Какие действия требуют отдельного разрешения склада или продавца?
Перед оценкой

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

  • Аккаунт Chat2Desk продавца, подключённый разрешённый канал, актуальная документация API и нужные права оператора/токена.
  • Карта tenant → компания/канал Chat2Desk → клиент/диалог; процедура проверки принадлежности заказа и обработки объединённого профиля.
  • Разрешённый набор полей заказа, понятное время его актуальности и запрет выдачи данных других продавцов.
  • Проверка подписи и времени вебхука по текущему контракту, журнал повторов и восстановление пропусков; защита текста/вложений как входных данных.
  • Решение, используется ли API или макрос/карточка для оператора; для макроса проверяется весь передаваемый контекст и исключаются ненужные данные.
Границы сценария

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

  • Сообщение покупателя не является разрешением автоматически отменить заказ, заменить адрес, списать товар или вернуть деньги.
  • Единый профиль и связанные диалоги не дают права просматривать все заказы с похожим именем или контактом; правила идентичности и доступа задаются отдельно.
  • Подпись вебхука подтверждает источник только после корректной проверки. Заголовки, алгоритм канонизации, окно времени и повторы требуют актуального формального контракта.
  • Импортированную переписку нельзя восстановить только по inbox/outbox; imported_message имеет отдельную семантику и не запускает стандартные автоматизации.
  • Доставка или прочтение доступны не одинаково во всех каналах. Принятый API-запрос не доказывает вручение сообщения и не подтверждает исполнение заказа.
  • Текущие тарифы, квоты, условия канала и география не установлены для аккаунта. Публичное описание API не подтверждает готовый коннектор Skirbo.
Стоимость и запуск

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

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

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

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

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

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

Чат с просьбой об отмене сразу отменит заказ?

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

Объединённый профиль гарантирует, что заказы принадлежат одному человеку?

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

Почему часть сообщений не приходит в inbox/outbox?

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

Достаточно встроить Chat2Desk через iframe?

Iframe показывает интерфейс и требует входа в Chat2Desk. Связь с заказом, права на данные Skirbo и аудит ответов всё равно нужно настроить отдельно.

Можно автоматически повторять ответ при сетевой ошибке?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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