Сервисный центр: ИИ на приёме заявки и в сообщениях о ремонте

Разговор до приёмки

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

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

Карточка без лишнего допроса

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

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

Цена и безопасность

Предварительную стоимость можно сообщать только по утверждённому правилу и с условиями. Не обещайте окончательную сумму ремонта по одному симптому. Даже похожее проявление может иметь разные причины и требовать разных деталей.

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

Статусы берут из учётной системы

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

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

Как избежать чужого статуса

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

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

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

Пилот на одной категории техники

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

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