The Five-Minute Reply
Choosing support for a financial workflow starts with the deadline the customer cannot miss.
Five minutes sounds like a good response time. I’d be happy to have it in a support agreement. I just wouldn’t give it much weight in choosing the vendor until I understood what happens after the reply. There’s quite a difference between getting someone on the phone and getting the right person, with enough access to do something useful, before the customer runs out of time.
Here’s the hypothetical I’d put in front of two vendors. It’s 9:15. A reconciliation has completed, but somebody spots that an input file was missing. The figures are wrong, and at 10:00 another process is due to pick them up. The buyer has 45 minutes to stop that happening. Assume the buyer initially needs the vendor’s help to block those outputs.
Provider A answers after five minutes and contains the problem after 90. Provider B answers after 20 minutes and contains it after 35. These are results from the same test, measured from the original report.
| Measure | Provider A | Provider B |
|---|---|---|
| Acknowledgment | 5 minutes | 20 minutes |
| Containment | 90 minutes | 35 minutes |
| 45-minute limit | 45 minutes late | 10 minutes to spare |
Containment means stopping affected outputs. Repairing the service and correcting anything already sent are separate tasks.
B is the better fit here. A leaves the customer 45 minutes late. With B, the figures are held by 9:50, although ten minutes of spare time isn’t much if the incident is harder than the one we tested. I’d want another run with the engineer who handled the first one unavailable. If the backup cannot do it, I wouldn’t accept the promised coverage for this workflow.
What interests me more is whether we need to buy our way out of this problem at all. Give the customer a reliable way to identify and hold the affected outputs, and A could be perfectly acceptable. There’s then time for its engineers to work. That depends on a person actually being available to use the control, knowing what to hold and understanding what else the pause will interrupt. I’d test that with the buyer’s team before treating it as a substitute for faster vendor support.
A young company might reasonably prefer to build that control instead of committing to an expensive support rota. The customer might prefer it too. Of course, it moves some responsibility to the customer, so the saving only makes sense if that team can take it on. A useful answer from the founder would explain the cost of both arrangements and be candid about what the current team can cover.
There’s still unfinished work after 10:00. Has anyone downloaded an earlier report? Did those figures reach another team? The customer needs help finding and correcting those copies, even after the service is working again. I’d include that work in the test and agree who owns it before signing. Otherwise the vendor can close the ticket while the buyer is still sorting out the consequences.
For cybersecurity incidents, NIST SP 800-61 Revision 3 provides guidance on response and recovery. The timings and buying decision here are illustrative, not NIST requirements.