1,842 VPN incidents, one unowned problem
A manufacturing firm with 6,200 users at 24 sites logged 1,842 incidents in Q1 matching the description VPN disconnects every 20 to 40 minutes, spread across three client versions. Each occurrence costs the user an average of 12 minutes and generates 41 escalations per month to the network team. Two known errors sit in the knowledge base, both with workarounds: reconnect, or switch to the backup gateway. Root cause has never been established. The network team believes it is an ISP peering problem outside the firm's control. The endpoint team believes it is a client driver defect. The problem manager is 0.5 full-time equivalent and owns 61 open problem records, 44 of them more than 180 days old. The service desk resolves VPN incidents at first line using the workaround, and incident records are rarely linked to a problem record.
1. Explain how you would prioritise this problem record against the other 60, using impact, urgency and the evidence available.
Read the worked answer
Prioritisation needs a consistent score applied to all 61 records, not an argument about which team is most frustrated.
The impact evidence is strong and quantifiable. 1,842 incidents in a quarter is roughly 20 per working day. At 12 minutes each, that is about 368 hours of user time lost in the quarter, before counting the 41 monthly escalations and the helpdesk time to handle each call. Spread across 6,200 users it is still a persistent, visible failure that users experience as IT not working.
Urgency is where a judgement is needed. Urgency should reflect trend and risk, not just volume. Ask: is the rate rising, is it concentrated in a business-critical group such as shop-floor or dispatch users, and does the workaround ever fail? A workaround that works reliably lowers urgency but does not eliminate the record.
The structural point is that this should be one problem record with 1,842 linked incidents, not 1,842 standalone tickets. The linking is what turns anecdote into evidence, and the current pattern of closing at first line is destroying that evidence.
With 0.5 FTE and 61 records, the honest move is portfolio triage. Re-score all 61, close or accept the ones with no measurable impact and no owner, merge duplicates, and publish the resulting top five. This VPN record should be in that top five on impact alone. Assign a named owner with allocated time, agree a hypothesis, and set a review date. A problem record without an owner and a date is a filing cabinet, not a practice.
2. What are the risks of closing every VPN incident at first line with the workaround, and how would you change the flow without destroying first-contact resolution?
Read the worked answer
First-contact resolution is genuinely valuable, so the answer is not to stop resolving. The problem is that resolution is happening without a trace that the problem management practice can use.
The risks are concrete. The organisation cannot size the problem, so it cannot justify funding the root-cause work: the 368 lost user hours are invisible because each incident is a two-minute call. Repeat contacts rise, because the same users call back, which inflates handle time while first-contact resolution still looks healthy. Known errors never get matched at the point of logging, so agents rediscover the workaround instead of being offered it. And problem ageing goes unmanaged: 44 records older than 180 days is a symptom of records that never received evidence or attention.
The flow change is small. Make linking mandatory but cheap: when an incident is resolved against a known error, the tool should offer the known error as a resolution code with one click, which both closes the incident and links it to the problem record. Where no known error exists, use matching rules on symptom text or on error signature and CI so the incident is auto-linked to the open problem. Add a repeat-incident measure, the proportion of users contacting the desk twice for the same symptom within 30 days, to the service desk scorecard so agents are not rewarded for a closure that recurs.
Keep the workaround at first line. It restores service quickly, which is correct. What changes is that each use is counted, and the count feeds the problem record. Also review the KEDB entries themselves: a workaround that takes 12 minutes per occurrence is itself a candidate for improvement, for example client-side automatic reconnection.
3. The network team says the cause is outside your control. How would you settle the dispute, and what do you do if root cause genuinely cannot be found?
Read the worked answer
Two teams holding contradictory beliefs is a hypothesis problem, not a political one. Replace opinion with a discriminating test.
Agree a written hypothesis for each position and the evidence that would confirm or eliminate it. For the peering theory, capture packet traces at the client, at the gateway and at the internet edge for the same failure windows, and compare against the provider's telemetry and published incident history. For the driver theory, test a single client version in a controlled group, correlate disconnect timing with driver version and with endpoint OS patch level, and check whether failures cluster by client build or by site and time of day. Cluster by site and by time is usually decisive: a peering fault follows the network path, a driver fault follows the endpoint build.
Run one joint session with both teams in the same place, with a shared evidence log and a single agreed owner of the investigation. Set a decision date. The problem manager's job is to force a decision, not to adjudicate technical truth.
If root cause genuinely cannot be established or lies outside your control, do not leave the record open indefinitely. Make an explicit accept decision, recorded with the evidence and the residual risk. Then shift the objective from root cause to impact reduction: improve the workaround so reconnection is automatic, add path diversity or a secondary gateway, or change the client configuration. Document the known error clearly with symptoms, workaround, and the reason the root cause is not being pursued. Review the decision at a set date or if the failure rate changes. Accepting a problem is a legitimate outcome; leaving it unowned and unmeasured is not.