A managed service provider is usually built for breadth: keeping many clients’ environments patched, backed up and working. Then a job arrives that needs depth. A SQL Server upgrade, a Microsoft 365 security review, a cloud migration. Hiring for a few weeks of specialist work rarely makes sense, and turning the client away hands the opportunity to someone else.
Bringing in a specialist subcontractor solves the skills problem, but it raises fair questions about the client relationship, quality and access. This is how to answer them before the work starts, and it is how we work too, as set out on our For IT partners page.
The worries are reasonable
Most hesitation comes down to four concerns:
- The client relationship. Will the specialist build their own relationship with your client and take the work direct?
- Standards. Will they document, ticket and hand over the way your team does?
- Access. Who gets into the client’s environment, with what rights, and for how long?
- Brand. Will the client be confused about who they are dealing with?
Each one has a practical answer, and most of them belong in writing.
Put the protections in writing
- A non-solicitation clause. The specialist agrees not to approach your clients directly, during the engagement and for an agreed period afterwards.
- A mutual NDA. Both sides protect the other’s information, including client details and pricing.
- A written scope. Deliverables, assumptions and exclusions, so nobody negotiates scope in front of the client.
- Who talks to the client. Decide whether the specialist works behind you, alongside you under your brand, or directly with the client on your behalf.
- Insurance. Ask for certificates of currency for professional indemnity and public liability before the work starts.
Access: named, least privilege and temporary
Shared admin passwords are the fastest way to turn a subcontract into a security incident. Instead:
- Create a named account for each person, with MFA, in the client’s environment or your own tooling.
- Grant only the rights the task needs, for the time it needs them. Privileged Identity Management or equivalent time-bound access helps.
- Keep the activity logged so you can show the client what was done.
- Remove the accounts at the end of the engagement, and confirm in writing that they are gone.
Work inside your systems
The client should see one way of working, and it should be yours:
- Work is tracked in your ticketing system, against your ticket numbers.
- Documentation follows your templates and lands in your documentation platform.
- Changes go through your change process and maintenance windows.
- The handover is written for your team to own the result, not for the specialist to keep coming back.
Match the engagement model to the work
- Fixed-scope projects suit work with a clear end: an upgrade, a migration, a security review.
- Pre-paid blocks of hours suit a run of smaller tasks across several clients.
- A monthly retainer suits ongoing specialist care, such as database monitoring and patching across your client base.
Be explicit about hours too. Business-hours support and planned after-hours work in agreed maintenance windows is a clear, honest arrangement that you can pass on to your clients.
A checklist before the first job
- Non-solicitation clause and mutual NDA signed.
- Scope, deliverables and the client-facing arrangement agreed in writing.
- Certificates of currency received.
- Named, least-privilege accounts created with MFA, and a removal date set.
- Ticketing, documentation and change process agreed.
Done this way, a specialist extends your team without putting your client relationship at risk. If you have a job that needs database, security or migration depth, start a partner enquiry.