Want help applying this guide?Ask the DripTell team
A support manager sends most billing conversations to the internal team and a smaller share to a service partner. On paper, the split looks precise. By lunchtime the partner queue is full, the internal team is rescuing old work, and the configured percentage no longer describes what customers are experiencing.
Use percentage routing only when both teams can safely handle the same kind of work. Set the initial share from real staffed capacity, keep eligibility and overflow as separate decisions, preserve the original customer record, and review actual allocation beside response and resolution outcomes. A percentage is a traffic plan. It is not proof of equal skill, available capacity or good service.
Prove both teams can own the same work
Start with one narrow request class, not the whole support operation. Two teams may both handle order-status questions while only one may approve refunds. If you mix those requests, a neat split creates transfers rather than capacity.
- Same workBoth teams receive a clearly comparable request type and service promise.
- Same authorityEach team has the skills, access and decision rights needed to finish the work.
- Known capacityThe planned share reflects staffed capacity rather than a convenient round number.
- Safe fallbackUnanswered work has one timed route that keeps age and context intact.
- Shared reviewVolume, acceptance, resolution and customer harm are reviewed in one cohort.
Write the common service promise first. Both destinations need the same required skills, channel access, customer history, decision authority, operating hours and escalation path. The broader support operating model should also say who owns a case when the route fails. If one team can answer but cannot complete, it is not an equivalent destination.
Microsoft documents percentage-based routing across multiple queues and notes that the final destination also depends on rule evaluation and overflow behavior. Its routing guidance also says short-run allocation can differ slightly from the configured share. That is normal. It is another reason not to judge a pilot after a handful of conversations.
Decide what the percentage controls
A planned split should apply at one clear point. Usually that is after intake and classification have established that the request belongs to the eligible pool, but before a particular representative is chosen. Keep the denominator visible. If the policy says sixty percent, is that sixty percent of all arrivals, all eligible arrivals, or all successfully assigned cases? Those are different cohorts.
Microsoft's record routing guidance separates intake, classification and queue selection from later assignment. The percentage chooses a queue; the next rules still decide whether an eligible person can accept the work.
Use one event trail in the shared inbox so the intake time, selected team, offer, acceptance, transfer and final owner stay connected. Without that chronology, a rescued case can look like a successful first assignment.
Keep allocation and fallback separate
Percentage routing is a planned distribution. Overflow is a recovery action. Combining them into one rule makes the result difficult to explain.
| Routing choice | Use it when | Evidence needed | Main risk |
|---|---|---|---|
| Percentage split | Two teams can finish the same work and need a stable planned share | Comparable authority, hours, capacity and outcomes | The ratio hides different service quality |
| Skill route | A request needs a capability that only some people have | Reliable classification and a qualified fallback | A missing skill leaves work stranded |
| Load based assignment | Eligible people share the work but current load differs | Honest capacity and active-work states | Simple case counts misstate effort |
| Overflow route | The planned destination cannot keep the promise | Observable trigger and a better prepared backup | Old work bounces and loses its age |
| Manual exception | A rare risk needs a human decision | Named approver, reason and final owner | Exceptions become the unwritten policy |
Give overflow one timed, tested path. Preserve original age, reason, notes and promised next step. If the backup cannot improve the outcome, keep the case visible rather than circulating it. Your automation rules should expose why the fallback fired, not merely show where the case ended.
Run a small reversible pilot
Choose a closed pilot cohort such as one language, one request type and one operating window. Keep the existing route available as a rollback. Before launch, replay routine work, missing data, an unavailable team, a full queue and a returning customer with history.
The customer record should not fork when the team changes. Keep identity, consent, conversation history and next action attached through the customer record. Apply the same access controls at both destinations. A partner that receives only a percentage of work should not gain broader access than that work requires.
Start with the smallest share that produces enough evidence without putting the service promise at risk. Do not change the percentage every day. Hold it long enough to see ordinary variation, then review a defined cohort. Record the effective date, owner, reason and rollback point for every adjustment.
Review the split and the outcome separately
First ask whether routing followed the plan. Compare eligible arrivals with the team initially selected, then explain deviations caused by rounding, unavailable capacity, overflow or manual intervention.
Next ask whether either destination changed the customer outcome. Compare time to acceptance, meaningful response, transfer rate, full time to resolution, reopen rate, missed promises and a sample of conversation quality. Break the results down by request type and operating window. A team can receive its planned share while producing slower acceptance or more repeat contact.
Do not reward a team for declining difficult work or closing it early. Keep one operations owner for the complete cohort, even when delivery is shared. DripTell can keep assignment, history and automation evidence beside each conversation, but the percentage still needs a human policy and a regular decision. If you want to map a controlled pilot to your current workflow, talk with the team.
Frequently Asked Questions
When should support work be split by percentage
Use a percentage split when two or more teams can complete the same defined work with equivalent authority and service expectations, and you need a stable planned share across them.
How large should the first allocation be
Base it on staffed capacity and contractual constraints, then start with the smallest reversible share that can produce a useful cohort. Do not choose a round number merely because it is easy to configure.
What happens when one team is unavailable
Trigger a separate, timed fallback to a qualified destination while preserving the original arrival time, context and owner. Record the fallback as a deviation from the planned split.
How do you know the split is working
Check both the actual allocation and customer outcomes. A ratio can be accurate while acceptance, resolution, repeat contact or quality is worse in one destination.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy