CRM-аналитика
Свой сервис рассылок или готовая ESP
Время чтения: 6 мин
Уровень материала: Для экспертов
Содержание
Когда расходы на рассылки растут, у компании может появиться идея написать собственный сервис. Разработчик показывает, что письмо отправляется через недорогого провайдера, и сравнение выглядит выгодным. Но передача готового письма — лишь одна часть работы: кому его отправить, как учесть отписку и что делать после ошибки, системе тоже нужно знать.
ESP (Email Service Provider) — сервис для подготовки и отправки email-рассылок, обычно с инструментами работы с получателями и автоматическими цепочками. Почтовый транспорт — компонент, который принимает подготовленное письмо и пытается доставить его почтовому серверу получателя. Компания может купить такой транспорт и построить собственное управление рассылками поверх него.
Поэтому «свой сервис» нужно описать точнее: какие функции компания разрабатывает сама, какие получает от провайдера и кто сопровождает всё решение. Иногда собственная разработка оправданна особыми требованиями и возможностями инженерной команды. Но цену одного отправленного письма нельзя сравнивать со стоимостью целой ESP без учёта остальной работы.
Разберём состав функций и условный бюджет на два года, чтобы сравнить варианты на одинаковых основаниях.
Определите что именно предлагается разрабатывать
Транспорт принимает подготовленное письмо и пытается доставить его почтовому серверу. Система управления рассылками дополнительно хранит шаблоны, аудитории, ограничения, сценарии и историю действий. Интерфейс для маркетолога — ещё одна часть продукта.
Для сравнения перечислите функции, которые команда использует сегодня и планирует в утверждённом горизонте. Не включайте всю функциональность крупной ESP, если она не нужна. Но и не исключайте обязательные процессы только потому, что их незаметно выполняет текущий поставщик.
| Задача | Что нужно обеспечить в своём решении |
|---|---|
| Подготовка письма | Шаблоны, подстановки, предпросмотр и проверка ссылок |
| Отбор получателей | Воспроизводимая аудитория и исключения |
| Ограничения | Отписки, запреты, частота и приоритеты |
| Отправка | Очередь, повторные попытки и защита от дублей |
| Доставка | Обработка отказов, жалоб и статусов |
| Измерение | События коммуникаций и связь с экспериментом |
| Эксплуатация | Доступы, журнал, остановка и восстановление |
Для каждой строки определите, что вы разрабатываете, что покупаете и что уже есть в компании. Тогда сравнение не будет противопоставлять полноценную ESP одному скрипту отправки.
Доставляемость остаётся отдельной работой
Покупка транспорта не освобождает отправителя от требований почтовых сервисов. Аутентификация отправителя помогает почтовому сервису проверить, что письмо действительно отправлено от имени указанного домена. Google публикует требования к такой проверке, качеству отправки и удобству прекращения подписки для писем в личные Gmail-аккаунты; часть требований зависит от объёма отправителя. [1] Эти требования нужно учитывать при любом варианте архитектуры.
Команде понадобится работа с доменами, репутацией, отказами, жалобами и изменениями объёма. Репутация отправителя отражает то, как почтовые сервисы оценивают его предыдущие отправки; она может влиять на приём писем и попадание во входящие. Часть задач выполняет провайдер, часть остаётся у компании. Зафиксируйте границу в сравнении и договоре.
Статус «передано провайдеру» также не равен доставке во входящие. В документации сервиса доставки писем Amazon SES различаются события отправки и последующей доставки или отказа. [2] Собственная отчётность должна сохранять этот смысл и не объявлять техническое принятие письма контактом, который человек обязательно увидел.
Условное сравнение на 24 месяца
Компания оценивает одинаковый набор email-сценариев. Объём отправок и цена внешнего транспорта в примере сопоставимы. Все суммы условные, в миллионах рублей без НДС; внутренний труд оценён по полной стоимости занятости.
| Расход | Готовая ESP | Собственная система |
|---|---|---|
| Внедрение или первоначальная разработка | 0,6 | 3,0 |
| Лицензия и базовая инфраструктура | 2,4 | 0,8 |
| Передача сообщений за период | 1,2 | 1,2 |
| Сопровождение и развитие | 1,2 | 3,6 |
| Проверка доставки и изменения требований | 0,4 | 0,7 |
| Всего | 5,8 | 9,3 |
Разница составляет 3,5 миллиона рублей. В этой конфигурации собственная система должна дать дополнительное преимущество, которое оправдает затраты, либо её оценка должна измениться на основании подтверждённых возможностей команды.
Расходы на развитие здесь не включают уже учтённую первоначальную разработку. Если один сотрудник выполняет несколько функций, распределите его время между строками, не прибавляя полную зарплату повторно. Такой же принцип применяется к общей инфраструктуре.
Где может появиться экономическое преимущество
При очень большом объёме разница тарифов может перекрыть стоимость команды. Но считать нужно не только текущую ставку за письмо: учитываются рост объёма, договорные скидки, резерв мощности и расходы на ошибки.
Собственное решение также может ускорять специфические сценарии, которые трудно реализовать в ESP. Это преимущество нужно описать через конкретный процесс: что станет возможным, насколько часто используется и как влияет на результат. Обещание «полной гибкости» без плана использования не является финансовым эффектом.
Amazon Web Services (AWS) при сравнении компонентов рекомендует учитывать операционные расходы и влияние управляемых сервисов на объём собственной работы. [3] Для CRM это означает, что передача части ответственности поставщику имеет стоимость, а возврат этой работы внутрь требует команды.
Учтите время до первого полезного результата
Если готовый сервис позволяет запустить нужные сценарии через месяц, а собственная система — через полгода, возникает стоимость задержки. Её можно оценить через реалистичный диапазон недополученного дополнительного результата или отложенных улучшений.
Не используйте всю выручку канала как потерю за время разработки. Действующая система может продолжать работать, а часть покупок не зависит от новых механик. Сравнивается именно разница между доступными вариантами.
У собственного проекта полезно задать этапы: надёжный обмен, безопасная отправка, интерфейс маркетолога, измерение, поддержка. Для каждого этапа — критерий готовности и бюджет. Иначе недостающие функции будут появляться уже после объявленного «запуска».
Кто будет поддерживать систему через год
Проверьте, есть ли как минимум возможность передать знания другому инженеру, документация, автоматизированный выпуск и понятный порядок реакции на сбой. Один сильный разработчик может быстро создать систему, но не обеспечивает непрерывную доступность в одиночку.
Также оцените интерес команды к этой задаче. Если CRM-инфраструктура постоянно проигрывает приоритет основному продукту, маркетинг может ждать исправления неделями. Такая зависимость должна учитываться так же, как сроки поддержки внешнего поставщика.
При выборе ESP аналогично проверяется поддержка: кто разбирает критичный инцидент, какие есть ограничения и как выгрузить данные. Готовая платформа не снимает необходимость управлять процессом со стороны компании.
Когда разумен промежуточный вариант
Компания может сохранить готовый транспорт и инструмент подготовки писем, а собственными силами управлять аудиториями или особыми решениями. Либо оставить ESP основной системой, вынеся одну нестандартную механику в отдельный сервис.
Такой вариант стоит выбирать, когда граница ответственности понятна и не дублирует запреты, частотные ограничения и историю отправок. Итоговое решение должно показывать, кто делает каждую часть работы, сколько это стоит и как система продолжит функционировать при изменениях команды и нагрузки.
Источники
[1] Google. Email sender guidelines. Gmail Help.
[2] Amazon Web Services. Monitoring your Amazon SES sending activity. Amazon SES Developer Guide.
[3] Amazon Web Services. COST05-BP03 Perform a thorough analysis of each component. AWS Well-Architected Framework.