KPI и контроль команды на масштабе: кто и как обрабатывает обращения в сети

С чего начинается проблема контроля

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

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

Почему метрики ассистента объективнее ручных отчётов

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

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

Загрузка по сотрудникам — кто сколько тянет

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

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

Воронка диалога — где именно теряются клиенты

Второй слой — воронка. Ассистент фиксирует путь обращения целиком: обращение → диалог → запись (или заказ, или бронь — смотря какая ниша). Воронка показывает не только сколько всего пришло, но и на каком шаге клиенты отваливаются.

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

Каждый видит ровно своё — это и есть контроль

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

• Владелец видит всё — всю сеть, всех сотрудников, сравнивает точки и людей между собой.
• Администратор точки ведёт операционку своего филиала: видит загрузку и воронку по своей команде, но не лезет в чужие точки и не видит долгосрочных финансовых трендов.
• Сотрудник видит только свою сводку — свою загрузку, свои записи, своих клиентов (с маскированными телефонами). Не чужие показатели и не настройки бизнеса.

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

Как это устроено на сети

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

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

Что это меняет для владельца

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