Skip to main content

​
UCaaS, CCaaS, and CPaaS

Three acronyms describe communication delivered from the cloud, and they equip different audiences:
  • UCaaS (Unified Communications as a Service) — a packaged cloud phone system, meetings, and team chat that a company turns on for its employees.
  • CCaaS (Contact Center as a Service) — the software a support or sales team uses to route, handle, and measure customer conversations.
  • CPaaS (Communications Platform as a Service) — the programmable communication APIs (voice, SMS, WhatsApp, email, video, AI voice agents) that developers build into their own product.

​
TL;DR

UCaaS equips every employee, CCaaS equips the contact-center team, and CPaaS equips your software. On Orbit all three are surfaces of one account: they read and write the same tenant schema, draw on the same wallet, pick from the same number pool, resolve senders through the same chain, and report delivery in the same status vocabulary. The sections below show what that sharing means at the architecture level, surface by surface.

​
One account, three surfaces

The single-account claim is not a packaging decision; it is a set of concrete shared layers. Every UCaaS, CCaaS, and CPaaS surface on one Orbit account sits on all of these:
  • One tenant schema. Each account’s data lives in its own isolated database schema, and all three categories write into it — a softphone call, a queued contact-center interaction, and an API-sent message are rows in the same tenant, visible to the same dashboards. See Tenant isolation.
  • One wallet. UCaaS minutes, CCaaS queue time, and CPaaS messages all debit the same prepaid balance through the same charge pipeline, so a single usage feed covers the whole account. See Wallets, credits, and charges.
  • One DID pool. A phone number is provisioned once and can answer as an employee line, a contact-center hotline, and an API caller ID at the same time — the one-number-many-surfaces property. The number’s lifecycle is owned by the account, not by any one surface. See Number lifecycle.
  • One sender-resolution chain. Whether a message leaves from the agent desk, a campaign, or POST /api/v1/messages, the platform resolves which sender identity and which carrier route it uses through one decision chain. See Sender resolution.
  • One DLR vocabulary. A delivery receipt means the same thing on every surface: the agent desk, the wallboard, and the API all consume the same two-plane status model (acceptance plane vs. network-outcome plane). See The DLR model’s two planes.

​
UCaaS — how the phone system works

The UCaaS surface is a SIP phone system whose clients happen to be browsers and apps:
  • Browser softphone. Each user’s softphone registers with a SIP credential bound to that user’s device — the credential issue/rotate/ revoke lifecycle described in SIP credential lifecycle — and the client-side register/call/hangup states follow the softphone client lifecycle. Registration, not a seat license, is what makes an employee reachable.
  • Auto-attendant. The company-wide answering menu is an IVR flow — the same node-and-transition model the contact-center menus use — attached to the main number rather than to a queue. See IVR flow model.
  • Team chat and video meetings. Internal messaging runs on the team chat model — channels, membership, and delivery semantics documented in Team chat model — and meetings are video rooms created from the same account.

​
CCaaS — how the contact center works

The CCaaS surface is a routing engine with a human desk behind it:
  • ACD queues. An inbound conversation enters a queue and the distributor offers it to agents by skill, priority, and availability — the queue semantics in ACD queue model.
  • Agent presence. An agent is only routable because their presence state says so; the available/busy/after-call-work transitions and what each admits are the agent presence lifecycle.
  • Supervisor plane. Wallboards, barging, and live queue telemetry are a dedicated read plane over the same routing events, not a scrape of the agent UI — see Voice supervisor plane model.
  • Recording pipeline. Every handled call can be captured, stored, and surfaced for playback and quality review through the call recording pipeline.

​
CPaaS — how the programmable layer works

The CPaaS surface is the API expression of the same send pipeline the dashboards use:
  • Message envelope. Every outbound message — API-sent or desk-sent — becomes one envelope with a sender, a recipient, a channel, and a body; the envelope is the unit that metering, routing, and status all attach to. See Message envelope model.
  • Delivery lifecycle. From accepted to sent to delivered (or failed), the status transitions and their terminal states are the delivery lifecycle.
  • Async processing. Sends, status callbacks, and DLR reconciliation run through queues and workers rather than in the request path — the async processing model — which is why POST /api/v1/messages returns an accepted envelope immediately and the network outcome arrives as a later status.
The API families on top of that pipeline:

​
Where the boundary between the categories is

The categories blur at exactly one place: the carrier leg. Every outbound voice leg — a softphone call, a queued contact-center call, or a call placed by POST /api/v1/voice — terminates on Devotel’s wholesale softswitch, and every message leg passes through the same routing layer. There is no per-category network. The boundary between UCaaS, CCaaS, and CPaaS on Orbit is which surface originated the work, never which carrier carries it. Because the legs share the carrier and the wallet, billing routes both through the same ledger: each surface writes usage records into the one usage-records feed, and the wallet applies charges from that single stream. A worked example. An agent answers an inbound call at /conversations (CCaaS surface). The talk minutes write usage records against the account wallet. After the call, the team’s product code posts POST /api/v1/messages with channel: "sms" to confirm the resolution (CPaaS surface). The SMS write lands in the same usage-records feed, debits the same wallet, and its delivery status comes back in the same DLR vocabulary the agent desk shows. One ledger, two categories — the debit stream never forks.

​
The mapping, with concept anchors

Where each surface lives in the dashboard:
  • UCaaS — the browser softphone per the softphone guide, the auto-attendant at /voice/ivr, team chat and meetings per the team chat and video meetings guides.
  • CCaaS — the agent desk at /conversations, queues at /voice/queues, IVR at /voice/ivr, and supervisor telemetry on /voice/wallboard and /wallboard.
  • CPaaS — the API families in the table above, plus the same sends the dashboards perform.

​
One tenant using all three at once

A support team on one Orbit account runs the loop with nothing leaving the account:
  1. Inbound call (CCaaS + UCaaS arrive on the same number). The DID answer is an IVR flow — for a support line that doubles as an employee phone number, the same DID is both the hotline and the team’s auto-attendant.
  2. AI agent handles the routine intent (CPaaS). The flow hands off to a voice agent from /api/v1/agents, which answers order-status questions headlessly.
  3. Human takes over in the inbox (CCaaS). Anything else routes to a queue and lands on the agent desk at /conversations; the supervisor watches queue health on the /voice/wallboard display.
  4. Programmatic follow-up (CPaaS). After resolution, the product code posts POST /api/v1/messages with channel: "sms" to send the customer a confirmation text on the same account.
One bill, one set of numbers, and the voice and messaging legs metered together — because the shared layers above make them one system, not three.