Сегментация по оплатам в онлайн-школе

Сегментация по оплатам в онлайн-школе начинается не после продажи, а в момент, когда клиент создал заказ. Он может оплатить полностью, внести аванс, зависнуть на платёжной странице или отменить заказ. Для владельца это четыре разные ситуации. Для продажника - четыре разных действия. Для техспеца - четыре разных сценария автоматизации. Но денег ещё нет.

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

Заказ создан - это ещё не продажа

Ошибка начинается там, где «создал заказ» приравнивают к «купил». Это не так.

GetCourse в своей документации разделяет статусы заказов: среди актуальных есть «Новый», «В работе», «Не подтвержден», «Ожидает оплаты», «Отложен», «Частично оплачен». А к актуальным уже не относятся «Завершён» и «Отменён». Отдельно указано, что дата оплаты выбирает только полностью оплаченные завершённые заказы, а частично оплаченные туда не попадают.

Вот почему один общий этап «Заявка» в CRM ломает картину. В нём могут лежать четыре разных клиента:

Сценарий Vakas-tools (Вакас-тулз) как раз строится вокруг этой логики: каждый статус заказа запускает отдельное действие, дожим, напоминание о доплате, выдачу доступа или альтернативный оффер.

Почему проблема реальная, а не надуманная

Есть несколько подтверждений из открытых источников:

1. Незавершённая оплата - массовое явление в онлайне. По данным Baymard Institute, в онлайне часто теряются заказы уже на этапе оплаты: в среднем около 70% пользователей не доводят оформление до покупки. Это не статистика только по онлайн-школам, но онлайн-курс продаётся через тот же путь: заказ → оплата → подтверждение → доступ.
2. У онлайн-школ часто нет зрелой системы продаж. Zenclass пишет, что начинающие онлайн-школы часто не используют CRM, решения принимаются стихийно, а проблемы устраняются по факту. Там же отмечено, CRM помогает видеть закрытые и незакрытые сделки, этапы продаж и эффективность менеджеров.
3. Продажники страдают не из-за лени, а из-за отсутствия истории. В материале Zenclass про ошибки отдела продаж описана ситуация, когда менеджер звонит клиенту «как в первый раз», потому что школа не систематизирует базу, не пользуется CRM и не сохраняет историю контактов. Результат - раздражение клиента вместо продажи.
4. GetCourse отдельно описывает, как работать с неоплаченными заказами. Рекомендуется выяснить, что помешало оплатить, отправить ссылку на оплату, предложить скидку или другой вариант, а дальше присвоить заказу подходящий статус: «Ожидаем оплаты», «Не подтвержден» или «Отменен». При поступлении платежа статус должен измениться на «Завершен».
5. Онлайн-школа обычно работает на стыке нескольких сервисов. Albato описывает типовой стек: LMS, CRM, платёжная система, рассылки, рекламные кабинеты. Когда данные между ними не связаны, заявки теряются, менеджеры копируют информацию вручную, а ученики ждут доступ к курсу часами.

Вывод простой: проблема сегментации по оплатам не сводится к «надо поставить ещё один тег». Это разрыв между оплатой, CRM, доступом к курсу и действиями менеджера.

Какие статусы оплаты нужно разделять

Минимальный набор - четыре сегмента.

1. Оплатил полностью

Это закрытая сделка. Здесь нельзя дожимать оплату. Нельзя отправлять «вы забыли оплатить». Нельзя держать человека без доступа.

Правильный сценарий:

1. перевести сделку в «Оплачено»;
2. выдать доступ к курсу;
3. отправить приветственное письмо;
4. через 5–7 дней поставить задачу на допродажу.

Почему через 5–7 дней? Клиент уже купил, но ещё не успел остыть. Он находится в моменте доверия. Если продукт модульный, можно предложить наставничество, клуб, разборы, продвинутый тариф.

2. Частично оплатил

Самый опасный статус. Снаружи кажется: деньги пришли, всё хорошо. По факту часть суммы ещё не получена. Пример без кейса, только расчёт:

