У каждой отрасли свой повод подключить платформу
Руководителю интернет-магазина нужно сохранить заказ после пропущенного звонка. Директору клиники — напомнить пациенту о приеме. Логисту — автоматически сообщить статус доставки. Все эти задачи можно решать с помощью платформы, но на странице каждой отрасли читатель должен был увидеть свой случай.
По данным Gartner от 15 сентября 2020 года, B2B-покупатели обычно отводят встречам с потенциальными поставщиками 17% времени. Еще до такой встречи им нужна информация для оценки продукта. Эту часть знакомства с МТС Exolve мы обеспечивали на отраслевых страницах.
McKinsey исследует сочетание личного, дистанционного и самостоятельного цифрового взаимодействия в B2B-продажах. В обзоре от 12 декабря 2023 года компания сравнивает число каналов покупки — до десяти в 2021 году против пяти в 2016-м. Такое разнообразие объясняет, почему бизнесу требуется объединять историю общения с клиентом.
При этом многие потенциальные клиенты еще не знали слова «омниканальность». Проблема была им знакома — человек пишет в мессенджер, затем звонит и оставляет заявку на сайте, а компания видит разрозненные обращения. Омниканальный подход связывает их в общую историю. API позволяет программно подключать сервисы, но само подключение еще не объединяет все процессы общения.
Готовых описаний сценариев не было
Экспертиза находилась у сотрудников. Технические специалисты и менеджеры знали, как платформа помогает конкретным клиентам, но для сайта эти случаи еще не описали. Нам предстояло получить сведения из первых рук и разобраться, что существенно для каждой отрасли.
Параллельно с интервью мы изучали работу ретейла, запись пациентов, складские операции и доставку. Это позволяло уточнять детали у экспертов и отличать сценарии, которые в общем описании продукта выглядели одинаково.
Текст должны были понять и руководитель, и разработчик. Эксперты объясняли продукт через протоколы, методы и архитектуру. Предпринимателю или маркетологу нужно было сначала понять, что изменится в работе компании. Мы перестраивали объяснение вокруг этой задачи, сохраняя существенные определения и технические ограничения. Затем эксперт проверял готовый текст.
Незнакомый термин требовал объяснения. Если после переписки в мессенджере клиент звонит, а менеджер снова выясняет обстоятельства обращения, назначение общей истории становится наглядным. Мы начинали с такой ситуации и только после нее вводили омниканальность.
До внедрения оставались вопросы об API. Клиенты опасались долгого, дорогого или небезопасного подключения и необходимости содержать собственную команду разработки. В короткое описание отраслевого сценария подробный разбор не помещался. Для вопросов об интеграции мы использовали блог.
Страницы строили на отраслевых случаях из интервью
Спрашивали, как решили задачу конкретного клиента. На интервью выясняли, что мешало компании, какое решение она выбрала и что изменилось после внедрения. Так получали подробности, которых нет в списке функций платформы.
Написанный текст возвращали тому же специалисту. Вместе уточняли технические объяснения и исправляли упрощения, которые меняли смысл.
Для каждой отрасли подготовили свою страницу. Ретейлу адресовали сценарии брошенных корзин и статусов заказов; финансовым компаниям — подтверждения операций и информирования; медицине — записи и напоминаний; логистике — уведомлений о доставке. Всего получилось 12 страниц.
Каждая начиналась с проблемы отрасли. Дальше мы объясняли, как ее решает платформа, что это дает бизнесу и как начать работу. Читатель мог оценить применение продукта и найти следующий шаг на той же странице.
Название подхода давали после примера. Сначала показывали, как разговор распадается на обращения в нескольких каналах. Затем объясняли, как общая история в одной системе связывает их между собой. После этого вводили термин «омниканальность» и отдельно поясняли роль API в подключении сервисов.
Такой порядок учитывал и особенности чтения с экрана. По материалу Nielsen Norman Group 2011 года, при посещении страницы пользователям обычно хватает времени примерно на четверть текста, а первые секунды особенно важны для решения остаться. Поэтому знакомую ситуацию мы выносили в начало объяснения.
В девяти статьях разобрали вопросы подключения. Объяснили безопасность, сроки интеграции и необходимые ресурсы разработки, в том числе действия компании без собственного технического специалиста. Примеры и цифры позволяли обсудить конкретные условия, не обещая одинаково простого внедрения во всех случаях.
Поставили ссылки между блогом и решениями. Из статьи читатель переходил к применению платформы в своей отрасли. С отраслевой страницы он мог вернуться к подробному разбору API. Так описание решения и объяснение интеграции дополняли друг друга.
Измеряли конверсию отраслевого раздела
Главной метрикой была доля посетителей раздела «Решения для отраслей», совершивших целевое действие после чтения. Сравнивали показатели до и после переработки на сопоставимых отрезках времени. Длительность этих отрезков и определение целевого действия в опубликованных данных не указаны.
Дополнительно смотрели на дочитывания, время на страницах, отказы и переходы к следующему шагу. Переходы из блога в раздел учитывали отдельно — они показывают вход в отраслевые решения, а не действие на самой странице решения.
Конверсия раздела выросла на 17% относительно прежнего значения. Это не прибавка в процентных пунктах и не значение конверсии. На показатель могли влиять также дизайн, скорость сайта, продукт и реклама; отдельный вклад текстов не измерен.
05 — Результат
Что получилось
Сопутствующие показатели:
06 — FAQ
Что про такие проекты спрашивают чаще всего
С чего начинать рассказ о незнакомой технологии?
В МТС Exolve мы начинали с ситуации из работы клиента. Когда переписка и звонки хранятся отдельно, менеджеру приходится заново выяснять обстоятельства обращения. Этот пример объяснял назначение омниканальности. Затем можно было рассказать, какие сервисы подключаются через API.
Как получить материал для текста у технического специалиста?
На интервью мы просили разобрать конкретный случай — что мешало клиенту, как решили задачу и что получилось. Это давало материал для страницы. Проверка готового текста тем же экспертом помогала сохранить смысл при редактуре.
Зачем делать отдельную страницу для каждой отрасли?
Клиника организует запись на прием, магазин работает с заказами, логистическая компания сообщает о доставке. Для каждой сферы мы выбирали ее сценарии, хотя технологическая основа оставалась общей. Так руководитель мог оценить применение платформы в знакомом процессе.
Зачем к страницам решений добавлять статьи об API?
На отраслевой странице мы объясняли назначение продукта, а в блоге разбирали вопросы внедрения. Читатель мог отдельно изучить безопасность, сроки и ресурсы подключения. Ссылки в обе стороны связывали эти материалы.
Можно ли приписать весь рост конверсии текстам?
Рост на 17% зафиксирован после переработки содержания раздела. Отдельный вклад текстов не измерен — на обращения могли влиять также дизайн, продукт, скорость сайта и реклама. При этом сравнение показывает результат всего раздела, над содержанием которого мы работали.
Когда этот опыт пригодится другому сложному продукту?
Когда продукт применяется в нескольких отраслях, а сведения о его работе находятся у специалистов компании. Для подготовки страниц нужен доступ к экспертам и реальным случаям. Вопросы внедрения при длинном цикле сделки можно разобрать в отдельных материалах; их состав зависит от продукта.