Most platform assessments of channel capability start and stop at a headcount: how many channels does this platform support? But channel count is trivial. Every platform at mid-market pricing will say yes to email, SMS, push, and WhatsApp.
What that headcount doesn’t tell you is whether those channels will actually work in the automations you need to run. Two platforms can both claim SMS support while being architecturally worlds apart — one running it on the same engine as email, one syncing to a third-party provider every 30 minutes. Identical on a feature grid. Completely different in production.
A proper assessment needs to go beyond coverage and evaluate four additional dimensions: data sharing, orchestration integration, suppression logic, and deliverability infrastructure. This post covers all five as part of Layer 3 of the 5-layer capability framework — the full methodology is in the Capability-Led Approach to Marketing Automation: A Complete Planning Guide.
Channel Coverage
Channel coverage is the starting point: which channels does the platform support, and — critically — how does it support them?
The how matters because of the architectural choice most email platforms made when customers started asking for additional channels. These platforms were built as email platforms. When SMS became a requirement, they had two options: rebuild the core data model and orchestration engine so SMS runs natively alongside email, or connect a third-party SMS provider via API and ship it fast. The second option is cheaper, quicker, and commercially obvious. Most platforms took it — then did the same again for push notifications, then for WhatsApp.
The result is a channel that appears on the feature list but runs on a separate system with its own data store, its own logic, and no live visibility of what the rest of the platform is doing. That is what bolted-on means. A native channel, by contrast, is built on the same data model and orchestration engine as email — it behaves as a first-class citizen of the platform, not a connected add-on.
The distinction matters because every other sub-capability in this layer — data sharing, orchestration, suppression, deliverability — degrades significantly when a channel is bolted on rather than native. The failure modes are covered in the sections below.
What to assess
For each channel a platform claims to support, establish:
- Is this channel built on the platform’s core data model and orchestration engine, or connected via a third-party integration?
- If it is integrated, how deep is that integration? Is the third-party provider’s data model mapped to the core contact record, or maintained separately?
- Which pricing tier is required to access each channel? Channel support that requires a top-tier contract is not the same as channel support that is available at mid-market pricing.
- What is the platform’s channel roadmap? A channel listed as ‘coming soon’ or ‘in beta’ carries execution risk that a generally available channel does not.
Data Sharing
When a contact interacts with a channel — opens an SMS, taps a push notification, responds to a WhatsApp message — that behavioural data should update the same contact record that drives every other decision in the platform. Segmentation, scoring, personalisation, and automation logic should all have access to the full picture of how a contact is engaging, regardless of channel.
In a native channel architecture, this is automatic. The SMS click, the push notification response, and the email open all write to the same contact record in real time. In a bolted-on architecture, the channel’s data lives in the provider’s system and syncs to the core platform on a schedule — hourly, daily, or on manual trigger. Until the sync runs, the core platform has a stale view of that contact.
Why this matters in practice
Consider a win-back sequence that escalates to SMS after two unopened emails. If the SMS click data doesn’t feed back into the core contact record in real time, the platform doesn’t know the contact has re-engaged via SMS when it evaluates whether to send the next email. The contact receives the third email anyway — because the platform’s view of their engagement is incomplete.
The quality of data flowing into the platform is a prerequisite for channel personalisation to work at all. The Data Layer Audit covers data layer readiness in depth — incomplete or delayed channel data is one of the most common reasons personalisation returns generic output despite the capability existing in the platform
What to assess
- When a contact interacts with this channel, does that behaviour update the core contact record in real time, or via a scheduled sync?
- Can behavioural data from this channel be used as a trigger or condition in automations built in the core platform?
- Is the contact identifier consistent across all channels, or does each channel maintain its own contact record that must be matched and merged?
- If the data sync fails or is delayed, what is the impact on automation logic that depends on that channel’s data?
Orchestration
Orchestration is the logic that determines what happens next in an automation sequence: which branch to take, which message to send, whether to wait or act immediately, when to exit. In a multi-channel programme, orchestration logic needs to be able to take every active channel into account at every decision point.
When channels share a single orchestration engine, this is straightforward. A sequence can branch to SMS or email based on a conditional logic step. A contact who clicks the SMS is routed differently from one who doesn’t. A goal exit — triggered by a purchase, a form submission, a CRM stage change — fires across all channels simultaneously because the orchestration engine governs all of them.
When a channel is bolted on, it runs its own logic in parallel. The core platform’s orchestration engine has no live visibility of what the bolted-on channel is doing, and the bolted-on channel has no access to the core platform’s contact data or decision logic. The result is two separate automations running against the same contact with no coordination between them.
What to assess
- Can I build a single automation sequence that branches between email and this channel based on conditional logic, within the core platform’s workflow builder?
- Can I set a goal exit that covers all channels — for example, exit the entire sequence if a purchase occurs, regardless of which channel triggered that exit?
- Can I apply wait steps and timing logic across channels — for example, wait 24 hours after an SMS send before triggering the next email?
- If a contact is mid-sequence in this channel, and their record in the core platform updates, does the in-progress sequence respond to that update?
Suppression Logic
Suppression is the mechanism that prevents a contact from being messaged when they should not be — because they have already converted, because they have hit their frequency cap, because they have opted out. It is the logic that makes multi-channel automation safe to run at volume, and it is the sub-capability most commonly broken by bolted-on channel architectures.
The reason suppression breaks is straightforward: suppression logic can only act on information it has access to. If email and SMS run on separate systems, each system suppresses based only on its own send history and its own opt-out records. Neither has visibility of the other. The contact who received an email at 8am can receive an SMS at 9am because the SMS system has no record of this morning’s email. The contact who opted out of SMS last night can receive another SMS this morning if the opt-out hasn’t synced yet.
Frequency caps
A frequency cap — no more than one message per day, no more than three touches in a seven-day sequence — is only meaningful if it covers all channels. A cap that applies to email but not to SMS, because the two systems can’t share send history in real time, is not a frequency cap. It is two separate caps operating independently against the same contact.
Opt-out handling
GDPR and PECR require opt-outs to be honoured promptly. In a native architecture, an SMS opt-out updates a single preference record that governs all channels instantaneously. In a bolted-on architecture, the opt-out is recorded in the SMS provider’s system and must sync to the core platform before it takes effect there. The sync window — even if it’s 15 minutes — is a compliance exposure. An automated trigger that fires in that window sends to a contact who has already opted out.
Purchase suppression
Purchase suppression — exiting a contact from an active sequence the moment they convert — requires a real-time event flow from the transactional system to the orchestration engine. In a single-engine architecture, a purchase event suppresses the contact from all in-flight sequences across all channels simultaneously. In a bolted-on architecture, the purchase event must reach both systems before suppression is complete. A 30-minute sync cycle means every contact who purchases in the 29 minutes after the last sync is still eligible to receive a message from the bolted-on channel.
What to assess
- Can I enforce a cross-channel frequency cap that covers email and all other channels combined, or does each channel enforce its own cap independently?
- When a contact opts out of a channel, how quickly does that suppression propagate to all other channels?
- Where are preference and opt-out records stored? Is there a single master record, or does each channel maintain its own?
- If a purchase event occurs mid-sequence, does it suppress the contact from all in-flight sequences across all channels simultaneously?
Deliverability Infrastructure
Deliverability means different things for different channels, but the underlying question is the same: does the platform have the infrastructure to reliably get messages to the intended recipient, and the reporting to tell you when it doesn’t?
For email, deliverability infrastructure is sending reputation, domain authentication (SPF, DKIM, DMARC), bounce handling, and list hygiene tooling. For SMS, it is carrier relationships, number provisioning (long code vs short code vs toll-free), and compliance with regulations governing commercial messaging — PECR in the UK, TCPA in the US. For push, it is app integration, device token management, and delivery confirmation.
In a bolted-on architecture, deliverability infrastructure for each channel is owned and managed by the channel provider, not the platform. This creates two practical problems. First, accountability is split: when an SMS campaign underperforms, it is not always clear whether the problem is the platform’s automation logic, the provider’s delivery infrastructure, or the data feeding into both. Second, deliverability events in one channel cannot inform suppression in another — a hard bounce on an SMS number, for example, doesn’t automatically suppress the contact from email in the way that a native architecture would allow.
What to assess
- Who owns and manages deliverability infrastructure for each channel — the platform, a third-party provider, or a combination?
- Is deliverability reporting for all channels available in a single view, or split across the platform and the provider’s dashboard?
- How are deliverability failures in one channel — hard bounces, delivery errors, carrier blocks — handled? Do they trigger suppression or notifications within the core platform?
- For SMS specifically: what number provisioning options are available, and what is the platform’s process for managing carrier compliance?
Putting It Together: The Channel Layer Evaluation
The five sub-capabilities above give a structured basis for comparing how any platform handles any channel it claims to support. The table below summarises the key evaluation question for each, and what a strong versus weak answer looks like in practice.
Sub-capability | The key question | Strong answer | Weak answer |
Channel coverage | Is this channel native or bolted-on? | Built on the core data model and orchestration engine | Connected via third-party API integration |
Data sharing | Does channel behaviour update the core contact record in real time? | Yes — all channels write to a shared contact record instantly | No — syncs on a schedule; core platform has a delayed view |
Orchestration integration | Can I build a single sequence that branches across channels? | Yes — all channels are visible to the core orchestration engine | No — each channel runs its own logic independently |
Suppression logic | Do frequency caps and opt-outs apply across all channels combined? | Yes — single suppression engine governs all channels | No — each channel enforces its own suppression independently |
Deliverability infrastructure | Is deliverability reporting unified across all channels? | Yes — single reporting view with cross-channel visibility | No — platform reports email, provider reports the rest |
When a Bolted-On Channel Is Acceptable
Not all bolted-on integrations are equal risks. The evaluation framework above is most critical when:
- Volume is high. At scale, sync latency and integration failures move from edge cases to expected events.
- Timing is sensitive. Behavioural triggers — cart abandonment, post-purchase, browse abandonment — lose their value if they fire 30 minutes late because the sync hasn’t run.
- Suppression is compliance-critical. Any sequence where an opt-out propagation delay creates regulatory exposure.
A bolted-on channel can be operationally acceptable for low-volume, low-frequency supplementary sends where none of the above conditions apply — a quarterly reactivation message to a small high-value segment, reviewed manually before each send. It is not acceptable as the SMS layer of a high-cadence win-back programme, or as the channel carrying purchase-suppressed sequences at any meaningful volume.
The B2C platform selection post covers channel requirements for abandoned cart, win-back, and browse abandonment across the full 5-layer framework — including where SMS escalation specifically requires native support to work reliably. The B2B platform selection post covers the same for opportunity nurture and account re-engagement. For platform-specific channel layer verdicts, the Brevo evaluation and Mailchimp evaluation run both platforms through all five layers — the channel layer verdicts there are direct illustrations of native versus bolted-on SMS in practice.
Next Steps
The channel layer is one of five dimensions that determine whether a marketing automation platform can support the use cases your business needs to run. A platform that handles channel coverage well but has orchestration limitations — shallow conditional logic, no per-contact date-relative triggers — will still fail on the use cases that require both layers to work together.
If you are evaluating platforms across all five layers, or planning a stack review to understand where your current platform is limiting you, the full capability-led planning methodology covers the complete process: audit, capability mapping, gap analysis, reference architecture, 12-month sequencing, and cost modelling.