Курс стоит 30 000 ₽. Клиент внёс аванс 10 000 ₽. Остаток - 20 000 ₽.

Если таких клиентов 40, то в зоне риска: 40 × 20 000 ₽ = 800 000 ₽ остатка.

Даже если без напоминаний не доплатят только 20%, школа теряет: 8 × 20 000 ₽ = 160 000 ₽.

И это не «потенциальные лиды». Это люди, которые уже достали карту и внесли деньги. Можно настраивать частичную оплату и после внесения части суммы и присваивать заказу статус «Частично оплачен». Пользователю можно отправлять ссылку на частичную оплату индивидуально или массово через рассылку.

3. Создал заказ, но не оплатил

Это не мусор. Человек дошёл до оплаты. Значит, интерес был. Но что-то остановило: карта, лимит, комиссия, сомнение, неудобный момент, вопрос по тарифу. В сценарии Vakas-tools (Вакас-тулз) для такого сегмента используется каскад: SMS через 30 минут, email через 4 часа, звонок на следующий день. В сообщении можно подставить ссылку на оплату через переменную. Расчёт:

За запуск школа получила 600 созданных заказов. Средний чек - 18 000 ₽. Не оплатили 360.

Если автоматический дожим вернёт хотя бы 3%: 360 × 3% = 10,8 оплаты.

Округлим до 10 оплат: 10 × 18 000 ₽ = 180 000 ₽.

При 5% возврата: 18 оплат × 18 000 ₽ = 324 000 ₽.

Здесь теряют деньги тихо. Не потому что продукт плохой. А потому что никто не получил задачу вовремя.

4. Отменил или отказался

Отменённый заказ нельзя держать рядом с активными. Иначе продажник будет звонить человеку, который уже сказал «нет», а владелец увидит раздутую воронку. Аналитика станет грязной. Отменённые заказы можно оставлять в списке и указывать причину отказа, чтобы потом анализировать количество и причины отказов. Это полезно для владельца: если 40% отмен связаны с рассрочкой, проблема не в менеджерах. Проблема в финансовом предложении.

Как это видит технический специалист

Для техспеца сегментация по оплатам, это не «ещё один этап в CRM». Это схема передачи данных. Нужно, чтобы из источника заказов в Vakas-tools (Вакас-тулз) и дальше в CRM уходили:

1. статус платежа;
2. сумма оплаты;
3. остаток к оплате;
4. стоимость тарифа;
5. ссылка на оплату;
6. название продукта;
7. номер заказа;
8. ID пользователя.

В сценарии Vakas-tools (Вакас-тулз) эти данные используются для правил: источник заказов передаёт сумму, статус, остаток и ссылку на оплату, а дальше правила запускают действия в CRM и рассылках. Техспецу важно не просто «передать заказ». Нужно защититься от хаоса.

Что проверять:

1. Один заказ - одна карточка или одна сделка. Повторная оплата не должна создавать дубль.
2. Статус обновляется, а не затирается случайно. Было «Частичная оплата», стало «Оплачено» - сделка двигается дальше. Было «Оплачено», прилетел старый webhook «Новый» - сделку нельзя откатить назад.
3. Есть стоп-флаг для правил. Один заказ не должен одновременно попасть в «Не оплатил» и «Частично оплатил».
4. В карточке виден остаток. Продажнику не нужен квест по вкладкам. Ему нужно видеть: оплачено 5 000 ₽, остаток 10 000 ₽, ссылка на оплату здесь.
5. Есть лог ошибок. Если платёж прошёл, а CRM не обновилась, это надо увидеть до того, как клиент напишет злое сообщение в поддержку.

В Vakas-tools (Вакас-тулз) сценарий строится через правила по статусам: «оплачен», «в работе» с остатком, «новый» без оплаты, «отменён». Для каждого статуса можно назначить этап в CRM, SMS, email и задачу менеджеру.

Как это видит владелец онлайн-школы

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

Без сегментации владелец видит: «У нас 1 000 заказов».

С сегментацией видит другое:

