Follow the Sun, Lose the Thread
Vantage Software runs a 24x7 follow-the-sun service desk for 14,000 enterprise customers' administrators, with hubs in Singapore, Bucharest and Denver and 46 analysts. Support is delivered in English, German, French and Japanese. A ticket opened in Singapore at 18:00 local is worked until 19:00, then picked up in Bucharest at 08:00, then Denver. The tooling is a single instance, but each hub has built its own queue views, its own status conventions - Singapore uses 'pending customer', Bucharest 'waiting on user', Denver 'on hold – user' - and its own local macros. Handover is a note in the ticket work log written by whoever is on shift, with no required fields. An internal audit of 300 tickets found that 22% required rework after handover, because the receiving analyst re-diagnosed the case or re-asked the user for information already provided. Satisfaction is 4.1 in Denver and 3.4 in Singapore, and no measure of handover quality exists. Denver has proposed 'shift left' targets for the other two hubs. Average ticket age is 6.8 days and 31% of open tickets have not been touched in five days.
1. Is the 22% rework a people problem, a process problem or a tooling problem? What would you change first?
Read the worked answer
Mostly process and tool configuration, with a knowledge gap underneath. The analysts are working hard; the system is asking them to guess.
The evidence: three different status conventions for the same real-world state, hub-specific queue views and macros, and a handover that is a note in the work log with no required fields. That design guarantees re-diagnosis, because the receiving analyst cannot tell what has been tested, what the user has been told, or what happens next.
Change first, in this order:
- One status model for the whole instance, with written definitions - 'waiting on user' means X and requires Y. Local variants are the root of the confusion.
- A handover standard expressed as mandatory fields completed at handover: symptom and scope, what has been done and ruled out, what the user has been told, next action and owner, next contact commitment. Enforce them in the tool at the point of handover rather than in a policy document.
- Shared queue views so a ticket looks the same in all three hubs, and a review of local macros to adopt or retire each one.
- Measure it: handover acceptance rate, rework rate on an audit sample, and percentage of handovers with all fields populated.
Name the deeper issue as well: the work log is a poor knowledge carrier. The durable handover is an article the next hub can read. The 22% will not fall far without that.
2. Critique Denver's proposal to set 'shift left' targets for Singapore and Bucharest, and describe what you would measure instead.
Read the worked answer
The instinct - resolve more at the point of entry - is sound. The proposal as stated is not, for three reasons.
First, shift left has no definition here. Shifted from where to where? In a follow-the-sun desk the meaningful version is: resolve at the hub that receives the contact, using knowledge rather than escalation, instead of passing work around the clock. Without that definition each hub will interpret it as 'keep the easy ones'.
Second, the measure invites local optimisation. If hubs are compared on a resolution percentage, the rational move is to hold simple tickets and push complex ones to the next hub. That raises the metric and lengthens end-to-end resolution - the same failure mode as a handle time target.
Third, comparability. Denver's 4.1 against Singapore's 3.4 may reflect case mix, language coverage or which time zones land where, not capability. Setting targets before adjusting for mix measures the queue, not the hub.
Better design: agree resolution-ownership rules by category, then measure (a) the percentage of demand resolved within the receiving shift, with a written definition, (b) handover acceptance and rework rate, which is where the current loss sits, and (c) satisfaction with case mix stated alongside. Publish hub profiles so comparisons are honest, and let the hubs propose their own improvement actions against the shared handover standard.
3. Average ticket age is 6.8 days and 31% of open tickets have not been touched in five days. What does that tell you about the 24x7 model, and what would you do?
Read the worked answer
Average age of 6.8 days with 31% untouched for five days is the signature of a queue with no owner at any given moment. In a single-site desk, staleness is visible and uncomfortable. In follow-the-sun it is invisible: every analyst reasonably assumes the next hub will progress the ticket, and no one's shift ends with it as their problem.
What it tells you about the model:
- Ownership must be explicit and continuous. Every ticket needs a named accountable analyst or hub at all times, transferred by an accepted handover rather than by a shift ending.
- Manage age by priority, not by average. A 6.8-day average can hide a 2-hour priority 1 and a 40-day priority 4.
- Staleness is a defect signal, not a backlog statistic. A ticket with no next action and no next contact commitment is broken, and should be treated that way in the daily stand-up.
Practical fixes: a staleness report owned by a named shift lead in each hub, reviewed at every handover; a rule that a handover is rejected if the next action is not stated; and a cross-hub measure of the percentage of tickets with a valid next action and a future contact commitment.
Worth stating explicitly: the 22% rework and the staleness are probably the same defect seen at two points. The handover does not transfer state, so the receiving hub starts again, and the ticket ages while it is being re-diagnosed.