Как проверить техническую готовность онлайн-школы перед запуском: чек-лист из 17 тестов

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

В онлайн-школе один клиентский путь часто проходит через пять-шесть систем: сайт принимает заявку, интегратор передает данные, CRM создает сделку, платежный сервис подтверждает оплату, учебная платформа выдает доступ, сервис рассылок отправляет письмо. Достаточно одной неверно сопоставленной переменной или одного устаревшего webhook, чтобы заявка исчезла, оплата не отразилась, а ученик остался без курса.

Поэтому перед запуском недостаточно открыть каждую систему и убедиться, что в ней «все включено». Нужен сквозной тест: пройти тот же путь, который пройдет реальный ученик, и проверить результат на каждом этапе.

Ниже приведен практический чек-лист из 17 тестов. Его можно использовать перед вебинаром, продажей курса, запуском нового тарифа или после изменения любой части воронки.

Почему проверка отдельных сервисов не заменяет сквозной тест

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

Принцип приемки один: не «настроено», а «проверено на конкретном тестовом пользователе».

Что подготовить до начала проверки

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

Подготовьте:

1. два новых email-адреса или алиаса, например launch+new@domain.ru и launch+repeat@domain.ru;
2. номер телефона, которого еще нет в базе;
3. тестовый или минимальный платеж, разрешенный вашей платежной системой;
4. отдельный тестовый тариф или предложение;
5. таблицу результатов: тест, время, использованные контакты, ожидаемый результат, фактический результат, ссылка на запись в CRM или LMS;
6. ответственного, который принимает решение: можно запускаться или нет.

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

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

Короткий чек-лист: 17 обязательных тестов

№	Тест	Что должно получиться
1	Отправка формы	Пользователь видит правильный экран после регистрации, форма не зависает
2	Передача email и телефона	В следующих системах сохранены исходные значения без обрезки и подмены
3	Создание нового пользователя	Контакт, сделка или ученик созданы с верным источником и UTM-меткой
4	Повторная регистрация	Система действует по заранее выбранной логике и не создает случайный дубль
5	Вебинарная комната	Зритель попадает в эфир по ссылке из письма, а факт посещения возвращается в воронку
6	Полная тестовая оплата	Заказ получает статус полной оплаты, сумма и тариф совпадают
7	Частичная оплата	Частичный платеж не превращается в полный и запускает только разрешенные действия
8	Выдача доступа	Ученик получает доступ именно к оплаченному продукту и на нужный срок
9	Закрытие доступа	После окончания срока или отмены доступ закрывается по правилам школы
10	Письма и уведомления	Сообщения приходят один раз, вовремя и с правильными данными
11	Ссылки	Все кнопки ведут на актуальные страницы, параметры и персональные ссылки не ломаются
12	Аналитика и цели	Каждое целевое действие фиксируется один раз, а отчет сходится с числом заявок в CRM
13	Мобильный сценарий	Форму, оплату, письмо и вход в курс можно пройти с телефона
14	Возврат	Возврат отражается в платежах, CRM и доступах по принятой логике
15	Журнал ошибок	По тестовому контакту видна последовательность событий и причина сбоя
16	Задержки и повторные события	Поздний или повторный webhook не создает лишних учеников, заказов и уведомлений
17	Недоступность одного сервиса	Ошибка обнаруживается, данные не теряются, а команда знает порядок восстановления

1. Проверьте форму регистрации

Что сделать. Откройте опубликованную страницу в режиме инкогнито и отправьте форму как новый пользователь. Затем повторите тест с незаполненным обязательным полем, ошибочным email и телефоном в другом привычном формате.

Проверьте:

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

Тест пройден, если пользователь понимает, что регистрация состоялась, а в первой принимающей системе появилась ровно одна запись.

2. Проверьте передачу телефона и email

Факт появления заявки еще не означает, что данные передались корректно. В CRM может прийти имя, но потеряться телефон. Номер может сохраниться без кода страны, а email может прийти с пробелом в конце. В результате менеджер не дозвонится, письмо не отправится, а следующая система не найдет существующего пользователя.

Что сделать. Отправьте форму с заранее записанными значениями и сравните их во всех точках маршрута:

1. в конструкторе сайта или журнале заявок;
2. в интеграторе;
3. в CRM;
4. в сервисе рассылок;
5. в учебной платформе.

Отдельно проверьте названия и назначение полей. Например, в корзине Tilda для имени, email и телефона должен быть выбран соответствующий тип поля. Иначе внешняя система может получить значение не в той переменной.

Тест пройден, если email и телефон совпадают с исходными значениями, а поиск по каждому из них находит одного и того же человека.

