Skip to main content

​
Contact-Center (Voice/CCaaS) Go-Live Runbook

The production go-live checklist covers the gates that apply to every launch — KYC, live API keys, webhooks, guardrails, billing, security, and compliance. This runbook stacks the voice/CCaaS readiness layer on top of it: the softphone, the queues, the routing, the outbound posture, and the cutover plan for a first-time contact-center tenant. Run this in addition to that checklist, not instead of it. Both pages use named owners; put a person on every item before launch day, and finish the platform-wide gates first.

​
1. Scope

This runbook applies when your first voice traffic (inbound contact-center, outbound dialer, or both) moves from sandbox testing onto live callers. Complete the following gates in the order below; skip a section only when the matching surface is genuinely unused (for example, no outbound dialing). Sequence matters because each stage proves the previous one: register the softphone before staffing queues, stand up the queue before routing the DID to it, and set outbound posture before the first agent dial.

​
2. Softphone readiness

Follow Set up the browser (WebRTC) softphone end to end for every agent who will answer or place calls.
  • Register each agent’s softphone device and mint its credentials. Use the built-in dashboard softphone, the embedded LiveKit client, or a SIP-over-WSS client — all three share the same credential path from the guide. Owner: Engineering.
  • Place and answer one full loop per agent in the browser: one inbound call and one outbound call, both established over WebRTC. A registration that connects in one direction only is still a misconfiguration. Owner: Engineering.
  • Grant and verify browser microphone permission on every agent workstation. Denied mic permission is the most common first-day failure; test it in the same browser profile the agent will use on launch day. Owner: Operations/Engineering.

​
3. Queue and agent setup

Build the ACD structure with Set up and run voice queues before any DID points at it.
  • Create the queue via POST /api/v1/voice/queues with concrete values: maxWaitSeconds, targetServiceLevelSeconds, overflowAction, routingStrategy, and the skills a caller must match. Every queue setting is tenant-owned — you pick the SLA target and overflow behavior. Owner: Operations.
  • Enroll agents with skills. The queue’s skills array filters which agents are eligible; enroll each agent with the matching skill tags so callers are not waiting on an empty eligibility set. Owner: Operations.
  • Wire the SLA pipeline per Per-queue SLA breach alerting and escalation policies: set the queue’s targetServiceLevelSeconds objective, opt into the same-target forecast and callback gate, declare the breach policy (/api/v1/voice/queues/{id}/sla-breach/policy), and add an escalation ladder (escalationSteps[]) so a missed target pages a named supervisor instead of sitting in a report. Owner: Operations.

​
4. Inbound DID routing

Pick each DID’s destination with Pick the right inbound routing for a DID.
  • Choose the route type (one of the 13 values on that guide’s decision table): run an IVR, drop into a queue, take a voicemail, ring a softphone group, and so on. Changing routing never affects outbound — this guide is inbound-only. Owner: Engineering.
  • Build and publish the IVR first if you picked ivr: use Build and ship your first IVR flow and make the graph pass the validator (one ivrStart entry node, every node reachable, at least one terminal node). A malformed graph answers 422 IVR_FLOW_GRAPH_INVALID at write time, so fix it before you point the number at it. Owner: Engineering.
  • Drive the simulator from the routing guide with a scripted caller before any phone rings the DID. The simulator walks the published flow so the answer, gather, and branch behavior are proven end to end. Owner: Engineering.
  • Attach the route to the DID (ivr with { flowId }, queue with { queueId }, and so on) and flip the row active. Owner: Engineering.

​
5. Outbound posture

Outbound calls must be ready before agents ever dial, and none of these gates are optional for a contact-center tenant.
  • Read the coverage matrix first: call GET /api/v1/voice/country-coverage and open the per-country matrix described in Outbound country coverage matrix for agents. A destination marked regulated or disabled surfaces there — not as a SIP rejection on the first live call. The matrix is advisory and never picks a provider: every outbound call still routes over the single Devotel wholesale softswitch. Owner: Operations/Compliance.
  • Set the per-country tenant policy where you manage compliance. Whether a regulated destination dials is your workspace’s decision (tenant-level, fail-open), not a platform-wide gate — record the choice per country before launch. Owner: Compliance.
  • Configure caller ID with CNAM and caller ID branding: register a branded name of 1–15 characters matching the documented charset. Carrier-side CNAM writes run only on the Devotel wholesale softswitch — the API captures and enqueues the name rather than writing a third-party registration directly. Owner: Compliance/Operations.
  • Keep an emergency address on file where the jurisdiction requires it per Emergency calling. Remember: Orbit blocks the short emergency codes (911/112/999/000) at dispatch — they never reach a carrier; agents must dial emergency services from a regular phone. Owner: Compliance.

​
6. Wrap-up and QA

Set disposition capture and quality review before launch, not after the first Tuesday.
  • Define each queue’s wrap-up code catalog and decide whether a code is required per Wrap-up codes. requireDisposition on the queue can hold an agent in wrap-up until a code is recorded; leave it off only if you accept untracked outcomes. Owner: Operations.
  • Layer tenant-level disposition tags on top for cross-cutting labels (lead, vip, escalated) — tags are many-per-call and complementary to the one-per-conversation wrap-up code. Owner: Operations.
  • Seed a QA rubric with Call QA scorecards: the five-dimension rubric (greeting, hold notice, empathy, resolution, closing) grades completed calls; turn on auto-scoring so supervisors only spot-audit samples. Owner: Operations/QA.

​
7. Cutover

Cutover is swap, watch, and be ready to roll back.
  • Swap traffic by re-pointing the DID’s route to the queue (or IVR) you just validated, leaving the old destination stored as the fallback — the per-DID routing write applies immediately to the next call. Owner: Engineering.
  • Watch the wallboard and its alarm rules. Mount the wallboard on the ops display; it renders calls waiting, average wait, service level against your target, agents available, longest wait, and the SLA-warning banners, and it dedupes those feeds across the voice and omnichannel pages. Each alarm rule you wired in section 3 becomes a live signal the moment the floor drifts. Owner: Operations.
  • Keep the rollback path explicit: re-point the DID to the previous destination and flip active off the new route. Since the route type is one row per DID, rollback is a single write, not a redeploy. Owner: Engineering.

​
Worked example — two gated test calls

Prove both directions of the go-live with one inbound and one outbound call:
  1. Inbound: phone the DID from an outside line. The simulator run in section 4 proves the flow; this live call proves the softphone registry, the queue dispatch, and the SLA timer in the wallboard all working together. Confirm the call lands on an available agent and the wrap-up/code enforcement you configured engages.
  2. Outbound: from a registered softphone, dial one destination that the coverage matrix flags as regulated. Confirm the tenant’s per-country policy is set, the structured advisory appears, and the call still terminates over the Devotel softswitch (or is refused by your own policy, if you chose that). This validates caller ID, the coverage advisory, and the compliance posture in one dial.
Pass both before you drain the old system’s last caller.