Техподдержка

Типовой вопрос закрывается ответом из ваших документов

Разбор месячного потока техподдержки показал: из 156 обращений 73 закрываются типовым ответом из документации без участия инженера. Это около 24 часов работы в месяц.

Черновик ответа клиенту рядом со страницей руководства: абзац-источник подсвечен и связан с ответом. Данные вымышлены.
  • Ответ из мануала
  • Ссылка на страницу
  • Отправляет сотрудник
Схема экрана, данные условные.
  1. входит Было

    Инженер каждый раз искал ответ в документации сам, хотя 73 из 156 обращений в месяц типовые.

  2. в работе Сделали

    Код определяет изделие по артикулу, ответ собирается из ваших документов со ссылкой на источник. Нет ответа в документах: система говорит об этом.

  3. готово Эффект

    73 обращения × 20 минут = 24 часа работы в месяц. Это оценка по прошлому потоку, ваш замер делаем на вашем архиве.

Как это работает

Вручную

было: поиск по документам руками

Автоматически

стало: ответ со ссылкой

  1. Вопрос клиента входит

  2. Изделие по артикулу в работе

  3. Поиск по документам в работе

  4. Ответ со ссылкой готово

Схема: вопрос клиента → ответ со ссылкой на ваш документ.
Ответ · черновикпо документам

Вопрос: не включается после грозы

Источник: руководство, страница 42

Схема: вопрос клиента, поиск по мануалам, ответ со ссылкой на страницу; мануалы лежат в базе. Данные вымышлены.

Ситуация

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

Что сделали

Сначала определяем, о каком изделии речь: поиск по точным кодам находит в тексте артикулы и обозначения моделей обычным кодом, без вызова модели. Затем собираем контекст из ваших документов и из истории прошлых обращений. Ответ генерируется со ссылкой на источник, и главное правило записано в самом задании модели: родственная функция, общий механизм и близкая настройка — это основание ответить, дословное совпадение формулировок не требуется. Без этого правила система отказывала почти на всех вопросах. Если ответа в документах нет, она сообщает об этом и формулирует поисковые запросы сама, а обрывок служебного формата пользователю не уходит никогда.

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

Результат в цифрах

73 обращения из 156 (47 %) закрываются типовым ответом. 73 × 20 минут = 24 часа работы в месяц, примерно три рабочих дня. Это оценка потенциала по прошлому потоку, ваш замер делаем на вашем архиве.

Как проверяли

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

Стопка вопросов проходит через ворота-порог: большая часть попадает в лоток ответов, два вопроса уходят в отдельный лоток
Клиент получает ответ только выше порога уверенности, остальные обращения уходят человеку.

Что переносится в ваш проект

Порядок «сначала ваши документы, веб-поиск последним». Определение предмета вопроса по точным кодам вместо поиска «по смыслу»: для артикулов и номеров регламентов это точнее и дешевле. Правило синтеза из частично релевантного фрагмента. Явный отказ вместо выдуманного ответа и порог уверенности, ниже которого отвечает человек.

Похожая задача? Пришлите 20 типовых вопросов и папку документов, покажем, сколько из них закрывается без человека.