Телемаркетинг, Автоматизация | Олег Брагинский, Максим Мухтаров
Основатель «Школы траблшутеров» Олег Брагинский и ученик Максим Мухтаров рассказывают, как спроектировать приложение для отправки и отслеживания эффективности коммуникаций пациентам в отечественных многопрофильных медицинских учреждениях.
Внедрение в крупной частной медицинской сети Microsoft Dynamics CRM не оправдало надежд маркетологов: ограниченный перечень фильтров не позволял формировать нужные выборки, а настройка кампаний и заданий по расписанию оказалась недружелюбной и непредсказуемой.
На первых порах проблему обходили ручным импортом контактов в статические списки CRM, рассылками по перечням телефонов через кабинет МТС Коммуникатора и привлечением агентств-подрядчиков для массовой отправки email’ов по передаваемым файлам с электронными адресами.
Сквозной процесс требовал слишком много ручного труда и технических навыков: файлы к загрузке маркетологи могли собирать только из фиксированных отчётов производственных систем, а отследить конверсию в предложение Excel’ем на таких объёмах не представлялось возможным.
Интегратор CRM просил выделить приличные суммы на кастомизацию по полным требованиям и ждать месяцы до первых успехов. Предлагаемая альтернатива – поставка отдельного модуля по подписке – кардинально не устраняла проблему с гибкой фильтрацией и отслеживанием воронки.
Решили автоматизировать постепенно и собственными силами: команда BI-аналитиков, умевшая делать выгрузки из исходных систем, выделила ответственных. С подачи консультантов, крутившихся в кабинетах топ-руководителей, проект назвали CVM (Customer Value Management).
Подрядчику предложили сузить масштаб доработок до создания простых методов API, заменяющих ключевые операции: создание статического списка, прикрепление и открепление контактов. Параллельно в проработку взяли прямую интеграцию с рассыльщиками, которую уже имела CRM.
Предстояло спроектировать целевой процесс запуска рекламной кампании, продумать архитектуру нового приложения, осуществить программную реализацию, протестировать, принять в промышленную эксплуатацию. Двигались итерациями в тесном контакте с внутренним заказчиком.
Выделили основные шаги: завести карточку с техническим заданием в трекинговую систему; выгрузить и проверить сегмент; сконфигурировать кампанию; поставить рассылку на отправку и, при необходимости, на регулярное формирование; настроить мониторинг и посмотреть отчётность.
Архитектурные компоненты очертили двумя контурами: а) внутренним – ядро из базы на MS SQL Server и DAG’ов Airflow с логикой, распределённой по функциональным модулям, и веб-приложение на python-фреймворке Django; б) внешним – корпоративные системы и сторонние рассыльщики.
Отказались от разработки маркетингового хранилища и продвинутого графического интерфейса: не предусматривали no-code конструктор сегментов – функционал, вызывавший изначальные вопросы и широко рекламируемый в вендорных решениях подобных SAS Marketing Automation.
Сегменты, разовые и по расписанию, собирали через привязку к кампании файлов с запросами к базам: а) SQL – для простых выборок; б) python – для соединения ряда источников, применения сложных функций и математических моделей. Вычитывали очереди триггерных событий в буфер.
Каскадные кампании по реакции реализовывали через две обычных: одну из системы-источника для изначальной выборки, вторую – по откликам этого сегмента из CVM. При настройке нескольких предварительных каналов выбирали приоритетный, исходя из ранга и доступности для пациента.
Для обеспечения коммуникационной политики сгрузили контактную информацию. Выделили два вида разрешений: а) общие – есть согласие на обработку персональных данных, не VIP, возраст до 80 лет, нет пометки о смерти в стационаре; б) специальные – пациент разрешил общение в канале.
Чтобы не «жечь базу», ввели исключения по пересечениям кампаний: по умолчанию предложение пациенту могли отправить раз в 7 дней, если получал другие, или раз в 30 дней, если такое же. При попадании в несколько сегментов оставляли пациента в одной рассылке по рангу кампании.
Несмотря на редактирование данных в системах-источниках технической поддержкой вследствие жалоб, для подстраховки ввели чёрный список. С целью аудита логировали изменения «галочек» и контактов в коммуникационном слое. Белый список повысил удобство запуска тестовых отправок.
С рассыльщиками взаимодействовали по API или через очереди – отправляли коммуникации и собирали статусы в режиме push и pull. Начав с SMS и email’ов, довели число доступных каналов до восьми. Освоили социальную сеть VK, в локальных процессах использовали звонки роботом.
В мобильном приложении отображали баннеры и поп-апы, отправляли пуш-уведомления с диплинками. В CRM создавали задачи на обзвон менеджерам премиум-отделений, крепили предложения к карточкам пациентов на экранах для регистратур и операторов контактного центра.
Маркетинговые кампании связывали с приёмами, анализами, диагностикой. Целевое действие категоризировали как любое – важен факт визита, индивидуальное – учитываем конкретные назначения врача; или сочетаниями сопоставлений со справочниками клиник, отделений, услуг.
Эффективность кампаний с основной и контрольной группами устанавливали A/B-тестом. Оцениваемой метрикой считали конверсию в целевое действие, т. к. средний чек зависел не от прихода пациента, а от клинической картины и навыка врача убедить следовать плану лечения.
Людей по группам распределяли случайно, разбиение советовали конфигурировать равномерно. Каждый канал изучали отдельно: различное прохождение коммуникационного слоя нарушало однородность выборки. Размеры групп балансировали после получения статусов рассыльщика.
Для кампаний по расписанию применяли U-критерий Манна-Уитни по 30 рассылкам, для разовых – одну исследовали критерием согласия Пирсона. Рекомендовали использовать 5%-й уровень значимости и односторонний тест: интересовала строго большая конверсия в основной группе.
Кроме маркетинговых и сервисных, запускали кампании по сбору обратной связи. В сообщения вставляли персональные ссылки на веб-анкеты. Интегрировавшись с сайтом, выгружали структуру опросника. Ответы на вопросы хранили в реляционном виде и связывали с элементом рассылки.
Веб-приложение выводило малотранзакционные сущности и справочники в разделе администратора. Наполняли таблицы кампаний, каналов, групп, шаблонов сообщений, конфигураций рассыльщиков, расписаний. Вели каталоги статусов, категорий, метапеременных.
Дополнительно создали статичные страницы для проверки отправки по идентификатору средства коммуникаций или сущности исходной системы; выгрузки сегмента в Excel на проверку; разбивки разовой рассылки на пачки; лёгкой замены шаблона сообщения в привязанном к кампании канале.
Ночные задания включали очистку логов вызовов API и буфера триггерных событий, перенос данных из операционного слоя в исторический для ускорения работы, перегрузку аналитических витрин, администрирование базы: бэкапирование, перестроение индексов, обновление статистик.
Выделяли отчёты трёх категорий: а) технические – мониторинг виртуальных машин, СУБД, Airflow в Zabbix и Grafana; б) оперативные – Direct Query дэшборды в Power BI о состоянии текущего дня и последней недели; в) аналитические – OLAP-куб и другие BI-продукты с данными за всю историю.
Инвестиционные аналитики советуют предпочитать покупные решения: поднимают оценку стоимости компании. Но собственники, не пребывающие на «рынке надежды», помнят принцип операционной эффективности: постоянные издержки приводят к дополнительным переменным.
Даже один грамотный разработчик при активном заказчике в состоянии сделать MVP в течение трёх месяцев и довести до промышленного состояния за аналогичный период. Развиваться ли инхаус дальше – зависит от класса критичности системы. Не mission critical? Смело начинаем проект!
Не стоит игнорировать предложения интеграторов: отсматривать ежегодно и черпать вдохновение. Опыт показал: на рынке сужают функционал в угоду графическому интерфейсу и технологиям. Следует спросить себя: точно ли хотим купить модную архитектуру, а не полезную возможность?