Коротко: Кнопочное меню предполагает, что клиент точно попадает в одну из заранее предусмотренных категорий. Реальное обращение часто содержит сразу несколько типов информации в одном сообщении, которые кнопочная структура вынуждена разбирать по одной за раз. Свободный текст с распознаванием намерения обрабатывает такое сообщение за один шаг вместо пяти последовательных нажатий. Кнопки остаются уместны для узких, действительно ограниченных выборов — но не как основной интерфейс всего диалога.
Кнопочное меню в чат-боте хорошо работает, когда у клиента чётко ограниченный выбор — «да/нет», «выбрать дату из трёх вариантов». Проблема возникает, когда реальное обращение клиента не укладывается в предусмотренную последовательность кнопок, потому что несёт сразу несколько единиц информации в одном сообщении.
Один и тот же запрос в двух подходах
Рассмотрим типичное обращение: «Здравствуйте, у меня Kia Rio 2019 года, стучит что-то в передней подвеске при повороте, можно на завтра после обеда?». В этом сообщении уже содержится марка, модель, год, симптом, предпочтительное время. Кнопочный сценарий не умеет извлечь всё это из одного сообщения — ему нужно провести клиента через последовательность отдельных вопросов.
Клиент: Здравствуйте, у меня Kia Rio 2019, стучит в передней подвеске при повороте, можно на завтра после обеда?
Бот: Здравствуйте! Выберите тип обращения: 1) Плановое ТО 2) Диагностика проблемы 3) Шиномонтаж
Кнопочный сценарий проигнорировал всю уже предоставленную информацию и вернул клиента к началу стандартной последовательности — теперь ему нужно заново вводить марку, год, описывать симптом отдельным сообщением и только потом добраться до вопроса о времени, которое он уже назвал в первом сообщении.
Клиент: Здравствуйте, у меня Kia Rio 2019, стучит в передней подвеске при повороте, можно на завтра после обеда?
Бот: Здравствуйте! Записал: Kia Rio 2019, диагностика стука в передней подвеске. На завтра после обеда свободны слоты 14:00 и 16:00 — какой удобнее?
Сценарий с распознаванием свободного текста извлёк все переменные из одного сообщения и сразу перешёл к финальному шагу — подтверждению времени. Разница не в «более умном» интерфейсе ради красоты, а в количестве шагов, которое реально нужно клиенту, чтобы записаться.
Когда кнопки всё же уместны
- Финальный выбор из ограниченного набора вариантов — например, выбор конкретного времени из предложенных слотов
- Подтверждение действия («да, записать» / «нет, показать другие варианты»)
- Быстрая навигация по меню, когда клиент ещё не сформулировал запрос текстом
Кнопки и свободный текст не исключают друг друга — рабочая конфигурация обычно сочетает оба подхода: возможность написать запрос своими словами в любой момент, с кнопками для финального подтверждения выбора, а не как единственный способ навигации по всему диалогу.
Почему это особенно критично для автосервиса
В отличие от, например, записи в парикмахерскую, где обращение почти всегда однотипно («хочу записаться на стрижку»), обращение в автосервис изначально неоднородно по структуре — клиент может начать с симптома, с марки машины, со срочности, с вопроса о цене. Жёсткая последовательность кнопок предполагает, что все клиенты формулируют запрос в одном и том же порядке, что на практике не так.
Настройка сценария, способного распознавать свободный текст и извлекать из него нужные переменные независимо от порядка изложения, требует другого подхода к проектированию диалога — не последовательности экранов, а условий распознавания намерения. В конструкторе Aigine такую логику можно задать текстовым описанием, не прописывая вручную все возможные комбинации порядка информации в сообщении клиента. Какие именно переменные стоит извлекать из такого сообщения — марку, симптом, время — разобрано в статье о данных клиента автосервиса.
Соберите похожий сценарий для своего автосервиса
Опишите задачу текстом — платформа Aigine соберёт рабочий сценарий диалога с учётом ваших процессов.
Частые вопросы
Не сложнее ли настраивать сценарий со свободным текстом, чем кнопочное меню?
Первичная настройка действительно требует описания того, какие намерения и переменные важны — но результат работает для всех вариаций формулировки клиента, а не только для точного порядка, предусмотренного в меню.
Что если клиент всё же предпочитает нажимать кнопки, а не печатать текст?
Рабочий сценарий должен поддерживать оба варианта одновременно — клиент, предпочитающий кнопки, может использовать их там, где они предложены, не теряя возможности написать текстом в любой момент.
Как сценарий понимает, что стук в подвеске — это диагностика, а не плановое ТО?
Это вопрос распознавания намерения по ключевым словам и контексту сообщения — задача, которую решает языковая модель, а не жёсткое сопоставление с фиксированным списком фраз.