Будни цифрового офиса, выпуск 2

ИИ-диспетчер, как заявка перестаёт теряться

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

Задача формулируется не как «бот»

Соблазн понятен. Поставить чат-бота с кнопками. Но клиент, у которого потекла гидравлика, не хочет проходить меню из четырёх пунктов, он хочет написать «здравствуйте, экскаватор, стрела просела, что делать». Задача диспетчера не в том, чтобы вести человека по сценарию, а в том, чтобы из этой фразы получить рабочую карточку.

У карточки есть минимальный набор полей, без которого заявку нельзя считать заявкой.

• Кто. Контакт, по которому реально можно ответить.
• Направление. Спецтехника, котельные и ИТП или автоматизация. От этого зависит, кто отвечает.
• Суть. Объект или узел плюс характер проблемы, в двух строках и без воды.
• Следующий шаг. Что конкретно должно произойти дальше и с чьей стороны.

Что делает ИИ

Разбирает свободный текст и вытаскивает из него смысл. Понимает, что «стрела просела» значит гидравлику, а «не греет второй контур» значит ИТП. Определяет направление и предлагает маршрут. Задаёт уточняющие вопросы по списку, привязанному к направлению. Для гидроцилиндра это марка техники, узел и характер течи, а для котельной это тип котла, что именно не работает, есть ли доступ.

Дальше он собирает карточку и передаёт её человеку. Клиент при этом получает не «ваше обращение принято», а осмысленный ответ. Что мы поняли из его описания, чего не хватает и что будет дальше.

Чего он принципиально не делает

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

Не ставит диагноз. Может сказать, какие причины бывают у симптома и что стоит проверить, но формулировка «у вас изношены манжеты» до осмотра узла недопустима.

Три сбоя, которые пришлось лечить

• Вежливая пустота. Первая версия отвечала гладко и не двигала заявку. Клиент писал «течёт», система сочувствовала. Помогли обязательные уточняющие вопросы, привязанные к направлению, и запрет закрывать сообщение без вопроса или без действия.
• Переход на язык модели. Русскоязычная система на некоторых формулировках соскакивала на общий, «переводной» стиль, а клиенту это сразу видно, и доверия не прибавляет. Лечится не одной настройкой в начале, а повторением требований к языку прямо в конце запроса.
• Поток мусора. Открытый чат на сайте собирает не только клиентов. Автоматические переборы дают часть трафика, и их нужно отсекать ещё до модели. Решается на уровне инфраструктуры, а не модели. Фильтрация источника до того, как запрос дойдёт до системы.

Что изменилось в работе

Главный эффект оказался не в скорости ответа, хотя она выросла. Он в том, что исчез класс ситуаций «а мне никто не ответил». Обращение фиксируется в момент поступления и существует как объект, а не как сообщение в ленте, которое можно пролистать.

Второе, качество первого контакта. Инженер получает заявку, в которой уже есть марка техники, узел и характер неисправности, и начинает не с «расскажите подробнее», а с сути. Для клиента это выглядит как компетентность компании, хотя по факту это просто дисциплина сбора данных.

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

Серия «Будни цифрового офиса», выпуск 1, с чего начинается автоматизация. Следующий выпуск, ИИ-механик, история техники и подсказка по узлу.