Бот для статуса заказа: как настроить чат-бота по данным магазина

Покупатель спрашивает «где заказ», сотрудник открывает учётную систему, ищет запись и пересказывает её статус. Когда такие обращения повторяются, бот может снять часть ручной работы. Но он должен отвечать по данным магазина, а не угадывать этап доставки по формулировке вопроса.

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

Когда нужен бот для статуса заказа

Бот полезен, если поддержка регулярно отвечает на однотипные вопросы: принят ли заказ, передан ли он на сборку, отправлен ли перевозчику, готов ли к выдаче. Он получает подтверждённый статус, переводит его на понятный язык и сообщает следующий шаг. Например: «Заказ передан в доставку. Номер отправления появится после ответа перевозчика».

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

Боту можно поручить:

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

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

Как выбрать канал и тип бота

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

Фиксированного сценария достаточно, когда пользователь нажимает «Узнать статус», вводит известные поля и получает один из заранее подготовленных ответов. Такой вариант проще проверять: допустимые переходы перечислены заранее.

ИИ можно использовать для понимания свободной фразы — например, чтобы распознать «когда привезут» как вопрос о доставке. Модель не должна выбирать статус по догадке. После распознавания намерения обычная интеграция проверяет пользователя и запрашивает запись в системе магазина. Если уверенного соответствия нет, бот уточняет вопрос или зовёт оператора.

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

Как построить диалог с проверкой пользователя

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

Последовательность выглядит так:

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

До подтверждения нельзя показывать имя получателя, адрес, состав покупки, стоимость или сам факт существования конкретного заказа. Нейтральный ответ — «Не удалось подтвердить доступ. Проверьте данные или обратитесь в поддержку» — не раскрывает, какой именно признак не совпал.

Источник статуса и актуальность

В ответе полезно отделить состояние заказа от прогноза. «Передан перевозчику в 14:20» — значение из источника. «Приедет завтра» — отдельное обещание, для которого нужен подтверждённый расчёт или ответ службы доставки. Если такого источника нет, бот сообщает только известный этап.

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

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

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

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

Откуда брать достоверный статус

Источником служит система, в которой магазин ведёт исполнение заказа: CRM, система управления заказами, складской или другой учётный контур. Бот обращается к ней через доступный интерфейс программирования приложений (API) либо читает согласованную выгрузку. Выгрузке нужны владелец, расписание обновления и правило действий при задержке.

До разработки составьте словарь статусов. Внутренние значения вроде packed, handover_pending или «Резерв 2» нужно сопоставить с понятными ответами. Для каждого значения укажите:

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

Модель может переформулировать разрешённое объяснение, если это проверено в проекте, но не является источником факта. При отсутствии записи она должна сообщить о нехватке данных, а не выбирать наиболее вероятный этап.

Как устроена интеграция

Чат-бот статуса заказа связывает интерфейс разговора с правилами доступа и рабочим источником. Учебная последовательность без привязки к конкретному магазину выглядит так:

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

Telegram Bot API официально описан как HTTP-интерфейс для разработки ботов. Документация n8n отдельно перечисляет операции Telegram-узла, включая отправку и изменение сообщений. Эти источники подтверждают возможности указанного канала и узла, но не наличие готового подключения к системе конкретного магазина. Его API, права и формат ответа нужно проверять отдельно.

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

Проверенный ответ

После успешного запроса бот формирует ответ только из разрешённых полей. Полезный шаблон содержит три части: текущий этап, время обновления и следующее подтверждённое действие. Например: «Заказ передан на сборку. Статус обновлён сегодня в 12:40. Мы сообщим отдельно, когда он будет готов к выдаче».

Неизвестный статус и передача оператору

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

Что делать при ошибке и исключении

Для исключений нужны заранее написанные ответы и действия системы. Фраза «Попробуйте позже» без регистрации обращения оставляет клиента один на один со сбоем.

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

Несколько заказов. После проверки пользователя бот показывает безопасный выбор — например, обезличенные номера и даты — либо просит уточнить идентификатор. Не следует угадывать, какой заказ имелся в виду.

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

Возврат. Статусы «запрошен», «принят», «получен складом» и «деньги отправлены» означают разные события. Их нельзя объединять в общее «возврат оформлен», если это создаёт ложное ожидание.

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

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

Как запустить пилот и измерить результат

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

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

Синтетический пример отрицательных проверок:

• Пользователь вводит номер чужого заказа. Ожидание: бот не подтверждает наличие заказа, ничего о нём не раскрывает и предлагает безопасный следующий шаг.
• Запись обновлялась раньше допустимого для процесса времени. Ожидание: бот показывает, что сведения устарели, не придумывает срок доставки и передаёт запрос оператору.
• Учётная система не отвечает. Ожидание: бот не выдаёт старое значение за текущее, фиксирует ошибку и объясняет, как продолжится обработка.

Это учебные данные и ожидаемое поведение, а не клиентский кейс или результат внедрения Switch On AI.

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

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

Когда требования понятны, Switch On AI может помочь спроектировать и проверить чат-бота под рабочий процесс: определить канал, правила доступа, подключение к источнику и передачу оператору.

Что влияет на стоимость и сопровождение

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

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

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

В проекте также нужно определить, кто следит за ошибками, обновляет формулировки и проверяет работу после изменения API или бизнес-правила. Сопровождение не возникает автоматически вместе с разработкой — его состав согласуют отдельно.

Чтобы оценить применимость решения, обсудите процесс со Switch On AI. Для первого разговора достаточно описать канал, источник статуса и три обезличенных примера: обычный заказ, спорный случай и недоступную систему. Пароли и данные покупателей отправлять не нужно.