Как зафакапить 2 проекта внедрения Carrot quest в SaaS-сервисы и хоть чему-то наконец научиться

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

Мы — команда Carrot quest. Это сервис, который сам собирает информацию о каждом посетителе сайта и на основе этих данных помогает вести каждого из них к покупке, как вручную, так и автоматически.

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

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

Внедрение — это непростая история, и как бы ни хотелось, не всегда всё идет так, как должно. Обычно в интернет-магазинах все клиенты двигаются к покупке по более-менее одинаковому маршруту. SaaS-сервисы предоставляют своим клиентам всевозможные услуги от изучения английского языка до сложных B2B возможностей по аналитике и маркетингу. Поэтому у каждого из них своя целевая аудитория, свои шаблоны поведения пользователей и потребности (а у многих сервисов сегменты ЦА могут сильно отличаться). Вот почему варианты автоматизации SaaS-сервисов намного сложнее и разнообразнее, чем в интернет-магазинах.

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

InnMind

Один из SaaS-сервисов, который обратился за услугой внедрения, находился на ранней стадии развития, поэтому у нас был большой простор для настройки коммуникаций.

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

Всего среди пользователей InnMind выделяется 4 сегмента: стартап, инвестор, партнёр (корпорация) и эксперт:

• Стартапы приходят в InnMind, чтобы рассказать о своём проекте, найти инвесторов и получить поддержку в различных аспектах развития своего бизнеса.
• Инвесторы, наоборот, ищут перспективные стартапы, в которые им будет интересно вложиться. Кроме того, прямо на InnMind они могут привлекать экспертов для инвестиционной оценки или технологической экспертизы проектов, создавать воронку стартапов и заказывать услуги due-diligence.
• Эксперты предлагают свои услуги целевой аудитории и могут анализировать приоритетные для них секторы рынка.
• Партнёры — это фирмы, промышленные компании и международные корпорации, которые стремятся к внедрению инноваций в свои продукты и процессы. Благодаря InnMind они могут  привлекать стартапы, приглашать партнеров для совместного инвестирования, находить лучших поставщиков услуг юридической и технологической экспертизы.

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

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

1. Не углубились в процессы

История с SaaS-сервисами всегда сложная. Мы составили своё представление о пользователях и действиях, которые они могут совершать. Мы не могли сказать, правильно это представление или нет, потому что основывались только на своих предположениях. В итоге мы не совсем правильно сформировали сценарии и первый бриф выглядел приблизительно так:

• Собрать события:
  • нажал на кнопку «войти»;
  • оплатил аккаунт.
• Собрать свойства:
  • Стартап;
  • Инвестор;
  • Партнёр;
  • Эксперт.

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

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

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

2. Проблема в коммуникациях

Мы собираем только те данные, которые можно собрать нашим Мастером сбора данных, не залезая в код сайта, поэтому не собираем данные через API (с клиента и с сервера). Задачей команды InnMind было собрать и передать нам данные по API. Мы сказали приблизительно следующее: «Соберите нам вот эти события» и дали какую-то общую ссылку с информацией о событиях (скорее даже не для программистов, а для маркетологов). Ошибка была в том, что мы не дали ни ТЗ для разработчиков ни хорошей инструкции о том, как настраивать события.

Мы не сразу выяснили, что настройку сбора событий клиент отдаст на аутсорс. Естественно, что без подробной инструкции сторонний программист, который ничего не знает о Carrot quest, не смог правильно собрать события. Например, мы не видели свойства пользователя (то есть мы не знали, стартап он, эксперт, инвестор или партнёр). По сути, это одна из важнейших характеристик, на которых основывалась наша сегментация. Клиент видит, что сообщения не отправляются, и делает вывод, что Carrot quest не работает. В итоге он расстраивается и перестаёт верить в способности нашего сервиса.

Чтобы наладить передачу событий и свойств, мы стали вмешиваться в этот процесс и объяснять ошибки. Цепочка общения стала слишком длинной: наш разработчик — аккаунт-менеджер с нашей стороны — их маркетолог — их разработчик. Естественно, что в таком случае терялся важный контекст, и мы тратили время слишком большого количества людей. Сейчас кажется очевидным, что, если проблема технического характера, то лучше, чтобы между собой общались сотрудники, которые понимают друг друга (то есть программисты напрямую).

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

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

3. Нерационально использовали время

Мы решили взяться за всё сразу и автоматизировать «по полной». У нас получилась разветвлённая карта, процесс согласования которой занял у нас около месяца.

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

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

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

Мы больше не гонимся сразу за всеми зайцами. Договариваясь с клиентами о настройке сервиса, мы на начальном этапе внедряем только 3 сценария. Их удобно настраивать и легко анализировать. Естественно, что они могут не покрыть всех потребностей сайта, но это хорошая отправная точка для следующих итераций.

Happy End

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

Yagla

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

Это интересный сервис, и мы с энтузиазмом взялись за внедрение.

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

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

Проблема пришла, откуда не ждали: мы никак не могли подумать, что не сможем наладить контакт и согласовать работу. Наши задачи казались нам настолько очевидными, что мы не подумали, что другие люди могут понимать их как-то иначе. А так как разногласия вскрылись слишком поздно, в итоге мы не смогли договориться.