3. Проверьте создание нового пользователя

Используйте контакт, которого гарантированно нет ни в CRM, ни в учебной платформе. После регистрации проверьте не только сам факт создания записи, но и ее содержание.

У нового пользователя должны быть корректны:

1. имя, телефон и email;
2. источник и UTM-метки;
3. продукт или мероприятие;
4. ответственный менеджер, если он назначается автоматически;
5. воронка и этап сделки;
6. дата и время регистрации;
7. согласованные теги и дополнительные поля.

Если по сценарию ученик создается только после оплаты, отсутствие его в LMS после простой регистрации будет нормальным результатом. Важно заранее зафиксировать именно вашу бизнес-логику, иначе команда будет считать ошибкой то, что настроено намеренно.

Тест пройден, если новый пользователь появился во всех положенных системах и нигде не создался преждевременно.

4. Проверьте повторную регистрацию

Повторная регистрация относится к самым недооцененным сценариям. Человек может записаться на два вебинара, вернуться с другой рекламы или повторно отправить форму, потому что не заметил страницу благодарности.

Что сделать. Повторно отправьте форму:

1. сначала с теми же email и телефоном;
2. затем с тем же email, но другим телефоном;
3. затем с тем же телефоном, но другим email.

До теста определите ожидаемую логику. Возможны разные варианты: обновить существующий контакт, создать новую сделку для другого продукта, сохранить первую UTM-метку или заменить ее новой. Единственного правильного поведения нет. Ошибка начинается тогда, когда поведение не определено.

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

Тест пройден, если результат соответствует заранее выбранной логике и повторная отправка не создала случайную россыпь контактов, сделок и писем.

5. Проверьте доступ к вебинарной комнате

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

Что сделать. Зарегистрируйтесь на тестовый вебинар новым контактом и пройдите путь зрителя до конца, а не только до страницы благодарности.

Проверьте:

1. ссылка на комнату приходит в письме и в мессенджере и открывается без дополнительного пароля;
2. персональная ссылка действительно персональная и не пускает под чужим именем;
3. комната открывается за оговоренное время до старта, а не за минуту;
4. дата и время указаны в одной часовой зоне на лендинге, в письме и в самой комнате;
5. напоминания приходят по расписанию и не дублируются;
6. чат, презентация и кнопка оффера работают у зрителя, а не только у ведущего;
7. ссылка на запись уходит тем, кому положено, и открывается без входа в чужой аккаунт;
8. факт посещения и время просмотра возвращаются в CRM или в базу для сегментации.

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

Если вебинарная комната подключена через Vakas-tools, в карточке тестового контакта видны связанные регистрации и вебинары. Так проще убедиться, что посещение записалось именно тому человеку, который регистрировался.

Тест пройден, если зритель попадает в эфир по ссылке из письма, а после эфира его статус посещения корректно виден в той системе, на которую настроены дожимные сценарии.

6. Проведите полную тестовую оплату

Не ограничивайтесь сообщением «Платеж успешен» на странице оплаты. Подтверждение должно пройти всю цепочку.

Что сделать. Оплатите тестовый тариф в тестовом режиме платежной системы или на минимальную разрешенную сумму. Запишите время оплаты и проверьте:

1. сумму, валюту и название тарифа;
2. номер заказа;
3. статус «Оплачен»;
4. появление платежа в платежной системе и учетной платформе;
5. изменение этапа сделки в CRM;
6. запуск только тех автоматизаций, которые привязаны к полной оплате;
7. отсутствие второго заказа при повторной отправке уведомления.

Если продажа идет через Tilda, учитывайте выбранную схему: стандартный webhook оплаты может передавать именно полностью оплаченные заказы, а неоплаченные заявки требуют отдельной настройки. Проверять нужно не абстрактную «интеграцию с Tilda», а тот вариант передачи, который используется в вашем запуске.

Тест пройден, если одна реальная операция превратилась в один корректный оплаченный заказ во всех системах.

7. Проверьте частичную оплату

Этот тест нужен школам с предоплатой, рассрочкой или оплатой частями. Самая опасная ошибка в том, чтобы приравнять первый платеж к полной оплате и открыть весь курс, хотя по бизнес-логике этого делать нельзя.

Что сделать. Создайте заказ на полную стоимость тарифа и внесите только часть суммы. Проверьте:

1. статус заказа: «Частично оплачен», а не «Оплачен»;
2. поля «Оплачено» и «Осталось оплатить»;
3. этап сделки в CRM;
4. письмо, задачу менеджеру или другой сценарий дожима остатка;
5. объем доступа, который положен после первого платежа;
6. реакцию системы на второй платеж и переход в полную оплату.

