Когда онлайн-школа запускает новый поток, команда собирает план: сколько человек хотим продать, какой бюджет заложили на рекламу, сколько выручки ожидаем. Через месяц после старта приходят фактические цифры — оплаты, расходы, возвраты. План-факт анализ сводит эти два массива в один отчёт и показывает, где совпали ожидания с реальностью, а где разошлись. Без сравнения плана и факта отклонения видны только косвенно, через общую динамику, и понять причину сложнее.
Обычно план-факт собирают в таблице: строки — запуски или потоки, столбцы — плановые и фактические показатели, последний столбец — отклонение в процентах или рублях. Если школа работает в GetCourse, данные о транзакциях выгружают через API или вручную, бюджет берут из рекламного кабинета или CRM, плановые цифры — из финмодели. Всё это сводят в Google Sheets, Looker Studio или Power BI.
Какие показатели включить в план-факт
Минимальный набор — выручка, количество оплат и средний чек. Эти три метрики дают первое представление о том, выполнен ли план продаж. Если выручка ниже цели, сразу видно, из-за чего: меньше клиентов купило или они выбрали более дешёвый тариф.
Дальше добавляют расходы на привлечение: бюджет на рекламу, комиссии платформ, партнёрские выплаты. Это позволяет посчитать маржинальную прибыль и понять, окупился ли запуск. Если выручка выполнена, но расходы превысили план в полтора раза, итоговая рентабельность может оказаться отрицательной.
Полезно включить метрики воронки: количество регистраций на вебинар, явку, конверсию в покупку. Так становится понятно, на каком этапе план разошёлся с реальностью. Например, регистраций пришло по плану, а конверсия в оплату упала — значит, проблема в презентации или оффере, а не в трафике.
Последний блок — операционные показатели: количество возвратов, отмен подписок, обращений в поддержку. Они не всегда попадают в классический план-факт, но помогают объяснить отклонения. Если возвратов больше обычного, фактическая выручка снизится даже при хорошей конверсии. Не стоит перегружать отчёт десятками метрик — лучше выбрать пять–семь ключевых показателей, которые влияют на решения.
Почему план и факт должны иметь одинаковые определения
Одна из частых ошибок — несовпадение методик расчёта. Например, в плане заложили выручку по дате старта потока, а в факте считают по дате зачисления денег на счёт. Между этими событиями может пройти неделя, и часть оплат сдвинется в следующий период. Отчёт покажет провал, хотя клиенты заплатили вовремя.
То же самое с количеством продаж. Если в плане учитывали все заявки с меткой «оплачено», а в факте считают только успешные транзакции без возвратов, цифры разойдутся. Или в плане средний чек считали по полной стоимости курса, а в факте — по первому платежу в рассрочке. Формально обе цифры правильные, но сравнивать их бессмысленно.
Чтобы этого избежать, нужно зафиксировать определения метрик до запуска. Прописать, что считается оплатой, в какой момент она попадает в отчёт, как учитывают возвраты и переносы, какой период берут для расчёта. Эти правила должны быть одинаковыми для плана и факта. Если в плане закладывали выручку по дате создания заказа, в факте тоже берут эту дату, а не дату поступления средств.
Когда методика меняется — например, школа перешла на новую CRM или изменила учётную политику — нужно пересчитать исторические данные по новым правилам или явно отметить разрыв в отчёте.
Как учесть перенос оплаты
Клиенты часто платят не сразу в момент покупки, а частями: первый платёж при старте, остальные — через неделю, месяц или после завершения курса. Ещё бывают ситуации, когда платёжная система задерживает зачисление, клиент попросил отсрочку или оплата прошла, но потом вернулась из-за технической ошибки.
Если считать выручку строго по дате транзакции, план-факт за текущий месяц будет неполным: часть денег физически придёт позже, хотя продажа уже состоялась. Чтобы это учесть, используют метод начисления: оплату относят к периоду, когда клиент совершил покупку, независимо от того, когда деньги зачислились на счёт.
Технически это выглядит так: в CRM или учётной системе у каждой транзакции две даты — дата заказа и дата платежа. Для план-факт анализа берут дату заказа. Если клиент купил курс 15 марта, а заплатил 22 марта, выручка попадает в мартовский отчёт.
Для рассрочек логика та же: полную сумму курса записывают в план и факт того месяца, когда клиент подписал договор, но отдельно отслеживают график платежей. Если клиент не внёс второй платёж, это фиксируют как просрочку, а не как снижение выручки текущего периода. Когда отчёт строится в Google Sheets или BI-системе, для этого создают отдельное поле «Период начисления» и группируют данные по нему.
Какие отклонения требуют пояснения
Не каждое расхождение плана и факта критично. Если выручка выполнена на 98% вместо 100%, это нормальная погрешность. Но если план сорван на 20% или больше, нужно понять причину и зафиксировать её в отчёте.
Распространённый порог для комментария — отклонение больше 10–15%. В комментарии пишут не оправдание, а факт: изменили креативы в рекламе, конкурент запустил акцию, технический сбой на платформе, отменили вебинар из-за болезни спикера. Эта информация помогает при планировании следующего запуска: если провал случился из-за разовой ситуации, её можно не закладывать в прогноз, а если из-за системной проблемы — нужно учесть.
Комментарии особенно важны для нефинансовых метрик. Например, конверсия в покупку упала с 8% до 5%. Причин может быть несколько: изменили скрипт продаж, запустились в другом сегменте аудитории, подняли цену. Без пояснения через три месяца уже не вспомнишь, что именно повлияло.
Иногда отклонение формально небольшое, но структура изменилась. Выручка выполнена на 100%, но за счёт того, что продали в два раза больше дешёвых тарифов и в два раза меньше дорогих. Это тоже требует комментария, потому что влияет на рентабельность и удержание клиентов. Комментарии удобно хранить в той же таблице, что и план-факт, в отдельном столбце.
Как использовать отчёт после запуска
План-факт анализ не заканчивается констатацией отклонений. Главная ценность отчёта — в решениях, которые принимают на его основе. Если конверсия просела, команда корректирует скрипт продаж или меняет посадочную страницу. Если расходы выросли, пересматривают рекламные каналы или ставки. Если средний чек ниже плана, тестируют допродажи или пересобирают линейку тарифов.
Удобно вести историю отчётов: сохранять план-факт по каждому запуску и раз в квартал сравнивать динамику. Так видно, какие гипотезы сработали, а какие нет. Например, если конверсия несколько запусков подряд растёт после добавления бонуса за быструю оплату, механику можно масштабировать.
Отчёт также помогает планировать бюджет на следующий период. Если фактическая стоимость привлечения клиента стабильно на 15% выше плановой, в следующий раз закладывают именно эту цифру, а не оптимистичный прогноз. Это снижает риск кассовых разрывов и делает финмодель реалистичнее.
Если в школе уже есть регулярные запуски потоков, можно начать с минимального отчёта: три–пять главных метрик, фактические данные из CRM, сравнение с целями и комментарий к каждому существенному отклонению. Если такой отчёт помог найти хотя бы одну неочевидную точку роста или объяснить провал, его стоит встроить в регулярную работу команды.