Дашборд по продажам дописывают агентами для ежедневного плана и разбора отклонений внутри отдела

Какой дашборд нужен руководителю продаж? Тот, с которого он видит отставание менеджера, открывает состав суммы и выбирает, что делать сегодня.

O2K и HighTime уже разбирают план-факт, результаты менеджеров и причины потерь. В прочитанных 8 октября текстах агентная разработка доработок не описана.

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

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

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

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

Для план-факт анализа сохраняют версию плана и основания каждого отклонения.

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

Что дописывают агентами поверх показателей? Переход от строки менеджера к исходным сделкам с сохранением периода и правила зачёта. Суммы должны сходиться.

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

В Microsoft Power BI такой переход к подробностям уже есть. Заказной код нужен, если штатная детализация не сохраняет ваш контекст или не ведёт к карточке в рабочей системе.

Задачу для агента формулируют наблюдаемым действием. «Открыть сделки из этой суммы» проверяется; «сделать аналитику удобной» оставляет смысл на усмотрение исполнителя.

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

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

У нас такая ошибка была в Индексе: 2 сентября 2026 счётчик вакансий показал ложный ноль из-за обрыва страницы. Ноль выглядел как падение рынка.

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

Что из этого мы делали сами? Собрали агентами админку: собственные заявки, разрезы продуктов и каналов, выбор периода и пояснения к счёту.

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

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

Связь правил, экрана и проверки разобрана в уроке «Руль, окно и сторож» курса агентной разработки. В дашборде это определение метрики, её значение и сигнал о сбое.

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

Эффект в вашем отделе придётся измерить. До запуска запишите время ручной сверки, затем сравните после; число написанных строк не покажет, перестал ли РОП собирать отчёт вручную.

Сколько стоит заказать такую работу? На 8 октября 2026 тариф «Один проект» в подписке на разработку стоит 250 000 ₽ в месяц. Это цена проекта с очередью задач.

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

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

Ежедневный экран завершают действием РОПа. После разбора он назначает ответственного и следующую задачу по сделке; новый график сам по себе этого не делает.

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

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

1. Ограничьте заказ ежедневным экраном отдела и его решениями.

2. Утвердите событие продажи, период и календарь плана до разработки.

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

4. Проверяйте свежесть, настоящий ноль, отсутствие датчика и сбой отдельно.

5. Измеряйте ручную сверку РОПа до и после запуска, а не объём написанного кода.