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

В понедельник утром руководитель открывает очередь и видит знакомую картину: у Антона восемь обращений, у Лены два, у Марины ни одного. Через час оказывается, что Марина всё это время разбирала сложный возврат из почты, Лена отвечала в Telegram, а Антон получил пять коротких вопросов подряд и уже раздражённо просит «раскидать нормально».

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

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

Ручное назначение хорошо, пока поток видно глазами

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

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

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

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

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

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

Очередь убирает споры, но не различает сложность

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

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

Но очередь не понимает вес обращения. Одному оператору может достаться короткое «спасибо, всё получилось», другому — клиент с пятью скриншотами и историей на три недели. Формально оба получили по одному тикету. По факту нагрузка разная.

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

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

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

Нагрузка честнее очереди, если считать живые обращения

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

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

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

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

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

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

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

Специализация нужна там, где ошибка дороже ожидания

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

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

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

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

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

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

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

Смешивать правила можно, но не прятать логику

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

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

У правила распределения должны быть три свойства.

Первое — оно видно. Оператор понимает, почему обращение пришло к нему, а не к соседу.

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

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

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

В DeskAI чат на сайте, email, Telegram, MAX, формы и API собираются в один inbox. Для обращений есть автораспределение по очереди, наименее загруженному оператору или случайно, а ответственного можно назначить и сменить без потери контекста. В аналитике видно нагрузку по агентам и каналам, пиковые часы, время первого ответа и решения.