What "Same-Day Response" Means When Everyone Claims It

The promise everyone makes

Pick any ten IT support companies in the North West and read their websites. You will find "rapid response", "same-day support", "4-hour SLA", "we're there when you need us" on most of them. Pick up their contracts and the picture changes. The phrase that usually appears is "response within four hours", and in a surprising number of contracts "response" is defined, a few pages later, as an automated acknowledgement that your ticket has been received.

That is not a response. That is a receipt.

We make the same-day, 4-hour promise ourselves, so this is not an attack on the promise. It is an attempt to explain what it should mean, how to check whether a company means it, and what ours commits to in writing.

Three things that get called "response"

When a provider says response, they mean one of three different things, and the gap between them is the whole argument.

1. Acknowledgement. The system has received your ticket. Usually automated, usually instant, and usually the thing the "4 hours" in the marketing is measuring.
2. A human working on it. Someone has read the ticket and started diagnosing, remotely. This is the first thing that actually helps, and most faults are fixed at this stage.
3. Attendance. An engineer is physically on site. For a failed switch, a dead access point, a till that needs a cable re-terminated or a server that will not power up, this is the only thing that ends the outage.

A contract worth signing defines all three and puts a time against each for a priority-one fault. Ours is: acknowledgement immediately, a human working on it within the hour and usually fixing it there, and an engineer on site within four working hours in our core cities if the fix needs hands. That last one is the commitment most people actually want and most contracts quietly avoid.

Why "response" and "attendance" drift apart

It is not malice. It is the shape of the business. A lot of IT support companies are, underneath, a remote helpdesk. They are very good at password resets, Microsoft 365 problems and software faults, and they can promise a fast human response because everyone is at a desk. What they do not have is engineers with vans, so anything physical gets booked with a third-party contractor, and that contractor has their own diary. The website says four hours; the switch that failed on Friday is replaced the following Wednesday.

The opposite shape exists too: an installer who is excellent with a ladder and slow at the phone, because everyone is out on jobs and nobody is watching the tickets.

We set up as an installer that supports, on purpose, so the same engineers who fit the cabling, the Wi-Fi, the tills and the cameras are the ones who answer the support line and drive out when needed. It is the only structure we know of that makes the four-hour attendance promise honest, and it is why we say "on site, not an auto-reply" rather than just quoting the number.

The questions that expose a hollow SLA

If you are comparing support contracts, these questions take ten minutes and save a year of frustration.

• **Define response.** Is it an acknowledgement, a human, or an engineer on site? Get the definition from the contract, not the salesperson.
• **Define priority one.** What counts? Tills down should. Internet down should. "One user cannot print" should not. If every ticket has to be argued into P1, the SLA is decorative.
• **Who physically turns up, and from where?** If the answer is "our partner network", ask what that partner's SLA is, because that is the real one.
• **What is the SLA for hours outside nine to five?** A restaurant's priority one is at eight on a Saturday. If the contract says "business hours", you are uncovered when it matters.
• **What happens when you miss it?** A credit, a documented review, nothing? A provider who will not put a consequence in writing does not expect to be held to the number.
• **Show me the last quarter's numbers.** Any provider who measures response and attendance can show you an anonymised report. One who cannot is not measuring.

What ours says, in plain words

Because it would be odd to write this and then hide behind our own schedule 3, here is what a Smart Wave IT support contract commits to:

• Same-day response: a ticket is picked up and worked by a person the same day, and most are fixed remotely within the hour.
• 4-hour attendance: for a priority-one fault in Liverpool, Manchester, Leeds, Preston, Blackpool, Chester or Crewe, an engineer is on site within four working hours. Elsewhere in the UK, an agreed response time in the contract rather than a number we cannot keep.
• Priority one is defined in the contract with examples: tills down, network or internet down, a server or line-of-business system unavailable, a suspected breach.
• Out-of-hours cover for venues and shift operations is priced as a line item so you can see it, not implied and then discovered absent.
• A quarterly review with the numbers: tickets, response times, attendance times, repeat faults and what we are changing.

None of that is unusual or heroic. It is just written down, which is the part that seems to be rare.

The Liverpool lunch service

The reason we are fussy about the word is a call we took from a Liverpool restaurant whose tills went down during the lunch rush. An engineer was on site in thirty minutes. The fault was a failing network switch in the back office that was dropping traffic between the tills and the kitchen printer. We swapped it, service carried on, and we explained afterwards what had failed and why it would not happen again. The write-up is in our Liverpool restaurant case study.

Nothing about that was clever. It was a van, a spare switch and a person who answered the phone. Which is, in the end, all "same-day response" ought to mean. If you want to see how that sits inside a contract, the IT support page sets out the per-user and per-site models, what is included, and the numbers.