План продаж выполнен у менеджера и провален у финансиста — оба могут считать правильно. Один видит принятые заказы, другой поступившие деньги. Прежде чем поручать ИИ разбор отклонений, стоит договориться о самом результате: иначе агент быстро объяснит число, которое разные люди понимают по-разному.
План-факт продаж сравнивает заранее согласованную цель с подтверждённым результатом за одинаковый период и по одинаковым правилам. Сначала определяют событие, дату признания, единицы и исключения, затем сверяют источники. Отклонение разбирают до конкретных сделок и действий. Заказы, поступления и отгрузки показывают отдельно, если они отвечают на разные управленческие вопросы.

Три отдела закрыли один месяц по-разному
Представим поставщика оборудования. В пятницу продавец закрыл сделку на 600 тысяч рублей, бухгалтер увидел аванс 180 тысяч, склад подготовил отгрузку на следующую неделю. В понедельник руководитель спрашивает выполнение месячного плана. Все три сотрудника честно называют разные суммы. Компании не нужен четвёртый человек, который усреднит ответы. Ей нужно договориться, какое событие считается результатом.
План-факт продаж — сравнение заранее заданной цели с подтверждённым результатом за одинаковый период, в одинаковых единицах и по одинаковым правилам. Сумма подписанных заказов, поступившие деньги и отгруженный товар могут быть полезными фактами. Объединять их в один показатель без объяснения опасно: разница будет похожа на рост бизнеса, хотя изменился только способ подсчёта.
Для условного примера план заказов — 900 тысяч, план поступлений — 450 тысяч. Подписанный заказ на 600 тысяч выполняет первый на 66,7%, аванс 180 тысяч выполняет второй на 40%. Это расчёт примера, не результаты клиента. Если записать в общий факт 780 тысяч, получится число, у которого нет хозяйственного смысла: часть одной продажи посчитали дважды.
В агентской CRM Цифра можно познакомиться с работой агентов рядом со сделками, знаниями и историей клиента. Для план-фактного разбора начните с одного отчёта вашей команды: какое событие признаётся фактом, где находится подтверждение и кто отвечает за отклонение. Подключение учётных данных и правила расчёта согласовывают отдельно под этот процесс.
Сначала паспорт показателя, потом красивый график
Я бы начал с пяти строк на листе, который могут одинаково прочитать продавец, финансист и руководитель. Название показателя; единица; дата признания; состав включённых операций; источник. Если хотя бы одна строка вызывает спор, диаграмма пока рано. Она только аккуратно раскрасит разногласие.
Показатель «новые продажи» особенно коварен. Новым может считаться клиент, договор, заказ действующего клиента или продукт в старом договоре. Для задач расширения клиентской базы и загрузки производства нужны разные определения. Сначала выбирают управленческий вопрос: сколько новых отношений появилось, какой объём принят к исполнению или сколько денег доступно для работы.
Официальная документация целей продаж HubSpot разделяет настройку цели по показателю, участникам и периоду. Это полезный пример устройства цели в CRM, а не описание готовой функции Цифры. Из него следует практическое правило: сравнивать нужно одну и ту же область ответственности, а не сумму всей компании с планом одной группы.
Паспорт сохраняют рядом с отчётом. «Продажи отдела оборудования, принятые заказы без отмен, рубли без НДС, дата подтверждения заказа, ответственный на момент события» — уже обсуждаемый показатель. «Выручка из CRM» — пока разговор о хорошем. Если юридическое или бухгалтерское признание выручки важно для отчётности, его отдельно определяет финансовая служба; CRM не назначает учётную политику названием поля.
План и факт должны встретиться в одной системе координат
Рабочую спецификацию удобно заполнить до настройки отчёта. Таблица ниже — шаблон решения, а не универсальная схема для каждой компании.
| Вопрос | Возможное правило | Что сломается без правила |
|---|---|---|
| Что планируем | Подтверждённые заказы | В факт попадут обещания и черновики |
| В каких единицах | Рубли по согласованной базе | Штуки, валюта и деньги окажутся рядом |
| Какая дата | Подтверждение клиентом | Перенос этапа задним числом изменит месяц |
| Кто выполняет | Владелец результата на дату события | Передача сделки перепишет прошлые заслуги |
| Какие исключения | Отмены, тесты, внутренние сделки | Отчёт начнёт расти от служебной работы |
| Чем подтверждаем | Запись заказа или иной принятый источник | Продавец сможет улучшать факт одной отметкой |
Отдельно фиксируют, как учитываются изменения. Если заказ подтвердили в октябре, а в ноябре уменьшили объём, есть два разных управленческих взгляда: пересчитать октябрь или показать ноябрьскую корректировку. Оба возможны при явном названии. Нельзя незаметно переключаться между ними, когда руководителю не нравится результат.
План тоже имеет версию. Согласованный в начале месяца ориентир и пересмотренный бюджет не обязаны совпадать. В отчёте полезно видеть исходный план, действующий пересмотр и причину изменения. Иначе план-факт превращается в соревнование, где дистанцию сокращают после финиша. Сравнение с первоначальной целью показывает качество планирования; сравнение с текущей — актуальную рабочую задачу.
Сумма сделки и деньги на счёте — разные факты
В официальном примере Битрикс24 по учёту оплаченной суммы сумма сделки отделена от связанных платежей; для оплаченного результата отбирают подтверждённые платежи и учитывают валюту. Нам здесь важен сам принцип разделения. Его нельзя заменить фразой «сделка выиграна»: выигрыш может означать договорённость, а не полную оплату.
У условного заказа на миллион возможны аванс, доплата, возврат и перенос части поставки. Для плана поступлений нужен поток подтверждённых денег за период. Для объёма заказов — согласованное обязательство. Для отгрузок — исполнение. Если руководитель хочет все три взгляда, лучше три понятных строки с основаниями, чем одна внушительная цифра «всего».
Неоплаченный счёт не становится поступлением после отправки письма. Ожидаемый платёж можно показывать в отдельной колонке, но факт не должен тайком включать ожидание. По той же причине прогноз продаж с ИИ решает соседнюю задачу: оценивает будущее на основаниях. План-факт отвечает, что уже произошло относительно принятого обязательства.
НДС, валюта и скидки требуют одинаковой базы сравнения. Если план задан без НДС, а факт пришёл с ним, проценты выполнения будут зависеть от формата выгрузки. При нескольких валютах нужен согласованный курс и дата пересчёта. Не обязательно усложнять первый отчёт международной финансовой моделью. Обязательно назвать, что именно считает текущая версия.
Неполный месяц нельзя честно сравнить с полным
На десятый рабочий день месячный факт почти всегда меньше месячного плана. Это ещё не диагноз. Для разбора полезны три величины: полный план, ожидаемое выполнение к текущей дате и текущий факт. Но ожидаемая траектория не обязана быть прямой линией. У бизнеса с поставками в конце месяца равномерное деление создаст тревогу, которой не существует в договорённостях.
В условном месяце план — 1,2 миллиона. Если по согласованному графику к текущей дате должно быть 300 тысяч, а фактически подтверждено 280 тысяч, отклонение от текущего ориентира — минус 20 тысяч. От полного плана осталось 920 тысяч. Это два разных сообщения. Первое описывает текущий темп, второе — оставшийся объём; смешивать их в ярлык «отдел провалился» не стоит.
Траекторию можно строить по рабочим дням, графику контрактов или историческому распределению, если данные пригодны. Выбранную модель подписывают. Праздники, выходные и сезонные кампании учитывают только тогда, когда они входят в плановую логику, а не служат объяснением любой неприятной цифры. Для первого запуска достаточно явно указать, что промежуточный ориентир пока условный.
Если план равен нулю, процент выполнения не рассчитывают обычным делением. Показывают абсолютный факт и пояснение «план не задан» либо «внеплановая продажа» согласно принятому правилу. Бесконечные проценты выглядят героически, но планировать с ними сложно. Отсутствие плана — состояние данных, а не выдающийся результат отдела.
Разложите отклонение до управляемого действия
Минус к плану — повод открыть состав результата, а не немедленно переписать мотивацию. Я бы разделял отклонения на четыре группы: изменился объём подходящих обращений, изменилось движение сделок, изменилась стоимость результата, сдвинулось время признания. Пятая группа стоит отдельно: ошибка данных. Пока она не исключена, обсуждать личную эффективность особенно дорого.
Пример разбора: ожидали три подтверждённых заказа по 200 тысяч, получили два на 180 и 220 тысяч. План 600 тысяч, факт 400 тысяч, разница минус 200 тысяч. Средний размер выполненного заказа не изменился. Причину ищут в третьем заказе и его сроке, а не предлагают всем продавцам «увеличить средний чек». Арифметика здесь экономит совещание.
Другой пример: три заказа состоялись, но каждый на 150 тысяч. Теперь количество совпало, сумма ниже на 150 тысяч. Нужно посмотреть состав, скидки и изменение объёма. Это не доказывает неправильную работу менеджера: клиент мог согласовать меньшую потребность. Разбор требует документов и реплик, а не характера сотрудника, восстановленного по одному проценту.
Для каждой значимой причины оставляют связку: наблюдение, основание, возможное действие, ответственный, дата проверки. «Заказ перенесён на декабрь» — наблюдение. «Клиент подтвердил новую дату письмом» — основание. «Уточнить возможность частичной поставки» — действие, если оно уместно. Причина без действия пригодна для истории; действие без основания быстро становится суетой.
Агенту поручают поиск оснований, решение оставляют проверяемым
Полезное задание ИИ звучит конкретно: «Собери сделки, из-за которых отдел отстаёт от согласованного плана подтверждённых заказов. Для каждой покажи изменение срока или суммы, ссылку на запись, последний подтверждённый следующий шаг. Если причина неизвестна, так и отметь». Здесь понятно, что агент должен принести и где сотрудник проверит результат.
Задание «объясни, почему продажи упали» соблазняет красивым рассказом. Модель может связать сезонность, конкурентов и мотивацию, даже если у неё есть только список сумм. Чтобы этого не случилось, отдельно хранят подтверждённую причину, гипотезу для проверки и отсутствие сведений. У каждого уровня своё действие: принять факт, запросить проверку или назначить уточнение.
В Цифре штатные роли включают ассистента, аналитика, юриста, продавца и поддержку; рабочий маршрут зависит от настроек и доступных данных. Роль аналитика не означает автоматического доступа к банку или учётной системе. Для план-факта заранее проверяют источники, права, формат результата и порядок подтверждения изменений. Неподключённый источник остаётся неподключённым, как бы уверенно ни назывался агент.
Автоматически изменять план вслед за найденной причиной не нужно. Агент может подготовить предложение пересмотра с основаниями, а уполномоченный сотрудник — принять его. Отдельно проверяют остановку работы и историю: какие записи вошли в отчёт, что исключили и почему появилась новая версия. Отчёт должен переживать вопрос «покажи, откуда это число» без коллективного поиска виноватого.
Даже в таблице можно построить воспроизводимый отчёт
Для первой проверки необязательно ждать интеграции всех сервисов. Возьмите согласованную выгрузку фактов, отдельный лист планов и справочник правил. В строке факта нужны идентификатор события, клиент или сделка, вид события, сумма, валюта, дата, ответственный и источник. Не копируйте в такой файл лишние персональные сведения: отчёту по суммам обычно не нужны полные переписки.
Официальная справка Microsoft о суммировании по нескольким условиям описывает SUMIFS: функция суммирует значения, отобранные по нескольким критериям. Это позволяет собрать простую проверку по периоду, сотруднику и типу факта. Формула не проверяет достоверность исходной суммы; она только аккуратно применяет заданные условия.
Порядок действий такой: сначала вручную сверяют несколько операций с первичными основаниями, затем собирают сумму по правилам, после сравнивают её с контрольной выгрузкой. Расхождения записывают отдельно: пустая дата, другая валюта, отменённая операция, дубль, отсутствие ответственного. Исправление одной строки не должно молча удалять след проблемы — иначе завтра она вернётся из того же источника.
Сохранённый срез нужен для воспроизводимости. Если через неделю карточки изменились, отчёт на прошлую пятницу должен объяснить, что было известно тогда. Для управленческой работы пригодны оба вида: «на дату среза» и «пересчитано сейчас». Подписывайте их. Исторический отчёт без даты состояния данных похож на фотографию, которую каждый вечер перерисовывают.
Приёмка отчёта проверяет исключения, а не только счастливую сумму
Подготовьте условный набор операций с заранее посчитанным результатом. Включите обычный заказ, частичную оплату, возврат, перенос даты, передачу сделки другому менеджеру, отмену и повтор строки. Для каждого сценария заранее запишите ожидаемую реакцию. Проверка, придуманная после просмотра результата, слишком легко становится объяснением того, что получилось.
Участники приёмки должны отвечать на разные вопросы. Руководитель подтверждает управленческий смысл. Финансист — согласованную базу денег и дат в своей зоне ответственности. Владелец CRM — источники и права. Менеджер проверяет, что его работу можно проследить до конкретной сделки. Не требуется, чтобы каждый понимал формулу импорта; требуется, чтобы итог был объясним тем, кто по нему действует.
| Проверка | Ожидаемый результат | Что сохранить |
|---|---|---|
| Повтор одной операции | Факт не удваивается | Идентификатор и правило исключения |
| Частичный платёж | В деньгах только подтверждённая часть | Связь с платёжным основанием |
| Изменение владельца | Прошлый период считается по принятому правилу | Дата и основание назначения |
| Отмена после закрытия месяца | Видна корректировка выбранного типа | Версия отчёта и причина |
| Пустая валюта или дата | Строка требует разбора | Отдельный список ошибок |
| Нулевой план | Нет некорректного процента | Подпись состояния плана |
Критерий выпуска простой: два человека, используя паспорт и один срез, получают одинаковый итог и находят основания существенных отклонений. Скорость пересчёта важна после этой проверки. Быстрая таблица, которую никто не может повторить, ускоряет споры, а не управление.
Цена отчёта — время решения, а не число графиков
Для небольшого отдела достаточно нескольких показателей и короткого разбора исключений. Если отчёт требует отдельного сотрудника только для обслуживания названий полей, возможно, задача раздулась. Начните с самого дорогого вопроса: почему не выполнен план заказов, почему поступления отстают от согласованного графика или где перенос срока требует вмешательства руководителя.
Стоимость процесса можно оценить собственными данными: время подготовки плюс время ручной сверки плюс время разбора ошибок. После пилота сравнивают ту же работу, включая труд проверки предложений ИИ. Экономию не считают по количеству сгенерированных комментариев. Комментарий полезен, если помогает принять своевременное решение или перестать делать ненужное действие.
Не стоит автоматизировать план-факт, когда план меняется устно каждый день, источники не подтверждают события, а ответственных за данные нет. Сначала нужен минимальный договор о смысле результата. Иначе агент получит роль самого быстрого участника общего недопонимания. Такой сотрудник уже встречается в компаниях, и обычно у него очень насыщенный календарь.
Что принести на первый разбор
Возьмите один завершённый период, плановую таблицу, обезличенную выгрузку фактов и несколько спорных операций. Отметьте, какие решения по отчёту действительно принимаются: перераспределение нагрузки, уточнение сроков, работа с конкретной сделкой. Дополнительно полезен список метрик отдела продаж, чтобы план-факт не пытался заменить всю управленческую картину.
Первый результат работы — согласованный паспорт и воспроизводимый расчёт на ограниченном срезе. Второй — список причин, которые требуют действий. Подключения, регулярный запуск и помощь агентов расширяют после проверки этих двух вещей. На следующем совещании руководитель должен открыть не самый эффектный график, а одно отклонение, по которому наконец понятно, что делать.
Источники и границы разбора
Проверено 6 ноября 2026. Первичные документы поясняют механизмы и определения, на которые опирается разбор. Методические примеры раскрыты в основном тексте.
- HubSpot — Create sales goals
Цель задаётся по показателю, участникам и периоду; не описание возможностей Цифры.
- Битрикс24 — Передать оплаченную сумму в сделку
Сумма сделки отличается от оплаченной суммы; платежи имеют подтверждение и валюту.
- Microsoft Excel — Sum values based on multiple conditions
SUMIFS суммирует по нескольким критериям; формула не проверяет истинность исходных данных.