Your best technician just gave two weeks’ notice.
You post the job, run the interviews, make an offer, and three weeks later a new hire shows up on Monday morning. They’re capable. Their certifications check out. Their trial ticket went well.
And then you hand them a PSA login and tell them to shadow someone for a few days.
What happens next – over the following 30 days – determines whether you’ve made a good hire or whether you’ll be repeating this entire process in four months. Most MSP technician attrition in the first 90 days isn’t about skill fit. It’s about structure. New hires who don’t have a clear framework for how to perform in their role, what is expected of them in the first month, and how they’ll be evaluated – disengage quickly, make avoidable mistakes, and either leave or become a performance problem that falls entirely on the service manager to untangle.
A structured 30-day onboarding process doesn’t just protect the hire. It protects the team, the clients, and the service manager’s time.
This is the framework BMK Community teaches in the Service Manager Certification — adapted here as a practical guide you can apply at your MSP immediately.
Why most MSP onboarding fails
The most common version of MSP technician onboarding looks like this: the new hire gets access to the tools on day one, sits with a senior tech for a few days, starts picking up tickets toward the end of week one, and is more or less on their own by week two. The service manager checks in informally. There’s no defined expectation set, no documented learning path, and no formal checkpoint until something goes wrong.
This approach fails for predictable reasons.
Without defined expectations, the new hire optimizes for looking busy rather than developing the habits that actually matter — proper time entries, accurate ticket documentation, correct escalation protocol. They can’t know what good looks like if no one has shown them.
Without structured learning phases, they move too fast into independent work before they have enough context to do it well. Early mistakes compound. The senior tech who was supposed to be mentoring them gets frustrated at the constant questions and stops being available. The service manager is now managing a new hire problem that didn’t have to exist.
Without a formal checkpoint at 30 days, there’s no moment of accountability — for the new hire or for the service manager. Problems that could have been addressed at week two become entrenched habits by month three.
Structure doesn’t slow down onboarding. It accelerates it — by giving the new hire a clear path from day one to full productivity, and by giving the service manager the visibility to course-correct early.
Phase 1 (Days 1–3): Access, tools, and expectations
The first three days are not about technical work. They are about setup and orientation — done thoroughly, not rushed.
Access and tools. Every system the technician will touch needs to be provisioned before they arrive: PSA login, RMM access, documentation platform, communication tools, ticketing queues. A new hire who spends day one waiting for access sends a signal about how the organization operates — and it’s not the one you want to send.
The client roster. Walk the new hire through your active client base: who they are, what tier they’re on, their agreement details, any known quirks or escalation sensitivities. Clients are not interchangeable. A technician who shows up to a VIP client interaction without knowing they’re a VIP is already behind.
Standards and expectations. Day one is the right time to establish your non-negotiables in writing: time entry standards (entries logged same-day, minimum detail requirements), ticket documentation expectations, communication protocol with clients, escalation thresholds. These aren’t punitive — they’re the operating framework. Setting them on day one means the new hire can build habits from the start rather than unlearning shortcuts later.
The 30-day roadmap. Give the technician a written overview of what the next 30 days look like — the phases, what they’ll be doing in each, and when the formal checkpoint happens. People perform better when they can see the path ahead of them.
Phase 2 (Days 4–10): Shadow, observe, and document everything
The second phase is structured observation. The new hire is not solving tickets independently yet — they are building pattern recognition by watching how work gets done at your specific MSP, with your specific clients, inside your specific systems.
Paired shadowing. Assign a senior technician as the formal shadow partner for this phase. Define what that means: the senior tech walks through their reasoning on every ticket, the new hire asks questions, and they debrief after each resolution. This is not passive observation — it’s active learning with a defined structure.
Documentation review. Walk the new hire through your knowledge base and runbooks. Every MSP has undocumented institutional knowledge that lives in the heads of senior staff — this phase is the time to surface as much of it as possible and get the new hire oriented to what’s already written down.
Dispatcher interaction. If you have a dispatcher function — whether internal or through a service like BMK Ops — make sure the new hire understands how tickets arrive, how they’re prioritized, and what the routing logic looks like. A technician who understands the dispatch process works with it instead of around it.
Daily debrief. Five minutes at the end of each day. The new hire writes down three things they observed, one thing they’re uncertain about, and one question for tomorrow. The service manager or shadow partner reviews it. This creates a feedback loop without requiring a formal meeting structure.
Phase 3 (Days 11–20): First solo tickets with structured review
By day eleven, the new hire should be ready to handle tickets independently — with a defined safety net.
Ticket type restrictions. Start with a constrained ticket scope: P3 and P4 tickets only, within a defined category of work that matches the technician’s demonstrated competency. This is not about doubting the hire — it’s about building confidence through successful reps before introducing complexity.
Pre-submission review. Before the new hire closes a ticket for the first 10 days of solo work, the service manager or senior tech reviews the resolution notes and time entry. Not to micromanage — to catch patterns. If the same documentation shortcut appears three times in a row, address it on ticket four, not at the 30-day review.
Escalation protocol practice. Every MSP has escalation thresholds — ticket complexity, client tier, time elapsed. This phase is when the new hire internalizes those thresholds through real application. Every escalation during this phase should be a teaching moment: what triggered it, was it the right call, what would a more experienced tech have done differently.
Midpoint check-in (Day 15). An informal 20-minute conversation, not a formal review. Three questions: What’s going well? What feels unclear? What do you need more of? This surfaces problems early enough to fix them before the 30-day checkpoint.
Phase 4 (Days 21–30): KPI baseline, accountability, and the first formal 1:1
The final phase shifts from learning to performance. The new hire is now doing real work at near-full capacity — and it’s time to establish the data baseline and the accountability structure that will govern their development going forward.
Establish the KPI baseline. Pull the new hire’s numbers from the PSA for weeks three and four: average resolution time by ticket type, time entry compliance rate, tickets handled per day, escalation rate, any CSAT data if your system captures it at the tech level. Don’t evaluate against a veteran standard — establish a baseline for this technician that you’ll use to measure improvement over the next 90 days.
The 30-day formal 1:1. This is a structured 45-minute meeting with a defined agenda: review the numbers together, acknowledge what went well, identify one or two specific development areas, and set measurable expectations for the next 30 days. This meeting sets the tone for how performance management works at your MSP. A new hire who experiences a thorough, fair, data-driven review at 30 days understands that accountability is real and consistent — not arbitrary.
The 30-day checklist. Before closing out the onboarding period, verify that the following are all confirmed: PSA workflow is correct and consistent, time entry standards are being met, escalation protocol is understood and practiced, client communication standards are demonstrated, the technician knows who to go to for what, and the service manager has a clear picture of where the technician stands.
The 30-day onboarding checklist
A simplified version you can adapt and use directly:
Days 1–3
— All system access provisioned before day one
— Client roster walkthrough completed
— Standards and expectations documented and reviewed
— 30-day roadmap shared with new hire
Days 4–10
— Shadow partner assigned with defined structure
— Knowledge base and runbook review completed
— Dispatcher process orientation done
— Daily debrief cadence in place
Days 11–20
— Ticket scope defined and communicated
— Pre-submission review cadence active
— Escalation protocol practiced and debriefed
— Day-15 informal check-in completed
Days 21–30
— KPI baseline pulled from PSA
— 30-day formal 1:1 completed with written notes
— Development areas identified and expectations set
— Full checklist confirmed before onboarding period closed
What this framework is really doing
A 30-day onboarding plan isn’t just an HR formality. It’s the first demonstration of how your MSP operates — and how you manage the people who work there.
New hires are paying attention. A technician who experiences structured, intentional onboarding — clear expectations, a real feedback loop, a fair performance review at 30 days — infers something important about the organization they’ve joined: that it knows what it’s doing. That inference affects retention, effort, and performance in ways that are hard to quantify but easy to feel in a team that stays together.
A technician who experiences the opposite — vague expectations, no check-ins, a 90-day review that covers things no one mentioned at 30 — infers the opposite. And the ones who infer the opposite tend to be the ones you most wanted to keep.
The service manager owns this process. Building it, running it consistently, and improving it over time is a core part of the role — alongside the KPI tracking, the coaching, the escalation management, and the monthly profitability reporting that the position also requires.
The BMK Service Manager Certification is a two-day, in-person course that teaches the full scope of what effective MSP service management requires — including the hiring, onboarding, and performance management frameworks that turn a good team into a high-performing one.
Ready to build a service management function that actually develops your team? Explore the BMK Service Manager Certification or book a free consultation with our team to talk through where your operation stands today.
BMK Community provides professional certification courses for MSP Dispatchers, Service Managers, Sales Professionals, and Sales Managers — built exclusively for the managed services industry. Based in Washington, DC, serving MSPs across the United States.
