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

Skirbo +
Jivo

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

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

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

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

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

Подтверждён setUserToken; выдача токена следует после авторизации кабинета.

Контекст отгрузкиSkirbo / оператор → диалогОбсудим в составе подключения

Предлагается выдавать проверенный ответ только в пределах прав клиента.

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

Человеческое согласование, не доказанный API изменения заказа.

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

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

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

Рассматривается виджет Jivo и его JWT-идентификация посетителя для синхронизации истории. Это узкая тема обращения из авторизованного кабинета продавца или клиента фулфилмента; импорт заказов, остатки и складские команды по API Jivo источником не подтверждены.

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

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

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

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

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

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

Разобрать вопрос об отгрузке из кабинета клиента

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

Когда начинается: Авторизованный сотрудник продавца открывает чат по своей отгрузке.

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

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

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

  • Недоступность Jivo не считается отменой складского задания; вопросы остаются в согласованном резервном процессе.

Продолжить диалог с другого устройства

Задача: Сохранить связь истории с авторизованным человеком.

Когда начинается: Сотрудник клиента переходит с рабочего компьютера на телефон.

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

Результат: История относится к человеку, а не только к локальному хранилищу браузера.

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

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

Развести сотрудников одного продавца

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

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

  1. Выбрать уникальный ID сотрудника и отдельно хранить его клиентскую принадлежность.
  2. Оператор получает только разрешённый контекст выбранного склада.
  3. После отзыва доступа прекращается выдача токена этому пользователю и проверяется обработка старой сессии.

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

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

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

Сменить пользователя на общем складском терминале

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

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

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

Результат: Вход другого человека не наследует доступ к чужому заказу и диалогу.

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

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

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

ДанныеОтветственный источникПравило обмена
Личность и праваКлиентский кабинетJWT чата не заменяет проверку принадлежности заказа.
Заказ, SKU, остатокУчётная система / SkirboЧат не становится источником резервов и количеств.
История диалогаJivoСвязывается с посетителем и каналом.
Статус отгрузки и документыСклад / учётная системаОператор сообщает проверенные факты, доступ к документу проверяется отдельно.
ВозвратПродавец и складПросьба в чате ещё не принятый возврат и не финансовая операция.
Посетитель, сотрудник и компанияСервер кабинета клиентаID посетителя принадлежит человеку в согласованной области сайта и канала; его компания, права и доступные заказы проверяются отдельно.

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

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

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

  • Авторизованный кабинет, стабильный ID пользователя и разделение клиентских прав.
  • Канал Jivo с согласованным secret и серверная выдача токена.
  • Регламент общего устройства, выхода, отзыва доступа и проверки истории.
Границы сценария

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

  • Прочитана JWT-инструкция, не API заказов или WMS.
  • В исходном тексте некорректно описано присутствие secret внутри токена; секрет нельзя раскрывать клиенту.
  • События виджета не подтверждают физическую отгрузку, приёмку или доступ ко всем заказам.
Стоимость и запуск

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

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

Кто общается через кабинет: продавец, сотрудник клиента или покупатель, и какую историю ему разрешено видеть?

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

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

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

Нужно ли положить secret в токен?

Нет. В предлагаемой архитектуре секрет остаётся на сервере и используется для подписи. Неточное объяснение в исходной статье не переносится в реализацию.

Чат может отменить отгрузку?

Сам текст сообщения не является подтверждённой командой складу. Отмену проводит уполномоченный сотрудник после проверки фактической стадии выдачи.

История с другого устройства всегда доступна?

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

clearHistory удаляет историю у операторов?

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

Если разговор о возврате повторился, будет второй возврат?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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