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

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

Что происходит между сообщением и назначением

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

Следующее состояние — обращение попало в очередь технической поддержки. Очередь здесь означает общий список работы для определённой группы. В нём могут находиться обращения, которые ещё никому лично не назначены. И только после выбора конкретного сотрудника появляется назначение.

Такое разделение есть, например, в документации Microsoft о маршрутизации в Dynamics 365. Microsoft выделяет классификацию и назначение, а при назначении учитывает характер работы, навыки, доступность и текущую нагрузку сотрудников. Это описание конкретного продукта. В другой системе набор условий и порядок работы могут отличаться.

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

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

Как описать правила для первой очереди

Начать удобнее с одного понятного вида обращений и одного входящего канала. Так можно пройти весь путь и увидеть, какие настройки уже есть в готовом решении. Необязательно сразу перестраивать поддержку целиком.

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

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

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

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

При настройке стоит отдельно посмотреть доступность сотрудников и часы работы. В описании очередей Dynamics 365 участники, способ назначения, рабочие часы и обработка переполнения задаются отдельно. Наличие таких настроек у Microsoft не означает, что они уже включены в используемой компанией системе или подходят её порядку работы.

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

Куда попадёт обращение без понятного маршрута

Обращение для ручного разбора и отдельные жетоны ответственных
Предметная иллюстрация. Не интерфейс системы и не результат испытаний.

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

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

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

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

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

Что проверить на повторе, отсутствии сотрудника и сбое

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

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

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

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

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

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

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

Когда имеет смысл добавлять AI

Если обращения приходят через форму с понятными полями, распределение может закрываться обычными правилами. Atlassian в описании автоматизации поддержки отдельно рассматривает правила продвижения задач и применение AI для анализа или подготовки ответов. Поэтому саму задачу распределения не стоит заранее приравнивать к внедрению AI.

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

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

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

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

Определение темы также не должно незаметно расширять полномочия системы. В нашем примере категория «повторная неисправность» не даёт права обещать бесплатный ремонт или время приезда мастера. Такие решения требуют отдельных правил и разрешений компании; в задачу распределения они автоматически не входят.

С чего начать проверку в своей поддержке

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

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

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

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

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

Источники