Правила маршрутизации чат-бота: продажи, поддержка, VIP

Что на самом деле решают правила маршрутизации

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

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

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

Весь дизайн — в порядке приоритетов

Почти все системы маршрутизации читают правила по приоритету и останавливаются на первом совпадении. В этом поведении живёт большая часть ошибок маршрутизации, потому что правило, верное само по себе, в контексте может оказаться недостижимым.

Практическое следствие: располагайте правила от самых конкретных к самым общим и считайте общие полом, а не планом. Широкое правило, поставленное слишком высоко, поглощает конкретные под собой — и делает это молча: ошибки нет, диалоги просто перестают приходить туда, куда должны.

1. 1Сначала безопасность и соответствие требованиямВсё, что нельзя автоматизировать независимо от того, кто спрашивает: юридические угрозы, вопросы безопасности, регулируемые консультации. Это стоит в самом верху, потому что сработавшее раньше нижнее правило обошло бы их целиком.
2. 2Затем идентичностьУзнанный клиент высокой ценности, открытый инцидент, договор в переговорах. Идентичность важнее темы: VIP с рутинным вопросом остаётся VIP, и отправить его в общую очередь — та ошибка, которую запоминают.
3. 3Затем явное намерениеТо, о чём человек прямо попросил: человека, возврат, коммерческое предложение. Явное заявление всегда важнее выведенного. Классификатор, переспоривший слова клиента, ошибётся самым заметным способом.
4. 4Затем выведенная темаПродажи, поддержка, оплата, логистика — выведенные из сообщения и страницы. Здесь решается большинство диалогов, и этот слой требует больше всего сопровождения.
5. 5Затем времяРабочие часы, праздники, ночной путь. Время применяется поздно, потому что оно не выбирает назначение, а изменяет его: тот же диалог в 23:00 уходит в другое место, а не к другой команде.
6. 6Затем правило-перехватчикОдно правило внизу, совпадающее со всем и называющее реальное назначение с реальным владельцем. Если такого правила нет, у системы есть неопределённое поведение, и вы встретитесь с ним в худший момент.

Как писать таблицу решений

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

• Условие — на языке бизнеса, а не регулярных выражений. «У клиента есть открытый заказ, и он говорит о доставке» поддерживать можно; список из одиннадцати синонимов — нет.
• Назначение — ровно одна команда, очередь или человек. Правило с двумя назначениями — это два правила, и запись их как одного прячет ошибку с дублирующимся уведомлением.
• Приоритет — явный номер, а не позиция в файле. Неявный порядок ломается при первой же вставке строки в середину.
• Владелец — названный человек, отвечающий за то, что туда попадает. Назначения без владельца становятся молчащими очередями, а молчание в очереди неотличимо от успеха, пока клиент не пожалуется.
• Запасной путь — что происходит, если назначение недоступно, переполнено или вне рабочих часов. Правило без запасного пути работает ровно до того дня, когда это важно.

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

Граница между продажами и поддержкой

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

Одна и та же фраза — «это работает с нашей складской системой?» — от незнакомца является предпродажным вопросом, а от клиента, у которого только что сломалась интеграция, вопросом поддержки. Классификация по теме их не различит. Узнавание клиента различит — поэтому сопоставление диалога с существующей карточкой должно происходить до маршрутизации по теме, а не после.

• Узнанный клиент + вопрос о продукте → поддержка. Продавать действующему клиенту посреди его проблемы — быстрейший способ его потерять.
• Неузнанный + вопрос о цене, сравнении или возможностях → продажи.
• Узнанный клиент + явный сигнал покупки (больше мест, ещё точка, апгрейд) → продажи, но с приложенной историей аккаунта. В большинстве компаний это самый ценный маршрут и чаще всего неправильно обработанный.
• Неузнанный + номер заказа или ссылка на аккаунт → поддержка. Это клиент, чью карточку просто не сопоставили; отправить его в продажи — показать, что у системы амнезия.
• Неоднозначно → задать один уточняющий вопрос, а не угадывать. Один вопрос дешевле одной ошибки маршрутизации.

Там, где узнавание невозможно — анонимный чат, новый номер, — примите неоднозначность и спроектируйте под неё. Вопрос «это по существующему заказу или что-то новое?» снимает почти всё и стоит одного хода.

VIP-маршрут без выдуманной иерархии

VIP-маршрутизация проваливается предсказуемо: кто-то определяет уровень, список никто не поддерживает, и за год уровень начинает означать «клиенты, громко пожаловавшиеся в 2025-м». Если вы не можете сказать, откуда берётся VIP-признак и кто его обновляет, у вас не VIP-маршрутизация, а устаревший список.

