Before handing a client to a white label IT support partner, agree the work they will handle, how they will communicate and who can approve changes. Put the arrangement in writing, then test it with a small, controlled handover. Do not promise your client a response time or service that the delivery partner has not accepted.
For agencies and smaller managed service providers, the first handover should settle the awkward details before a real incident does. BMT’s white label service can work behind your brand or as an introduced technical partner.[6] Whichever arrangement you choose, make sure the people answering tickets understand it as clearly as the people who signed the agreement.
Start with one defined piece of work
Write down what you want to hand over. That might be day-to-day Microsoft 365 support, website maintenance or overflow tickets during agreed hours. Name the client, systems and locations in scope. Record exclusions too, particularly specialist software and on-site work. Ask the partner to confirm what it can deliver before you build your own offer around it.
Use a recent, anonymised support request to check the boundary. If a user cannot send email, who investigates the mailbox, who checks connectivity and who contacts another supplier? Agree where responsibility changes hands. Avoid sending a bundle of unresolved tickets and assuming every task is now included in the monthly fee.
Agree what the client will see
Decide who answers the phone, which email address sends updates and how engineers introduce themselves. Specify whether your team reviews messages before they reach the client or whether the partner replies directly. Prepare a short approved introduction so staff do not improvise an explanation when somebody asks who is helping them.
Keep commercial conversations separate from technical support. Agree who discusses extra work, renewals and complaints, and put client-contact boundaries in the partnership agreement. Check any customer notification or consent requirements with whoever handles your contracts and data protection. A white label arrangement should not depend on concealing information you are required to disclose.
Make escalation usable under pressure
Write down support hours and the route for urgent requests. Separate a first response from an investigation or a completed fix, and confirm which target your own client agreement promises. Ask what happens when a ticket arrives just before closing time. Include a backup contact rather than making one person’s availability the entire escalation plan.
Agree who owns the next update when two suppliers are involved. Ask the partner to demonstrate how your team can see ticket notes, outstanding actions and the current owner. For a suspected security incident, decide who can authorise disruptive steps and who contacts the client. The joint NCSC and CISA advisory recommends clearly assigning security responsibilities in MSP contracts.[8]
Arrange access before the first ticket
Ask your technical lead to define the access needed for the agreed work, then arrange it through the client’s approved process. Use individually attributable accounts where supported and record who approves them. Do not paste passwords into a handover document or ordinary ticket. Agree a secure method for sharing any necessary credentials.
The joint advisory calls for MFA on MSP accounts accessing customer environments and for unused accounts to be disabled.[8] Make those checks part of onboarding and departure, not an assumption about the partner’s tools. Keep a record of the access granted and agree who removes it when an engineer leaves or the service ends.
Rehearse a ticket and check the charges
Run an agreed test request that does not interrupt the client’s work. Follow it from submission to acknowledgement, assignment, update and closure. Check that messages use the agreed identity and that your team can find the outcome. Use dummy information, not live customer records, when you only need to test routing and communication.
Before expanding the service, compare that example with the charging terms. Ask about minimum commitments, included hours or users, onboarding work and chargeable escalations. Confirm who approves extras before engineers begin them. Request a sample billing breakdown without another customer’s details, so you can see how delivery costs will fit the service you sell.
Bring a small handover brief
Prepare a brief covering the work, support hours, communication arrangement, escalation contacts and access approvals. Attach the agreed exclusions and charging terms. Include an exit arrangement: how you receive usable documentation, resolve open tickets and remove access if the partnership ends. Ask both delivery leads to confirm the brief before the first client request arrives.
If you are considering white label IT support, bring one client scenario to BMT first. Explain what your team wants to keep and what you want a partner to handle. Agree a manageable starting scope, review the first tickets together and resolve any gaps before adding more clients.
Sources
[6] https://bm-technologies.co.uk/whitelabel-services
[8] https://www.cisa.gov/news-events/alerts/2022/05/11/protecting-against-cyber-threats-managed-service-providers-and-their-customers