Почему ежедневные отчёты в чат быстро превращаются в шум

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

Утром открываешь Telegram или корпоративный чат и сразу видишь, что произошло в компании за вчера.

По отделу продаж:

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

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

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

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

Я сам много раз пытался построить такую систему.

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

Эта статья продолжает серию «Управленческие алгоритмы» - о том, почему сначала нужно определить управленческую задачу, а уже потом выбирать инструмент.

Почему идея отчёта в чат кажется правильной

У такого решения есть понятная логика.

Руководителю не нужно открывать CRM, телефонию, почту, рекламный кабинет и несколько таблиц. Система сама собирает данные, формирует сообщение и отправляет его в привычный канал.

Например:

Иван Петров
Звонки: 40, из них 15 длиннее 30 секунд
Общее время: 65 минут
Email: 4 исходящих, 2 входящих
Коммерческие предложения: 3 на 500 000 рублей
Новые лиды: 5, необработанных: 2
Просроченных лидов в CRM: 2

На первый взгляд в одном сообщении есть почти всё необходимое.

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

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

Именно поэтому клиенты регулярно просили нас сделать подобные механики. И именно поэтому я сам просил внедрять их в своих проектах.

Мы не только советовали. Мы это разрабатывали

За последние несколько лет мы участвовали в создании нескольких сотен разных отчётов для бизнеса.

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

Часть из них отправлялась в почту. Часть - в Telegram и корпоративные чаты. Часть - в интерфейсы CRM и отдельные панели.

В одном из наших продуктов - платформе «Статистика компаний» - мы тоже реализовывали отправку показателей в чат.

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

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

На экране результат выглядел очень просто: одно аккуратное сообщение.

Но под ним часто находился отдельный технический контур.

Нужно было:

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

Поэтому фраза «просто отправлять статистику в чат» нередко скрывает полноценный микросервис сбора, нормализации и доставки данных.

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

Главная проблема начиналась после запуска.

Первое время сообщения читают. Потом они становятся частью фона

В первые дни новый отчёт привлекает внимание.

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

Через некоторое время сообщение становится привычным.

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

Если в отчёте нет явной аварии, взгляд быстро скользит дальше.

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

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

Мы доставили цифры. Но не ответили на вопрос, что именно должен сделать руководитель после их получения.

Чат показывает отдельный кадр, а управлять нужно движением

Одно сообщение показывает состояние в конкретный момент.

Например, сегодня менеджер сделал 40 звонков, вчера - 35, а неделю назад - 52.

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

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

Чат не запрещает анализировать эти данные. Он просто заставляет человека собирать анализ в голове.

В нём неудобно ответить на простые управленческие вопросы:

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

В результате отчёт создаёт наблюдаемость, но не обязательно создаёт управляемость.

Активность, своевременность, качество и результат - разные уровни

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

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

Менеджер может сделать 40 звонков и ни в одном не договориться о следующем действии.

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

Может подготовить несколько коммерческих предложений и отправить их без договорённости, когда клиент вернётся с обратной связью и когда менеджер свяжется повторно.

Может вовремя закрывать задачи в CRM, но указывать формальный результат.

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

Просто это разные уровни:

• объём действий;
• своевременность действий;
• качество действий;
• итоговый результат.

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

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

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

Когда отчёт в чат всё-таки подходит

Я не считаю, что сообщения с показателями нужно полностью исключить.

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

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

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

Также чат хорошо подходит для редкого события, которое требует немедленной реакции.

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

В таблице сохраняется история. Дни и сотрудники стоят рядом. Можно посчитать сумму, долю, среднее значение и отклонение. Можно отфильтровать период и увидеть тренд.

Не нужно искать старые сообщения и пытаться восстановить картину по памяти.

Таблица может быть очень простой. Но она уже отделяет хранение истории от потока коммуникации.

Если лид не обработан, нужен не вечерний отчёт

Хороший пример - контроль новых лидов.

