# Omni-Channel routing built on capacity you actually measured > Every routing configuration rests on one number describing what an agent can hold. In most orgs that number was typed into a required field during a workshop, and everything downstream inherits the guess. - Source: https://synconai.com/insights/omni-channel-implementation-best-practices - Publisher: SynconAI (https://synconai.com) - Desk: Service Cloud - Author: SynconAI Delivery Team, Consulting & implementation - Published: 9 April 2026 - Updated: 29 August 2026 - Reading time: 10 minutes - Topics: Omni-Channel, Service Cloud, Routing, Capacity Planning, Service Operations ## Key points - One capacity number per agent assumes work items are equivalent. They are not, and the weighting is where the design either holds or collapses. - Queues should model skill, not the org chart. Queues named after teams route by who reports to whom, which is not what the customer needs. - Routing work and reserving capacity are separate problems. Conflating them produces agents who are technically available and practically unreachable. - The overflow path is designed last and exercised most. Everything about how service feels under pressure is decided there. --- Every Omni-Channel implementation contains one number that nobody measured. It sits on the presence configuration, it is usually round, and it was typed in during a workshop because the field would not save empty. Everything downstream inherits it. Queue design, skill assignment, overflow rules and the service levels the business committed to all resolve, eventually, to whether that number describes what an agent can genuinely hold. When routing misbehaves two quarters later, the diagnosis runs back to it almost every time, and the intervening two quarters were spent adjusting things that were never the problem. ## The number that was never measured Capacity in Omni-Channel looks simple enough to be safe. An agent has a capacity ceiling, each work item carries a weight, and [Service Cloud](https://www.salesforce.com/service/cloud/) routes until the assigned weights reach the ceiling. Three fields, one arithmetic rule, no obvious place to go wrong. The difficulty is that the model is a claim about human attention, and it is being populated from nothing. Ask where the capacity value came from and the answers are consistent across organisations: it was in the documentation example, it makes the arithmetic tidy, or it was what the last implementation used. None of those is a measurement, and each one hardens into a constraint the moment go-live happens. The ceiling itself does not matter. It is an arbitrary unit, and 100 is as good as 12. What matters is the ratio between the weights assigned to different work types, because that ratio is the only thing the routing engine knows about how much of an agent each item consumes. Set every item to the same weight and you have told Salesforce that a long complaint call and a two-line delivery query are the same size, which is the assumption behind most of the routing complaints that follow. ## Work items are not equivalent, so one number cannot describe them Two properties separate work types, and a capacity model that ignores either will misroute. The first is **duration**: how long the item occupies the agent from acceptance to disposition, including the wrap-up nobody counts. The second is **concurrency**: how many of that type one agent can hold at once without quality dropping. These vary independently. An asynchronous messaging thread has a long clock time and low agent effort, so concurrency is high. A voice call has a shorter clock and total attention, so concurrency is one. Median duration alone is misleading, and this is the trap in most capacity workshops. A work type with a tight distribution and one with a long tail can share a median and behave nothing alike, because the tail is what generates the queue. Record the median and a high percentile, and treat a wide spread as evidence that the work type is really two work types wearing one name. Concurrency also degrades rather than stops. An agent holding four chats does not fail at the fifth. Response times stretch, the fourth customer waits, quality drops in ways no dashboard records, and the organisation discovers the limit through complaints rather than through configuration. The number worth capturing is the point where quality starts to move, not the point where the agent says they cannot cope. ## The capacity worksheet This is the artefact we build in the first week of an Omni-Channel engagement, and it is the deliverable that makes the rest of the design arguable rather than assertive. The concurrency figures below are illustrative, set against a capacity ceiling of 100. The middle two columns are yours to fill from your own data; the last column is arithmetic. | Work type | Measured duration | Concurrency an agent can hold | Capacity weight | | --- | --- | --- | --- | | Voice call | Median and 90th percentile, from telephony | 1 | 100 | | Live chat | Median session length, plus wrap-up | 3 | 33 | | Asynchronous messaging | Agent effort, not elapsed time | 6 | 16 | | Email or web case | Median handling, no real-time obligation | 5 | 20 | | Escalation from an AI agent | Median handling, easy questions already gone | 2 | 50 | The weight is the ceiling divided by concurrency. That is the whole calculation, and its value is not the precision of the output. It is that the middle column now has to be defended by somebody, which is the conversation that never happens when a single default weight is applied to everything. ::: tip Two columns will be contested immediately, and both arguments are useful. Team leaders will say concurrency is lower than operations believes. Operations will say durations are inflated by wrap-up that should not take that long. Both are probably right, and both are findings worth having before the routing rules are written. ::: The last row deserves attention. Work that reaches a human after an AI agent has already tried is systematically harder than the same channel's ordinary traffic, because the straightforward version was resolved upstream. Weighting it the same as a normal chat quietly overloads exactly the people handling the hardest conversations, and the [architecture of that handover](/insights/agentforce-service-cloud-integration) determines how much context arrives with it. ## Queues should model skill, not the org chart The second design decision is what a queue represents, and this is where most implementations take a wrong turn that is expensive to reverse. A queue is a statement about what kind of work this is. A team is a statement about who reports to whom. Those two things overlap on the day of the workshop and diverge steadily afterwards, because teams reorganise and work types do not. When queues are named after teams, the routing model is quietly encoding a management structure, and the next reorganisation rewrites service delivery without anyone intending it. The symptom is easy to recognise. An agent cross-skilled across two capabilities can only sit in one team-shaped queue without distorting the other team's reporting, so the organisation staffs to the org chart rather than to demand. Meanwhile a queue named after a team that no longer exists keeps receiving work, because a routing rule somewhere still names it. Model queues on capability instead. Ask what resolving this work actually requires: a language, a product authorisation, a system access, a regulatory permission. Then staff each queue from whichever teams hold that capability. Reporting on team performance is a grouping problem in the reporting layer, not a routing problem, and separating the two keeps both honest. A good number of the [contact centre design](https://www.salesforce.com/service/contact-center/guide/) questions that arrive labelled as routing problems turn out to be this one. ::: warn A practical test before build: for every proposed queue, write down what an agent must be able to do in order to work it. If the answer is a team name rather than a capability, the queue is modelling the org chart and it will not survive the next restructure. ::: ## Skills-based routing, and when it is over-engineering Skills-based routing is the natural next step, and it is oversold. It earns its complexity in a narrower set of situations than most implementations assume. It is worth it when a real capability gap exists, meaning some agents genuinely cannot resolve some work rather than preferring not to, and when that gap is stable enough to maintain as people join and leave. Language qualifies. Regulated product authorisation qualifies. A certified technical tier qualifies. Account familiarity, seniority and personal preference usually do not, because they describe a soft ordering rather than a hard constraint, and the routing engine cannot express soft. The cost is combinatorial and easy to underestimate. Every skill added multiplies the combinations that must be staffed at every hour the service is open. Three skills at two levels each is eight combinations, and each one needs coverage across every shift or it becomes a routing dead end. The failure mode is silent: a work item requiring a combination nobody currently holds simply waits, with nothing amber anywhere, until somebody asks why one customer has been in the queue since Tuesday. Two disciplines contain almost all of it. Every skill needs a named owner responsible for who holds it, reviewed on a stated cadence, because skill assignment rots faster than any other configuration in service. And every skill requirement needs a documented fallback: what routing should do when the ideal match is unavailable. A skill with no fallback is a trap that has not sprung yet. ## Routing work and reserving capacity are different problems Teams conflate these two constantly, and the resulting arguments are impossible to settle because the participants are discussing different things. Routing answers who should get this item. Reserving answers who should be protected from receiving items at all. They are separate mechanisms with separate failure modes, and Omni-Channel provides levers for both: presence status controls whether an agent receives anything, capacity weighting controls how much they receive, and queue and skill configuration controls what. Reservation problems are almost always presented as routing problems. A team leader needs two hours to coach. A specialist must stay free for escalations. An agent is on a training call. None of that is a question about which queue the work belongs to, and trying to solve it with routing rules produces a configuration nobody can read six months later, full of conditions encoding a staffing arrangement that changed last quarter. The clean separation is that routing configuration is stable and describes the work, while presence and capacity are operational and describe today. If a request would change routing rules to reflect something true this week only, it belongs in presence configuration or a capacity adjustment, not in the routing model. This is the same discipline that keeps [service automation from accumulating past the point of usefulness](/insights/service-cloud-automation-best-practices): stable structure in one place, operational reality in another. ## The overflow path is designed last and matters most Overflow is where the routing design meets reality, and it is invariably the last thing configured, usually in the fortnight before go-live, by whoever has capacity that week. That ordering is backwards. Normal routing describes what happens when supply meets demand as forecast, which is the condition service is in least often. Overflow describes what happens when the model is wrong, and everything customers experience as a bad service interaction happens on this path: the long wait, the transfer to someone who cannot help, the queue nobody is watching. Four questions settle it, and all four need explicit answers rather than defaults. **What triggers overflow.** Queue depth, wait time, or both. Wait time is usually the better trigger, because it reflects what the customer is experiencing rather than what the queue looks like from the inside. **Where the work goes.** A secondary queue with a broader skill profile, a supervisor queue, or a deferred channel. Each of those carries a different implication for what the customer should be told. **What the customer is told, and when.** Silence during overflow is what converts a delay into a complaint. This is a service design decision with a routing dependency, not a routing decision. **What happens when overflow itself overflows.** The answer is allowed to be that everything lands in one supervised queue with a named owner. It is not allowed to be undefined, because undefined means work sitting somewhere nobody is looking. ::: note Test the overflow path deliberately before go-live by constraining agent availability in a full sandbox and watching where the work lands. Almost nobody does this, and it is the single test that most reliably finds a queue with nobody assigned to it. ::: ## Measuring whether routing is working Average handle time is the metric most organisations reach for, and it answers a different question. It measures how long agents take, which is a productivity question. Routing quality is about whether the right work reached the right person quickly, and four measures get closer. **Time to accept**, from the moment the item is routed to the moment an agent takes it. This isolates the routing layer from the handling layer. If time to accept is climbing while handle time is flat, the problem is capacity or availability, not agents. **Transfer rate, by source queue.** A high transfer rate out of a queue means the queue definition is wrong, not that the agents are. It is the most direct evidence available that the capability model does not match the work arriving. **Capacity utilisation spread across agents.** If a few agents run at ceiling while others sit well below it, the weighting or the skill assignment is concentrating work rather than distributing it, and that concentration is invisible in any team-level average. **Abandoned and expired work by queue.** Items that timed out, expired or were abandoned in a queue are the clearest signal of a routing dead end, and they rarely appear on a service dashboard because they never became a completed interaction to report on. The same measurement gap applies to deflected volume, which is covered in [deflection that does not cost you the customer](/insights/agentforce-customer-service-automation). Read these together rather than singly. Rising time to accept with flat utilisation means capacity is reserved somewhere it should not be. Rising transfers with healthy accept times means the queues are wrong. Any competent [customer service software](https://www.salesforce.com/service/what-is-customer-service-software/) will report all four. The work is deciding in advance which combination means what, so the answer is available before the escalation meeting rather than after it. ## Where to start If Omni-Channel is already live and behaving oddly, the first move is not a redesign. Build the capacity worksheet against what is actually configured, and put the measured durations next to the weights currently in use. The gap between those two columns is the size of the problem, and a fortnight of existing data is enough to produce it. Then list every queue and write down the capability it represents. The ones that can only be described by naming a team are the redesign candidates. Then check which skill combinations have no coverage on a Friday afternoon. That last check takes an hour, and it finds problems that have been costing the organisation quietly for a year.