Павел Харитонов

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

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

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

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

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

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

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

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

Получается, работу он делегировал, а контроль — нет. И из операционки в итоге вышел только наполовину.

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

Спасибо за здравый взгляд на цифровизацию — особенно за то, что начинать предлагаете не с выбора ПО, а с аудита процессов. На практике этот этап действительно часто пытаются перескочить.

Я бы только между аудитом и выбором ПО добавил ещё один шаг — спроектировать, как процесс вообще должен работать после внедрения.

«У нас теряются документы» ещё не значит, что надо просто внедрить документооборот. Кто создаёт документ, кто согласует, что считается завершением, где руководитель видит просрочку, что происходит дальше?
В проектах регулярно сталкиваюсь с тем, что запрос начинается с «нам нужна CRM / отчёт / согласование». Начинаешь разбирать — и оказывается, что сначала надо договориться, как должен выглядеть сам результат работы.
А уже потом выбирать инструмент. Иначе можно довольно успешно автоматизировать плохо спроектированный процесс.

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

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

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

Разница только в том, как ловится. Форму находит тест. Мою историю тест бы не нашёл — я бы сам прошёл голосовое меню и дошёл до менеджера, всё работало как настроено.

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