Может ли один оператор заменить трёх координаторов? Проверка

Почему команды сокращают не ту роль

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

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

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

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

Стоимость проявляется в мелких сбоях, которые быстро накапливаются:

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

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

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

Сначала разберите работу, потом считайте людей

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

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

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

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

Разделение на работу по правилам и работу, где нужен выбор, — самое важное. Работу по правилам легко объяснить одним предложением: «Если реселлер просит цену, направьте запрос в channel sales». Работа, где нужен выбор, требует контекста и компромиссов: «Этот клиент хочет возврат, изменение договора и срочное продление. Кто должен этим заняться?»

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

Считайте и трение. Запрос с четырьмя передачами и тремя сообщениями для уточнения — это не просто медленный запрос. Это дорогой запрос, и обычно он указывает на сломанное правило или отсутствующего владельца.

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

Как выглядит повторяющаяся маршрутизация

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

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

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

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

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

Время обработки тоже многое показывает. Если один оператор в спокойный час обрабатывает 80 запросов, а во время пика — 40, замедление обычно связано с объёмом, а не с выбором. Работа не стала сложнее. Просто её стало больше.

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

Как выглядят потоки с большим количеством исключений

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

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

Признаки знакомые. Тикеты с пометкой «срочно» приходят без объяснения. Клиенты просят сразу о двух вещах, на которые распространяются разные правила. Команда не может действовать, пока кто-то не заполнит недостающий контекст. Менеджеры постоянно утверждают скидки, возвраты, изменения доступа или исключения по срокам. Один и тот же тип проблемы уходит разным людям в зависимости от времени и контекста бизнеса.

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

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

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

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

Как проверить, справится ли один оператор

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

Возьмите свежую выборку из реальной очереди, а не отобранные вручную случаи. Обычно достаточно двух–четырёх недель тикетов, email или форм, чтобы получить честную картину, особенно если объём меняется по дням.

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

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

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

Потом смотрите не только на скорость, но и на самостоятельность. Один оператор может коснуться 120 случаев в день, но без помощи закрыть только 70. Это важнее, чем просто объём. Если оператору постоянно нужен «спасатель» из координаторов, значит команда по сути роль ещё не убрала.

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

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

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

Простой пример из очереди поддержки и продаж

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

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

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

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

Часто помогает простой фильтр:

• Стандартный возврат в рамках политики
• Изменение адреса с подтверждённым аккаунтом
• Нет открытого спора и кастомных условий
• Всё неясное — координаторам

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

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

Ошибки, из-за которых сокращают неправильно

Команды ошибаются, когда измеряют объём вместо усилий. Очередь на 500 тикетов может выглядеть лёгкой на бумаге, но если 80 из них требуют 10 минут на проверку, звонок или исправление, нагрузка уже не маленькая.

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

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

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

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

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

Перед тем как убрать роль, проверьте пять вещей:

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

Если этих данных нет, подождите. Сокращать штат до того, как вы разобрали работу, — это не эффективность. Это отложенный хаос.

Короткие проверки перед изменением ролей

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

Проведите короткий стресс-тест, прежде чем трогать оргструктуру.

• Посадите на задачу по маршрутизации нового сотрудника или человека из другой команды на один день. Если к обеду ему всё ещё часто нужна помощь, процесс живёт в головах людей.
• Прочитайте письменные правила и посчитайте, как часто кто-то всё равно спрашивает менеджера, что делать. Здоровый маршрут закрывает большую часть случаев на бумаге, а реальные исключения встречаются редко.
• Возьмите три случая с недостающими данными и посмотрите, что произойдёт. Кто-то должен взять на себя случай, решить следующий шаг и сдвинуть его дальше. Если он просто лежит в общем ящике, значит, у вас пробел.
• Удвойте объём на один час с помощью старых тикетов, тестовых записей или повтора трафика прошлой недели. Посмотрите, что ломается первым: скорость ответа, точность, передачи или обновления для клиентов. Слабое место покажет, кого именно защищали дополнительные люди.
• Решите заранее, как вы откатите изменения за неделю. Если вы не можете быстро вернуть покрытие, риск выше, чем кажется.

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

Вот в чём смысл. Объём может не меняться, а координационная работа — резко вырасти.

Что делать дальше

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

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

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

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

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

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

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