​

What omnichannel means on Orbit

Omnichannel is the posture where every customer-facing channel — SMS, voice, email, WhatsApp, RCS, wallet passes, USSD, and web chat — runs on one account, under one sender identity, and against one conversation timeline. All three halves must hold, or the stack is multichannel (several channels existing side by side), not omnichannel. This page defines the term and points at the shipped models that make the three halves real on Orbit. It is the conceptual anchor the channel-selection matrix and fallback chain pages assume when they say “omnichannel.”

​

The three halves of the definition

1. One account. Channels are provisioned under a single organization — not four vendor logins behind a logo. That is a sender-identity posture.
2. One sender identity. The same brand registration, verified number, or sender name faces the customer on every channel. Registration scope per country and per channel is decided at the organization level, per the fallback compliance matrix.
3. One timeline. Every conversation, call, and reply lands in a single record a human or AI agent reads per customer. The unified read surface that projects conversations and call logs onto one row shape is the unified Interactions model; the operator view that works it is the shared omnichannel inbox.

​

Why it differs from multichannel

Multichannel means channels exist; omnichannel means they coordinate. Three moves do the coordinating, and all three are tenant-configured:

• Unified routing across channels. A blended agent answers voice calls and chat threads on the same shift, so assignment has to be a cross-channel decision. The omnichannel capacity and reservation model holds a single reservation store: voice dispatch and digital routing both claim a slot atomically against a tenant-set blended ceiling, so two channels cannot double-book the same agent.
• A designed fallback chain. When the primary channel cannot carry a recipient — a capability check, provider exhaustion, or an unreachable recipient — the router advances through an organization-level ordered chain instead of failing silently, per the cross-channel fallback model. The same org-level chain applies uniformly across every send path.
• Unified consent and suppression. Country rules and sender-registration scope are evaluated per channel against the same contact record, so an opt-out on one channel closes the loop everywhere. Which channels a tenant is actually permitted to use is decided per the fallback compliance matrix, which scores each channel across the registration, send-window, and opt-in planes.

​

One contact across channels

The definition is easier to trust once you can watch one contact record move across two different channel families without any identity work on your side. The example below is one conversation: it opens on WhatsApp, falls back to SMS when the recipient is unreachable on WhatsApp, and ends as a voice call — three legs, one contact record, one conversation id, one row in the unified Interactions read model. Three properties make this omnichannel and not multichannel:

• The fallback leg kept the identity. The WhatsApp-to-SMS advance reused the same contact record — the org-level chain decides which channel, never which customer. The cross-channel fallback model defines exactly which reachability failures trigger an advance and which checks re-run per hop.
• Consent re-entered at the channel hop. Switching to SMS did not inherit the WhatsApp opt-in: the SMS leg re-ran the opt-out check against the same contact record before delivering, per the consent and suppression model.
• The voice leg competed for the same capacity as the digital legs. Assigning the callback to a blended agent went through the one reservation store the capacity and reservation model defines — there is no second counter per channel.

​

Worked example: one blended agent under the capacity rules

The capacity model’s numbers are small enough to walk by hand. Take one blended agent with the default configuration, max_concurrent_slots = 3 — the shape where one voice call plus two chats, or three digital conversations, fits. The shift starts empty: base load 0, live holds 0 of 3.

1. A chat arrives. Digital routing reserves one digital slot (grant: 0 + 0 + 1 ≤ 3), writes the conversation assignment, and releases the hold. The agent now carries base load 1 of 3.
2. An inbound voice call queues. The voice dispatcher reserves one voice slot (grant: 1 + 0 + 1 ≤ 3), transitions the agent’s ACD presence to busy, and releases the hold. Base load 2 of 3 — one voice, one chat.
3. A second chat arrives. Base load 2 + holds 0 + 1 = 3 ≤ 3, so the reservation succeeds and the agent is now at exactly 3 of 3: one voice call plus two digital conversations.
4. A third chat arrives while the call is live. 3 + 0 + 1 = 4 > 3. The reservation is refused, and digital routing falls back to the next candidate agent, an overflow queue, or the unassigned pool. The agent is at ceiling, so this is a hard stop, not a warning.
5. Wrap-up. The call ends and the agent’s ACD presence moves into wrapup; the voice slot stays occupied during the after-call window, so the removal happens only after that window closes. Base load drops to 2, and digital routing can bind one more conversation.

Two properties of this walk are worth committing to memory. The ceiling counts channels, not channels-in-isolation: without the shared reservation store, step 2 and step 3 could each look at their own counter and both decide there is headroom — this is the exact double-booking the capacity-reservation model was built to prevent. The supervisor gauge reads the same rows: the blended score the wallboard renders uses the same ACD presence and open-conversation count the gate enforces, so the number the supervisor sees is the number routing enforced.

​

The channel map

Orbit’s first-registered channels ship from the same account day one. Per-channel mechanics live under the Channels reference; the concept-level entry points are SMS, voice, email, WhatsApp, RCS, wallet passes, and USSD. Which one opens a conversation is a tenant posture decision, and the channel-selection matrix is the starting point for weighing reach, consent, and registration burden per channel.

​

Where omnichannel ends — what stays tenant-owned

The models above are the coordination layer: they run on every tenant without configuration. The posture layer is a set of decisions Orbit deliberately does not make for you, because they are regulatory and business calls, not mechanical ones:

• Registration scope per country and channel. Which countries you register your sender identity in, and which channels that registration covers, is an organization-level decision. The compliance matrix scores the burden and reach per channel; the sender-identity classification model defines how the registration anchors to your brand.
• Channel order in the fallback chain. The org-level chain — e.g. RCS → WhatsApp → SMS — is yours to sequence per traffic class, per the cross-channel fallback model. Orbit advances through the order you set; it never reorders on its own.
• Consent and suppression scope. Whether an opt-out closes one channel or all of them, and which traffic classes each channel carries (marketing vs transactional), is a posture you set. The consent and suppression model and the compliance matrix enforce and score what you configure — they do not pick the posture.
• Capacity ceilings. max_concurrent_slots, the channel weights, and the overloaded threshold are tenant settings on the capacity configuration; the defaults described in the capacity-reservation model are starting values, not prescriptions.

In short: Orbit ships the one-account, one-identity, one-timeline mechanics and enforces the posture you configure. The regulatory adequacy of that posture for your traffic remains your call, exactly as the tenant-owned Note at the top of this page states.

​

Where the shared timeline lives

The third half of the definition resolves into a single read model. The Interactions surface projects conversations and call logs onto one recency-ordered row shape — channel discriminator, contact link, back-link to the native surface — with no separate sync to keep. Operators work that same timeline per queue through the omnichannel queue routing guide.

​

See also

• Omnichannel capacity and reservation model — the atomic slot hold that keeps two channels from double-booking one agent, plus the numbers the worked example above used.
• Cross-channel fallback — the org-level ordered chain that advances a failed send to the next channel, with the per-hop consent re-check.
• Consent and suppression model — how opt-ins and opt-outs are evaluated per channel against one contact record.
• Channel capability and coverage matrix — per-channel capability purification: which channels are actually available for which destinations before a chain is ordered.
• Unified Interactions model — the read model that projects the multi-channel legs onto one contact row.
• Omnichannel compliance matrix — the channel-selection scores this page’s boundary section defers to.