1. 260 оплачено полностью;
2. 90 частично оплачено;
3. 610 создано без оплаты;
4. 40 отменено.

Это уже управленческая картина. Сразу появляются вопросы:

1. почему 610 человек дошли до заказа, но не оплатили;
2. сколько денег зависло в частичных оплатах;
3. кто из менеджеров лучше возвращает неоплаченные заказы;
4. какой тариф чаще бросают;
5. какие UTM-источники дают много созданных заказов, но мало оплат.

Пример:

Школа продаёт курс за 22 000 ₽. За неделю: 200 заказов созданы; 55 оплачены полностью; 25 частично оплачены по 7 000 ₽; 120 не оплачены.

На первый взгляд: 55 продаж.

Но остаток по частичным оплатам: 25 × 15 000 ₽ = 375 000 ₽.

Потенциал дожима неоплаченных при возврате 4%: 120 × 4% × 22 000 ₽ = 105 600 ₽.

Итого зона внимания: 375 000 ₽ + 105 600 ₽ = 480 600 ₽.

Это не гарантированная выручка. Но это деньги, которые владелец не увидит, если все статусы смешаны.

Как это видит продажник

Продажнику не нужна «автоматизация ради автоматизации». Ему нужно понимать, кому звонить и что говорить. Без сегментации он открывает CRM и видит список сделок. У всех одинаковый этап. У кого-то платёж прошёл. У кого-то аванс. У кого-то карта не сработала. У кого-то уже отмена. Начинается импровизация. А импровизация в продажах стоит дорого. Сегментация даёт менеджеру простой маршрут.

1. Оплатил полностью: > «Добрый день, вижу оплату, доступ уже открыт. Подскажите, удобно ли начать сегодня? Через неделю напомню про дополнительные разборы, они могут усилить результат».
2. Частично оплатил: > «Вы внесли 10 000 ₽, осталось 20 000 ₽. Отправляю ссылку, по ней можно закрыть остаток. Если удобнее разбить платёж, скажите - подберём вариант».
3. Создал заказ, не оплатил: > «Вы оформили заказ, но оплата не завершилась. Подскажите, технически что-то помешало или остались вопросы по программе?»
4. Отменил: > «Вижу, что заказ отменён. Можно уточнить причину? Это поможет понять, какой формат вам подойдёт: другой тариф, рассрочка или следующий поток».

Разница заметная. Продажник не давит на того, кто уже оплатил. Не забывает того, кто внёс аванс. Не тратит время на отменённые заказы как на активных.

Где теряются деньги

Ошибка 1. Неоплаченный заказ не получает задачу

Клиент дошёл до оплаты и пропал. Менеджер не увидел. Через день клиент уже остыл.

Потеря в расчётной модели: 300 неоплаченных заказов; средний чек 20 000 ₽; возможный возврат через дожим - 3%. 300 × 3% × 20 000 ₽ = 180 000 ₽. Здесь теряют не лиды. Здесь теряют людей с намерением купить.

Ошибка 2. Частичная оплата считается почти продажей

Аванс пришёл, менеджер расслабился. Остаток никто не контролирует.

Потеря: 50 частичных оплат; остаток по каждой - 12 000 ₽; 25% не доплатили без напоминаний. 50 × 25% × 12 000 ₽ = 150 000 ₽. Деньги зависают не в маркетинге, а в процессе.

Ошибка 3. Оплативший клиент не получает быстрый доступ

Клиент оплатил и ждёт. Администратор проверяет платежи раз в день. Доступ открыли через 6 часов. Формально продажа состоялась. Но клиент уже раздражён. Он пишет в поддержку, просит вернуть деньги, хуже относится к продукту. Vakas-tools (Вакас-тулз) в блоге о сбоях автоворонок описывает такую проблему: человек оплатил, а курс не открылся; если доступ не выдаётся быстро, появляется раздражение и риск возврата. Цена ошибки считается не только возвратами. Ещё есть нагрузка на поддержку, репутация и потерянные допродажи.

Ошибка 4. Отмены смешаны с активными сделками

