Operations
Choosing a data centre smart hands provider: 8 questions that reveal what a proposal does not
· 10 min read
Choosing a data centre smart hands provider is largely a process of identifying what they cannot do before an incident makes the discovery. Coverage claims, SLA figures and accreditation lists look similar across most proposals. The gap between a provider worth having and one that will disappoint appears when you ask specific questions: which cities have genuine capacity today, how the access list is managed across multiple facility operators, what vetting evidence exists for the named engineer attending your site and what documentation comes back when the job is complete. The provider who answers all four precisely, before you need them, is worth continuing with.

Why the proposal does not tell you enough
A smart hands proposal typically states a response time SLA, lists the facilities the provider covers, describes the types of work the engineers can perform and includes a reference to engineer vetting. These details are necessary but not sufficient. The SLA is a contractual commitment that may be measured from ticket creation rather than from the moment you call. The facilities list shows historic access, not current authorised-engineer status. The vetting description tells you the policy, not whether the specific engineer attending your site has been through it. Evaluating a provider means asking questions the proposal does not answer on its own.
Question 1: Which cities do you have capacity in today?
Coverage maps and city lists show historic presence, not current capacity. Ask specifically: 'If I needed an engineer at [facility name] in [city] at 2am tonight, how many vetted engineers do you have authorised for that facility at this moment?' A provider who answers with a number and can name the facility operator contact they would call has genuine coverage. A provider who answers with 'we cover the whole of the UK' has not answered the question.
Question 2: How is the access list managed?
Access to a colocation data centre requires the engineer to be on the authorised access list held by the facility operator. Maintaining that list requires proactive management: engineers must be added before a job, any engineer whose vetting has lapsed must be removed and the list must be accurate at the time of access, not merely at the time of signing the contract. Ask the provider: 'How is the access list maintained at each facility you cover, and what happens when an engineer's vetting lapses?' The answer tells you whether access management is a live process or a set-and-forget one.
Question 3: What vetting do your engineers hold?
Most data centres require engineers to hold a valid Disclosure and Barring Service (DBS) check, or an equivalent background check for non-UK citizens, before granting physical access. Some facilities require a higher-level security clearance for government, financial or critical national infrastructure tenants. Ask the provider to describe their vetting process and what they can produce as evidence for a specific engineer. A provider who can provide a named engineer's vetting reference number on request is managing this as a live record rather than a policy statement.
Question 4: What documentation comes back from each job?
The value of a smart hands engagement is not just the physical work performed but the record of what was done. Ask the provider: 'What documentation do I receive after a standard job?' The minimum useful response includes timestamped photographs of before and after states, a written description of the work performed, serial numbers for any devices touched, and confirmation that the work matches the scope agreed. A provider who can describe this precisely, including the format and delivery method, has clearly done it before.
Question 5: Where does the scope of your work end?
Smart hands work sits between remote management (which your team does via the network) and managed services (where the provider owns the outcome). The scope boundary is important: a smart hands provider should be able to follow precise instructions from a remote engineer, swap hardware, run cables and carry out physical checks, but should not be making network configuration decisions without explicit authorisation. Ask how they handle a situation where the work scope changes once the engineer is on site, and what the escalation path is when the first diagnosis turns out to be wrong.
Question 6: How does the SLA actually work?
Response time SLAs are commonly stated as 'two-hour response' or 'four-hour response'. The key question is: response to what, measured from when? An SLA measured from ticket creation by your team gives a different real-world response time than one measured from when the engineer makes first contact, or from when they arrive on site. Ask the provider to walk through a scenario: 'If I call at midnight with a critical hardware fault at a London data centre, what happens, and what SLA governs each stage?'
Question 7: How do multi-site estates work?
If your infrastructure spans multiple data centres, you need a provider whose coverage matches your footprint. This is about more than whether they list your cities. It means consistent documentation formats, the same vetting standard for engineers at every site, a single escalation path regardless of which site has the incident and ideally a single agreement rather than separate engagements per location. Ask how a multi-site account is managed and whether there is a named account contact who understands your full estate.
Question 8: Can I see a sample of your post-job documentation?
Asking to see a sanitised sample of the documentation produced after a standard job is the fastest way to assess delivery quality. A provider who produces clear, formatted, timestamped reports with photographs, a work summary and a scope-versus-completed comparison is one whose engineers are trained to document consistently. A provider who produces a brief email note with one photograph is telling you what their standard looks like before you are under contract.

