Единая платформа или набор сервисов для CRM

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

Набор систем, которые обеспечивают работу с клиентскими данными и коммуникациями, называют CRM-стеком. В него могут входить CDP — платформа для объединения клиентских данных, ESP — сервис email-рассылок, инструменты других каналов и аналитики. Архитектура стека описывает, как распределены их задачи и как между ними движутся данные. Интеграция — настроенный обмен, благодаря которому, например, оплаченный заказ становится известен системе рассылок.

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

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

Начните со схемы одного клиентского действия

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

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

В таблице профиль означает связанную запись с данными клиента, а клиентская модель — правила, по которым такие записи устроены и объединены. Сегментация выбирает из базы группу по заданным условиям, например покупателей определённой категории за месяц.

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

Считайте сложность обмена по последствиям

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

В архитектуре из нескольких сервисов запись об одной покупке может получать несколько систем. Этот подход называют publish–subscribe: источник сообщает о событии, а подключённые получатели обрабатывают его для своих задач. В документации Amazon Web Services (AWS) отдельно отмечены гарантии доставки и возможные дубликаты. [1] Для CRM это означает, что канал отправки, аналитика и программа лояльности должны распознавать повторную передачу сведений об одной покупке.

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

Сравнивайте стоимость изменения

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

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

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

Условный пример сравнения на два года

Ретейлеру нужны email, push-уведомления — сообщения от приложения или сайта на устройстве пользователя — и программа повторных покупок. В обоих вариантах функциональный результат одинаков, необходимые ограничения проверены. Суммы ниже условные, в миллионах рублей без НДС; стоимость отправок одинакова и не включена. Время сотрудников оценено по полной внутренней стоимости занятости: доле оплаты труда, обязательных начислений и других согласованных расходов на команду, которая приходится на проект.

Лицензии отдельных сервисов дешевле на 1,8 миллиона, но эта экономия в примере компенсируется внедрением и сопровождением. Поэтому выбирать по стоимости подписок нельзя. AWS при оценке компонентов также предлагает учитывать управленческие и эксплуатационные расходы, а не только цену ресурса. [2] Сам расчёт выше — редакционный пример CRM Lab.

Если у компании уже есть подходящие интеграции и свободная команда, второй вариант может подешеветь. Однако существующие расходы нельзя объявлять нулевыми: для решения о бюджете отдельно покажите дополнительные выплаты и занятость уже нанятых сотрудников. Последняя может не увеличить счёт в этом месяце, но сократит возможности делать другую работу.

Проверьте поведение при отказе

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

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

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

Назначьте владельца сквозного результата

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

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

Как оформить выбор

Сравните архитектуры по пяти проверенным параметрам: выполнение обязательных сценариев, полная стоимость, скорость типовых изменений, поведение при отказе и возможность замены компонентов. Требования, без которых нельзя запускаться, проверяйте отдельно от удобства интерфейса.

Если различия по бюджету невелики, решающим может стать наличие команды сопровождения. Компании, у которой такой команды нет, полезно выбирать решение с меньшим объёмом собственной эксплуатации. Для бизнеса с развитой инженерной функцией отдельные компоненты могут дать нужную свободу. Оба решения профессиональны, если их последствия посчитаны и понятны тем, кто будет работать с системой ежедневно.

Источники

[1] Amazon Web Services. Publish-subscribe pattern. AWS Prescriptive Guidance.

[2] Amazon Web Services. COST05-BP03 Perform a thorough analysis of each component. AWS Well-Architected Framework.