Год на MVP. Как и почему мы делаем сервис кнопочных диалогов КвикСпик

Приветствую, меня зовут Вячеслав Устинов, руководитель агентства, ориентированного на мед.проекты и сферу услуг. Пишем системы аналитики, управляем проектами и IT-процессами наших клиентов. Специфика работы располагает к экспериментам. Один из таких перерос в разработку конструктора лендинг-ботов с кнопочным диалогом QuickSpeak.me (Квик), над которым активно работаем уже около года.

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

Особенности сервиса — в алгоритме диалога и в способах его сборки.

О чем этот сервис и какие проблемы решает

Технически, это механики бота с кнопочным диалогом, адаптированные под веб.

Идеологически, Квик позволяет:

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

Если есть понимание о чем писать, квик собирается за 10-30 минут.

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

И главное, ради чего и был задуман сервис — расширение возможностей в таргетинге.

О чем расскажу на примере из нашего опыта.

Медицина, с которой мы в основном работаем — сама по себе непростая тематика. Много ограничений, дорогие запросы в горячих кластерах, бесполезные запросы в холодных.

Если ну очень упрощенно, кластеры медтрафика можно раздробить на 4 группы:

  • Натив и фамилии докторов

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

Здесь вопрос плейсмента закрывается основным сайтом/сайтами + медицинскими агрегаторами.

  • Направления и приемы — основное конкурентное поле

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

Я написал скрипт для телеги, который рассчитывает в нон-стоп режиме суточное присутствие игроков по директу во множестве тематик (по часам) — ниже скрин. Кое-кто из этого списка тратит на направление 100+ (на очень компактный пласт горячих запросов с показами в регионе), а его полоса присутствия почти незаметна (на графике чем жирнее полоса, тем больше объем присутствия). То есть - масштабировать горячий пласт — дорого, особенно для небольших клиник.

  • Фарма

В фарме, как и в блоке выше, сохраняется определенная конкуренция среди МЦ, но к ней добавляются производители и продавцы лекарственных препаратов. Некоторый результат при работе с будущим пациентом на уровне фармы присутствует, но с настройками нужно тонко работать и 10 раз подумать перед тем как планировать запуск в этом сегменте запросов.

  • Холодные запросы

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

Объемы (по гуглу) неплохие, но влияние на запись в клинику непропорционально этому графику.

В итоге. Есть проблема. Имеется инфо-трафик. Его много — хочется работать с ним эффективнее.

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

Появилась гипотеза и идея:

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

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

Заложенный концепт реализовали довольно быстро. Сначала - в telegram простеньким скриптом за пайтоне (для проверки и сборки алгоритма), а потом перевели в веб.

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

Идею из теста смасшбировали на другие медицинские ниши:

  • на эндоскопию начали вести людей с широким таргетом 40+ с итоговым CTR 0.45-1% в запись на первом взаимодействии, что неплохо с учетом дешевизны аудитории и высокой стоимости эндоскопии + полипэктомии;
  • на лечение геморроя — аудитории профессиональных водителей; в т.ч. куда более успешно, чем ранее, монетизировали запросы из фарм-кластера “свечи и подушки от геморроя”;
  • получили результат с трафика по часто путешествующим на самолете людям на флебологию;
  • получили запись на лечение лишнего веса к психотерапевту и т.п;
  • по итогу, нарастили объем покупки холодного трафика для ряда компаний.

Кнопочный диалог оказался не столько инструментом, который может гарантировать “шквал лидов”, сколько способом получить качественные заявки. Форму в интерактиве заполняют не ради интереса, а на основе рационального вывода. Менеджер/колл-центр получает не холодный контакт, а пользователя, которому уже понятна суть и требуется информация в рамках индивидуальных вопросов.

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

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

Как все работает внутри

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

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

Все это делается без особых проблем. Сами мы предпочитаем собирать интерактив в таблицах, а редактор использовать для внесения быстрых корректировок.

Чуть подробнее о матричном варианте

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

Как связаны реплики (простая схема)
Как связаны реплики с учетом использования доп-идентификаторов при одинаково звучащих вопросах.

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

В дальнейшем есть желание реализовать более эффективные автоматизации.

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

Но у матричной структуры диалога есть один очевидный недостаток - возможность повтора реплик

Его решили надстройкой, скрывающей просмотренные варианты, если обратное не приведет к поломке самого диалога.

UX

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

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

Технологии

Бэкенд крутим на Джанго. Сейчас присматриваемся к связке Django + Go + Reddis ради хороших скоростей. Также GoLang позволит нам реализовать нормальную встроенную аналитику на проекте (выше скорость — точнее данные).

Использование сервиса и дальнейшее развитие

