Прогнозная модель (Forecast Model Template)

Qualified pipeline = target accounts reached × engaged rate × meeting rate × opportunity rate × average pipeline value. Модель показывает, какой именно коэффициент должен измениться для достижения плана.

Прогнозировать итоговую цифру без drivers. Тогда forecast невозможно использовать для управления.

Шаблон особенно полезен, если одной метрикой пользуются несколько команд, данные собираются из разных систем или расчёт влияет на бюджет и решения. Для одноразового анализа допустима облегчённая версия, но definition и источник данных всё равно должны быть указаны. Чем дольше живёт показатель, тем важнее governance и change log.

• Начните с решения и бизнес-вопроса, а не с доступных таблиц. Это определит, какие метрики и уровень детализации действительно нужны.
• Зафиксируйте definitions, grain, time window и source of truth до построения расчётов. Одинаковое название не гарантирует одинаковую метрику.
• Проверьте качество данных: полноту, дубли, пропуски, изменения tracking и структурные разрывы во времени.
• Для прогнозов и моделей явно храните assumptions, диапазоны и сценарии. Не маскируйте неопределённость одной точной цифрой.
• Назначьте owner и cadence пересмотра. Аналитический артефакт без ответственного и правил обновления быстро перестаёт быть источником истины.

Pipeline forecast строится через target accounts, engagement, meetings, opportunity rate и average value. Если план не сходится, видно, какой driver должен измениться.

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

• У каждой метрики есть точная definition.
• Источник данных и grain указаны.
• Метод позволяет ответить именно на поставленный вопрос.
• Неопределённость, лаги и limitations не скрыты.
• Есть owner и правило обновления.

Пересматривайте определения при изменении tracking, CRM, data model, business logic или accounting rules. Любое изменение формулы должно иметь change log, дату вступления в силу и оценку влияния на исторические сравнения.

Нужно ли хранить все метрики в одном документе?

Нет. Канонический dictionary и measurement plan должны быть связаны, но operational dashboards могут показывать только релевантный subset.

Что делать, если источники дают разные цифры?

Назначить source of truth и документировать расхождение. Нельзя тихо выбирать источник, который показывает более удобный результат.

Как часто пересматривать модель?

По cadence бизнеса и при изменении данных. Forecast и campaign metrics могут обновляться часто, definitions и governance — реже, но обязательно после системных изменений.

• KPI Tree
• Unit Economics Model
• MMM Input Specification

• Demand Forecasting
• Revenue Forecasting
• Lead & Pipeline Forecasting