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