Модуль 13

Forecast и планирование capacity

Прогнозируй объём результата и управляй нагрузкой так, чтобы качество не падало. Модель Low/Base/High, лаги, capacity caps и quality gates.

4 урока ~3–4 часа 2 шаблона
Урок 13.1

Карта воронки и definitions (что именно прогнозируем)

теория

Forecast без чётких definitions — это споры и "рисование цифр". Capacity без definitions — хаос. Прежде чем прогнозировать, нужно договориться о терминах.

Единые стадии воронки

Минимальный набор стадий, которые нужно отслеживать:

  • Prospects — целевые компании/контакты в работе
  • Replies — живые ответы (не автоответы)
  • SQL — квалифицировано SDR по критериям
  • SAO — принято AE (Sales Accepted Opportunity)
  • Held — встреча состоялась
  • Opp — создана возможность в CRM

Почему это важно

Каждая команда должна иметь единые критерии перехода между стадиями. Типичные проблемы без definitions:

  • SDR и AE спорят что считать SQL
  • Forecast показывает одно, факт — другое
  • Команда начинает "оптимизировать" под метрики, а не под результат
Правило

Прогнозируем не "чувства", а конверсии по стадиям. Каждая стадия должна иметь чёткие критерии входа.

Урок 13.2

Модель прогнозирования (входы → выходы + лаги)

практика

Простой forecasting строится на трёх компонентах: объём входа, конверсии между стадиями, и лаги — время между действием и результатом.

Простой рабочий forecasting-скелет

  • Вход: сколько целевых компаний/контактов берём в работу за неделю
  • Конверсии: Reply→SQL, SQL→SAO, SAO→Held, Held→Opp
  • Лаги: через сколько дней ответы/встречи/opp появляются (обычно 3–21 день)
Критично

Forecast = (объём) × (конверсии) × (учёт лагов). Если лаги игнорировать — прогноз всегда "сломается".

Минимальный набор допущений

  • Конверсии берём из последних 2–6 недель
  • Если поменяли ICP/оффер — конверсии "обнуляются", нужны новые данные
  • Всегда держим диапазон: low/base/high

Low/Base/High модель

Никогда не давай один "точный" прогноз — давай диапазон:

  • Low: конверсии -20% от текущих (пессимистичный сценарий)
  • Base: как сейчас (реалистичный)
  • High: +20% (если улучшения сработают)
Честно

Один "волшебный показатель" не спасёт. Прогноз — это всегда диапазон, а не точка.

Урок 13.3

Capacity: люди, объём, нормы (сколько команда переварит)

теория практика

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

Capacity-логика (без магии)

  • У каждого SDR есть "производственная мощность" в неделю
  • Мощность зависит от: глубины персонализации, количества каналов, объёма inbox, числа встреч
  • Если перегрузить inbox — упадут ответы и качество

Что ограничивает SDR (обычно)

Три основных bottleneck'а:

  • Inbox — сколько диалогов можно вести одновременно (30–60 активных)
  • Research — сколько аккаунтов можно персонализировать в день
  • Scheduling — сколько встреч можно подготовить/подтвердить

Как планировать без точных норм

Если у тебя нет исторических данных:

  1. Фиксируешь текущую скорость (baseline) на 2 недели
  2. Ставишь "cap" на inbox (например, 30–60 активных диалогов)
  3. На рост добавляешь людей/автоматизацию, а не давление
Правило роста

Рост = увеличение capacity (люди, инструменты), а не "ускориться любой ценой". Давление на существующую команду даёт краткосрочный эффект и долгосрочную деградацию.

Урок 13.4

Quality gates: как не убить качество при росте

теория

Quality gates — это контрольные точки, которые не дают масштабировать проблемы. Если гейт не пройден — не увеличиваем объём.

4 "гейта" качества

  • ICP gate: право сказать "не наш клиент" без давления брать всех подряд
  • Message gate: библиотека офферов/кейсов, единые формулировки
  • QA gate: регулярная оценка качества встреч и хэндовера
  • SLA gate: скорость реакции AE на переданные лиды

Анти-правила (что нельзя делать)

  • Нельзя "заливать объём", если падает SQL→SAO — сначала чиним качество
  • Нельзя брать клиента/проект сверх capacity команды
  • Нельзя менять 5 переменных сразу — не поймёшь, что сработало
Признак провала

Больше встреч → меньше доверия sales → pipeline падает. Это спираль, которую сложно остановить. Лучше не начинать.

Выход модуля

После этого модуля у тебя должно быть:

  • Прогноз на 4 недели в формате low/base/high
  • Capacity cap по нагрузке на каждого SDR
  • Чёткие правила, когда "не берём сверх лимита"

Шаблоны

Готовые шаблоны для forecast и capacity planning. Скопируй и адаптируй под свою команду.

Шаблон 13A — Forecast (low/base/high) + лаги

FORECAST (4 недели)
======================================

ВХОД (weekly):
- Prospects в работу: ____
- Expected reply rate: ____%

КОНВЕРСИИ:
- Reply→SQL: ____%
- SQL→SAO: ____%
- SAO→Held: ____%
- Held→Opp: ____%

ЛАГИ (дней):
- Reply lag: ____ (обычно 3-7)
- Meeting lag: ____ (обычно 7-14)
- Opp lag: ____ (обычно 14-21)

ДИАПАЗОН:
- LOW: конверсии -20%
- BASE: текущие
- HIGH: +20%

ПРОГНОЗ НА НЕДЕЛЮ:
              | LOW | BASE | HIGH
--------------+-----+------+-----
Replies       |     |      |
SQL           |     |      |
SAO           |     |      |
Held          |     |      |
Opp           |     |      |

======================================
Дата прогноза: ____
Период: ____
Ответственный: ____

Шаблон 13B — Capacity & Caps

CAPACITY PLAN
======================================

КОМАНДА:
- SDR count: ____
- AE count: ____
- SDR/AE ratio: ____

CAPS (на 1 SDR в неделю):
- Active dialogs cap: ____ (рекомендуем 30-60)
- Personalized accounts: ____
- Meetings scheduled: ____
- Meetings held: ____

SLA:
- AE accept SQL: ≤ __h
- First touch после assign: ≤ __h
- Feedback по reject: ≤ __h

ПРАВИЛО "НЕ БЕРЁМ СВЕРХ":
Условия остановки входящего потока:
1. Active dialogs > cap
2. SQL→SAO падает ниже ___%
3. Reply rate падает ниже ___%

ДЕЙСТВИЯ ПРИ ПЕРЕГРУЗКЕ:
□ Уменьшить входящий объём на ___%
□ Добавить SDR (если capacity = bottleneck)
□ Пересмотреть ICP (если конверсия = bottleneck)

======================================
Дата: ____
Пересмотр: каждые 2 недели
← Предыдущий Модуль 12: Масштабирование Следующий → Бонус: Лайфхаки и ресурсы