Every MSP and integrator hits the same wall. A customer needs hands on site in a city where you have nobody. You can say no, fly someone in, or hand the work to a subcontractor. The third option works well when you control the brief, the contact and the evidence. It goes badly when you hand over a vague ticket and hope.
This guide is practical advice for the buyer. It covers when to subcontract, what to put in the scope, who speaks to the customer, how to handle access and data, what proof to demand, which liability questions to ask, how to run a pilot and what to do when a job fails.
When should you subcontract IT field work instead of hiring?
Subcontract when the work is uneven, spread across many places or needed in cities where you have no staff. Hire when the work is steady, local and specific to your own customers and tools.
A salaried engineer in every market costs you whether or not jobs arrive. A subcontractor costs you when work exists. The trade is control: you give up some day to day supervision and gain reach.
| Situation | Usually better | Why |
|---|---|---|
| One-off visits in a new city | Subcontract | No local staff to justify hiring |
| Multi-site rollout with a fixed window | Subcontract | Many engineers needed for a short time |
| Daily work for one large customer nearby | Hire | Steady volume and deep site knowledge |
| Work needing your own proprietary tools | Hire, or subcontract with training | Control over method matters |
What belongs in the scope and the brief?
The scope belongs in writing, and it must let an engineer finish the job without phoning you. If the engineer has to guess, you are paying for the guess.
Treat the scope as the contract for one visit. Anything not written in it needs your approval before work begins.
- Site address, contact on site, working hours and the exact window.
- Numbered steps, device names, rack or room locations and port or cable labels.
- What is in scope, what is out, and what the engineer does if reality differs from the ticket.
- Parts: who supplies them, where they are delivered and who takes the failed part away.
- Skills needed, such as a certification the customer requires.
- Pass or fail tests, such as a link light, a ping, a speed test or a signed acceptance.
- Evidence required: which photos, which results and what the closeout report must show.
- A stop rule: when to stop and call instead of improvising.
Who should talk to the customer, and how do you stay the single point of contact?
You should be the only party that speaks for the project, and the engineer should speak to the customer only about the work on site. This protects your relationship and keeps the customer from hearing two versions of events.
Agree three rules before the visit. First, the customer receives all scheduling, status and invoices from you. Second, the engineer is introduced as working on your behalf, with your project name and ticket number. Third, scope changes, sales questions and complaints go back to you, not to the engineer.
Tell the customer who is coming, when and what they will do. Send the engineer's name and contact window ahead of time. Ask the engineer to message you at arrival, at any change and at completion, so you can update the customer before they ask.
How do you handle access, site rules and data?
Arrange access and data rules before the visit, because delays at the door and surprises with data are the most common causes of a failed job.
Many sites need names on a list, ID checks, escorts, induction, safety gear or a booked loading dock. Ask the customer for these in writing and pass them to the engineer with the brief.
For data, apply the same care you would give your own staff. Share only what the job needs. Agree in writing that the engineer keeps no copies of configurations, credentials, diagrams or customer information. Use a non-disclosure agreement that covers the engineer, and check that your customer contract allows you to use a subcontractor at all.
NIST's Cybersecurity Framework 2.0 treats supplier risk as part of governance. It suggests knowing which suppliers touch sensitive data or systems and putting security requirements into agreements. Scale your checks to the access the job needs.
- Name each engineer who will attend, and bring photo ID.
- Do not send admin credentials by email. Have the customer provide access on site or through their own process.
- Say what the engineer must not touch.
- Agree what happens to any media, labels or parts removed from the site.
What evidence should you require at closeout?
Require a closeout report with dated photos, test results and notes, delivered before you tell the customer the job is done. Evidence is how you check work you did not witness.
Ask for before and after photos, labels in frame, serial numbers where relevant, results of every test in the scope and a short note on anything unexpected. Open the report yourself. If a photo does not show the work, ask for another before you invoice.
A report also protects you later. If the customer disputes a change weeks afterward, you have a record of what was done and when.
- Arrival and departure times and the name of the person on site who signed off.
- Photos of each device, port or cable touched, before and after.
- Test results matching the pass or fail tests in the scope.
- Parts used and parts removed, with serial numbers if needed.
- Open items, with a recommendation and no action taken without approval.
What liability and insurance questions should you ask?
Ask who carries the risk if something is damaged, lost or breached, and get the answer in writing. Do not assume your own insurance covers a subcontractor's mistakes.
These questions are for your own advisers to confirm. This guide is not legal or insurance advice.
Also check how the engineer is engaged. The IRS looks at behavioral control, financial control and the type of relationship when deciding whether a worker is an independent contractor or an employee. If you direct how an individual works, supply their tools and keep them on indefinitely, the arrangement may not look like subcontracting. Ask your adviser.
- What insurance does the provider carry, and will it send a certificate for this customer's site?
- Does the cover include general liability, professional liability and cyber liability, and what are the limits?
- Does your customer contract require you to be named, or require the subcontractor to be named?
- Who is liable for downtime or data loss caused during the visit?
- What does the provider do about damaged equipment, and how is a claim started?
- Does your contract with the customer allow you to subcontract, and does it flow down your obligations?
How should you run a pilot job first?
Run one small, low risk job before the first important one. A pilot shows you how the provider communicates, how complete the evidence is and whether the engineer follows the brief.
Pick work with a clear pass or fail test, such as a single device swap or a cable check. Give it the same scope format you will use later. Do not hide problems from the pilot, because they are what you want to learn about.
Afterward, score it. Did the engineer arrive on time and follow the steps? Did you hear from them at the right moments? Was the report complete without chasing? Did the customer notice anything that reflected badly on you? Fix the brief, then scale.
Deploris works this way: written scope before work, vetted engineers from a network, one engagement manager as the point of contact, a closeout report with photos and test results where they apply, and no lock-in contracts. Whichever provider you use, ask for the same things and expect them in writing.
What do you do when something goes wrong?
Tell the customer quickly, own the problem and fix it, then work out the cause with the provider. The customer cares about the outcome and about how you handled it.
Most problems are an engineer who could not enter the site, a missing part, a scope that did not match the site, or a change made without approval. Decide in advance who calls whom, how fast and in what order. Put the process in the brief so the engineer knows to stop and call.
- Contact the customer yourself, with facts and a next step.
- Ask the engineer for a written account and photos while memory is fresh.
- Make the site safe and stable before anything else.
- Agree who pays for a revisit before it is booked.
- Review the cause with the provider and update the brief or the checklist.
- If the same failure repeats, change provider.
Key takeaways
- Subcontract for reach and uneven demand. Hire for steady, local, tool-specific work.
- A written scope with numbered steps, pass or fail tests and a stop rule prevents most failed visits.
- Stay the only voice to the customer and agree that rule with the engineer before the visit.
- Require photos, test results and a closeout report, and check them before you call the job done.
- Run a small pilot first, and settle insurance, data handling and responsibility for mistakes in writing.