Коротко: Путь клиента автосервиса состоит минимум из пяти узлов, каждый со своим набором переменных и точками ветвления. Линейный скрипт с фиксированным порядком вопросов ломается уже на втором узле, где ответ клиента определяет, какой вопрос задать дальше. Ключевые переменные — марка/модель, характер проблемы, предпочтительное время, статус ремонта — должны сохраняться между узлами, а не собираться заново. Закрытие наряда — не конец диалога, а точка, откуда логично инициировать следующий цикл (отзыв, следующее ТО).
Диалог с клиентом автосервиса редко идёт по прямой линии «вопрос — ответ — следующий вопрос». Уже на этапе первичного обращения ответ клиента определяет, какая ветка сценария активируется дальше: плановое ТО ведёт к одному набору вопросов, авария и работа со страховой — к совершенно другому, а повторное обращение по уже знакомой машине вообще не требует части вопросов, заданных новому клиенту.
Узел 1: классификация обращения
Первая задача агента — определить тип обращения, прежде чем задавать любые уточняющие вопросы. Если сразу пытаться выяснить время визита, не разобравшись, обычное это ТО или страховой случай, диалог рискует собрать не те данные и потребовать повторного уточнения.
| Тип обращения | Что нужно узнать дальше |
|---|---|
| Плановое ТО | Марка/модель, примерный пробег или дата последнего визита |
| Внезапная поломка | Характер симптома, срочность, наличие возможности доехать своим ходом |
| Страховой случай (ОСАГО/КАСКО) | Номер полиса, фото повреждений, тип полиса — чек-лист документов отличается от обычного визита |
| Повторное обращение | Сверка с историей клиента — часть данных уже известна и не запрашивается заново |
Узел 2: сбор данных о машине и проблеме
После классификации агент запрашивает только те переменные, которые релевантны конкретной ветке. Здесь важно не собирать избыточные данные «на всякий случай» — каждый лишний вопрос увеличивает вероятность, что клиент бросит диалог до записи.
- Для нового клиента: марка, модель, год выпуска, характер проблемы своими словами
- Для повторного клиента: сверка по сохранённым данным, уточнение только новой информации
- Для страхового случая: параллельный сбор документов чек-листом, специфичным для типа полиса
Узел 3: подбор времени и поста
Этот узел требует связи с реальным расписанием сервиса, а не абстрактного «когда вам удобно». Агент должен предлагать конкретные свободные слоты с учётом типа работы — диагностика, шиномонтаж и кузовной ремонт занимают разное время поста и требуют разного оборудования.
Узел 4: подтверждение и напоминание
После записи диалог не завершается — логично зафиксировать точку для будущего напоминания (за день до визита) и, если применимо, отдельно инициировать сбор недостающих данных (например, донести документы по страховому случаю до даты визита).
Узел 5: закрытие наряда и следующий цикл
Выдача автомобиля — не финальная точка диалога, а начало следующего цикла: запрос отзыва в момент удовлетворённости, фиксация даты для будущего напоминания о плановом ТО, при необходимости — предложение реферальной ссылки. Каждый из этих шагов использует переменные, накопленные на предыдущих узлах (марка, характер визита, оценка удовлетворённости).
Почему линейный скрипт не подходит для этой схемы
Скрипт с фиксированной последовательностью вопросов предполагает, что каждый клиент проходит один и тот же путь. Но уже на первом узле путь расходится минимум на четыре ветки, а внутри каждой ветки есть собственные точки выбора (нашёлся ли VIN в базе партнёрских продаж, хватает ли документов по страховому случаю, свободен ли предпочитаемый слот). Жёсткий порядок вопросов в такой структуре либо требует отдельного скрипта на каждую комбинацию условий, либо начинает задавать нерелевантные вопросы, теряя доверие клиента.
В нелинейной модели узлы диалога связаны не жёсткой последовательностью, а условиями перехода — какой вопрос задать дальше, зависит от накопленных на предыдущих шагах переменных, а не от номера шага в скрипте. Такую логику для конкретного автосервиса не обязательно проектировать вручную с нуля: в конструкторе Aigine её можно описать текстом — какие узлы нужны, какие переменные собирать на каждом — и агент соберёт рабочую схему сценария. Подробнее о том, почему именно нелинейная структура нужна уже на этапе первого узла — в статье про сценарии vs кнопочные меню.
Соберите похожий сценарий для своего автосервиса
Опишите задачу текстом — платформа Aigine соберёт рабочий сценарий диалога с учётом ваших процессов.
Частые вопросы
Нужно ли проектировать все пять узлов сразу или можно начать с части?
Разумно начинать с узлов, закрывающих основной поток обращений (классификация + запись), и добавлять специализированные ветки (страховой случай, флотовые клиенты) по мере роста нагрузки на конкретный тип обращения.
Как хранятся переменные между узлами диалога?
Переменные, собранные на одном шаге (марка машины, тип обращения), должны быть доступны на последующих шагах того же диалога — без этого агенту придётся переспрашивать уже названные данные.
Что происходит, если клиент отвечает не по ожидаемому шаблону?
Нелинейный сценарий должен уметь распознать намерение из свободного текста, а не требовать точной формулировки — это отличает диалоговый подход от кнопочного меню с фиксированными вариантами ответа.