Если остатки обновляются с задержкой, ИИ-агенту Aimylogic нужно показывать не безусловное обещание, а статус с пояснением, когда его проверили. Для этого задайте правила ответа: какие данные считать актуальными, как формулировать сомнение и когда передавать вопрос сотруднику. В статье разберём схему, которую можно адаптировать под магазин или небольшую компанию в Беларуси, и покажем, как проверить ответы до запуска.
Почему агент не должен обещать наличие по устаревшим данным?
Остаток в таблице или CRM показывает состояние на момент последнего обновления. За это время товар могли купить, зарезервировать или переместить. Если агент отвечает «есть в наличии», опираясь на старую запись, клиент может приехать или оформить заказ, а товар уже окажется недоступен.
Сначала выясните, откуда поступают сведения о товаре и как часто они обновляются. Запишите для каждого источника название, время последней синхронизации и доступные статусы. Если система не передаёт время обновления, агенту сложнее отличить свежую запись от устаревшей. В таком случае безопаснее отвечать, что наличие нужно подтвердить.
Полезно разделить ответы на три ситуации: данных достаточно для уверенного ответа, запись устарела или сведения отсутствуют. Каждой ситуации назначьте отдельный текст. Например, при старой записи агент может сообщить, что информация требует проверки, и предложить связаться с сотрудником.
Подготовить формулировки и переходы между ними помогают сценарии для частых вопросов клиентов в Aimylogic.
Как определить, когда сведения ещё актуальны?
Правило актуальности зависит от того, как быстро меняются остатки. В небольшой точке продаж обновление после каждой покупки даст более свежую картину, чем ручная выгрузка по расписанию. Если связать системы так нельзя, задайте внутреннее правило: запись считается пригодной для ответа только в пределах согласованного периода. Этот период должен соответствовать реальному графику обновления данных.
Попросите сотрудника, который отвечает за товарный учёт, определить источник истины и частоту обновления. Затем зафиксируйте правило в сценарии: при свежей записи агент сообщает статус, при просроченной — не подтверждает наличие, при пустой — просит уточнение или передаёт диалог человеку. Время и порог актуальности выбирает бизнес, универсального значения для всех магазинов нет.
Если данные приходят из нескольких мест, установите приоритет. Например, запись из системы, где сотрудник подтверждает резерв, может быть важнее общей таблицы. Не смешивайте остаток и доступность для заказа: товар на складе может быть зарезервирован или недоступен для выбранного способа получения.
Как настроить ответ агента для разных статусов?
Для каждого статуса подготовьте короткий ответ и следующий шаг. Агенту нужны не только слова, но и понятное действие: уточнить вариант товара, предложить проверку сотрудником или принять запрос на уведомление. Сложные условия лучше описывать отдельно и проверять на примерах.
| Ситуация | Что сообщает агент | Следующий шаг |
|---|---|---|
| Запись свежая, товар доступен | Называет статус и уточняет нужный вариант товара | Продолжает оформление или отвечает на следующий вопрос |
| Запись устарела | Говорит, что наличие нужно подтвердить | Передаёт вопрос сотруднику или предлагает оставить запрос |
| Данных нет | Не делает вывод о наличии | Просит уточнить товар или направляет диалог сотруднику |
| Статусы расходятся | Сообщает, что требуется дополнительная проверка | Передаёт диалог человеку |
Не просите агента угадывать остаток по похожим товарам или прошлым диалогам. Для ответа используйте только согласованный источник. Если агент не может прочитать дату обновления или статус резерва, предусмотрите передачу сотруднику.
Для вопросов с несколькими условиями пригодится база знаний чат-бота Aimylogic. В ней можно подготовить понятные ответы на уточнения о цвете, размере или варианте получения, а статус наличия оставить отдельной проверке.
Как проверить сценарий до запуска?
Соберите примеры из реальных вопросов клиентов и проверьте каждый статус отдельно. В тестах должны быть свежая запись, устаревшая запись, пустое поле, расхождение источников и товар, который числится, но уже зарезервирован. Для каждого случая заранее запишите ожидаемый ответ. Так сотрудник сможет сравнить результат агента с правилом, а не оценивать его по впечатлению.
Проверьте и формулировки. Клиент должен понимать, подтверждено ли наличие и что ему делать дальше. Если фраза звучит как гарантия, хотя данные устарели, перепишите её. Если агент часто передаёт вопрос человеку, выясните, какой информации не хватает: времени обновления, статуса резерва или конкретного варианта товара.
После запуска просматривайте диалоги, где клиент переспрашивал о наличии или не завершил заявку. Такие случаи показывают, где ответ оказался слишком неопределённым или сценарий не предложил ясный следующий шаг. Подход к проверке вопросов для автоматизации описан в материале о том, какие вопросы клиентов передавать чат-боту.
Какие ошибки чаще всего мешают точному ответу?
- Агент сообщает остаток без времени последнего обновления.
- Сценарий считает любой товар в таблице доступным для заказа.
- Одинаковый ответ используется для пустых и устаревших данных.
- Сотруднику не передают вопрос, хотя источники показывают разные статусы.
- В тестах проверяют только наличие товара, но не резерв или вариант товара.
Начните с одного источника остатков и одного популярного сценария. Определите, когда запись считается актуальной, подготовьте ответы для свежих и сомнительных данных, затем проверьте их на примерах диалогов. Если правила зависят от нескольких систем или статусов, сначала опишите схему интеграции и передачи вопросов сотруднику, а потом настраивайте агента.
