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

До даты старта ему уходит серия «разогревающих» писем на e-mail и в Telegram-бота. В зависимости от даты регистрации клиенту уходит разный набор писем по индивидуальному графику. Эта задача была решена с помощью основного процесса и подпроцессов – на входе проверялось время попадания клиента в воронку и он перенаправлялся в соответствующий подпроцесс, где был прописан индивидуальный график отправки писем.
Все сработало хорошо :) Но конечно же эту задачу можно было решить и несколькими отдельными процессами, где сразу на входе проверялось бы время регистрации клиента.

Всегда в своих проектах стараюсь использовать максимум средств для коммуникации с клиентом и не исключаю электронную почту. Также в этой задаче через электронную почту дожимали на подписку на Telegram-бота, так как марафон проходил исключительно в нем – некоторые элементы геймификации можно выполнить только в мессенджерах, а также это просто и удобно для клиента :)

Марафон стартовал! Что же ждало участников?

1. Задания на платформе GetCourse, за выполнение которых начислялись бонусные рубли.
2. Возможность оставить заявку на контакт с менеджером, за которую начислялось сразу максимальное количество бонусных рублей. Задания можно было не сдавать :)
3. Бонусные рубли в рамках марафона можно было потратить на покупку гайдов или как скидку на основной курс. После окончания марафона они сгорали.
4. Многообразные фото- и видеоконтент в Telegram-боте, побуждающий участников выполнять задания и вообще двигаться в марафоне.
5. Элементы геймификации в боте – клиенту предлагались вопросы, нужно было выбрать вариант ответа и в зависимости от ответа предлагалась своя цепочка сообщений.
6. Возможность увидеть свой бонусный баланс по кодовому слову в боте.
7. Возможность выполнять задания в комфортном режиме – все отсрочки были настроены таким образом, чтобы они не влияли как на выдачу полезного материала в нужный день, так и на возможность дать ответ участником и заработать свои бонусные рубли.
8. Итоговый вебинар.
9. Запись вебинара для всех.

Трудности в реализации марафона и автомарафона:

1. Количество начисляемых бонусных рублей в рамках марафона было ограничено фиксированной суммой. Но способы их начисления (сдача домашнего задания, заявка на контакт с менеджером) предполагали возможность заработать больше допустимого. Поэтому были внедрены проверки текущего баланса и НЕначисление, если предел достигнут.
2. Бонусные рубли уже были ранее использованы в проекте и поэтому просто обнулить бонусный счет пользователя было нельзя. Была введена дублирующая переменная пользователя, в которую сохранялся промежуточный результат. И значение которой выводилось пользователю в автоматическом режиме, когда он хотел проверить свой баланс по кодовому слову.
3. Эта же переменная использовалась и для списания неиспользованных бонусных рублей. Клиент мог приобрести гайды разной стоимости и у него мог образоваться остаток. Именно этот остаток нужно было списать по окончании марафона (помним, что у клиентов еще есть бонусные рубли, которые они могли заработать в ранее проводимых активностях).
4. Так как в проекте автовебинар всегда сопровождает живой менеджер, то было решено зафиксировать дату старта марафона всегда в определенный день на неделе. Марафон проводился еженедельно. В течение предшествующей недели клиенты регистрировались на марафон и получали письма после регистрации всегда с актуальной датой марафона. Это легко решается с помощью переменных даты, но нужно готовиться к тому, что писем будет очень много :) Особенно если используется несколько каналов для коммуникации с клиентом. Число писем умножаем на число каналов.
5. Клиент мог участвовать в марафоне несколько раз поэтому было принято решение запускать процесс автомарафона из формы регистрации. Не использовала процесс по заказам, так как не было возможности отсегментировать заказы по времени создания – марафон начинался на неделе, плюс те, кто регистрировался в день марафона также попадали в стартовавший на этой неделе марафон. При запуске процесса из формы есть риски множественного дублирования задач – иногда клиенты вводят данные несколько раз, иногда спустя пару дней они уже забыли, что регистрировались и регистрируются повторно. Поэтому в марафон была была включена проверка на то, является ли клиент в настоящий момент участником марафона. Для этого использовалась переменная по пользователю, которая меняла статус в зависимости от статуса клиента – участник/не участник. На входе в процесс проверялось значение этой переменной, и в зависимости от него задача завершалась, либо ждала время старта марафона.

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

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