Телемаркетинг, Процессная эффективность | Олег Брагинский, Максим Мухтаров
Основатель «Школы траблшутеров» Олег Брагинский и ученик Максим Мухтаров рассказывают, как организовать процесс старта рекламных кампаний, направленных на прямую коммуникацию с пациентами, в отечественных многопрофильных медицинских учреждениях.
В крупной частной медицинской сети начали разработку приложения CVM по автоматизации маркетинговых рассылок. Для изначального формирования требований к системе и последующей стабильной эксплуатации возникла необходимость описать процесс запуска рекламных кампаний.
Регламент видели основой для инструкций пользователей, одновременно причиной и результатом принимаемых архитектурных решений. Предстояло классифицировать роли, выделить этапы, утвердить наполнение работ по зонам ответственности, настроить систему отслеживания задач.
Отказ от графического конструктора сегментов ради максимальной гибкости создания выборок обусловил необходимость в двух дополнительных по отношению к маркетологу ролях и снял нагрузку, которую вендорные решения возлагают на «менеджера по управлению кампаниями»:
- Маркетолог – оформляет техническое задание в виде карточки задачи в таск-трекере.
- Аналитик-исполнитель – создаёт кампанию, выгружает сегмент, отправляет рассылку.
- Аналитик-контролёр – проверяет код с запросом и настройки коллеги в системе.
Под ролью маркетолога выступали как сотрудники одноимённого централизованного департамента, так и работники смежных подразделений, которых функционально обязывали аккумулировать требования о рассылках: рекламным, сервисным, по сбору обратной связи.
Аналитики числились в штате Управления по работе с данными, обладали навыками составления SQL-запросов и python-скриптов. Одновременно выступали как младшие члены проектной команды и могли в пределах компетенции расширять функциональность системы в рамках спринтов.
В качестве таск-трекера выбрали облачный Bitrix24: там маркетологи взаимодействовали с агентствами. Создали проект, добавили участников. По соображениям информационной безопасности решили обмениваться файлами, указывая в комментариях путь к сетевым папкам.
Настроили шаблоны задач с названиями двух типов: а) «<Отправка через> | <Название кампании>» и б) «ПРОЧЕЕ | <Задача>». Сотрудникам с ролью маркетолога выдали права на использование. Редактирование сохраняли за техническим владельцем внутренней системы и заместителем.
Первые содержали ТЗ на кампанию и подразделялись в зависимости от способа конечной отправки: CVM, Агентство (массовые email-рассылки через подрядчиков), ЛК МТС Маркетолога. Вторые служили для общих вопросов, конкретизировавшихся фразой в пояснительной части заголовка.
Заводя по пять новых кампаний в рабочий день, маркетологи хотели по названию ориентироваться в том, где, как, что и кому отправляем. Ввели инструкцию, регулирующую нейминг кампании, чтобы при взгляде на карточку прояснялась суть: «<Регион>. <Каналы>. <Предложение>. <Фильтры>».
Например, «Москва. Пуш, СМС. Кортизол бесплатно. СК. Не был с 2022» информирует через мобильное приложение или телефон об акции по соответствующему анализу пациентов с действующим в столичных клиниках полисом ДМС, не совершавших визитов с указанного года.
Внутри задачи предусмотрели разделы под параметры кампании: сегмент, целевое действие, каналы, шаблоны сообщений, расписание, разбиение на группы, пересечения. Создали инструкцию, определявшую, как переложить информацию из карточки в таблицы веб-приложения.
Спроектировали канбан-доску, заложив в качестве столбцов этапы процесса. Определили вход, выход, технологию – кто что делает в ходе фазы. Результат каждой стадии поместили внутрь карточки как пункт чек-листа. Граф состояний регулировал переходы по виртуальному конвейеру:
В «Идее» маркетолог преобразовывал поступающий запрос в карточку на запуск рекламной кампании. Ставил задаче ожидаемый срок, обсуждал с коллегами на совместном планировании. Для демонстрации предстоящих рассылок по дням рассматривал встроенный в Bitrix календарь.
После внутренних согласований: исключения конфликтов по предложениям и целевой аудитории, выравнивания коммуникационной нагрузки на базу пациентов, маркетолог переносил карточку в «План», изменяя срок на требуемый. Задача становилась готовой к проработке аналитиком.
Аналитик-исполнитель изучал карточку «В плане» и, если понимал, что реализовать запрос текущим функционалом нельзя, переводил задачу «В отложено по техническим причинам». Перед планированием очередного спринта на доработку CVM техлид формировал из таких задач бэклог.
Альтернативно, описание конфигурации кампании могло вызвать вопросы или желание проконсультировать маркетолога, как удовлетворить потребность иначе. Тогда аналитик перемещал карточку в «Ожидание уточнений» и затевал переписку с заказчиком в комментариях.
При однозначных и ясных требованиях, реализуемости кампании текущим функционалом CVM аналитик-исполнитель брал карточку «В работу» сразу: настраивал кампанию в интерфейсе веб-приложения, выкладывал в сетевую папку файл сегмента на ревизию кода и переносил «В review».
Получив задачу «В review», аналитик-контролёр сверял код коллеги по чек-листу создания сегмента, описанному в отдельной инструкции: SQL- или python-файл соответствует шаблону, под сущности использованы типичные запросы, пункты из ТЗ помещены в комментарии внутри скрипта.
После ревизии кода аналитик-контролёр возвращал карточку в «Работу» либо с указанием исправить алгоритмы, либо с согласованием на формирование рассылок. Аналитик-исполнитель выгружал файлы веб-приложением на сетевой диск и переводил карточку в «Проверку сегмента».
Для кампаний, требующих настройки во внешних системах и сохранения сторонних идентификаторов в CVM перед выгрузкой файлов, аналитик-исполнитель переносил задачу в «Ожидание реквизитов рассылки». Дополнив описание, маркетолог помещал карточку в «Работу».
В сформированных поканально Excel’ях маркетолог проверял атрибуты и размер сегмента, текст сообщения для каждого элемента с подставленными в шаблон значениями метапеременных. Затем возвращал карточку в «Работу» с указанием исправить недочёты или запустить рассылку.
По разовым кампаниям аналитик-исполнитель отправлял рассылку или разбивал на пачки для отложенной автоматической обработки в нужные даты, по регулярным – настраивал расписание. Если задача предполагала целевое действие, переносил карточку в «Проверку мониторинга».
Изучая статистику по воронке, маркетолог смотрел на агрегированные показатели дэшбордов, убеждался в корректности, проверяя детализированную информацию в OLAP-кубе. При сомнениях возвращал в «Работу» с просьбой перенастроить целевое действие и перегрузить витрины данных.
По кампаниям с контрольной группой маркетолог переносил карточку в «Ожидание результатов A/B-тестирования». После истечения периода мониторинга, достаточного для проведения исследования исходя из конфигурации целевого действия, знакомился с выводом в отчётности.
Затем переносил в «Работу» с комментарием: если конверсия в основной группе больше, чем в контрольной, и отвергаем нулевую гипотезу, то убираем разбиение; иначе – останавливаем кампанию. Аналитик-исполнитель завершал обработку, перемещая карточку в столбец «Готово».
Ход любого процесса рано или поздно начинает буксовать. Дребезжание устраняется двумя путями: а) автоматизацией, исключающей отклонения, б) привитием внутренних стандартов сотрудникам. Первый, требуя стратегичности и значительных инвестиций, не заменяет второго.
Убедились на практике: только регулярный совместный контроль способен обеспечить сонаправленность усилий на всех этапах процесса и держать команду в тонусе. Регламенты, инструкции, дэшборды, доработки системы – лишь инструменты, подкрепляющие волю лидера.