Архитектура

Notification fabric: один канал доставки вместо десяти

Push, SMS, email, voice, in-app — у каждой команды свой стек. Notification fabric централизует доставку, prioritization, frequency caps, consent. Без неё клиент тонет в шуме.

Обсудить задачу

Зачем оператору централизованный notification слой

В типичном операторе уведомления пушит каждый, у кого есть API: маркетинг через campaign tool, биллинг про задолженность, fraud про подозрительные транзакции, network про инциденты, app team про функциональность.

Без централизации:

Клиент получает 8 push-уведомлений в день и отключает их.
Никто не знает, сколько всего сообщений ушло клиенту за неделю.
Frequency caps существуют в каждой команде по-своему.
Consent проверяется неконсистентно.
При смене SMS-провайдера придётся менять 12 интеграций.

Notification fabric — централизованный слой, через который проходит всё, что доставляется клиенту через любой канал.

Структурные элементы

Channel adapters. Унифицированные интерфейсы к каждому underlying каналу: SMS gateway, push provider (FCM/APNS), email service, voice (TTS+IVR), in-app messaging.

Routing engine. Решает, какой канал использовать для каждого сообщения. Логика: preference клиента, urgency, fallback chain (push → SMS → email если недоставлено).

Frequency caps. Глобальные лимиты на сообщения в день/неделю/месяц per клиент, с приоритизацией: critical (transactional, fraud) всегда проходит, marketing соревнуется в quota.

Consent and preference. Клиент выбирает: какой контент в каком канале он готов получать. Проверка consent перед отправкой — обязательный gate.

Template management. Тексты сообщений, локализация, A/B-варианты. Изменение текста — без редеплоя.

Delivery tracking. Receipt acknowledgement, retry logic, dead letter для каналов. Репортинг по delivery rate.

Audit. Каждое сообщение — кто отправил, кому, когда, через какой канал, с каким status. Без audit невозможно отвечать на запросы регулятора.

Где обычно ломается

Fabric есть, но команды обходят его и шлют напрямую через свои интеграции — потому что fabric «медленный» или «не поддерживает наш use case». Через год полцентрализации.

Frequency caps не enforced. Marketing видит квоту, но игнорирует, потому что KPI важнее. Жалобы клиентов растут.

Consent проверяется в момент отправки, но не в момент сборки сегмента. Маркетинг включает в campaign 100k клиентов, fabric отбрасывает 30k без consent — отчёты не сходятся, маркетинг недоволен.

Prioritization не работает. Critical fraud-alert стоит в очереди за маркетинговой рассылкой и приходит через час.

Multi-channel fallback не настроен. Push не доставлен — клиент так и не узнал.

Templates меняют через инжиниринг — каждое изменение текста занимает неделю.

Operating model

Owner — Customer Communications platform lead, в составе CX или digital direction. Не маркетинг (он consumer), не IT инфраструктура (узко).

Команды:

Platform engineering (channel adapters, routing, scale)
Communications operations (templates, governance)
Compliance (consent, audit, regulator interface)

Routine — еженедельный обзор: top senders, delivery rate per channel, opt-out rate, complaints.

Что меряется

Delivery rate per channel — сколько из отправленного дошло. Open / engagement rate — клиент посмотрел / нажал. Opt-out rate — сколько клиентов отказались от канала за период. Frequency utilization — какая доля квоты потрачена. Consent coverage — какая доля базы имеет consent на каждый use case.

Без этих метрик fabric — чёрный ящик.

Как SamaraliSoft подключается

Notification Fabric Blueprint — 6-8 недель. Inventory current senders, дизайн channel architecture, governance, choice of platform (build vs MoEngage / Twilio / Braze), pilot — обычно один use case (например, transactional биллинг) с миграцией senders.