Vakas-tools (Вакас-тулз) может получать и передавать частичную оплату как отдельное событие в поддерживаемых связках. Поэтому для правил полной и частичной оплаты нужны разные условия и ожидаемые действия.

Тест пройден, если первый платеж не запускает действия полной оплаты, а после внесения остатка статус, доступ и коммуникации обновляются без дублей.

8. Проверьте выдачу доступа

После успешной оплаты войдите в учебную платформу именно под тестовым учеником, а не под администратором.

Проверьте:

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

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

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

9. Проверьте закрытие доступа

Доступ должен не только открываться, но и закрываться. Это особенно важно для подписок, аренды курса, рассрочки с условиями и продуктов с фиксированным сроком обучения.

Что сделать. На тестовом продукте установите короткий срок или вручную воспроизведите событие, которое должно закрыть доступ: окончание подписки, перевод заказа в нужный статус или отмену по правилам школы.

Проверьте:

1. закрылся ли правильный курс;
2. сохранился ли доступ к уже оплаченным другим продуктам;
3. изменился ли статус ученика или сделки;
4. отправилось ли предусмотренное уведомление;
5. может ли менеджер увидеть причину закрытия.

Некоторые интеграции Vakas-tools (Вакас-тулз) с LMS поддерживают отдельные действия открытия и закрытия доступа. Например, в документации для Zenclass описано создание и обновление студентов, а также открытие и закрытие курса; для Skillspace описаны выдача и отзыв доступа. Возможности и условия нужно проверять для вашей конкретной платформы.

Тест пройден, если доступ закрывается адресно и не затрагивает остальные покупки ученика.

10. Проверьте письма и уведомления

Проверьте всю коммуникацию, а не только первое письмо после регистрации. Минимальный набор зависит от воронки, но обычно включает подтверждение регистрации, ссылку на эфир или оплату, уведомление об оплате, данные для входа и напоминания.

Для каждого сообщения проверьте:

1. дошло ли оно и сколько времени заняла доставка;
2. не попало ли в спам;
3. корректны ли имя отправителя, тема и адрес ответа;
4. подставились ли имя, дата, тариф и другие переменные;
5. одна ли часовая зона указана на лендинге и в письме;
6. не пришло ли одно событие дважды;
7. не отправилось ли письмо полной оплаты после частичной.

Тестируйте минимум в двух почтовых сервисах и, если используются мессенджеры, отдельно проверяйте сообщения в каждом канале.

Тест пройден, если ученик получает нужные сообщения в правильной последовательности и может понять, что делать дальше, не обращаясь в поддержку.

11. Проверьте все ссылки

Ссылка может выглядеть правильно в шаблоне, но ломаться после подстановки переменных, редиректа или открытия из мобильного приложения.

Пройдите по каждой ссылке из:

1. страницы благодарности;
2. писем и сообщений;
3. кнопки оплаты;
4. личного кабинета;
5. напоминаний о вебинаре;
6. сообщения менеджера, если оно формируется автоматически.

Проверьте протокол HTTPS, домен, страницу назначения, UTM-метки, персональные параметры, срок жизни ссылки и доступ без авторизации. Не используйте для приемки только клик из редактора письма. Откройте реально полученное сообщение.

Тест пройден, если все ссылки ведут в актуальное место, не требуют от ученика угадывать логин и не раскрывают данные другого пользователя.

12. Проверьте аналитику и цели

Технически исправный запуск может оказаться неуправляемым: заявки приходят, а в отчете рекламного кабинета их нет. Тогда оптимизация работает вслепую, а решение отключить связку принимается по неверным данным. Аналитика такая же часть маршрута, как CRM и учебная платформа.

Что сделать. Пройдите регистрацию и оплату с включенными инструментами отладки и убедитесь, что каждое целевое действие зафиксировано ровно один раз.

Проверьте:

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

Сверьте три числа за один и тот же период: заявки в конструкторе сайта, достижения цели в системе аналитики и контакты в CRM. Расхождение в несколько процентов объяснимо, расхождение в разы означает, что часть пути не считается.

Тест пройден, если каждое действие тестового ученика видно в аналитике ровно один раз, а количество заявок в отчете сходится с количеством записей в CRM.

13. Пройдите весь путь с мобильного устройства

Даже адаптивный лендинг не гарантирует работоспособность мобильного сценария. Клавиатура может перекрыть кнопку, маска телефона может не принять номер, а окно платежной системы может открыться внутри браузера мессенджера и не вернуть пользователя обратно.

Что сделать. Пройдите регистрацию и оплату с реального телефона:

