> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# What omnichannel means on Orbit

> The definitional concept page: one account, one sender identity, one timeline across SMS, voice, email, WhatsApp, RCS, wallet, and USSD — how it differs from multichannel, and where the unified routing, compliance, and read models live.

# 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](/concepts/omnichannel-compliance-matrix) and [fallback chain](/concepts/cross-channel-fallback) pages assume when they say "omnichannel."

<Note>
  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.
</Note>

## 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](/concepts/sender-identity-classification-model) 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](/concepts/omnichannel-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](/concepts/interactions-unified-model); the operator view that works it is the [shared omnichannel inbox](/guides/omnichannel-queue-routing).

## 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](/concepts/omnichannel-capacity-reservation) 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](/concepts/cross-channel-fallback). 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](/concepts/omnichannel-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](/concepts/sms-segments-and-encoding), [voice](/concepts/voice-call-lifecycle), [email](/concepts/email-delivery-lifecycle), [WhatsApp](/channels/whatsapp), [RCS](/concepts/rcs-fallback-and-capability), [wallet passes](/channels/wallet-passes), and [USSD](/channels/ussd). Which one opens a conversation is a tenant posture decision, and the [channel-selection matrix](/concepts/omnichannel-compliance-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](/concepts/interactions-unified-model) 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](/guides/omnichannel-queue-routing).
