Как распределять обращения бота между ответственными

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

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

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

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

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

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

Выберите признаки, которые действительно меняют исполнителя

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

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

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

Согласуйте минимальные сведения для первого решения. Учебный пример: направление «обучение» передаётся координаторам программ, вопрос по действующему обращению связывается с его рабочей записью. Это образец логики, а не фактическая структура Nazara. Реальные группы и признаки берутся из Вашей команды.

Запишите порядок правил и разрешите пересечения

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

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

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

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

Определите доступность и правила ожидания без выдуманного срока

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

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

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

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

Подготовьте запасного получателя и контролируемое переназначение

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

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

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

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

Покажите сотруднику и пользователю подтверждённое состояние

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

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

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

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

Проверьте назначение на учебных обращениях до запуска

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

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

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

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

Я создаю ботов под рабочие процессы бизнеса. Посмотрите раздел ботов Nazara, а через Умную форму можно описать направления обращений, роли команды и случай, где владелец теряется. Для начала достаточно учебного сценария без клиентской переписки и доступов.

Частые вопросы о распределении обращений

Можно ли отправлять все обращения в общий чат

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

Нужна ли ИИ-классификация для маршрутизации

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

Что делать при совпадении двух правил

Заранее согласуйте порядок или отдельное правило пересечения. Для учебного примера должно быть известно одно ожидаемое назначение либо контролируемое уточнение.

Кому принадлежит обращение во время ожидания

Назначьте роль, которая контролирует очередь до принятия исполнителем. Ожидание должно быть видимым состоянием, а не отсутствием ответственности.

Нужно ли создавать новую заявку при переназначении

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

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

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