1. откройте ссылку из Telegram или другого источника трафика;
2. заполните форму;
3. оплатите тестовый заказ;
4. откройте полученное письмо;
5. войдите в кабинет ученика;
6. запустите первый урок.

Желательно проверить хотя бы iPhone/Safari и Android/Chrome, а также встроенный браузер основного рекламного источника.

Тест пройден, если путь можно завершить без перехода на компьютер, горизонтальной прокрутки и ручного копирования непонятных ссылок.

14. Проверьте возврат

Возврат часто тестируют уже на реальном недовольном клиенте. Лучше заранее выяснить, какое событие получает каждая система и что происходит с доступом.

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

1. статус операции в платежном сервисе;
2. статус и сумму заказа в учетной системе;
3. этап сделки и поля оплаты в CRM;
4. доступ к курсу;
5. автоматические письма и задачи;
6. корректность повторной покупки после возврата.

Не предполагается, что возврат всегда должен мгновенно закрывать курс. Иногда школа оставляет доступ, иногда закрывает его полностью, иногда решение принимает менеджер. Важно, чтобы фактическое поведение совпадало с утвержденным регламентом.

Тест пройден, если возврат нигде не выглядит как действующая полная оплата, а доступ меняется именно по правилам школы.

15. Проверьте журнал ошибок и путь диагностики

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

Возьмите любой тестовый контакт и восстановите по нему цепочку:

1. когда отправлена форма;
2. когда регистрация принята;
3. какое правило сработало;
4. куда отправлены данные;
5. какой ответ вернул следующий сервис;
6. создан ли заказ;
7. когда пришла оплата;
8. какое действие выдало доступ.

Затем безопасно воспроизведите ошибку в тестовом контуре: например, укажите несуществующий код тестового предложения или отключите только тестовое правило. Не ломайте рабочий токен перед запуском.

В Vakas-tools (Вакас-тулз) для этого можно использовать логи контакта и раздел «История событий». В истории видны событие, сработавшее правило, сервис назначения и статус выполнения; в деталях ошибки видны отправленный запрос, ответ сервиса и текст ошибки. Неуспешные данные можно отправить повторно из истории событий.

Тест пройден, если сотрудник, который не настраивал интеграцию, способен за несколько минут назвать точку сбоя и дальнейшее действие.

16. Проверьте задержки и повторные события

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

Что сделать. На тестовом заказе проверьте три ситуации:

1. быстро оплатите заказ сразу после его создания;
2. повторно отправьте одно и то же тестовое событие из журнала;
3. дождитесь обработки всех очередей и сравните результат через 15-20 минут.

В GetCourse, например, процессы могут обрабатываться с интервалом, поэтому мгновенное отсутствие результата не всегда означает потерю данных. Но задержка должна быть известна команде и укладываться в согласованный срок.

Тест пройден, если повторное событие обновляет нужную запись или безопасно игнорируется, а не создает второй заказ, второй доступ и три одинаковых письма.

17. Проверьте сценарий недоступности одного из сервисов

Перед запуском команда должна знать ответ не только на вопрос «что работает?», но и на вопрос «что делаем, если один сервис временно не отвечает?».

Проверяйте это в тестовом контуре. Например, временно отключите тестовое действие передачи в CRM или используйте недействительный тестовый идентификатор. Затем отправьте форму и убедитесь, что ошибка обнаруживается.

Зафиксируйте:

1. где появляется ошибка;
2. кто и как узнает о ней;
3. сохраняются ли исходные данные;
4. можно ли повторить отправку после восстановления;
5. как собрать заявки вручную за период сбоя;
6. какой канал используется для экстренной выдачи доступа;
7. кто принимает решение остановить рекламу или продолжить запуск;
8. сколько времени допустимо на восстановление.

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

Тест пройден, если после восстановления сервиса тестовая заявка доходит до конца, не создавая дублей, а команда может повторить этот процесс по короткой инструкции.

Как провести приемку запуска за один проход

Чтобы проверка не превратилась в хаотичное переключение между кабинетами, двигайтесь по шагам.

Шаг 1. Нарисуйте маршрут данных

Запишите цепочку одним предложением: «лендинг → интегратор → CRM → платежная система → учебная платформа → рассылка». Для каждого перехода укажите, какое событие идет дальше: регистрация, заказ, частичная оплата, полная оплата, возврат.

Шаг 2. Назначьте ожидаемый результат

Для каждого из 17 тестов заранее напишите, что должно произойти. Формулировка «проверить оплату» слишком расплывчата. Рабочая формулировка: «после платежа 1 000 рублей заказ №… получает статус “Оплачен”, сделка переходит на этап…, ученику открывается курс…, письмо приходит один раз».