1. SaaS — это сложная история

Если в ситуации с InnMind мы не сразу углубились в процессы и путь пользователей, то в случае с Яглой мы кинулись в другую крайность и потратили на это слишком много времени.

На первый чек-лист (в котором мы описываем основные события и свойства пользователей) мы потратили 9 дней (и потом несколько дней на согласование и доработку). Для интернет-магазинов это занимает несколько часов, но там мы знаем основные маршруты пользователя. Как мы уже говорили, каждый SaaS-сервис отличается по функционалу, целевой аудитории и пути пользователя. Мы думали, что удастся использовать нашу готовую карту сценариев для SaaS, но на практике они им не подошли. Поэтому нам пришлось углубиться и пройти по примерному пути пользователя конкретно в этом сервисе. Конечно, 9 дней — это перебор и можно было справиться за 3-4 дня.

2. Не перенесли отработанные бизнес-процессы на новые инструменты

Обычно мы строим карту коммуникаций (помните, мы писали о ней в начале статьи?) в Mindomo, а потом рассказываем клиенту обо всех шагах с помощью гугл-презентаций.

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

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

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

Вывод? Переходя на новый инструмент, необходимо переносить с собой бизнес-процессы. Это сложно сделать быстро и за один раз, поэтому лучше всего внедрять постепенно, параллельно с другими проектами. Пользоваться новыми инструментами хорошо, но не забывайте о тех принципах работы, которые вы долго настраивали. Не стоит переворачивать всё с ног на голову за один раз.

Это повлекло все дальнейшие трудности.

3. Проблема в терминологии

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

Сейчас еще раз остановимся на процессе подробнее.

4. Не объяснили клиенту план и процесс

Наша стандартная схема работы во время настройки выглядит так:

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

Из-за сбившихся процессов возникло недопонимание — мы не донесли полноценный план.

Сначала мы дали шаблонную карту для SaaS-сервисов, из которой можно было выбрать сценарии. Вскоре мы поняли, что она не подходит под решаемые задачи, и пришлось разрабатывать сценарии под цели заказчика. Тем не менее, мы старались придерживаться плана «не больше 7 сценариев». Клиент об этом знал и был согласен.

Мы отклонились от стандартного процесса и пытались выстроить более развёрнутую карту, максимально учитывая пожелания клиента. Из-за этого начался полный бардак. Часть сценариев начала дублировать другие сообщения, и мы рисковали забросать пользователя повторяющимися сообщениями. Итоговую карту мы так и не предоставили. Мы старались доделать, подстраиваясь под желания заказчика, потому что нам не хватило смелости сказать «нет, это будет уже на втором этапе». В итоге уже ни мы, ни Ягла не понимали, где границы этого этапа внедрения.

Мы сами создали себе проблему, не потрудившись расставить все точки над i с заказчиком. Сейчас первым делом мы обсуждаем план внедрения, сверяем понимание объёма и последовательности работ, а только потом беремся за выполнение.

5. Много слов не значит, что всё понятно

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

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

Выводы

Проект мы потеряли, так как наши ожидания разошлись с ожиданиями клиента, но в итоге мы пришли к пяти выводам:

1. Ожидания клиента всегда должны совпадать с реальностью, а для этого нужно говорить с клиентом не только о мелочах, но и о плане в целом.
2. Клиент должен быть в курсе всех шагов и тонкостей плана.
3. Все процессы должны быть синхронизированы, все понятия — объяснены, чтобы не возникало хаоса.
4. Нужно создавать правила, о которых рассказывать клиенту и сотрудникам. От этих правил мы не должны отступать (например, менять карту после согласования только в случае фатальных ошибок или после аналитики).
5. Четко следовать плану!

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

К счастью, число успешных внедрений у нас перевалило за 50, что намного больше, чем провальных. Почитайте, как мы увеличили продажи на 30% в интернет-магазине 21Shop, собрали в 2 раза больше лидов для Make case, подняли продажи на 15,77% для Цвет Диванов или снизили отток пользователей на 30% для Get lost. Get natural.

Выстраивать бизнес-процессы непросто. Мы стараемся найти общие вещие в разных сферах, чтобы быстрее внедрять эффективные методики. Тем не менее, каждый сервис, который приходит к нам на внедрение, уникален и с каждым мы работаем индивидуально. Поэтому быстро встаёт вопрос о каких-то универсальных правилах внутри команды, которые необходимо разработать и принять, чтобы не совершать (или не повторять) ошибок. Именно о таких базовых принципах, которые мы вынесли из работы, мы и рассказали в этой статье.

Случались ли у вас факапы? Чему они вас научили? Поделитесь своими идеями и наблюдениями и давайте вместе улучшать процессы и быть продуктивными.

С удовольствием, Carrot quest, сервис, который автоматически собирает информацию о каждом посетителе вашего сайта и помогает вести его к покупке, как вручную, так и автоматически. Вы можете попробовать сервис бесплатно в течение 7 дней.