Первоначально мы определили несколько итераций MVP:

  • Проверка гипотезы, что порционная подача контента в заданном формате действительно будет эффективной (для проверки самой идеи продукта);
  • Получение регистраций при минимальных охватах рекламных кампаний. Здесь 2 гипотезы - первая, что сервис понятен не только нам, но и холодной аудитории, и что тестовая рекламная кампания не даст условный максимум регистраций (если бы РК дала регистрации, но на большом охвате, то конечно о масштабировании в дальнейшем речи идти не может);
  • Вовлеченность в кабинет, работа внутри.

На втором этапе уже определили моменты отсечки пользователей на старте - не всем все понятно. Постепенно решаем этот момент.

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

Первый шаг мы проверили как агентство. Второй шаг проверили в конце 2020 года, когда на еще совсем сырой продукт для тестов запустили первую рекламную кампанию с целью на регистрации. Получили в короткий промежуток времени 200 регистраций в кабинет. Стоимость лида в зависимости от региона варьировалась от 50 до 150 рублей, охваты РК были крайне сжатыми.

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

Что есть на текущий момент:

  • Завершенный MVP 2 (хотя это мы себе говорим каждые пару недель, а потом ставим в приоритет разработки очередной вагон тасков, без реализации которых нам кажется что ничего не готово))
  • Функциональный кабинет с возможностью загрузки таблиц и визуальным редактором;
  • Системы премодерации, чтобы снизить объем ручных проверок публикуемого контента;
  • Механики оформления с настройкой цветовой палитры и вспомогательных блоков;
  • Документация и все к ней сопутствующее (не всегда успевает за изменениями, но в целом, читаемая);
  • Возможность использования квика не только в качестве лендинга, но и как виджета, или встраиваемого блока на сайте. (iframe как виджет и статичный формат готовы и применяются, скрипт - в работе);
  • Тесты в нишах в т.ч. за пределами медицины (девелопмент, сфера обучения, бьюти услуги). Кстати, отдельно про бьюти услуги - зашло хорошо, но с справедливости ради — это сравнительно легкие офферы и с ними можно придумать еще миллион доступных способов эффективной работы;
  • Возможность развертывания квика на собственном хостинге (часть кода на хостинге - часть на стороне нашего сервера).

Что было реализовано, но на определенных этапах отсечено:

  • Статичное расположение кнопок (убрали в борьбе за максимальное пространство экрана под контент реплик, хотя в целом старое решение до сих пор кажется неплохим, не считая лишнего 1% отказов по тестовым квикам);
  • Тонны лишней анимации;
  • Механики историй в диалоге (заменили на кнопку “Подробнее”) под развернутый контент.

Планы

  • Придумали как внутри логики диалога и заданного шаблона таблиц реализовать интернет-магазин и легко обновлять цены. Есть гипотеза, что для бутикового формата с малым ассортиментом, или продаж сложных товаров/услуг встраивание механизма продажи в диалог может быть эффективным решением;
  • Также, с учетом формата таблиц, нашли массу поводов реализовать механику, схожую с вордпрессовыми шорткодами с возможностью создания своих функций на пользовательском уровне (придумана масса вспомогательных вещей, которые классно спрячутся в короткие команды)
  • Встроенная система анализа данных. Любим писать скрипты аналитики, и в целом много работаем с цифрами и построением предиктивных моделек, так что, надеюсь, сможем хорошо адаптировать наш опыт под Квик + крайне интересно задействовать GoLang на этом этапе (получение нами нового опыта);
  • Автоматизацию построения диалога через алгоритм с самообучением на паст-дате (пользователь пишет реплики, алгоритм сам выстраивает эффективные сценарии диалога исходя из набранных данных)
  • Как и любой стартап, работаем над выходом сервиса на зарубежные рынки) Есть стратегия и понимание процессов выхода на турецкий рынок и конечно - запад.

Собственно, пощупать квик можно по ссылке - https://quickspeak.me

Буду рад вашим тестам и обратной связи. Возможно, где-то сыровато. Если что найдется/упадет — поправим)

0
4 комментария
Game Topia

Я тоже теперь хочу такой сделать! Рассказывайте о ходе продвижения.

Ответить
Развернуть ветку
Вячеслав Устинов
Автор

Спасибо, потом напишу по маркетингу сервиса и результатам) Ну и буду ждать обратной связи по удобству кабинета)

Ответить
Развернуть ветку
Game Topia

Вы, видимо, не так меня поняли. Я теперь такой же конструктор хочу создать! 

Ответить
Развернуть ветку
Сергей

Супер! Мне понравилось :)

Ответить
Развернуть ветку
1 комментарий
Раскрывать всегда