Before scoping, 'we'll cover everything while you're away' is a proposed promise your MSP hasn't earned. After scoping, a one person IT department has a list of work your team will accept, a way to authorize it, and cover that can operate without calling the absent employee for every decision.
I'd cut the promise to cover a percentage of their job. A percentage doesn't say which request reaches your desk or what happens when it needs an approval. Start with the work the internal IT person wants covered, then test whether your team can perform it.
Separate Absence Cover From the Other Offers
Planned leave, after-hours response, and project assistance need different service decisions. Don't bundle them under backup IT and assume the buyer understands the boundary. Ask which situation they need to solve first and what work must continue in it.
For planned absence, establish the work the client will send your team and how that coverage is scheduled. For unplanned absence, establish who activates the arrangement and what your team has already been prepared to handle. A service that only works after a detailed live handover doesn't yet solve an unexpected absence.
Keep project work specific. The internal IT person might want your MSP to handle routine support while they focus on a project, or might need you to deliver part of the project itself. Those are different workloads, and the second needs its own scope rather than arriving through the ordinary cover queue.
A useful opening question is: 'Which work would still need an answer if you couldn't be contacted, and who could authorize that answer?' It gives the manager a way to describe the gap without assuming they want your MSP to take over their role.
Write the Cover List as Work You Can Accept
Use a service list the receiving technician can apply. The table below is a scoping worksheet, not a default bundle or a claim that every client needs every line. Have the internal IT person and your delivery lead complete it together.
| Coverage Situation | Decision Before You Offer It | Evidence Before Activation |
|---|---|---|
| Planned absence | The dates, service window, accepted request types, and activation process | Your delivery lead confirms capacity and the client confirms the handover |
| Unexpected absence | Who can activate cover without the internal IT person | The alternate client contact can authorize the agreed work |
| After-hours need | Which events qualify and how the request reaches the on-call service | The contact route and escalation are checked against the actual coverage |
| Support during a project | Which routine work your MSP takes while internal IT does project work | Accepted requests and project dependencies are recorded separately |
| MSP project assistance | The deliverables, approvals, and commercial scope | A separately agreed project plan and delivery owner |
Give every included task an accepted input and an owner. If your team needs a vendor contact or a current configuration record, identify that dependency before activation. Don't let a signed proposal hide the fact that the covering technician can't yet begin the work.
Becky Teal recommends involving operational staff in tool adoption and assigning primary and backup people who understand the tool and can educate colleagues. That's her practitioner advice. The useful application here is to prepare the people who will actually provide cover rather than relying on an owner-led sales explanation.
Request the Access the Agreed Work Needs
Start with the tasks, then have the technical owner identify their access requirements. Ask the client to approve those permissions through its normal process. Don't use the possibility of an absence to justify unrestricted access to everything.
Check the approved access before the internal employee becomes unavailable. Record how an assigned technician obtains it through your controls, including the route for an access failure. A password your contact intends to share later isn't operational readiness.
Keep a client decision-maker available for actions outside the agreed authority. The absence of the internal IT person doesn't make the MSP authorized to approve every production change. If nobody can approve a particular action, make that a visible limit of the service.
For a security event, use the client's agreed incident and escalation arrangements. This offer shouldn't create a competing promise that the cover technician will independently make every incident decision. State which specialist or incident lead the service can actually call on.
Describe the Night Service You Actually Staff
The model's after-hours default is an on-call engineer. Don't describe that as a continuously staffed service desk. Explain the request route and the eligible work, with response commitments that your delivery team has confirmed it can support.
Ask the buyer what needs action outside the agreed daytime window. A requirement to receive every routine request overnight is different from an arrangement for eligible incidents to reach an on-call engineer. If the buyer needs a staffed desk, investigate a supported service instead of changing the wording of the on-call offer.
Keep a communication route that works for the scenario. Rich Freeman suggests discussing where people work and how they communicate if the client loses access to its office, alongside data recovery. That is his continuity-planning suggestion; it is a useful prompt to test whether your cover depends on the very workplace or system the client might lose.
Price Readiness and Delivery as an Actual Service
Use the model's flat monthly fee with clear inclusions and exclusions. Estimate the work of staying ready as well as responding when cover is active. The model doesn't provide a ready-made price for this narrower service, so calculate it from the responsibilities and capacity your team will carry.
Have finance and delivery review the tools and labor that remain required during quiet periods. Price the coordination you are committing to perform. Don't assume a month without a cover request had no cost, or that all future requests will fit spare desk capacity.
Keep changes to the offer visible. If the client now wants project delivery or a wider service window, scope and approve that change before work begins. The fee should describe the accepted responsibility, rather than becoming a cheaper fully managed agreement whenever the internal employee is away.
Test Coverage Before Calling It Ready
Walk an agreed representative request through the service without asking the internal IT person to supply missing information during the test. Record who accepted it and whether the necessary access worked. Note any decision that still depended on the person the service is intended to cover.
Count accepted cover requests completed without contacting the absent employee, and record exceptions separately in the PSA. Compare actual work and coordination time with the estimate behind the fee. A rise in sales alongside more accepted requests that still need the absent person's intervention would make me revise the offer before promoting it further.
Marketing can't supply missing documentation, approval authority, or technician capacity. Fix those conditions or narrow the service. More enquiries aren't useful evidence of readiness when delivery still needs the client's only IT employee to make the arrangement function.
Take the next interested client through the coverage worksheet and access check. Confirm the people and authority on both sides, then price the service your team has accepted. Present the boundary as part of the offer, so the internal IT person can decide whether it actually lets them step away.
mspoutpost.com/articles/one-person-it-department-cover-your-msp-can-deliver
Written by Owen Gallagher
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.