ИИ-бот для онлайн-школы на GetCourse: как выбрать первый процесс
У школы несколько программ: люди приходят с сайта, смотрят вебинары, возвращаются из писем и задают вопросы в мессенджерах. Кажется логичным подключить ИИ сразу ко всему. Но у этих обращений разные условия и разные следующие шаги.
Я бы начал с процесса, который можно проверить целиком: от первого вопроса до ответа сотрудника. Ниже - как его выбрать, что проверить в GetCourse и когда переходить к следующей воронке.
Сначала определите, где нужен ИИ
Фраза «автоматизировать онлайн-школу» слишком многое объединяет. Отправить письмо после регистрации, ответить на свободный вопрос о программе и разобраться с доступом ученика - три разные задачи.
В GetCourse уже есть процессы для автоматизации работы. Поэтому сначала стоит проверить, достаточно ли штатного правила и заранее известного действия.
Есть точное условие
Оплата подтверждена системой - выдать предусмотренный доступ. Наступило время - отправить подготовленное письмо. Здесь решение задается правилом. Языковая модель не нужна, чтобы определять факт оплаты.
Есть свободный вопрос
«Подойдет ли программа с моим опытом?», «Чем отличаются варианты обучения?» Здесь агент может уточнить задачу, найти ответ в согласованных материалах и предложить подходящий следующий шаг.
Это и есть граница первого процесса: какая часть требует разговора, какие действия выполняет система и в какой момент вступает человек.
Первым берите процесс с понятным входом, актуальными материалами и сотрудником, который сможет продолжить разговор.
Большой поток обращений сам по себе не делает процесс хорошим кандидатом. Если условия программы меняются без единого источника, а за передачу никто не отвечает, агент получит ту же неопределенность, что сейчас мешает команде.
Четыре кандидата на первый запуск
Сравните реальные процессы своей школы. Таблица ниже - моя рабочая рамка для выбора. Это не рейтинг, где продающая страница всегда лучше вебинара.
| Процесс и вход | Материалы и данные | Следующий шаг и владелец | Что может помешать старту |
|---|---|---|---|
| Вопрос с продающей страницы | Нужно подготовитьОдна программа, действующие условия, ответы на частые вопросы. Источник страницы сохраняется в разговоре. | Куда ведемОтвет о программе, оформление заказа или менеджер. Владелец - продажи. | До запуска проверитьАгент не смешивает тарифы и программы. Сотрудник получает обращение и продолжает нужный диалог. |
| Обращение участника вебинара | Нужно подготовитьОффер конкретного эфира, сроки и условия. Достоверно известно, какой вебинар человек посетил. | Куда ведемУточнение предложения, заказ или менеджер. Владелец - продажи. | До запуска проверитьУчастнику не предлагают устаревшие условия другого запуска и не отправляют повторные сообщения после передачи. |
| Зарегистрировался, но не пришел | Нужно подготовитьДанные регистрации и посещения, доступная запись или следующий эфир, отдельное начало разговора. | Куда ведемЗапись, новая регистрация или сотрудник. Маркетинг и продажи назначают одного владельца процесса. | До запуска проверитьЧеловек определен верно. Агент не спрашивает о впечатлениях от эфира у того, кто его пропустил. |
| Вопрос действующего ученика | Нужно подготовитьКурс, поток, правила доступа и актуальные материалы поддержки. Для части вопросов нужны данные ученика. | Куда ведемОтвет поддержки или профильный сотрудник. Владелец - поддержка либо куратор. | До запуска проверитьВопрос доступа не превращается в продажу нового курса. Финансовый спор и нестандартная ситуация передаются человеку. |
Отметьте для каждого кандидата: «готово», «нужно уточнить», «мешает запуску». Не суммируйте это в красивый средний балл: отсутствие ответственного нельзя компенсировать хорошим FAQ.
Если у двух процессов все готово, выбирайте тот, где есть реальные обращения и проще проверить полный путь. Если не готов ни один, сначала закройте конкретный пробел: условия, источник данных или рабочее место сотрудника.
Пример: несколько воронок, одна первая программа
На рабочем разборе проекта онлайн-школы мы обсуждали подключение нескольких продуктовых воронок. У первой программы выделили две продающие страницы и два сегмента писем: участники вебинара и те, кто зарегистрировался, но не дошел.
Виджет на странице регистрации отложили. На этом экране человеку сначала нужно закончить регистрацию. Существующие письма и воронку сохранили; разговор с агентом решили добавить как отдельную возможность задать вопрос.
Что я бы проверил первым
Входящий вопрос с продающей страницы этой программы. Человек сам начинает разговор, источник связан с понятным продуктом, а базу ответа можно ограничить его действующими материалами.
Например, посетитель спрашивает, подойдет ли ему обучение и сколько времени оно потребует. Агент уточняет исходную ситуацию и отвечает по программе. Если нужны индивидуальные условия, переводит разговор сотруднику. Это учебный сценарий, а не цитата из клиентской переписки.
Что остается в очереди
Письма после вебинара подключаем после проверки связи между человеком, конкретным эфиром и предложением. Для тех, кто не пришел, отдельно проверяем сегмент и начало разговора. Поддержку учеников рассматриваем как другой процесс со своим владельцем.
Общий объем проекта можно согласовать сразу. Последовательный запуск нужен, чтобы одна ошибка передачи не повторилась во всех воронках одновременно.
При этом порядок может быть другим: если школа уже надежно учитывает участников вебинара, а продающие страницы давно не обновлялись, первым кандидатом окажется послевебинарный разговор.
Восемь проверок до подключения второй воронки
Работающий виджет показывает, что человек может открыть окно. Сообщение в группе показывает, что уведомление дошло. Для приемки первого процесса этого мало.
Проверять нужно со стороны посетителя и сотрудника. Технические сбои моделируйте в тестовом контуре, без остановки действующих продаж и отправок клиентам.
- Правильный вход.
Откройте каждый подключенный источник. Проверьте программу и контекст разговора: агент не должен переносить условия соседнего продукта.
- Ответ по материалам.
Задайте обычные вопросы о содержании, формате и условиях. Сверьте ответы с текущей утвержденной версией. Красивый ответ с выдуманным условием тест не проходит.
- Неизвестный вопрос.
Спросите о том, чего нет в материалах. Агент должен обозначить ограничение и предложить согласованный маршрут к сотруднику.
- Просьба позвать человека.
Напишите прямо: «Хочу поговорить с менеджером». Проверьте, что агент передает запрос без дополнительных уговоров и обязательного опроса.
- Доставка обращения.
Найдите его на рабочем месте ответственного. Проверьте контакт, источник, содержание запроса и отсутствие дубля.
- Ответ сотрудника.
Попросите сотрудника ответить тестовому посетителю. Ответ должен попасть в нужный разговор. Уведомление внутри системы не заменяет эту проверку.
- Остановка агента.
После подключения сотрудника продолжите разговор. Агент не должен отвечать одновременно с человеком. Условие возврата управления задайте заранее.
- Сбой и повторная передача.
Проверьте, кто видит ошибку, как обращение восстанавливается и не создаются ли повторные пользователь, заказ или задача.
Мое правило приемки: пока обращение теряется, попадает не тому сотруднику или агент мешает человеку отвечать, следующую воронку не подключаем.
Сам состав передаваемого контекста разобран отдельно: какие данные о заявке на обучение нужны менеджеру.
После запуска: отдельно качество и оплаты
Сначала нужно понять, работает ли процесс. Для этого просмотрите реальные разговоры и отдельно посчитайте:
- сколько раз правильно определились программа и источник;
- сколько ответов соответствуют действующим материалам;
- сколько обращений доставлено сотруднику без потерь и дублей;
- в скольких случаях сотрудник продолжил разговор;
- были ли ответы агента после передачи человеку.
У каждой доли должен быть понятный знаменатель. Например, успешные передачи делите на обращения, которые действительно требовали сотрудника, а не на все сообщения агента.
Затем смотрим движение к покупке
Диалог → квалифицированное обращение → разговор с менеджером → заказ → оплата. Заказ и оплата - разные результаты. Созданный заказ без денег не становится выручкой.
Сравнивайте один и тот же процесс: программу, источник, условия предложения и сопоставимые периоды или запуски. Несколько удачных разговоров показывают примеры работы, но еще не доказывают рост конверсии.
Когда расширять, а когда дорабатывать
Расширять - если путь до сотрудника устойчив, ошибки видны, а следующий процесс использует похожие материалы и действия.
Дорабатывать - если проблема понятна: не хватает ответа в базе, теряется источник или неверно выбран маршрут.
Приостановить расширение - если нельзя надежно определить человека, обращения теряются или агент продолжает писать после сотрудника. Сначала исправляем эту причину.
Что учесть в GetCourse
Можно ли подключить ИИ ко всем программам сразу?
Общий объем можно запланировать сразу. Но для каждой программы нужны свои материалы, условия и маршруты. Я бы выпускал их последовательно, после проверки первого полного процесса.
Достаточно ли доступа к API GetCourse?
Нет. API дает способы обмена данными, а не готовую логику разговора. Нужно определить, что передается, как находится нужный человек, кто получает обращение и как обрабатывается ошибка.
Официальная документация GetCourse описывает импорт пользователей и заказов, а также экспорт данных. Export API предназначен для периодической аналитической выгрузки. Для оперативной передачи новых событий GetCourse рекомендует процессы с операцией «Вызвать URL». Конкретную связку с внешним агентом нужно настроить и проверить отдельно.
Где сотрудник должен продолжать разговор?
В том рабочем месте и канале, которые выбраны для конкретной интеграции. До запуска покажите это сотруднику и проверьте реальный ответ тестовому посетителю.
Интерфейс GetCourse может отличаться: на дату проверки 8 октября 2026 года документация Helpdesk указывает его доступность для новых аккаунтов с 16 июня 2026 года; в старых используется раздел «Входящие». Наличие любого из этих разделов само по себе не подтверждает передачу диалога от внешнего ИИ.
Можно начать с поддержки учеников?
Да, если у нее понятный владелец, актуальные материалы и проверяемые данные о курсе и доступе. Просто не объединяйте ее с продажами по умолчанию: другой вопрос может требовать другого сотрудника и другого набора сведений.
Через сколько диалогов можно оценивать результат?
Универсального числа нет. Критические технические ошибки нужно устранять сразу. Для коммерческого вывода нужны сопоставимые данные по своему процессу и достаточное число наблюдений; срок зависит от потока обращений и цикла покупки.
Начните с одного реального процесса
Выпишите несколько источников обращений. Для каждого отметьте материалы, следующий шаг, ответственного и незакрытые проверки. Выберите один, где понятен весь путь человека. Этого достаточно для предметного разговора о первом запуске.
В ALIOT мы разбираем входы, материалы и передачу сотруднику до настройки ИИ-Квалификатора. Обмен с GetCourse, каналы и границы действий определяем для конкретной школы.
Материал подготовлен 8 октября 2026 года. Возможности платформы сверены с официальными разделами GetCourse о процессах, API и Helpdesk. Матрица выбора и критерии приемки - рабочий подход автора. Иллюстрации созданы с помощью ИИ и не являются скриншотами внедрения.