Payment Failover on Saturday Peak
An online retailer processes about 9,000 orders an hour. For three consecutive Saturday nights, the payment authorization step has stalled for 6–11 minutes. The service desk logs a major incident each time, the on-call team fails traffic to a secondary payment gateway, and service is restored within the 15-minute SLA. Each major incident review closes with 'failover worked; no further action'. The primary gateway vendor says its logs show normal latency. The secondary gateway costs 2.5 times more per transaction, so failover is meant to be exceptional. Customer complaints are rising, and finance has noticed a small but growing refund cost. No problem record exists, and the known-error database has no entry for this symptom.
1. Using ITIL 4 definitions, decide whether a problem record should be raised. Explain the reasoning and state what would be lost by treating each event only as an incident.
Read the worked answer
Raise a problem record. ITIL 4 defines a problem as a cause, or potential cause, of one or more incidents. The three Saturday stalls share a symptom, timing, and component, so they are not independent incidents. Incident management correctly restored service, but meeting the SLA only shows the workaround worked; it does not show the cause was removed. Without a problem record, the organization keeps paying for failover, keeps exposing customers to failed payments, and never builds a known error. The value at stake is reduced likelihood and impact, not faster restoration. The problem statement should be narrow: 'Primary payment authorization stalls for 6–11 minutes on Saturday peak, cause unknown, requiring failover.' That gives the investigation a boundary without assuming the vendor is at fault.
2. Draft the first three actions the problem manager should take, and explain how each action creates value rather than just following process.
Read the worked answer
First, validate and scope the problem with evidence: incident timestamps, order volumes, gateway latency, failover logs, and refund data. Second, assign a problem owner and form a small team with the payment platform owner, network, application, and the vendor's technical contact. Third, publish the current workaround and a known-error entry marked 'root cause unknown', so the service desk does not re-diagnose each time. Each action creates value: evidence prevents a fishing expedition; ownership ends the 'review closed' loop; the known error reduces incident handling time and sets a baseline. Do not treat the workaround as resolution. The problem record stays open until the cause is verified and the permanent fix is accepted.
3. The vendor refuses to share full logs, citing commercial confidentiality. What options does the problem manager have, and which would you recommend first?
Read the worked answer
Options include invoking the contract's audit or data-sharing clause, requesting a joint technical bridge, capturing own-side packet traces and timestamps, running controlled test transactions, and escalating through service review governance. Recommend own-side evidence first. It is fast, within the retailer's control, and gives the vendor a precise question instead of a broad complaint. If the vendor still withholds data, escalate contractually and ask for a data-protection-compliant extract rather than full logs. Do not let the dispute stop work: the problem manager can confirm whether the stall is in the retailer's network, the gateway handshake, or the vendor's authorization service using observable behavior. The goal is a verified cause, not winning the argument.