Обсудить задачу
CRM

Skirbo +
Webim

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

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

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

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

ОперацияНаправлениеСостав и готовность
Идентификация и размещениеКабинет → WebimОбсудим в составе подключения

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

Состояние виджетаWebim → кабинетОбсудим в составе подключения

Использовать callbacks и status для интерфейса, не для статуса заказа.

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

Проектный процесс, не обещание server API обмена заказами.

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

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

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

Рассматривается visitor JavaScript API Webim: открытие чата, обработчики виджета и обновление идентификации. Источник прямо отделяет его от серверных Stored Data, Custom Channel и Realtime API. Для склада полезен управляемый контакт клиента с поддержкой на странице разрешённого заказа.

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

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

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

  1. Кабинет проверяет пользователя, клиента и разрешение на выбранный заказ. Объекты accountName, domain и при необходимости location соответствуют согласованному размещению Webim.
  2. Инициализировать выбранный режим виджета: в iframe требуется явная инициализация, в стандартном варианте её выполняет скрипт. Показать доступность поддержки по актуальному status.
  3. После действия пользователя открыть чат. Номер заказа передаётся только согласованным способом; операторы проверяют его принадлежность, а не доверяют произвольному тексту.
  4. Складской сотрудник выполняет требуемую проверку: например, сверяет количество грузовых мест перед выдачей. Результат и время фактической проверки остаются в складском учёте.
  5. Оператор сообщает клиенту подтверждённый вывод и фиксирует принятие обращения. Закрытие пользователем окна не означает закрытие диалога на сервере или завершение складской задачи.
  6. При смене пользователя обновить идентификацию и уведомить виджет; если авторизация не восстановлена, не показывать прежний контекст. Ошибка чата не должна повторно запускать складское действие.

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

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

Открыть обращение с разрешённой страницы заказа

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

Когда начинается: Клиент нажимает «Обсудить заказ» в своём кабинете.

  1. Кабинет проверяет пользователя, клиента и разрешение на выбранный заказ. Объекты accountName, domain и при необходимости location соответствуют согласованному размещению Webim.
  2. Инициализировать выбранный режим виджета: в iframe требуется явная инициализация, в стандартном варианте её выполняет скрипт. Показать доступность поддержки по актуальному status.
  3. После действия пользователя открыть чат. Номер заказа передаётся только согласованным способом; операторы проверяют его принадлежность, а не доверяют произвольному тексту.
  4. Складской сотрудник выполняет требуемую проверку: например, сверяет количество грузовых мест перед выдачей. Результат и время фактической проверки остаются в складском учёте.
  5. Оператор сообщает клиенту подтверждённый вывод и фиксирует принятие обращения. Закрытие пользователем окна не означает закрытие диалога на сервере или завершение складской задачи.
  6. При смене пользователя обновить идентификацию и уведомить виджет; если авторизация не восстановлена, не показывать прежний контекст. Ошибка чата не должна повторно запускать складское действие.

Результат: Клиент получает ответ по своему заказу, а UI чата не подменяет складской статус.

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

  • При занятых операторах интерфейс показывает реальное состояние без обещания мгновенного ответа.

Сменить аккаунт без перезагрузки страницы

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

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

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

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

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

  • Поддержка метода обновления токена зависит от версии сервера; источник указывает границу версии.

Показать занятость поддержки и продолжить складскую работу

Задача: Не блокировать приёмку из-за визуально закрытого или занятого чата.

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

  1. Использовать status из onInit; устаревший boolean online не различает все состояния.
  2. Предложить согласованный порядок обращения, оставляя складскую задачу в её собственном состоянии.
  3. После ответа оператор сверяет, не изменилась ли отгрузка за время ожидания.

Результат: Ожидание поддержки не скрывает актуальный складской факт.

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

  • Наличие callback не является гарантией SLA или получения сообщения конкретным сотрудником.

Обсудить отменённую отгрузку при повторном открытии чата

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

Когда начинается: Клиент снова открыл окно ранее начатого диалога, а заказ за время ожидания изменился.

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

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

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

  • Visitor JS API не объявляется API отмены заказа, возврата денег или смены складского резерва.

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

ДанныеОтветственный источникПравило обмена
Пользователь и праваКлиентский кабинетСмена аккаунта требует смены идентификации чата; право на просмотр заказа проверяет сервер кабинета.
ЗаказМагазин / OMS клиентаЗаказ и его версия остаются в системе клиента. Обсуждение в чате не меняет состав или разрешение выдачи без отдельного подтверждённого действия.
SKUКаталог / учётная система клиентаТоварные коды сопоставляются с каталогом владельца заказа; текст сообщения и вложение не создают новую товарную карточку.
Физический остаток и складской резервSkirboКоличество и резерв изменяются по подтверждённым складским событиям. Чат не создаёт резервов и складских движений.
Состояние окна и диалогаWebim; решение по обращению — поддержкаЗакрытие окна отличается от серверного завершения диалога. Завершение общения не подтверждает решение складской претензии.
ДокументыУчётная система клиентаУчётный владелец хранит принятые документы; поддержка проверяет приложенные копии. Файл в чате сам по себе не подтверждает документ или его приёмку.
ВозвратПродавец — разрешение; Skirbo / склад — физический фактПоддержка связывает обращение с решением продавца; склад отдельно подтверждает фактические SKU, количество и состояние возврата. Закрытие диалога не выполняет приёмку.
Связь размещения с клиентомАдминистратор Webim и сервер кабинетаaccountName/domain/location выбирают согласованный контур чата, а сервер кабинета независимо проверяет tenant, сотрудника, склад и заказ.

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

  • Есть ли смена пользователя без перезагрузки и общий терминал у сотрудников?
  • Какой статус поддержки должен видеть клиент при ожидании проверки склада?
Перед оценкой

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

  • Режим стандартного виджета или iframe, версия сервера и настройки размещения.
  • Выбранная схема авторизации, проверка входа/выхода и сопоставление клиентских прав.
  • Регламент ответа поддержки на складские вопросы и обработки очереди.
Границы сценария

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

  • Visitor JS API не заменяет серверные API; чтение истории и файлов не заявляется по этой статье.
  • Callback onInit подтверждает инициализацию, не приём сообщения оператором.
  • Срок ответа, тариф и готовая связь Skirbo не подтверждены.
Стоимость и запуск

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

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

Какой кабинет, режим виджета и круг клиентов должны получать поддержку по складским операциям?

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

Закрытие окна означает, что претензия решена?

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

Почему online=false, хотя операторы на месте?

В описании устаревший boolean равен true только для online и не отражает busy_online. Предлагается использовать строковый status.

Можно использовать этот API для скачивания документов?

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

Что происходит после выхода пользователя?

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

Можно разграничить продавцов только разными location?

Размещение относится к настройкам чата. Доступ к заказу определяет сервер кабинета по клиенту и пользователю; одного location для этого недостаточно.

Почему окно снова открылось, хотя мы его закрывали?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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