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

Skirbo +
Omnidesk

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

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

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

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

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

Предлагается внутренняя заметка с проверенным автором и привязкой к case_id.

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

Подтверждены файлы и attachment_urls; доступность и состав проверяются.

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

Сохранить message_id и признак note; прочтение человеком подтверждается отдельно.

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

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

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

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

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

Подтверждены метод заметки и чтение сообщений обращения. Текущий пример использует note, однако имя поля автора в примерах расходится; перед реализацией нужен согласованный тестовый контракт. Наличие метода не означает готовность Skirbo.

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

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

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

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

Передать результат пересчёта в обращение

Задача: Не отправить покупателю неподтверждённую внутреннюю версию расхождения.

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

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

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

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

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

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

Задача: Приложить материал, который относится к конкретному месту.

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

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

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

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

  • Ссылка, недоступная серверу Omnidesk, не считается доставленным файлом.

Добавить позднее уточнение без переписывания истории

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

Когда начинается: После первого ответа найдено дополнительное подтверждение.

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

Результат: Уточнение видно как новое доказательство.

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

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

Сверить заметку после потерянного ответа

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

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

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

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

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

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

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

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

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

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

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

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

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

  • В архивных примерах было расхождение note/message; текущий curl использует note. Различие staff_id/note_staff_id сохраняется, поэтому рабочее тело и права автора проверяются отдельно.
  • Не заявлены webhook, гарантированная доставка сотруднику или готовый коннектор Skirbo.
  • Цифры ограничения файлов в сохранённом документе требуют актуальной проверки перед загрузкой.
Стоимость и запуск

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

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

Какое обращение и какой сотрудник поддержки должны получать внутренний результат складской проверки?

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

Заметка и ответ покупателю — одно и то же?

Нет. Здесь проектируется внутренняя заметка. Клиентский ответ должен быть отдельным подтверждённым действием поддержки.

Что доказывает message_id?

Что есть идентификатор записанного сообщения, если ответ проверен. Он не доказывает прочтение и согласие сотрудника с выводом.

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

В тексте можно сохранить фактическое время проверки. Использование created_at меняет обработку правил по документации и требует отдельного решения.

Как избежать дублей после таймаута?

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

Исправлено ли расхождение note/message в документации?

В текущем примере добавления заметки используется note. Однако примеры поля автора всё ещё расходятся: staff_id и note_staff_id. Рабочее тело и права автора требуют отдельной проверки.

Достаточно перечитать последние сообщения для защиты от дубля?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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