Traffic classes have incompatible requirements
The argument for one sender identity and one route is simplicity: one registration, one integration, one bill. The argument against it is that the classes sharing that route have different deadlines, different consent bases, different content review and different definitions of success.
Once they share a route, a scheduled campaign's queueing behaviour applies to an authentication code, and a content review triggered by promotional wording applies to the sender identity carrying that code. Neither effect is visible in an aggregate delivery percentage.
Five classes are worth separating explicitly:
- Authentication — a code or link the user is actively waiting for. Useful only inside the window they remain in the flow.
- Service — order, payment, appointment, account state. Expected, tied to a business event.
- Promotional — marketing. Requires a consent basis, subject to content rules and time-of-day restrictions in many markets.
- Support — conversational, often two-way, needs a reply path and a human owner.
- Urgent operational — outage, safety, fraud alerts. Rare, high consequence, escalation path if unacknowledged.
What has to differ between them
Sender identity and registration
Registered sender identities carry the declared use case and, in some markets, approved templates. In the US, 10DLC registration through The Campaign Registry includes a declared use case, and the registration details affect how traffic is treated; the specifics are set by the registry and carriers and should be confirmed with your provider for the campaign in question. Sharing one identity across authentication and promotional content means a content decision about one class lands on the other.
Consent and suppression
Promotional traffic depends on a consent record and an honoured opt-out. Authentication and service messages generally rest on a different lawful basis, and suppression rules must not silently block a code the user requested. That requires per-class suppression semantics: a marketing opt-out is not a global block, and a global block must still be honoured.
Queue priority and throughput allocation
Give each class its own queue with an explicit priority, and its own throughput allocation on the route. Without a per-class allocation, a large scheduled send consumes capacity from whatever else is on that route.
Route policy
Separate route identities per class where a provider supports it, and preferably separate providers for authentication and promotional traffic, so failure domains, throttling behaviour and contracts are independent. A rule worth stating explicitly: promotional traffic never fails over onto an authentication route.
Retry and deadline policy
Each class needs a useful deadline — the point after which delivery no longer helps — and a stop condition rather than unbounded retries. Authentication deadlines are short and set by the flow the user is in; a service notification's deadline is set by the business event; a promotional deadline is set by the campaign window and quiet hours.
Content and template governance
Authentication and service content should be templated, reviewed and versioned, with the sender identity, template ID and approval state recorded. Promotional content changes frequently and needs a review path that cannot alter a template another class depends on.
Monitoring baselines
Alert against each programme's own recent baseline per route and destination, not a universal number. Useful signals differ by class: for authentication, the latency distribution to final status and the verification outcome; for promotional, throttling and rejection reasons and complaint or opt-out rate; for support, response time and unanswered inbound; for urgent traffic, acknowledgement.
Incident response
Define per class who is paged, what the first action is, and what "resolved" means. An authentication route degradation and a slow campaign should not reach the same person the same way.
Isolation matrix
| Dimension | Authentication | Service | Promotional | Support | Urgent operational |
|---|---|---|---|---|---|
| Sender identity | Dedicated, registered | Dedicated or shared with service | Dedicated, registered for marketing use case | Two-way capable | Dedicated or service identity |
| Route | Dedicated, latency-first | Dedicated or shared with authentication only if allocation is enforced | Separate route and preferably separate provider | Route supporting inbound | Dedicated with independent fallback |
| Queue priority | Highest | High | Lowest, scheduled | Interactive | Pre-emptive |
| Consent basis | Requested by user | Business event | Recorded consent, opt-out honoured | Existing conversation | Legitimate operational need |
| Suppression | Global blocks only | Global blocks only | Marketing opt-out plus global | Conversation state | Global blocks only |
| Deadline | Set by the live flow | Set by the business event | Campaign window, quiet hours | Session-based | Immediate, escalate if unacknowledged |
| Retries | Bounded, no duplicate code per session | Bounded, deduplicated per state | Bounded, respects quiet hours | Human-driven | Bounded, then alternate channel plus escalation |
| Failover target | Authentication route on another provider | Service route | Never an authentication route | Support-capable route | Independent path |
| Alerting | Latency distribution and verification outcome | Final-status mix per route | Throttling, rejections, opt-outs | Unanswered inbound | Acknowledgement |
Migration checklist
Moving from a shared setup to separated classes, in an order that does not create an outage:
- Classify existing traffic. Tag every send with a class at the application boundary before changing anything, and confirm the tags against real volume.
- Record current baselines per programme and route, so the change can be evaluated afterwards.
- Register the new sender identities per market and wait for confirmed registration; treat lead time as a third-party dependency.
- Provision separate route identities and throughput allocations per class.
- Implement per-class queues, priorities, deadlines and stop conditions.
- Implement per-class suppression semantics, and verify that a marketing opt-out cannot block a requested authentication code.
- Move the lowest-risk class first, usually promotional, and observe against the recorded baselines.
- Move service traffic, then authentication last, with the previous route kept warm as fallback.
- Split alerting by class, with named owners and defined actions.
- Re-baseline after the move, and remove the mixed-class fallback path so it cannot be used silently.
Flowstates sells and operates messaging routes, supports customers keeping their own provider contracts, and supports hybrid arrangements. The separation above is the same work in each case: what changes is who holds the supply contract, not who has to enforce the isolation.