Владелец смотрит в CRM и думает: «У нас большая база в работе». На деле половина уже отказалась. Продажники звонят не тем. Аналитика врёт. План продаж строится на воздухе.

Работаете в связке GetCourse и amoCRM? Изучите готовый сценарий настройки, чтобы статусы платежей, суммы и тарифы автоматически падали в карточку сделки без участия менеджера.

Как настроить сегментацию по оплатам в Vakas-tools (Вакас-тулз)

Схема простая: источник заказов → Vakas-tools (Вакас-тулз) → CRM и рассылки.

Шаг 1. Подключить источник заказов

Это может быть GetCourse, Prodamus или другой сервис, где создаются заказы и фиксируются оплаты. Vakas-tools (Вакас-тулз) получает данные автоматически: статус, сумму, остаток, ссылку на оплату, продукт и номер заказа.

Шаг 2. Подключить CRM и каналы связи

amoCRM, Битрикс24, PlanFix, Close, email, SMS, зависит от того, где работает команда. Главное - не просто передать контакт. Нужно передать смысл статуса.

Шаг 3. Создать правила по статусам

Минимальная логика:

1. Оплачен полностью:
   - Условие: статус = оплачен.
   - Действия: этап «Оплачено», письмо с доступом, задача на допродажу через 7 дней.
2. Частичная оплата:
   - Условие: статус = в работе, остаток больше 0.
   - Действия: этап «Частичная оплата», SMS с остатком и ссылкой, задача менеджеру через 3 дня.
3. Новый, не оплачен:
   -Условие: статус = новый, оплачено = 0.
   - Действия: SMS через 30 минут, email через 4 часа, звонок на следующий день.
4. Отменён:
   - Условие: статус = отменён.
   - Действия: этап «Отменён», письмо с вопросом о причине, задача на альтернативный оффер.

Эти сценарии соответствуют логике страницы Vakas-tools (Вакас-тулз): оплатившему - доступ и допродажа, частично оплатившему - напоминание об остатке, неоплатившему - дожим, отменённому - отдельная обработка.

Шаг 4. Проверить карточку сделки глазами менеджера

В карточке должны быть видны:

1. название курса;
2. тариф;
3. сумма заказа;
4. оплачено;
5. остаток;
6. статус;
7. ссылка на оплату;
8. история касаний.

Если менеджер должен открывать три сервиса, чтобы понять, что делать, сценарий недонастроен.

Шаг 5. Посчитать эффект

До настройки зафиксируйте: сколько заказов создаётся; сколько оплачивается полностью; сколько частично; сколько не оплачивается; сколько отменяется; средний чек; среднее время до первого касания. Через 2-3 недели сравните. Не только по выручке. Ещё по скорости реакции и чистоте CRM.

Когда не стоит усложнять сценарий

Сложная сегментация не нужна, если у школы 5 заказов в месяц и владелец сам каждый день проверяет оплаты. Но даже в этом случае нужен минимум: «Оплатил», «Не оплатил», «Частично оплатил», «Отменил».

Не стоит строить 20 этапов, если менеджер не понимает первые четыре. Не стоит запускать пять писем, если нет нормальной ссылки на оплату. Не стоит делать допродажу, если доступ после оплаты выдаётся вручную и с задержкой. Сначала порядок. Потом сложные сценарии.

Вывод

Сегментация по оплатам, одна из первых автоматизаций, которую стоит настраивать в онлайн-школе. Не потому что это модно. А потому что она убирает слепую зону между «клиент оформил заказ» и «деньги пришли».

1. Техспец получает понятную схему данных.
2. Владелец видит, где зависают деньги.
3. Продажник понимает, кому звонить и с каким смыслом.

Главный принцип простой: каждый статус оплаты должен запускать своё действие. Оплатил - доступ и следующий шаг. Частично оплатил - остаток и напоминание. Не оплатил - дожим. Отменил - причина отказа и отдельный сценарий. Иначе CRM превращается в список надежд. А школе нужна не надежда, а управляемая выручка.