Notification fabric: one delivery layer instead of ten

Why an operator needs a centralised notification layer

In a typical operator, anyone with an API pushes notifications: marketing through the campaign tool, billing about debt, fraud about suspicious transactions, network about incidents, app team about features.

Without centralisation:

• The customer gets 8 push notifications a day and turns them off.
• Nobody knows how many messages in total went out to a customer in a week.
• Frequency caps exist in each team in its own way.
• Consent is checked inconsistently.
• Switching the SMS provider requires changing 12 integrations.

Notification fabric is the centralised layer through which everything delivered to the customer in any channel passes.

Structural elements

Channel adapters. Unified interfaces to each underlying channel: SMS gateway, push provider (FCM/APNS), email service, voice (TTS+IVR), in-app messaging.

Routing engine. Decides which channel to use for each message. Logic: customer preference, urgency, fallback chain (push → SMS → email if undelivered).

Frequency caps. Global limits on messages per day/week/month per customer, with prioritisation: critical (transactional, fraud) always passes, marketing competes for quota.

Consent and preference. Customer chooses what content in which channel they are willing to receive. Consent check before sending — a mandatory gate.

Template management. Message texts, localisation, A/B variants. Changing text — without a redeploy.

Delivery tracking. Receipt acknowledgement, retry logic, dead letter for channels. Reporting on delivery rate.

Audit. Every message — who sent, to whom, when, in which channel, with what status. Without audit it is impossible to respond to regulator requests.

Where it usually breaks

The fabric exists but teams bypass it and send directly through their own integrations — because the fabric is “slow” or “does not support our use case”. A year later — half the centralisation.

Frequency caps are not enforced. Marketing sees the quota but ignores it because KPI matters more. Customer complaints grow.

Consent is checked at the moment of sending but not at the moment of segment assembly. Marketing includes 100k customers in a campaign, the fabric drops 30k without consent — reports do not match, marketing is unhappy.

Prioritisation does not work. Critical fraud alert sits in the queue behind a marketing send and arrives an hour later.

Multi-channel fallback is not set up. Push not delivered — the customer never finds out.

Templates are changed through engineering — each text change takes a week.

Operating model

Owner — Customer Communications platform lead, within CX or digital. Not marketing (a consumer), not IT infrastructure (too narrow).

Teams:

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

Routine — weekly review: top senders, delivery rate per channel, opt-out rate, complaints.

What is measured

Delivery rate per channel — how much of what was sent arrived. Open / engagement rate — customer looked / clicked. Opt-out rate — how many customers opted out of the channel over the period. Frequency utilisation — what share of quota was spent. Consent coverage — what share of the base has consent for each use case.

Without these metrics the fabric is a black box.

How SamaraliSoft engages

Notification Fabric Blueprint — 6-8 weeks. Inventory of current senders, channel architecture design, governance, platform choice (build vs MoEngage / Twilio / Braze), pilot — usually one use case (for example, transactional billing) with sender migration.

Related

• /en/architecture/telecom-consent-architecture/ — consent layer
• /en/architecture/telecom-realtime-decisioning-architecture/ — decisioning as trigger
• /en/insights/telecom-message-fatigue/ — message fatigue
• /en/solutions/telecom-cvm-platform/ — CVM as fabric consumer