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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фарма

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UX

Технологии

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

Планы