Статус заказа без догадок: отвечаем только из системы учёта

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

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

Назначьте единственный источник состояния

Определите систему, которая отвечает за жизненный цикл заказа: магазин, ERP, складская программа или агрегатор доставки. CRM может хранить контакт, а чат — историю, но это не делает их источником фактической отгрузки. Если статусы распределены между системами, задайте правила приоритета и время последнего обновления.

Составьте словарь внутренних кодов. packed может означать, что упаковка завершена, но посылка ещё на складе. Созданный трек-номер не доказывает приём перевозчиком. Пользовательский текст должен отражать именно подтверждённое событие: «заказ подготовлен; подтверждения передачи перевозчику пока нет».

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

Проверьте право видеть заказ

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

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

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

Соберите ответ из наблюдаемых фактов

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

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

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

Моделируемый сценарий

Покупатель пишет в авторизованном чате: «Заказ уже у курьера? В приложении давно ничего не меняется». Система находит заказ по привязанной сессии. В магазине стоит этап «передан в службу доставки», а у перевозчика — «принят на сортировке»; назначение курьера отсутствует.

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

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

Обработайте исключения до запуска

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

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

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

Что измерять и как начать

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

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

Первое следующее действие — составить таблицу внутренних статусов и честных фраз для клиента. Рядом укажите запрещённые выводы и источник времени. Такая таблица важнее обещания «бот знает всё»: она делает ответ проверяемым даже тогда, когда внешняя система молчит.

Контроль источника ответа

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

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

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

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