Интернет-магазин в пик: как спроектировать помощь агентом, не обещая чудес

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

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

Разделите вопросы по типу истины

Первый класс — статичные правила: сроки акции, условия промокода, география доставки, порядок возврата. Они должны приходить из канонической базы знаний. AiHummer может искать по документам и возвращать ссылки; документация по RAG напоминает, что точность зависит от качества источника, индексации и модели. Перед пиком назначьте владельца каждому документу, дату вступления и срок снятия. Старую политику нельзя оставлять рядом с новой без явного приоритета.

Второй класс — динамическое состояние: оплачен ли заказ, где посылка, доступен ли размер, применился ли возврат. Ответ должен приходить из OMS, CRM, каталога или API логистики, а не из памяти диалога. Если источник недоступен или данные старые, агент сообщает ограничение и создаёт обращение. Фраза «заказ уже едет» без подтверждённого статуса хуже честного ожидания.

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

Проектируйте очередь до нагрузки

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

Для каждой очереди задайте предел. Сколько одновременных запросов выдерживает нижестоящая система? Какой тайм-аут? Что делать при 429 или 5xx? Очередь должна иметь ограниченную ёмкость, иначе перегрузка просто переместится в память процесса. При заполнении система честно предлагает позже повторить или регистрирует обращение, если такой канал настроен. Нельзя обещать время ответа без измеренного SLO и рабочего расписания команды.

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

Нагрузочный тест должен напоминать реальность

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

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

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

Подготовьте контент и людей

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

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

Как оценивать бизнес-эффект

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

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

Ограничения

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

Чек-лист перед акцией

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

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