Skip to main content

Inbox settings map — every operator console in one place

The Inbox docs section splits coverage by surface — coaching, reply approvals, SLA escalation policies, social mentions — because that is how the features shipped. Operators do not work that way. A tenant rolling out an inbox team asks one question: where do I set what? This page answers it, collecting the twelve consoles under Inbox → Settings into one coherent map, in the order you should touch them. Every console below is a tenant-owned control — you set it for your workspace, nothing applies until you turn it on. Each maps 1:1 to a tile on the Inbox → Settings hub in the dashboard.

Console map

There is no wrong first console — every tile is independent and off by default — but some orders waste less effort than others.

Suggested onboarding order

When you stand up an inbox team, touch the consoles in this order. Each step builds on the one above it:
  1. Tags — define the vocabulary everything downstream filters and reports on. A routing rule that matches on a tag only works once the tag exists.
  2. Routing — set auto-assignment so inbound conversations land on a person instead of a shared pile. Dry-run each rule on recent conversations before enabling it.
  3. Digital queues — if you route email, chat, and social by skill, define the queues and their overflow policies here. Routing rules can then target queues instead of individual agents.
  4. Auto-close — pick the idle threshold now, not after three months of abandoned threads bury the queue.
  5. Macros — write the reply playbooks once every channel is live, based on the questions that actually come in.
  6. Reply approvals — if you gate replies for juniors or regulated queues, configure who is gated after the team has macros to answer with.
  7. SLA report / escalation policies — set first-response and resolution targets per channel or per queue, then hang breach alerts off them.
  8. AI deflection budget — once you know your real volume, cap AI-resolved tickets per month with a soft alert.
  9. Dispositions — define close-out outcome labels early, so analytics and conversation-intelligence signals have categories to land in from day one.
  10. Ticket automation — automate reassignments, retags, escalations, and notifications once the manual flow is stable. Dry-run every rule before it goes live.
  11. Agent scripts — build guided flows for the conversations that follow a decision tree. Train them on live tickets only after routing and macros settle.
  12. Conversation intelligence — define the operator taxonomy last: the signals you want extracted are clearer once you have real closed conversations to read.
Steps 1–4 unblock a working queue. Steps 5–8 make it efficient. Steps 9–12 turn it into something you can measure and automate.

Concepts behind the consoles

These pages explain the underlying models the settings consoles configure:
  • ACD queue model — how queues, skills, and overflow fit together; this is what Digital queues and Routing assign against.
  • Agent presence lifecycle — the presence states an agent moves through, which determines when Routing and Digital queues consider an agent available.
  • Conversations — the conversation data model that Tags, Dispositions, and Auto-close mutate.
  • Conversation merge troubleshooting — when two threads about the same contact collide, merge decides which console’s tags and dispositions survive.

Troubleshooting: symptom → console

See also