Рабочее определение берётся из системы, которую и так поддерживают по другой причине. Стоимость договора в CRM, уровень тарифа в биллинге, назначенный аккаунт-менеджер, открытая корпоративная сделка. Каждое из этого кто-то держит в актуальном состоянии, потому что от этого зависит его работа, — а признаку маршрутизации нужно именно это.

• Выводите признак, а не ведите его руками. Ночная синхронизация из биллинга или CRM лучше таблицы, которую правит один человек.
• Направляйте к названному человеку, если он есть, и в приоритетную очередь, если нет. «Отправить в VIP-команду» имеет смысл, только если эта команда работает в тот час, когда пришёл диалог.
• Решите, что именно меняет VIP: позицию в очереди, целевой срок ответа, отвечает ли вообще ИИ, или уведомление конкретного человека. Все четыре законны; смешивать их — нет.
• Явно задайте поведение вне рабочих часов: именно ради этого случая признак и существует. VIP, попавший в пустую очередь в полночь, получил худший сервис, чем обычный клиент, которому сказали ждать утра.

Ещё одно правило, которое стоит записать: VIP с пустяковым вопросом всё равно должен получить быстрый путь. Условие вида «VIP, и вопрос важный» возвращает ровно то суждение, которое признак и должен был убрать.

Нерабочие часы, переполнение и запасные пути

Большинство таблиц маршрутизации написано для вторника после обеда. Интересны остальные случаи — и именно там наносится реальный ущерб клиенту.

1. 1Вне рабочих часовРешайте по каждому назначению, а не глобально. Поддержка может подождать до утра; запрос в продажи может получить запланированный обратный звонок; вопрос безопасности требует пути эскалации, который реально существует в три часа ночи. Одно общее сообщение «мы закрыты» обходится со всеми тремя одинаково.
2. 2Никто не ответилУ каждой очереди должны быть таймаут и второе назначение. Без них отказ выглядит не как ошибка, а как диалог, пролежавший непрочитанным два дня, — и этого никто не замечает, потому что ничего не сломалось.
3. 3Назначение переполнено или без людейПраздники, болезнь, выезд команды. Если маршрут зависит от графика дежурств, он должен этот график читать. Если не может — нужен ручной переключатель, который кто-то повернёт за десять секунд.
4. 4Недоступен сам ИИРешите, что произойдёт, если модель или API лежат. Правильный ответ — диалоги уходят на человеческий путь или получают простое подтверждение, а не исчезают.
5. 5Ничего не совпалоПравило-перехватчик должно вести в реальную очередь, которую действительно читают. Отправлять несовпавшие диалоги в общий ящик без владельца — самый частый способ потерять сообщения.

Проверяйте запасные пути намеренно и по графику. Это единственная часть маршрутизации, которая срабатывает исключительно тогда, когда что-то уже пошло не так, — а значит, и та, что с наибольшей вероятностью молча сломалась с прошлого раза.

Что должно быть под этим

Правила маршрутизации зависят от данных, доступных в момент прихода диалога. Недостающие входные данные — основная причина ошибок маршрутизации, и чинятся они намного дешевле самих правил.

• Узнавание клиента по устойчивому ключу — телефону или почте — в тех форматах, которыми клиенты реально пользуются, а не только в каноническом.
• Признак уровня или ценности, выведенный из поддерживаемой системы, как описано выше.
• Классификация намерения, достаточная для разделения четырёх-пяти категорий. Не стройте таксономию из тридцати намерений: по тридцати никто не сможет маршрутизировать.
• Рабочие часы и праздники как данные, доступные правилам, — по команде, а не по компании.
• Назначения, которые принимают и подтверждают: очередь, групповое уведомление, назначение в CRM. Назначение, только пишущее в лог, назначением не является.
• Журнал того, какое правило сработало. Без него разбор ошибки — это гадание, а первый вопрос после каждого инцидента именно такой.

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

Метрики, вскрывающие плохую маршрутизацию

Качество маршрутизации не видно в сводной статистике. Его делают видимым четыре числа, и все четыре требуют, чтобы кто-то зафиксировал вердикт, а не полагались на собственный оптимизм системы.