Шаг 3. Проведите тесты на новых контактах

Не смешивайте все сценарии на одном пользователе. Минимум разделите нового ученика, повторную регистрацию, частичную оплату и возврат. Иначе будет сложно понять, какое действие изменило запись.

Шаг 4. Фиксируйте время и идентификаторы

Сохраняйте email, телефон, номер заказа, ID контакта или сделки и точное время события. Эти данные позволяют быстро найти запись в логах нескольких систем.

Шаг 5. Повторите исправленный тест с начала

Если обнаружена ошибка, недостаточно вручную поправить итоговую запись. Исправьте настройку и снова выполните весь сценарий от действия пользователя. Только так можно убедиться, что следующий реальный ученик пройдет путь без вмешательства администратора.

Шаг 6. Зафиксируйте решение о запуске

Разделите дефекты на три группы:

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

Запускать рекламу при блокирующем дефекте нельзя. Косметические ошибки можно вынести в отдельный список, если они не мешают покупке и обучению.

Где в этой проверке помогает Vakas-tools (Вакас-тулз)

Vakas-tools (Вакас-тулз) не заменяет приемку лендинга, платежной системы, CRM и учебной платформы. Его роль в том, чтобы связать участвующие сервисы и дать общую точку для проверки движения данных там, где маршрут построен через Vakas-tools.

Во время тестирования можно:

1. проверить, поступила ли регистрация или оплата в нужную Базу;
2. открыть карточку тестового контакта и увидеть связанные регистрации, вебинары, заказы и логи;
3. посмотреть в истории событий, какое правило сработало и куда отправлялись данные;
4. открыть детали ошибки с запросом и ответом внешнего сервиса;
5. после исправления причины повторно отправить неуспешное событие;
6. отдельно проверить правила для регистрации, частичной и полной оплаты;
7. проверить поиск дублей и поведение при повторной регистрации в поддерживаемых интеграциях.

Конкретный набор действий зависит от сервисов, подключенных к вашей школе. Поэтому перед тестом стоит свериться с документацией нужной интеграции, а не переносить настройки из другой связки по аналогии.

Итог

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

Семнадцать тестов занимают больше времени, чем быстрый просмотр настроек перед стартом. Но почти всегда меньше, чем разбор потерянных заявок, ручная выдача доступов и объяснения клиентам после запуска.

FAQ

За сколько дней до запуска проводить техническую проверку?

Первый полный прогон лучше провести за 3-5 дней, чтобы осталось время на исправления. Контрольный тест критического маршрута (форма, оплата, доступ и письмо) повторите после последних изменений и за несколько часов до старта рекламы.

Нужно ли повторять все 17 тестов перед каждым запуском?

Если цепочка полностью совпадает и ничего не менялось, достаточно контрольного прогона ключевого сценария. Но новый лендинг, тариф, форма, домен, платежный метод, письмо, webhook, правило, токен или продукт в LMS уже повод повторить связанные тесты. После крупных изменений лучше пройти чек-лист полностью.

Можно ли тестировать на реальной оплате?

Да, если платежная система не предоставляет полноценный тестовый режим. Используйте минимальную допустимую сумму и заранее проверьте порядок возврата и возможные комиссии. Не имитируйте оплату ручной сменой статуса: она не проверяет уведомление от платежной системы.

Кто должен проводить приемку: технический специалист или продюсер?

Лучше вдвоем. Технический специалист видит интеграции и логи, а владелец процесса знает ожидаемую бизнес-логику: когда открывать доступ, что делать при частичной оплате, какую сделку создавать повторному клиенту. Финальную приемку полезно дать человеку, который не участвовал в настройке: он чаще замечает неочевидные шаги.

Что считать блокирующей ошибкой?

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

Достаточно ли увидеть успешный статус в интеграторе?

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

Что делать, если ошибка проявляется не всегда?

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

Что открыть в документации перед тестом

Разделы документации Vakas-tools (Вакас-тулз), которые чаще всего нужны во время приемки:

1. история событий и логи контакта: где остановились данные;
2. регистрации с Tilda: подключение webhook к конкретной форме;
3. настройки Базы и поведение при повторной регистрации;
4. выгрузка оплат из GetCourse;
5. интеграции с Zenclass и Skillspace: открытие и закрытие доступа.

Если маршрут сейчас собран вручную и вы не видите, где именно теряются данные, соберите цепочку в Vakas-tools (Вакас-тулз) и пройдите по этому чек-листу на тестовом контакте. Пробный период длится 14 дней.