Choosing a business IT support company means looking beyond a promise of “fast support”. A ticket acknowledgement can arrive in seconds while the fault stopping your team from working remains untouched. What matters is when a suitably skilled person takes ownership, how the incident is escalated and what happens until service is restored.
For an SME, those distinctions affect payroll runs, customer calls and access to shared systems. Use response commitments to compare providers on a consistent basis, then check that their contract, staffing arrangements and reporting support the promises made during the sales conversation.
Separate a response from a recovery
A service level agreement (SLA) should distinguish between acknowledging an issue, starting technical work and restoring the affected service. These are different milestones, even when a proposal groups them under “response times”.
Ask a business IT support company to explain exactly what happens before its response target is marked as met. An automated email confirms receipt, but does not demonstrate that an engineer has assessed the incident.
| Commitment | What it should describe | What to clarify |
|---|---|---|
| Acknowledgement | Confirmation that the report has arrived | Is this automated or human? |
| Technical response | An appropriate person assesses the issue and begins action | What evidence records meaningful engagement? |
| Service restoration | The affected business function becomes usable again | Does a safe workaround count? |
| Permanent resolution | The underlying fault is fixed | Can this follow restoration under a separate problem record? |
| Progress updates | Communication while the incident remains open | Who receives updates and how frequently? |
A short response target is not a promise of a short outage. Permanent resolution can depend on replacement equipment or an external supplier. Where a fixed resolution deadline is impractical, look for clear restoration objectives, escalation triggers and communication commitments instead.
How a business IT support company should prioritise incidents
Priority should reflect business impact and urgency, not simply who reports the problem or how many people are affected. A single employee unable to release a time-critical payment may need more urgent help than several employees experiencing a minor inconvenience.
Agree definitions before signing. The following examples illustrate a discussion framework, not a universal priority scheme:
| Priority | Illustrative business impact | Point to agree |
|---|---|---|
| Critical | A core service is unavailable with no usable workaround | Who can declare a critical incident? |
| High | A major function is impaired or a time-sensitive process is blocked | Does an approaching deadline change the priority? |
| Normal | An individual has a fault but can continue through a workaround | What happens if that workaround fails? |
| Planned request | A new user, software installation or scheduled change is needed | What lead time applies? |
Security incidents need their own route. Suspected account compromise may require urgent containment even when every application still appears to work.
Ask who assigns the initial priority, how disagreements are resolved and whether any downgrade must be explained. Otherwise, an apparently strong critical-incident commitment may cover fewer situations than you expect. Your organisation should also nominate someone authorised to confirm business impact when the helpdesk needs clarification.
Check the hours behind the promise
Before comparing headline times, ask each business IT support company which hours count towards them. “One-hour response” can mean one elapsed hour, one covered working hour or a target applying only to a particular service tier.
For example, suppose a contract covers 09:00 to 17:00, Monday to Friday, excluding bank holidays. An incident logged at 16:50 on Friday with a one-covered-hour response target could have a deadline of 09:50 on Monday, assuming Monday is not a bank holiday. That is very different from expecting action by 17:50 on Friday.
Check whether the agreement distinguishes between:
- Ticket submission: When users can send a request.
- Monitoring: When systems generate alerts and who reviews them.
- Staffed support: When people are available to investigate.
- Emergency intervention: When someone can take action outside normal hours.
A portal accepting tickets around the clock does not establish that engineers are working around the clock. Likewise, monitoring without an out-of-hours action process may identify a fault without shortening the disruption.
Match coverage to your actual operations. Include early starts, weekend trading and month-end deadlines rather than relying on your registered office hours. Confirm which contact method activates emergency support, who may use it and whether additional charges apply.
Read the rules governing the SLA clock
The target itself is only part of the commitment. You also need to know when measurement starts, when it can pause and what ends it.
Ask whether timing begins when a user calls, when a portal submission arrives or when the helpdesk finishes categorising the incident. If an alert detects a failure before anyone reports it, establish whether that alert starts a contractual clock.
A business IT support company should make these rules understandable without requiring you to reconstruct them from several documents. Pay particular attention to “awaiting customer” and “awaiting supplier” statuses. Waiting for essential access may reasonably affect measurement, but a status change should not conceal an unexplained delay.
Request written clarification on how priority changes affect deadlines and whether the original timestamps remain visible. Check what happens when a ticket is closed prematurely or reopened because the same fault returns.
Restoration also needs a definition. A workaround might get staff working again while leaving a permanent repair outstanding. That can be sensible, provided the workaround is safe, its limitations are recorded and the remaining work has an owner.
Finally, distinguish a contractual commitment from a non-binding objective. Ask what happens after a missed target, including escalation, corrective action and any contractual remedy. Service credits, if offered, do not recover lost working time.
Establish who owns supplier hand-offs
An outage can involve your support provider, broadband carrier, software vendor and internal team. A response promise is less useful if each party waits for someone else to investigate.
For each important service, identify who opens third-party cases, supplies diagnostic evidence and keeps your business informed. The IT provider may not control a cloud platform’s repair time, but the contract can still describe its own responsibilities for investigation, escalation and workaround assessment.
Ask your prospective business IT support company who remains accountable for coordinating the incident when another supplier must act. “We have raised a ticket with them” should not leave you managing the next stage without warning.
These boundaries matter especially where responsibilities are shared. If you are weighing different operating models, the distinction between outsourced and co-managed IT support helps frame which tasks stay with your team and which move to the provider.
For a wholesaler, restoring the network may not clear orders already delayed with a fulfilment partner. Map those external hand-offs too; these questions to ask international logistics companies provide a complementary checklist for ownership, escalation and visibility beyond the IT contract.
Record named roles rather than relying on one individual’s mobile number. Your escalation route needs cover for absence, holidays and incidents affecting several customers simultaneously.
Give cyber incidents and recovery separate commitments
Routine support targets do not automatically describe an adequate response to ransomware or a compromised administrator account. Ask how suspected security incidents reach someone authorised and equipped to contain them.
The process should identify who can approve disruptive action, such as isolating a device or restricting access. Establish an alternative communication channel if company email is affected, and define who coordinates with your cyber insurer or specialist incident-response provider where relevant.
A business IT support company should also distinguish helpdesk response times from recovery planning. Two measures are useful here:
Recovery time objective (RTO) is the intended time within which a service should be restored after disruption.
Recovery point objective (RPO) describes the intended limit on data loss, measured in time. For example, an agreed RPO concerns how far back the recoverable data may be, not how quickly an engineer answers.
Neither measure should be treated as a guarantee merely because it appears in a proposal. Ask which systems it covers, what assumptions apply and what testing supports it.
Recovery may depend on clean backups, available equipment, application dependencies and authorised staff. Request evidence of restore testing relevant to your environment rather than accepting a successful backup notification as proof that operations can resume. Also check who decides when a restored service is safe to use.
Ask for evidence that the commitments work
A proposal describes intended performance. Reporting and references help you assess whether the provider can deliver it.
Request an anonymised example service report showing performance by priority, not just one overall average. A large volume of straightforward requests can make the headline figure look healthy while urgent incidents receive inconsistent attention.
When evaluating a business IT support company, ask for the percentage of incidents meeting each target, the number measured and the exclusions applied. Median response time can be useful, but also ask about slow cases, missed targets and what changed afterwards.
A report should distinguish the provider’s response performance from restoration time and third-party delays. Check whether related tickets from one widespread outage are identifiable, rather than assuming each ticket represents a separate event.
References can add context that figures miss. Ask a comparable organisation how communication worked during disruption, whether escalation reached someone with authority and whether recurring issues received follow-up action.
You can use CIS customer success stories to identify relevant business contexts for a discussion, then request evidence specifically addressing your response requirements. A case study can help establish relevance, but it does not replace a written SLA.
Finally, ask what service reviews do with the findings. Repeatedly missing the same target should lead to an identified cause, an action owner and a date for checking progress, not simply another monthly report.
Test a realistic incident before signing
Give shortlisted providers the same scenario and ask them to walk through it. For example: your order-processing system becomes unavailable shortly before support hours end, staff at two sites are affected and the cause could be connectivity or the application.
Ask how the incident enters the helpdesk, which priority applies and when the response deadline falls. Then follow the escalation path into the evening. Establish who contacts each supplier, who updates your nominated manager and what happens if a workaround fails.
The exercise should reveal how a business IT support company applies its commitments, rather than how confidently it describes them. Request the relevant contract wording for each answer, including any extra charges or coverage restrictions.
Compare providers against the same requirements. A simple assessment can record whether each requirement is clearly agreed, needs clarification or is unavailable. Treat missing coverage for a genuinely critical process as a decision issue, not something a high score elsewhere can cancel out.
Before service starts, confirm onboarding responsibilities too. The provider may need working access, asset information and verified escalation contacts before particular commitments take effect. Agree how those prerequisites will be completed and recorded.
Frequently asked questions
What is a reasonable IT support response time? It depends on business impact, coverage hours and the action included in “response”. Compare providers against your critical processes rather than assuming one advertised time suits every incident.
Does a response SLA guarantee that my problem will be fixed? No. Response, restoration and permanent resolution are separate milestones. Ask a business IT support company which are contractual commitments, which are objectives and what dependencies or exclusions apply.
Do SMEs need 24/7 IT support? Some do, particularly when revenue-generating or essential operations continue overnight or at weekends. Others need business-hours support with a defined emergency option. Base the decision on the consequences of waiting until the next covered period.
Should every issue have a guaranteed resolution deadline? Not necessarily. Some faults depend on third-party repairs or further investigation. In those cases, clear ownership, escalation, updates and restoration objectives are more useful than an unrealistic fixed deadline.
Bring your response requirements to CIS
CIS provides managed IT support, cyber security, backup and recovery planning and co-managed support for UK organisations. To make a discussion useful, bring a short list of your critical systems, operating hours and the disruptions your business cannot comfortably absorb.
Discuss your IT support requirements with CIS and ask how the proposed scope, response commitments and escalation arrangements would address those scenarios before making your decision.
