ChatDeskOps / The process
Section 01Two channels, three threads at a time, every hour of the year
Chat is roughly two thirds of the volume and email a third. The two behave differently enough that they are staffed, measured and ramped separately.
| Live chat | Email and ticket | |
|---|---|---|
| Share of volume | ~65% | ~35% |
| Concurrency | 2.5–3.5 conversations at once | Sequential, worked from a queue |
| What the customer expects | An answer inside 30 seconds | A considered answer inside 4 hours |
| Where it goes wrong | Speed at the cost of accuracy | A queue that ages quietly overnight |
| Who works it | Chat-primary agents | Email and escalation agents |
| Ramp position | Introduced in week three, one chat at a time | Where every new agent starts |
What customers actually write in about
Indicative of the current placement. The mix matters because it sets how much product depth an agent needs before they are useful, and therefore how long the ramp is.
| Contact type | Share | Typical resolution | Depth required |
|---|---|---|---|
| How-to and configuration | ~35% | Answered from the knowledge base with a cited article | Moderate — the largest single category |
| Account, access and login | ~24% | Resolved in the conversation against the client's admin tooling | Low, but identity checks are strict |
| Troubleshooting a defect | ~20% | Diagnosed, reproduced where possible, escalated with evidence | High — this is where escalation accuracy is won or lost |
| Billing and subscription | ~15% | Explained; anything that moves money is routed to the client | Moderate; the boundary is absolute |
| Feature requests and roadmap | ~6% | Logged, acknowledged honestly, never promised | Low, but judgement is required |
The numbers the rate was built on
Read concurrency as a range and not a target. An agent pushed to 3.5 chats will hit the number and lose the quality score, and the composite is weighted so that trade never pays.
| Measure | Standard after ramp | Notes |
|---|---|---|
| Productive hours per agent per shift | 7.0 of an 8.0-hour shift | Excludes breaks, briefings, coaching and training |
| Concurrent chats | 2.5–3.5 | Three is the working target; above that quality falls before speed does |
| Chats handled per shift | 45–65 | Varies with contact type and time of day |
| Emails handled per shift | 40–55 | Higher on account and billing queues, lower on troubleshooting |
| Occupancy | 80–85% | Deliberately not higher; overnight bands run quieter by design |
| Schedule adherence | ≥ 95% | The measure that protects coverage |
| First-contact resolution | ≥ 75% | Influenceable — depends on product and permissions as well as skill |
| Knowledge-base citation rate | ≥ 90% | An answer that cannot be sourced is an answer no one can audit |
Indicative monthly volume at 30 seats
At 22 working days and 7.0 productive hours per agent, a 30-seat pod delivers approximately 4,620 productive hours a month. On the current channel mix that is roughly:
- Productive hours
- 4,620
- Chats handled
- ~21,000
- Emails handled
- ~9,500
The concurrency curve
Six weeks, and it cannot be rushed. Billing starts on the agent's first live conversation; training time is never billable.
| Period | What the agent handles | Expected output |
|---|---|---|
| Weeks 1–2 | Email only, reviewed before sending | 50% of the email standard |
| Week 3 | Email plus a single chat at a time | 60% of the combined standard |
| Week 4 | Two concurrent chats | 75% |
| Week 5 | Two to three concurrent chats | 85% |
| Week 6 onward | Full concurrency, all queues | Full standard |
Next step
The conversation is the easy part. The roster is not.
The coverage page sets out the arithmetic, the four bands, and the one credit mechanism on this process that has real teeth.
Read the coverage arithmetic See the scope of work