Как распределять обращения сотрудников по отделам через бота
Пример расчёта (условные цифры): если за месяц поступает 60 обращений по теме «маршрут внутреннего обращения» и каждый шестой требует повторного уточнения, команда возвращается к десяти уже начатым задачам. Проверьте свои числа до выбора решения. На БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ можно разобрать процесс и первый пилотный сценарий.
Результат, который нужен по теме «маршрут внутреннего обращения»
Отделите частый путь от исключения. В обычном процессе пользователь ждёт понятного следующего шага, но сейчас запрос о зарплатной справке попадает IT, потому что сотрудник выбрал первую кнопку. Укажите точку, где требуется подтверждение системы или человека.
Внутренняя заявка должна попасть к тому, кто действительно выполняет действие. Для неё нужны инициатор, объект, описание, срок и маршрут согласования. Если бот лишь переслал сообщение в общий чат, сотрудник всё равно будет выяснять владельца задачи и спрашивать о статусе. Сразу определите, в каком реестре появляется запись и откуда приходит ответ о её завершении.
Маршрутизация зависит от темы и прав отдела, а не от первого слова сообщения. Если сотрудник просит справку и одновременно сообщает об ошибке портала, создайте две связанные задачи с разными исполнителями.
Показывайте пользователю только подтверждённые сведения из источника «Справочник отделов и ответственных». Дату обновления и ограничение ответа стоит обозначить там, где информация меняется до окончательного решения.
Вопрос к вам: у скольких запросов можно найти итог в рабочей системе без поиска по личным чатам?
Лайфхак: проверяйте сценарий фразами реальных пользователей. Внутренние названия процессов часто не совпадают с тем, как люди описывают задачу.
Какие данные и решения подготовить
Сразу определите правило для пустого, ошибочного и противоречивого ответа. Бот должен дать способ исправить поле или передать ситуацию человеку, сохранив исходный текст.
Прогоните «тема затрагивает два отдела» на тестовом диалоге. Посмотрите на экран пользователя и запись исполнителя: оба должны видеть одинаковый статус, даже если решение ещё не готово.
Права корпоративного бота связывайте с подтверждённой учётной записью сотрудника. Не выводите служебные сведения после смены роли и не используйте введённое имя как доказательство личности. Для аварий и недоступности рабочей системы предусмотрите отдельный контакт дежурного.
В журнале нужны время, идентификатор запроса, версия данных и ответ системы. По этим полям можно восстановить ошибку без чтения всей личной переписки.
Перед тестом назначьте владельца исходных сведений и владельца текста бота. Когда правило меняется, оба проверяют одну и ту же цепочку: что введено, что сохранилось, кто получил задачу и каким сообщением она завершилась. Дата обновления без ответственного не защищает от старого ответа.
Два способа обработать запрос
Вручную. Диспетчер или руководитель разберёт необычный запрос и расставит приоритеты. При ручной обработке легко потерять вложение, срок и историю изменения, если сообщения живут в личном чате.
Через бота. Бот создаёт структурированную заявку и сообщает номер. Ошибка возникает, когда подтверждение отправлено до записи в рабочую систему или когда неверная категория направила вопрос не тому отделу.
Для пилота возьмите сопоставимые типы запросов. Если в автоматический канал попали только простые задачи, общая средняя скорость ничего не говорит о сложных случаях.
Как запустить сценарий по шагам
Шаг 1. Описать типы запросов
Покажите варианты с различиями, влияющими на решение. Необязательные поля оставьте на следующий этап, а нестандартный ответ передайте человеку.
Шаг 2. Назначить владельца каждой темы
Передайте ответственному исходный запрос, проверенные данные и причину маршрута. Убедитесь, что задача принята, а не только отправлена.
Шаг 3. Собрать минимальные данные
Запросите только поля, необходимые для этого действия. Сохраните исходное пояснение и дайте возможность исправить ответ без нового диалога.
Шаг 4. Проверить ошибочный маршрут
Сопоставьте ввод с источником «Справочник отделов и ответственных». Отсутствие записи и несоответствие данных требуют разных сообщений и разного пути к сотруднику.
Пройдите весь маршрут на нескольких реальных ситуациях. В тесте нужны успешный вариант, неполные данные, повтор, изменение исходной записи и исключение «тема затрагивает два отдела». Смотрите одновременно на экран пользователя и запись исполнителя. Если они говорят о разных итогах, сценарий ещё не готов к широкому потоку.
Таблица проверки результата для «маршрут внутреннего обращения»
Для этой задачи контролируйте показатель «доля передач между отделами». Зафиксируйте его определение, период и источник до запуска. Дополните его временем до результата и числом случаев, которые пришлось исправлять вручную. Иначе отчёт может объявить успехом отправку сообщения, за которой не было нужного действия.
Пример расчёта (условные цифры): если 60 обращений за месяц проходят через бот, но шесть не получают подтверждённого результата, доля проблемных случаев составляет 10%. Это важнее числа отправленных автоответов. Это оценка для проверки процесса, а не обещание эффекта внедрения.
Добавьте в журнал причину ручной передачи. Частая причина подскажет, какое правило, документ или поле нужно обновить следующим.
Вопрос к вам: сколько похожих задач в месяц завершается без повторного уточнения и сколько возвращается с той же проблемой?
Лайфхак: храните три проверочных случая рядом с описанием сценария. После каждого изменения прогоняйте их заново и добавляйте новый случай, если обнаружили повторяющуюся ошибку.
Что ещё связано
Сценарий опирается на качество исходных данных и понятную передачу исключений. В A3bot можно собрать маршрут вокруг вашей рабочей системы. Стоимость обсуждаем после разбора задачи.
Заметка эксперта
У задачи «маршрут внутреннего обращения» есть проверяемое завершение. Бот полезен, когда он приближает к этому завершению и не скрывает задержку или ошибку. Начните с небольшого потока, подтвердите итог в основной системе и только затем расширяйте сценарий.
Напишите, какой процесс хотите автоматизировать: A3bot