Руководитель говорит: «Я хочу видеть необработанные лиды, чтобы сразу разбирать это с менеджерами».

Можно собрать вечерний отчёт и написать в чат, что у сотрудника осталось два необработанных обращения.

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

Если задача заключается именно в своевременной обработке, точнее встроить контроль в сам процесс.

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

Задача закрывается не нажатием кнопки ради закрытия, а понятным результатом:

• лид переведён на следующую стадию;
• контакт состоялся;
• назначено следующее действие;
• лид признан нецелевым с указанием причины;
• связаться не удалось, но результат попытки зафиксирован.

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

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

Здесь особенно хорошо видно различие между инструментами.

Когда требуется немедленное действие, нужен событийный сигнал, встроенный в процесс. Вечерняя сводка сообщает о проблеме постфактум.

Логика выбора инструмента здесь такая же, как в статье «Сначала цель, потом инструмент»: сначала определяем решение и действие, затем выбираем механизм. А если вопрос касается обязательного действия сотрудника, полезно отдельно проверить, что лучше подходит - задача, дело или другой объект процесса. Эту разницу я разбирал в статье «Задачи или дела».

Четыре механизма, которые не стоит смешивать

После нескольких попыток собрать всё в одном чате я пришёл к простой схеме.

Сообщение в чат

Оно подходит для временного запуска, малого объёма данных, одного сотрудника или редкого события.

Чат удобен как канал доставки. Но он плохо подходит для накопительного анализа, сравнения периодов и поиска причин.

Таблица

Она подходит, когда нужно хранить историю, сравнивать дни, недели, месяцы и сотрудников, считать доли и находить отклонения.

Таблица отвечает на вопрос «что происходило и как это соотносится с другими периодами».

Но сама по себе она не всегда объясняет, почему показатель изменился.

Мгновенный сигнал

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

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

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

Полноценная аналитика

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

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

Не потому, что красивый дашборд лучше текста. А потому, что разные управленческие вопросы требуют разных представлений данных.

Почему так устроены отчёты в «Дожми Продажи»

Этот опыт сильно повлиял на то, как мы строим отчёты в «Дожми Продажи».

Мы не пытаемся показать руководителю всё, что можно посчитать. Сначала нужен один управленческий фокус и один проверяемый критерий.

Например: фиксируют ли менеджеры следующий шаг после разговора с клиентом.

Дальше каждый элемент интерфейса решает свою задачу.

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

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

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

Карточка конкретной коммуникации нужна, чтобы проверить агрегированную цифру по фактам.

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

Фильтры нужны, чтобы не смешивать разные этапы, сегменты, типы звонков и ситуации.

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

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

Вместе получается не одно сообщение, а управленческая последовательность:

коммуникации -> проверяемый критерий -> таблица и сравнение -> динамика на графике -> сигнал об отклонении -> конкретные факты -> управленческое решение.

Мы делаем несколько форм представления данных не ради количества экранов.

Таблица помогает сравнивать. График помогает видеть изменение. Сигнал помогает вовремя вмешаться. Факты из коммуникаций помогают понять, что именно произошло. Калибровка помогает доверять оценке.

Каждый элемент закрывает отдельную часть управленческой работы.

Такая же проблема возникает не только в продажах

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

В поддержке - обращения, среднее время ответа, закрытые тикеты и просрочки.

В разработке - задачи, коммиты, часы и закрытые ошибки.

Каждая цифра может быть полезной в своём контексте.

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

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

Частые вопросы

Когда отчёт в чат действительно полезен?

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

Почему простая таблица часто полезнее ежедневной сводки?

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

Как лучше контролировать необработанные лиды?

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

Какие данные нужны для управления менеджером?

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

Проверка, которую я теперь применяю к каждому отчёту

Перед тем как автоматизировать новый отчёт, я стараюсь ответить на несколько вопросов:

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

Последний вопрос особенно полезен.

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

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

Но со временем я понял: удобная доставка показателей ещё не создаёт систему управления.

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