Воронка на вебинар без прогревающего контента с напоминанием

Клиент

Клиент занимается управлением бизнеса и обучает бухгалтеров, как правильно составлять отчеты. Была поставлена задача: создать чат-ботов для трёх мессенджеров: ВКонтакте, Telegram и Viber.

Исходя из анализа целевой аудитории — это бухгалтера, которые чаще используют Viber и Email-рассылки.

Клиент своими силами решил настраивать рекламу на посадочную страницу, которую они создали с партнёром на Тильде.

В основном необходимо было создать чат-ботов, а также настроить интеграцию и воронку для email-рассылок с уведомлением о вебинаре. До email-рассылок мы не дошли.

Процесс работы

1. Сначала обговорили с клиентом суть вебинара и как он видит внедрение инфобизнеса в своем продукте. На видеосозвоне клиент рассказал свою историю и какой продукт они хотят запустить.
2. Исходя из результатов общения с клиентом, я создал предварительный скелет воронки для их вебинара. Затем клиент решил сам разобраться и предложил свой прототип воронки.
3. Клиент не хотел идти по стандартному пути с прогревающим контентом и отказался от него, и поставил задачу просто использовать воронку в чат-ботах для уведомления о начале вебинара.
4. После этого я начал собирать чат-бота на канале ВКонтакте, чтобы сперва протестировать на одном канале всю воронку и действие цепочек и уже после этого переносить на другие мессенджеры.
5. Воронка состояла из нескольких блоков: приветствие на регистрацию, где пользователю предлагаем завершить регистрацию, используя удобный для него мессенджер. Затем пользователь завершает регистрацию уже в выбранном мессенджере и получает сообщение об успешной регистрации и получает сообщение о времени, когда состоится вебинар. Просим запланировать дату в своем календаре, чтобы быть готовым к вебинару.

Текст для сообщений делал сам клиент.

Отступление 1. Клиент изначально предложил сделать чат-ботов на вебинар также и для тех, кто не смог прийти или отказался купить запись вебинара.

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

6. Изначально я создал воронку, где пользователь проходил всю цепочку с условиями по дате и времени. Также добавил цепочку, уводящую на оплату вебинара. Сделал заранее, так как клиент об этом говорил, но вводных данных и доступов к Робокассе не предоставил.

Отступление 2. Клиент предложил сделать условия в чат-ботах по времени часового пояса по каждому городу. Чтобы каждый пользователь, находящийся в своем городе, получал первое напоминание о вебинаре в 9:00 по его часовому поясу (не по Москве).

Здесь я озадачился, так как такого ни разу не было в практике (даже в теории). Проконсультировался с коллегами, как это лучше реализовать.

10 способов увеличить доходимость до вебинара в 3 раза с помощью чат-ботов BotHelp

Был предложен вариант:

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

Т.е. необходимо было настраивать рекламные кампании на каждый город отдельно со своими UTM-метками, где было бы условие «City». И уже от этого выстраивать оповещение о дате напоминания.

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

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

Клиенту необходимо было запустить бота быстрее, так как первоначальная дата стояла 13 или 14 января. Спустя время дату изменили на 25 января.

Дальнейшие действия

Первоначальная воронка была готова и необходимо было ее протестировать.

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

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

А вот, протестировать временной интервал в днях у вас за 1 час не получится никак. На это нужно время. Если у вас оповещения идут сначала через 3 дня, потом через 1-2 дня и затем несколько оповещений в течение 1 дня, то как минимум вам нужно протестировать чат-бота в течение 5-7 дней.

Итак. Первый вариант чат-бота был успешно скорректирован и протестирован. Но тут клиенту понадобилось внести правки.

Отступление 3. Я не брал дополнительную оплату за корректировки того, что уже было сделано по техническому заданию (далее - ТЗ). Клиент логически не понимал, как всё происходит. Но так как я имею довольно долгий опыт в построении чат-ботов, то выстроил его логически исходя из своего опыта.

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

Чат-бот и воронки были скорректированы. Идем дальше.

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

На создание, корректировку чат-бота с основной воронкой и автоворонкой я затратил примерно 23 часа, но с ожиданием ответа от клиента и внесением правок на разработку и внедрения ушёл почти месяц. Так как от изначального ТЗ, где необходимо было сделать линейного чат-бота (простого бота), мы ушли в сложного построенного чат-бота с автоворонками и достаточно сложными условиями.

Начало

