Выдача доступа к курсу без ручной работы

Курс продаётся, деньги приходят, а доступ всё равно выдаёт человек. Это частая точка, где онлайн-обучение упирается не в маркетинг, а в свободные руки владельца. Разбираем, как выглядит ручная цепочка, где она рвётся, из чего собирается автоматическая и что в ней стоит оставить ручным сознательно.

Ручная цепочка и место, где она рвётся

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

Рвётся она в предсказуемых местах. Человек решается на покупку вечером, платит ночью и до утра сидит без доступа, наедине с сомнением «а точно ли дошло». Выходные и праздники эту паузу растягивают. Съёмка, поездка, второй запуск, обычная занятость - и ответы уходят пачками, когда до них дойдут руки.

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

Из чего состоит автоматическая связка

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

• Точка входа. Место, откуда человек приходит: пост, реклама, ссылка в шапке профиля, автоответ в директе. В одном из проектов, где бот принимает оплату, подключён автоответ в Instagram, чтобы первое сообщение человек получал сразу.
• Страница с описанием. Программа, для кого курс, что внутри, формат, ответы на частые вопросы. Она нужна, чтобы решение принималось до оплаты, а не в переписке.
• Оплата. Платёжный сервис вместо перевода по номеру: у платежа появляется статус, который система может прочитать сама. Именно это отличает автоматическую выдачу от ручной - не бот, а проверяемый статус оплаты.
• Бот. Встречает после оплаты, здоровается, объясняет, что дальше. Telegram-бот удобен тем, что курс и общение живут в одном приложении, без отдельных логинов и паролей.
• Выдача доступа. Ссылка-приглашение в закрытый канал или добавление в него. Оплата - бот - доступ, без участия человека.
• Уведомление владельцу. Сообщение о каждой покупке. Не для контроля, а чтобы вы видели поток и замечали сбои раньше, чем о них напишет покупатель.

Почему ручная выдача остаётся

Мы намеренно оставили в этом кейсе ручную выдачу доступа. Не как временное решение на период отладки, а как постоянную часть системы.

Нестандартных случаев всегда больше, чем кажется на этапе ТЗ. Курс покупают в подарок, и доступ нужен другому человеку. Платит компания, а учится сотрудник. Оплата уходит на карту напрямую, потому что так договорились. Человеку нужно продлить доступ, вернуться после паузы, получить материалы отдельно. Он оплатил с одного аккаунта, а в Telegram сидит с другого.

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

Возвраты и ошибки оплаты

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

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

Второй сценарий - повторная оплата. Человек не увидел подтверждения и заплатил ещё раз. Система должна такое замечать и не делать вид, что это две продажи.

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

Что проверить перед запуском

Список короткий, но проходить его лучше целиком, живыми руками:

• Реальная оплата небольшой суммой настоящей картой, не только тест в песочнице.
• Что происходит, если закрыть страницу сразу после оплаты.
• Что происходит, если человек уже состоит в канале.
• Что происходит при второй оплате того же курса.
• Как выглядит путь ночью: сообщения бота читают без вас, они должны быть понятны сами по себе.
• Куда приходит уведомление владельцу и не тонет ли оно среди прочих.
• Где хранится список купивших и можно ли его выгрузить.
• Кто и как выдаёт доступ, если бот недоступен.
• Тексты бота: их читают в момент, когда деньги уже отправлены. Здесь важнее ясность, чем стиль.

Когда автоматизировать рано

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

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