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