Defining One Practice on Top of Two Desks
Two insurers have merged. Desk A has 40 agents serving 22,000 users on ServiceNow, with a three-tier hierarchy, a formal priority matrix, published SLAs including 30-minute response for priority 1, 26,000 tickets a month, first contact resolution of 55% and satisfaction of 3.5. Desk B has 12 agents serving 6,000 users on Jira Service Management, organised around product teams, with no SLAs, swarming instead of escalation, 4,100 tickets a month, a claimed first contact resolution of 81%, satisfaction of 4.2, and 9% of tickets with no category assigned. The CIO wants 'one service desk' within nine months and has frozen both headcount and new software spend; both tools are licensed until a renewal 14 months away. In one of the two countries, collective consultation rules require 90 days' notice before any change to role profiles or shift patterns. Neither knowledge base has been reviewed in over a year, and 30% of desk A's agents are contractors whose contracts end in five months. Users from the acquired company still raise tickets through their old portal.
1. What must be decided at practice level before any decision about tooling or organisational structure, and why does the order matter here?
Read the worked answer
Before anything else the combined organisation needs a written answer to: what demand does the service desk practice capture, for which user populations, in which value streams, with what service experience promise, and where does it hand off.
Decide at practice level:
- Scope and segmentation: which users, which contact types, which channels, what response expectation per segment.
- Interfaces: what the desk does versus incident management (major incident coordination), service request management (request models, approvals), problem management (trend handoffs) and knowledge management (article ownership).
- Common taxonomy, priority model and definitions - especially first contact resolution and repeat contact - so that numbers become comparable across both populations.
Why the order matters: tooling is frozen for 14 months and headcount is frozen, so the org chart and technology are not available levers inside the nine months. Definitions and interfaces are. If you restructure first, you design around two incompatible definitions of a ticket and then rebuild.
There is also a conceptual point worth making explicitly to the CIO: a practice is a set of organisational resources designed for a purpose, not a department. One practice can be performed by several teams on two tools, provided the taxonomy, priority model and measures are common. 'One service desk' does not have to mean one team or one tool within nine months - but it does have to mean one set of definitions.
2. How should the SLA-driven tiered model and the product-aligned swarming model be reconciled, and what would you do with desk B's 81% first contact resolution figure?
Read the worked answer
Treat the 81% as unproven rather than as a benchmark to chase.
Comparability checks: 9% of B's tickets have no category, so the denominator is soft; B supports 6,000 users against 22,000, and a smaller population with known products is easier to resolve at first contact; swarming works when knowledgeable engineers are available, which A's tiering was built to compensate for; and no SLA pressure changes analyst behaviour. The claim may be true, but it has not been measured the same way.
Reconcile by segment rather than by picking a winner:
- High-volume, well-understood, low-risk requests such as access and standard software: standardise and resolve at the entry point, automate where possible.
- Product-specific questions: route to the team that owns the knowledge, using a swarm or direct-contact model.
- Cross-product incidents, and anything with regulatory or safety impact: coordinated and tiered, with escalation and major incident handling.
Then run both models against the common taxonomy for one quarter and compare like-for-like: repeat contact rate, reopen rate, time to resolve by priority, and satisfaction by contact type.
The design constraint is real. Swarming depends on knowledge maturity and engineer availability. Transplanting the model without the knowledge base and the capacity will lower desk A's 55% further, not raise it.
3. Given a nine-month deadline, a 90-day collective consultation requirement, a hiring freeze and a contractor cliff in five months, sequence the first 90 days and justify the sequence.
Read the worked answer
Start consultation on day one; sequence everything else behind it.
Days 1–30 - stabilise and define. Begin the 90-day collective consultation immediately, because no role profile may change before it concludes, and anything that changes what people do has to be scoped by then. In parallel: agree the common taxonomy, priority matrix, and the definitions of first contact resolution and repeat contact; stand up a single front-end intake serving both user populations with both tools behind it, and set a named cut-off for the old portal with redirects and communications.
Days 31–60 - make the seams work. Publish operational-level agreements across resolver groups. Nominate article owners and start retiring or rewriting the worst knowledge; two bases untouched for a year is a service risk, not a documentation backlog. Begin capturing contractor knowledge deliberately, because 30% of desk A's agents leave in five months and their tacit knowledge leaves with them unless it is written down now.
Days 61–90 - measure and decide. Run four weeks of comparable data, then select the target operating model on evidence rather than preference.
The sequencing trap to name explicitly: the tempting move is to choose the tool and draw the new org chart in week one. Both levers are frozen, and both depend on definitions that do not yet exist. Meanwhile the two things that can be delivered inside nine months - one intake and one set of definitions - are exactly the things that make the 14-month tooling decision evidence-based.