Оформление мини-лендингов в большей степени делаю в самом конце, когда воронки и чат-боты готовы. Оформление меняли всего два раза. Изначально мы просили пройти регистрацию и выбрать мессенджер. Где в первом сообщении мы предлагали снова зарегистрироваться, что было нелогично. Это исправили.

Сделали так, что просим завершить регистрацию, выбрав тот или иной мессенджер. И в первом сообщении уже показываем кнопку «Регистрация». Хотя здесь я бы подправил и переименовал бы кнопку на «Завершить регистрацию».

Первое приветственное сообщение без всяких изысков. Обращаемся к пользователю по имени и предлагаем зарегистрироваться (по сути, завершить регистрацию).

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

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

Здесь я столкнулся с тем, что условие было только одно, оповещение за 4 дня до начала вебинара и проверял его по одной дате 21 января, следом время 9:00. Когда во второй раз тестировал это в часах, всё было нормально, но затем, когда поставили временной интервал в днях, мы получили данное сообщение на следующий день в 9:00 утра.

Необходимо было продумать и скорректировать другие условия, если пользователь попадает в воронку позже 21 января 9:00 утра. Изначально этот момент я упустил, так как логически думал, что если он пропустил этот период, то следующее уведомление он получит 24 января за 1 день до начала вебинара, как было в воронке. Об этом позже мне сказал клиент. И я начал это корректировать. На это у меня ушло практически 2 дня ,и мне в этом помогала техническая поддержка Bothelp.

Хочу выразить благодарность Амину и Елене из Краснодара. Спасибо вам огромное за проведенные многочасовые беседы с условиями и датами с задержками по времени в моей воронке для клиента.

На скриншоте видно уже полностью рабочая схема со всеми условиями (датами и задержками), чтобы сообщения приходили и 21, 22 и 23 января:

Технический факт: если мы проверяем дату «Меньше или равно» 21 января и он не соответствует действительности (уводим на – Нет). Там у нас проверка следующего условия по дате 22 января.

Чтобы сообщения уходили в 9:00 ,необходимо было в проверке условий по времени поставить 8:59. Таким образом, в задержке по времени «Немедленно в 9:00» сообщение будет отправлено ровно в 9:00. Точно так же по другим условиям.

Про задержки расскажу поподробнее. Исходя из ТЗ клиента, необходимо было отправлять сообщения 21 января в 9:00, где мы напоминаем о вебинаре, который состоится уже на следующей неделе.

Задержки необходимо ставить после проверки условия по времени и расхождение у вас должно быть хотя бы в 1 минуту. В условиях проверка идет 8:59, задержка в 1 минуту, если мы идем по первому условию 21 января, то отправляем в 9:00 немедленно.

Для остальных, если пользователь пришел в воронку 21 января, но позже 8:59 мы его отправляем на следующий день 22 января и проверяем время 8:59, если соответствует, то в задержке ставим «Завтра 9:00» и пользователь, соответственно, получит 22 января в 9:00.

Также действуем, если пользователь вошел в воронку позже 22 января 8:59, отправляем его на 23 января. Дальше при несовпадении условий уже отправляем в основную воронку с проверкой на 24 января, где придет сообщение о том, что вебинар уже состоится завтра.

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

Здесь я показал на скриншоте стрелочками суть воронки и взаимодействие ОТ и ДО.

Теперь разберемся подробнее. Красная стрелка — это основная цепочка, если пользователь попал в воронку до 21 января 8:59 и прошел по ней. Мы отправляем немедленно в 9:00 сообщение о том, что вебинар уже на следующей неделе.

После этого мы проверяем снова условия по дате. Проверяем соответствие того, что пользователь в нашей воронке находится до 21 января, затем время 18:59. Эта проверка нужна, чтобы мы за 24 часа отправили ему сообщение с напоминанием, что вебинар начнется через 24 часа в 19:00. Задержка у нас выставлена на 18:59, с разницей в 1 минуту от условия по времени.

Синие стрелки — это те пользователи, которые пошли по воронке с условиями по дате 22 января, и те, кто не вошел в эшелон 21 января и ранее.

Зеленая стрелка — это 23 января, соответственно.

Если наши условия не соответствуют по дате и времени — я указал эту цепочку стрелками фиолетового цвета. То есть мы отправляем подписчика на проверку на другую дату. Если пользователь совсем не соответствовал ни одному из условий, то мы проверяем его на Условие по дате 24 января, затем по времени 18:59, если и тут нет, то делаем задержку и направляем сообщение в день вебинара на 25 января. Здесь мы снова проверяем дату 25 января.

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

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

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

Отступление 5. Изначально я просил клиента предоставить платформу или ссылку на вебинар, так как непонятно было, как пользователи будут регистрироваться. Спустя несколько недель клиент предоставил ссылку на вебинар. Но там увидел, что пользователя снова просят зарегистрироваться и ввести много данных.

Это было не логично и не удобно, ну нужно столько полей, они убивают конверсию. Клиенту порекомендовал сократить поля, выделил красным, что необходимо было оставить. По желанию отметил синим, что нужно собирать (если в будущем делать смс-рассылку или прозвоны).

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

Ниже на скриншоте мы проверяем условия по дате дня вебинара 25 января, время 17:59 и задержка Немедленно в 18:00. Если условия не выполняются (здесь отметил красной стрелкой), уводим на проверку условий по дате 25 января (день вебинара) и условие по времени 18:44. То есть за 15 минут до начала вебинара.

Сделал это специально, потому что от клиента так и не получил информации, до какого времени будет идти трафик на чат-ботов. Может, они прекратят лить трафик за 5 минут.

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

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

Клиент выбрал площадку Pruffme. Ранее я предлагал клиенту провести вебинар на Бизон356, где есть прямая интеграция с Bothelp (и даже с Unisender и всё вместе взятых для сбора электронных почт пользователей. Это я мог всё сделать, но клиент отмалчивался).

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

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

Здесь я сделал следующее: поставил в основной воронке задержку в 4 минуты. Затем мы спрашиваем пользователя: «Удалось ли ему ввести данные?» Если удалось, ему присваивается метка «удалось», если нет – то присваивается другая метка «не удалось».

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

Так как для Бизон356 необходимо иметь свой YouTube-канал, настраивать его, и там идут большие задержки и, соответственно, все комментарии идут на YouTube-трансляции (если пользователь не авторизовался там, он не сможет комментировать). Поэтому клиент выбрал другую площадку.

Допустим, пользователь ввел свои данные и попал на вебинар. Мы через 1 минуту отправляем сообщение с напоминанием. С учетом временного интервала мы высчитали и получается по ТЗ — за 5 минут напоминаем о вебинаре:

Если пользователь не смог ввести свои данные или у него произошла ошибка, мы, проверив условия, отправляем сразу сообщение и спрашиваем: «В чем возникли трудности?». Здесь два варианта: первая ошибка регистрации – следом мы ставим ему метку, что у данного пользователя возникли трудности (чтобы в будущем я или клиент мог технически обговорить с пользователем этот момент), и отправляем его сразу на Чат с агентом.

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

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

А может пользователь вовсе передумал, или изменились планы, тогда мы ему предлагаем купить запись.

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

Присылаем сообщение, что запись платная (мы об этом упоминаем в сообщениях, когда уведомляем пользователя). Ранее здесь была кнопка «Оплатить», так как необходимо было связать платежи с Робокассой клиента и настроить оплату.

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

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

Дальнейшую логику воронки я не знал: как клиент будет брать оплату с них, и отправлять запись.

Отступление номер 100500. Клиент в итоге отказался от продажи записи.

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

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

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

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

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

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

Внедрена автоворонка с учетом напоминания о вебинаре за 4 дня, за 3 дня, за 2 дня, за 24 часа, за 3 часа, за 1 час, за 15 минут, за 5 минут и во время начала вебинара.

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

Выводы:

— работайте строго по договору, где в ТЗ должно быть прописан хотя бы скелет воронки, какие условия будут применяться, будет ли это интегрироваться с другими площадками, будет ли у вас оплата внутри чат-бота и так далее;

— когда у вас как у исполнителя (или у клиента) есть четкое представление о воронке, логике, решений вы сэкономите время на корректировки и доработки чат-бота;

— данная воронка и цепочки в чат-боте, безусловно, помогут клиенту сэкономить время на отправку сообщений уведомлений о начале вебинара, увеличить доходимость пользователей до вебинара и возможность продать запись для тех, кто поменял планы;

— не позволяйте клиентам говорить, что ваша работа — это халтура, а для клиентов рекомендую не бросаться такими словами, когда вам делают сложную работу (если для вас такие чат-боты — халтура, тогда сделайте сами);

Не работал по договору. Чат-бот оказался не линейным, а сложным. Необходимо было увеличить стоимость работы. Оплату я получил полностью (как было оговорено с клиентом). Клиент получил готового сложного чат-бота для трёх мессенджеров ВКонтакте, Telgram, Viber.

Всем спасибо!

40.000 рублей в месяц на вебинарной воронке без бюджета