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

Skirbo +
Usedesk

Проектировать очередь складских инцидентов в Usedesk: недостача, расхождение возврата или ошибка упаковки создаёт внутреннее обращение для ответственной поддержки.

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

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

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

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

Предлагается create/ticket с private_comment и внешней связью события.

Клиент, группа и каналСправочник клиента → UsedeskОбсудим в составе подключения

Используются согласованные IDs; нежелательное создание/перепривязка компании исключается.

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

Проверять success и ticket_id; принятие поддержки отдельно от API-квитанции.

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

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

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

Рассматривается метод создания запроса Usedesk. Он позволяет задать тему, сообщение, клиента, группу, дополнительные поля и приватный первый комментарий. Для фулфилмента важна граница: регистрация инцидента не должна случайно отправить сообщение не тому клиенту или перепривязать его компанию.

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

Подтверждены POST создания запроса и POST /ticket для чтения по ticket_id в облаке; адрес коробочной версии уточняется у поддержки. Внешний ключ связи не гарантирует идемпотентность. Обновление, поиск потерянного ticket_id и события требуют отдельной проверки.

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

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

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

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

Зарегистрировать недостачу как внутренний инцидент

Задача: Довести проверенное расхождение до поддержки с правильным клиентом и ответственным.

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

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

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

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

  • Неверный ID исполнителя, клиента или канала направляет операцию на разбор до повторной записи.

Связать возврат и доказательства

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

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

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

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

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

  • Порядок field_id и field_value должен совпадать; неверный вариант списка не заменяется текстом.

Выделить разные сервисные команды

Задача: Не направлять инцидент одного клиента в чужой канал.

Когда начинается: Фулфилмент добавляет нового продавца.

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

Результат: У каждого клиента понятный маршрут поддержки.

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

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

Проверить фактический маршрут уже созданного запроса

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

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

  1. Сохранить исходный incidentId, клиента, склад, ожидаемый канал и возвращённый ticket_id; повторное создание запроса по этому событию не начинать.
  2. Прочитать отдельный запрос по ticket_id через документированный метод /ticket; применить согласованную проверку прав агента.
  3. Сверить client_id, company_id, channel_id и additional_id с разрешённым маршрутом. Дополнительный ID проверяется как связь события, без обещания идемпотентности.
  4. Проверить первый комментарий и область его видимости в разрешённом контуре. Статус отправки в канал не приравнивается к принятию инцидента ответственным.
  5. При верном маршруте передать ссылку назначенной группе; склад продолжает хранить собственный акт и не дублирует пересчёт.
  6. Ответственный подтверждает, что получил именно этот инцидент и комплект доказательств. Запрос, принятие и решение учитываются раздельно.
  7. Если канал или компания не совпали, сохранить расхождение и передать исправление администратору. Автоматический перенос, изменение компании и повторная отправка требуют отдельного контракта.

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

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

  • Если ticket_id потерян, этот метод не может найти его по additional_id; включается отдельная сверка, а не повторное создание.

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

ДанныеОтветственный источникПравило обмена
Заказ, SKU, остатокУчётная система / SkirboИнцидент не меняет резерв или отгрузку.
Клиент, компания и каналUsedesk / администратор клиентаТаблица ID проверяется перед записью, имя компании не универсальный ключ.
Статус инцидентаПоддержка UsedeskСоздан, принят и решён — разные подтверждения.
Документы и фотоСкладВложения связаны с актом и событием, доступ проверяется.
Возврат и компенсацияСклад / продавецФизическое поступление и финансовое решение остаются раздельными.
Связь складского инцидента и запросаSkirbo / журнал обменаЛокальный incidentId в области клиента и склада связывается с additional_id и ticket_id; связь не подменяет компанию или владельца канала.

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

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

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

  • API-канал и токен, список клиентов/групп, проверенный приватный режим.
  • Соответствия дополнительных полей и идентификаторов вариантов списков.
  • Регламент сверки неизвестного результата и запрет повторных клиентских сообщений.
Границы сценария

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

  • additional_id — поле связи, а не доказанный ключ идемпотентности.
  • Прочитан метод получения отдельного запроса по известному ticket_id. Поиск после потери ticket_id, обновление и события требуют отдельной проверки; сроки обработки и SLA не обещаются.
  • Примеры документации не должны переносить отключение проверки TLS в рабочую реализацию.
Стоимость и запуск

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

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

Какие инциденты требуют внутреннего запроса и как выбираются клиент, канал и группа поддержки?

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

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

Метод может создать компанию или перепривязать клиента. Для фулфилмента безопаснее заранее согласовать соответствия; изменение клиентского справочника должно быть отдельным решением.

Что будет при ошибке channel_id?

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

additional_id защищает от дубля?

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

Будет ли покупатель видеть первую запись?

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

Что можно проверить, когда ticket_id уже получен?

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

Можно исправить неверный канал повторным create/ticket?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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