Skip to main content

​
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.”
Every control described under unified routing and consent is tenant-owned. Orbit carries the settings and enforces what you set; which posture is adequate for your traffic remains your call. None of this is legal advice.

​
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.

​
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 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.