1. 1Доля ошибок маршрутизацииДиалоги, переданные хотя бы раз после первичной маршрутизации, к общему числу маршрутизированных. Это главная цифра. Её фиксация должна быть в одну кнопку для того, кто передаёт, иначе её не будут фиксировать.
2. 2Время до первого ответа человека по назначениямСводное время ответа прячет то назначение, которое тихо не справляется. В разбивке по очередям провальная видна за неделю.
3. 3Доля несовпавшихСколько диалогов доходит до правила-перехватчика. Растущая цифра означает, что мир изменился, а таблица нет. Близкая к нулю при большом объёме обычно означает, что широкое правило слишком высоко ловит слишком многое.
4. 4Доля переоткрытий после передачиДиалоги, курсирующие между двумя назначениями. Две команды, маршрутизирующие друг на друга, — это конфликт правил, и он невидим во всех остальных метриках.

Разбирайте ошибки маршрутизации раз в месяц вместе с теми, кто их получил. Большинство проблем маршрутизации — не проблемы классификации, а разногласия о зоне ответственности, всплывающие только тогда, когда кто-то смотрит на конкретный диалог, попавший не туда.

Где маршрутизация обычно ломается

• Широкое правило над конкретными, молча делающее их недостижимыми. Самый частый дефект маршрутизации.
• Маршрутизация по теме до проверки, является ли человек клиентом, — отсюда отправка действующего клиента в продажи.
• VIP-признак, который никто не поддерживает и который вырождается в список бывших жалобщиков.
• Отсутствие правила-перехватчика: у несовпавших диалогов неопределённое поведение.
• Назначения без владельца, превращающиеся в молчащие очереди, неотличимые от работающих.
• Рабочие часы, заданные один раз для всей компании, когда у команд они разные.
• Тридцать намерений там, где хватило бы пяти: уверенно ошибающийся классификатор и таблица, в которой никто не разберётся.
• Отсутствие записи о сработавшем правиле, превращающее каждый разбор в археологию.

Как маршрутизация устроена в Vexvon

На голосовой стороне маршрутизация Vexvon собрана из трёх частей, которые настраиваются отдельно и комбинируются: временные политики, назначения и правила. Правила читаются по приоритету, и побеждает первое совпадение — то самое поведение, из-за которого дисциплина порядка здесь имеет прямое значение.

Набор правил можно симулировать до запуска. Панель отвечает, куда попадёт конкретный звонок, — это и есть описанный выше тест трассировки, применённый к реальной таблице, а не к мысленной модели. Быстрее всего так находится правило, ставшее недостижимым из-за более широкого над ним.

На стороне переписки все каналы обслуживает один и тот же движок, и диалог несёт карточку клиента, а не начинается анонимным. Телефоны определяются пятиступенчатым процессом и сопоставляются с существующими клиентами: человек, написавший в Instagram на прошлой неделе и позвонивший на этой, — та же карточка, а не новая. Это и есть шаг узнавания, от которого зависит разделение продаж и поддержки. Фильтр покупательского намерения решает, действительно ли извлечённый контакт является лидом, а собственные номера компании исключаются.

У передачи человеку три явных триггера: просьба клиента об операторе поднимает уведомление, стоп-символ, введённый агентом, ставит ИИ на паузу в этом диалоге на тридцать минут, и ИИ можно выключить для диалога целиком. Лиды назначаются одним из четырёх режимов — вручную, по кругу, по каналу или по загрузке, — а каждое назначение и смена статуса пишутся в журнал активности с десятью типами действий.

Частые вопросы

1. 1Что такое правила маршрутизации чат-бота?Это условия, определяющие, какая команда, очередь или человек получит диалог; читаются по приоритету, побеждает первое совпадение. На практике они фиксируют соглашение о том, кто кому отвечает и как быстро.
2. 2Сколько должно быть правил?Столько, чтобы читались с одного экрана. Большинству организаций хватает пяти-десяти правил плюс перехватчик. Таблицы, перевалившие за двадцать, обычно копят исключения, которым место в дизайне разговора.
3. 3Смотреть сначала на намерение или на идентичность клиента?На идентичность, после безопасности. Узнанный клиент с вопросом о продукте — это поддержка, даже если тема читается как продажи, и перепутанный порядок здесь даёт самую частую ошибку.
4. 4Какие данные нужны?Узнавание клиента по телефону или почте, поддерживаемый признак ценности, небольшая таксономия намерений, рабочие часы по командам, назначения, подтверждающие приём, и журнал сработавших правил.
5. 5Как измерить, работает ли маршрутизация?Доля ошибок маршрутизации, время до первого ответа человека в разбивке по назначениям, доля несовпавших и доля переоткрытий после передачи. Сводное время ответа прячет все четыре.
6. 6Что должно происходить вне рабочих часов?Разное по каждому назначению и решённое намеренно. Поддержка может подождать до утра, продажи — запланировать звонок, а всё, связанное с безопасностью, требует пути, реально существующего ночью.

Начните с трассировки двадцати диалогов

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