A shared inbox stops being a shared mailbox the moment someone asks "how long has this customer been waiting" and the tool can answer. Most teams buy an inbox and run it by feel until the volume forces the question. This post walks through the pieces an SLA-managed inbox runs on, what each one does, and where the line sits between this and a ticketing system or an entry-level CCaaS bundle.
What a shared inbox actually is
A ticketing system treats the ticket as the unit of work: a form-backed record with fields, statuses, and a workflow state machine. It excels at structured back-office processes where the customer is an attribute on a record.
A shared omnichannel inbox treats the conversation as the unit of work. On Devotel Orbit, web chat, WhatsApp, SMS, RCS, email, social mentions, and voice follow-ups land on one timeline per customer, and the channel is a property of each message, not the organizing axis. Tickets still exist in Orbit for the genuinely ticket-shaped work, and ticket automation handles that lifecycle, but the day-to-day queue is conversation-first. The distinction matters because it decides what "SLA" can even mean: clocks hang on conversations and queues, not on form states.
The primitives Orbit ships behind the inbox
The inbox's documentation set is sixteen pages deep. Five primitives carry the SLA-managed pattern, and each has its own page:
[Digital queues](/inbox/digital-queues) are the inbox's ACD surface for non-voice channels. Where routing rules decide which facets a new conversation matches, a digital queue decides which agent it lands with, meaning the longest-idle operator whose skills cover the queue's requirements, and what happens when no eligible agent is free. SLA timers and overflow policy live on the queue.
[Dispositions](/inbox/dispositions) are the outcome labels agents pick, or the AI judge assigns, when a conversation closes: "Resolved", "Refund issued", "Escalated to billing". They feed the Distribution view, reports, and conversation-intelligence operators, so close-out classifications are data rather than habit.
[Per-queue SLA escalation policies](/inbox/sla-escalation-policies) complement the workspace SLA timers. Workspace timers answer "this conversation waited too long". The per-queue policy answers "this queue is stalling", with a severity floor on breached conversations and a wait gate on the oldest open conversation, and it can page supervisors or fire a signed webhook. An optional escalation ladder chains further steps when nobody acts.
[Tags](/inbox/tags) are the shared vocabulary. A routing rule matches on a tag, a saved view filters on a tag, an intelligence operator extracts one. Until a tag exists in the Tags console, everything downstream that keys on it fires on nothing.
[Reply approvals](/inbox/reply-approvals) put a supervisor gate on outbound replies. A gated agent composes as usual; the reply sits in the pending queue until a supervisor approves it, which dispatches the exact queued body, or rejects it with a reason. The gate is configurable per agent on top of the org default, so you can gate new hires during ramp and leave seniors direct.
Every control above is tenant-owned: your owner and admin roles author the policies, labels, and gates under your own compliance posture.
SLA-managed routing patterns
The two SLA levels compose into a few patterns operators actually run. They follow the same flow:
Inbound message -> routing rule -> digital queue
|
skill match -> longest-idle agent
|
no free agent -> hold on the queue
|
queue policy trips -> supervisors paged,
webhook fired, escalation ladder runsThree patterns cover most setups:
- Warn-before-breach. Set workspace SLA timers to alert at a percentage of target, so a single thread waiting too long surfaces to the room before the breach tier fires. The queue policy stays quiet for individual slow threads.
- Queue-backlog triage. Give each digital queue a severity floor, such as "three breached conversations open" or "oldest open conversation waiting past its gate". When the queue stalls as a whole, the policy pages supervisors and fires the queue webhook your paging tool subscribes to. Routing itself never changes because an alert fires; overflow still owns routing. The alert tells humans, and humans act.
- Approval-gated escalation replies. For queues where an unreviewed reply is the risk, gate the agents who need it. SLA clocks still count while a reply sits awaiting approval, so the pending queue must be worked, which is why supervisors have a dedicated pending replies surface rather than an email subfolder.
Tags and dispositions close the loop: a disposition set per queue tells you what "closed" meant, and tag-driven routing makes sure the threads that breached were at least the threads that belonged in that queue.
Social mentions, ingested like any other channel
Public mentions behave differently from DMs in exactly one structural way: a mention is a standalone broadcast, so the connector has to supply the context a DM carries for free. The platform token, the author's handle, the permalink back to the original post, and optionally sentiment and reach all travel with the mention into the queue, where the same triage, assignment, and reply workflow takes over. The social mentions guide documents the connector fields, and the social mentions explainer walks the ingestion path end to end. Operationally the point is simple: social care joins the SLA-managed queue rather than living in a separate feed someone skims.
Choosing this over an entry-level CCaaS bundle
An SLA-managed inbox is the middle step between a shared mailbox and a full contact-center suite, and for many teams it is the destination. The decision criteria:
- Your channels are digital-first. If voice is a follow-up channel rather than the primary queue, inbox primitives cover the workload.
- Your SLA promise is response-time based. First-response and queue-backlog SLAs are exactly what the two levels above measure. If your promise is answer-speed-on-live-calls, you want the ACD wallboard instead.
- Your approval risk is bounded. Gating some agents on some queues beats routing every reply through review, and per-agent overrides keep it that way.
- You read outcomes. Dispositions only pay off if reports get built on them; if nobody reads the Distribution view, the labels decay.
When the thresholds move past these, graduation on Orbit is a configuration change rather than a migration: the same queues, skills, SLAs, and history carry into the full CCaaS pillar. The shared-inbox entry-level post covers that graduation path from the buyer's side. If you are comparing against bundled suites, the contact center software page is the comparison surface to start from.
Frequently asked questions
What separates a shared inbox from a ticketing system?
The unit of work. Ticketing organizes around form-backed records with workflow states; the inbox organizes around one conversation timeline per customer, with the channel as a message property. SLA clocks then hang on conversations and queues rather than form states.
Which SLAs can an inbox actually enforce?
Two levels: workspace SLA timers with first-response, next-response, and resolution clocks on each conversation, and a per-digital-queue escalation policy watching backlog, meaning how many conversations have breached and how long the oldest open one has waited. Breaches can notify supervisors, post to Slack or Teams, fire a signed webhook, or trigger an escalation ladder.
How do dispositions differ from tags?
Tags are the vocabulary routing, filters, and reporting match on while a conversation is open. Dispositions are the outcome labels assigned at close. Routing rules match tags; reports and the Distribution view group by disposition.
When should reply approvals be turned on?
Gate agents whose replies carry risk, typically new hires during ramp, agents on regulated queues, or anyone handling refunds. Approvals are per-agent overrides on the org default, so the rest of the team stays direct.
What does a social mention carry into the queue?
The platform it came from, the author's handle, the permalink to the original post, and optionally sentiment, reach, and the matched keyword. The connector supplies that context because a public mention, unlike a DM, arrives with no thread history.