21 августа 2026 г. · Maksim Shchegolev

Отчёт по заявкам: какие метрики смотреть и кому показывать

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

Хотите проверить это на своём сайте? Запустите бесплатную проверку видимости в ИИ, она занимает десять секунд и не требует почты.

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

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

Одним предложением

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

Почему отчёт по заявкам никто не читает

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

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

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

Как начинать с решения, а не со списка метрик

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

Инструмент, который делает это осязаемым, называется карточкой решения. Её заполняют до того, как появился первый график.

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

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

Три аудитории и три разных отчёта

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

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

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

Что показывать менеджеру на смене

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

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

Две детали отличают экран, которым пользуются, от экрана, который закрывают. Сортировка по возрасту, а не по баллу: потерю создаёт именно возраст, а балл во время смены проверить невозможно. И абсолютные счётчики вместо процентов: «одиннадцать заявок без единой попытки» рождает действие, «покрытие попытками 94 процента» рождает пожатие плечами.

Что входит в еженедельный разбор руководителя

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

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

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

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

Минимальная сводка для собственника или директора состоит из трёх объектов.

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

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

Каждый добавленный объект добавляет и определение, которое кому-то придётся защищать, а защита определений и съедает совещание. Три объекта защищаются за полторы минуты. Шесть не защищаются.

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

Опережающие и запаздывающие сигналы: почему отчёт по объёму ничего не решает

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

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

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

Старое исследование про время ответа стоит процитировать ровно один раз и по той же причине. Речь про замер Harvard Business Review 2011 года на 2 241 американской компании, где медиана первого ответа у ответивших оказалась около 42 часов. Это одна выборка многолетней давности, и это не современный ориентир. Он показывает другое: без измерения обработка входящего потока проседает гораздо глубже, чем в компании кто-либо готов допустить. Это и есть аргумент в пользу отчёта по поведению, а не по объёму.

Какие разрезы действительно меняют решение

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

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

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

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

Как показывать сбои процесса рядом с результатами

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

Их выводят на ту же поверхность, где лежат результаты. Отдельный «отчёт по качеству данных» читает операционная роль и не читает никто, кто может согласовать исправление.

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

Заметка оператора. Сбои процесса показывают абсолютными числами и с приложенным списком записей, а не одной долей. «Успешных записей 97 процентов» звучит как здоровая система. «41 обращение на этой неделе не доехало до CRM, вот они» приводит к исправлению к четвергу. Одно и то же число, два разных совещания. И если какой-то из этих счётчиков несколько недель подряд стоит ровно на нуле, не радуйтесь: отправьте заведомо сломанное тестовое обращение и убедитесь, что счётчик вообще способен сдвинуться. Метрика, которая не может вырасти, ничего не измеряет.

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

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

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

Откуда берутся сами числа, вопрос смежный, и ответ короткий. Системы веб-аналитики описывают источники визитов: у Google есть документация по измерениям источника трафика, у Яндекс Метрики похожая модель источников и отчёты по переходам. CRM описывает, что произошло с записью после приёма, включая штатное поведение по ответственным: у Salesforce это правила назначения заявок, у HubSpot справка о назначении ответственного за запись, а в российской практике те же числа собирают выгрузками из amoCRM и Битрикс24 и отчётами виртуальной АТС по звонкам. Когда две стороны расходятся, неправа не одна из них: они считают разные совокупности, и ровно для этого нужны примечания о сверке. Практические расхождения между двумя основными российскими системами разобраны отдельно в гайде про amoCRM и Битрикс24 в операционном стеке, а обращения из мессенджеров дают собственный набор пропусков, описанный в гайде про заявки из Telegram в CRM.

Ритм разборов и что каждому совещанию разрешено менять

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

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

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

Какие примечания о сверке публикуются вместе с отчётом

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

Держите это в объёме абзаца или короткого блока. Это рабочая заметка, а не документация. Реалистичный пример выглядит так: числа взяты в понедельник в 09:00; совокупность это принятые обращения после отсева спама; исключено 37 тестовых отправок; число в CRM ниже числа отправок форм в Яндекс Метрике, потому что аналитика считает отправки, а CRM считает записи после удаления дублей; определения версии 4, не менялись с марта.

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

Кто владеет определениями метрик и что попадает в журнал изменений

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

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

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

Методология NIST по управлению рисками ИИ формулирует мысль, которая шире искусственного интеллекта: результатом автоматики можно управлять только тогда, когда его можно проследить и измерить. Метрика, определение которой нельзя привязать к владельцу, версии и дате, не управляется, как бы ни выглядел график.

Как понять, что отчёт пора закрыть

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

Три вопроса закрывают отчёт быстрее любого процесса пересмотра.

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

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

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

Практическая последовательность внедрения

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

1. Соберите решения. Поговорите с менеджером на смене, руководителем отдела и собственником по отдельности и запишите по карточке на каждое решение, которое они реально принимают. Обычно их меньше десяти.
2. Назовите ответственных. У каждой карточки есть роль и момент, когда решение принимается. Карточка без момента это не решение, а интерес.
3. Свяжите метрики с владельцами. Для каждого нужного числа найдите документ, который его определяет. Где владельца нет, определите метрику и назначьте владельца до начала сборки.
4. Проверьте входные данные. Убедитесь, что данные вообще есть: отметки времени проставлены, источник заполнен, ответственный назначен, попытки фиксируются. Отсутствующие входы становятся метриками сбоев процесса, а не поводом остановиться.
5. Соберите три поверхности. Очередь смены, пакет руководителя, сводка для руководства, именно в этом порядке: экран смены улучшает качество данных, от которого зависят две остальные.
6. Напишите примечания о сверке до первого совещания, а не после первого спора.
7. Проведите один полный цикл разборов с соблюдением колонки «что можно менять» и записывайте каждое решение или явное «изменений нет».
8. Через два цикла проверьте пользование. Примените проверки на закрытие, уберите провалившее их и заведите журнал изменений для выживших определений.

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

Тревожный признак для оператора

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

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

Починка мелкая и неэффектная. Возьмите шесть чисел, которые сейчас на экране, напишите к каждому карточку решения, удалите провалившие проверку и поставьте фамилию и дату рядом с тем, что осталось. Определения остаются за своими гайдами: таймеры за гайдом про скорость ответа на заявку, источники и выручка за атрибуцией источников заявок, назначение за плейбуком по распределению заявок, экономика за окупаемостью автоматизации, а граница между системами за гайдом Lead Hub или CRM: Через узел приёма проходит каждая заявка, и часть счётчиков сбоев живёт именно в нём. Где слой отчётности стоит в общей схеме, видно на карте системы OperStack, варианты объёма работ собраны на странице тарифов, а если нужны карточки решений и примечания о сверке, написанные не по примеру, а по вашим данным, это тема консультации: на выходе вы получаете три описанные поверхности, заполненную карту владения метриками и список блоков, которые убирают первыми. Сборку отчётов, где рядом с успешной метрикой стоит метрика провала, берём в рамках автоматизации продаж.

Цены