
The model budgets $5,000 per hire, but hiring doesn't recreate the knowledge a technician takes with them. Start cross training employees by finding work that only its current owner can continue, then have another qualified person demonstrate it using the written record. Check access and scheduled cover as well as skill. Names on a spreadsheet have perfect attendance.
I'd start with the client work that would stop if its usual technician became unavailable. Don't ask people whether they could probably cover it. Ask them to show the next decision and the approved route to act on it.
Map the Work That Depends on a Person
Build the list around client activities rather than broad product names. Being comfortable with a vendor doesn't establish that someone can continue this client's unusual workflow. Record the specific task and what makes it dependent on its current owner.
| Coverage Record | What You Establish | Evidence to Check |
|---|---|---|
| Client and Activity | The work that would be interrupted if the usual person was absent | The agreement and actual service or project record |
| Current Owner | Who can perform or coordinate the task today | Recent completed work and its decisions |
| Proposed Cover | Who has the underlying skills and can take the assignment | A relevant work example, not only a claimed familiarity |
| Documentation and Access | What the covering person must find and be authorized to use | The current procedure and approved access route |
| Demonstration | The task the covering person will perform to show readiness | A reviewed result with any help recorded |
| Available Capacity | Who covers the task when it arrives alongside existing work | The roster and any displaced commitment |
Include the owner's technical work. The model's enterprise-value position is to build profitable recurring revenue without reliance on the owner. Moving a dependency from a technician to the owner doesn't satisfy that aim.
Keep the record current when a client environment or staff assignment changes. A training entry against an old procedure doesn't establish cover for the new one. Name the service lead who decides whether the change requires another demonstration.
Choose the First Gap by Its Consequence
Prioritize the work whose absence would cause the most serious interruption to the service you have agreed. Look at when it must happen and whether an alternative is usable. A rare task can still deserve attention if nobody else can perform it when required.
Don't allocate training only by whichever technician asks most loudly. Compare the dependency with the business effect of losing cover. Keep the reason for the order visible so the team understands why a less frequent activity may go first.
For a hypothetical example, suppose a client uses a custom reporting process that its usual technician maintains. Another engineer can administer the underlying platform but hasn't operated that process. Start by establishing the process's purpose and stop conditions, then identify the knowledge and access the covering engineer lacks.
A tool change may help with a dependency, but it doesn't remove the need to understand the task. Ask what the replacement changes and who can maintain it. Don't exchange a person dependency for an undocumented automation only the same person can repair.
Teach the Decision and Check the Work
Have the current owner explain why the procedure takes the path it does. Use a suitable training environment or an approved, supervised task. Write down where the covering person must stop and escalate rather than improvising a change.
- The current owner demonstrates the task and explains the decision points.
- The covering technician checks the procedure and identifies missing information before acting.
- The covering technician performs the approved task while the reviewer observes the result.
- The reviewer records any prompts or corrections that were needed.
- The service lead accepts the demonstrated scope or schedules the next practice needed.
Don't mark the whole client as covered because a task went well. Record the boundary of what was demonstrated. A technician may be ready for routine support while still needing help with an unfamiliar recovery or application change.
Check access under the covering person's own authorized identity. Don't make the solution a shared account or a borrowed credential. A person who knows what to do but cannot legitimately reach the system still needs an access decision before you can rely on them.
Make the Handoff Usable Without Its Author
Give the covering technician the record and ask them to find the next action. Note where they need the author to translate a reference or explain a client exception. Update that missing information in the maintained procedure rather than leaving the answer in the training conversation.
Don't call the result knowledge transfer until someone else can use it. A recording can support the handoff, but it isn't proof the receiving person can perform the task. Keep the reviewed work result beside the training record.
For the hypothetical reporting process, the test could be completing its approved run and checking the output against the acceptance criteria. Include the expected response to an error. A successful run that never tests the learner's uncertainty leaves that part of the coverage unexamined.
The model favors one standard technology stack with every technician trained on it. Use that common base, then record the client-specific exceptions you actually support. An exception nobody can explain to a second person belongs on the improvement list.
Give the Client a Familiar Route
Make introductions where the service arrangement requires them. The covering technician needs to know the client's working contacts, and the client needs the agreed support route when the usual person is absent. Don't wait for an urgent request to explain who is taking over.
In practitioner relationship-continuity advice, Paul Green recommends that clients know a small team rather than only a single named person. His suggestion aims to preserve familiar contacts when roles change. It isn't evidence that an introduction by itself supplies technical cover or guarantees retention.
Keep the client's escalation and approval boundaries in the account record. A covering engineer shouldn't need to guess which person can authorize a change. Check the current contact route rather than relying on a remembered name.
Check the Roster as Well as the Skills
Use the board test: what does this do to the board on Monday morning? If the covering engineer has a full assignment elsewhere, the service lead still needs to move work or provide another route. Demonstrated competence doesn't create simultaneous availability.
The model's 20% annual staff turnover is a planning assumption, not a prediction that a particular person will leave. Use your actual coverage gaps to choose training. Don't convert that assumption into a claim that cross training will save a fixed number of hires.
The $5,000 hiring allowance is also a model assumption, not the full measured cost of losing a particular technician. Record actual mentor time and displaced work when funding this plan. Avoid counting payroll twice, but keep the capacity used for training visible.
The service lead owns the dependency list and training order. The current owner owns the procedure corrections, and the reviewer owns the evidence of readiness. The roster owner confirms who can take the work when the usual person isn't there.
Choose an uncovered activity and ask the proposed covering technician to explain how they would continue it from the current record. Fund the missing practice and access decisions that exercise reveals. Mark the gap resolved only for the scope the person has actually demonstrated and the coverage you can schedule.
mspoutpost.com/articles/cross-training-employees-for-real-msp-client-cover
Written by Megan Friesen
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.
