How to Automate User Onboarding Across Your MSP Client Base
7 min read
User onboarding is the task every MSP knows is broken and nobody has time to fix. A new hire request comes in, and a tech spends 30-60 minutes bouncing between five or six tools — creating the M365 account, assigning licenses, setting up the RMM agent, updating documentation, configuring security policies, adding the user to the PSA. Multiply that by the 15-30 onboarding tickets a mid-sized MSP handles per month, and you’re looking at a full-time job’s worth of repetitive, error-prone manual work. The fix is to automate user onboarding across your MSP client base — not with a single script, but with a system that handles per-client SOPs, cross-tool execution, and tech approval at every step.
Here’s what that looks like in practice.
Why Onboarding Is Harder Than It Looks
On paper, onboarding is straightforward: create accounts, assign permissions, install tools, document it. In practice, every client does it differently.
Client A wants new users added to specific M365 security groups based on department. Client B requires a shared mailbox for every new hire in their sales team. Client C has a mandatory security training enrollment through KnowBe4 before the user gets VPN access. Client D needs the NinjaOne agent deployed manually because their SOE image doesn’t include it.
These aren’t edge cases. They’re the norm. When you manage 30, 50, or 100 clients, you have 30, 50, or 100 variations of the onboarding process. A checklist in your PSA captures the steps, but it doesn’t execute them. And it definitely doesn’t adapt per client.
This is why generic automation scripts fall short. A PowerShell script that creates an M365 user and assigns an E3 license works for Client A but breaks the process for Client B, who uses E5 with a specific conditional access policy. To automate user onboarding at MSP scale, the automation needs to be client-aware.
The Manual Onboarding Tax
Let’s quantify what manual onboarding costs. A typical onboarding ticket involves these steps:
- Read the ticket and identify what’s being requested
- Look up the client’s onboarding SOP in ITGlue or Hudu
- Create the user in M365 or Google Workspace
- Assign the correct license tier
- Add the user to the right security groups and distribution lists
- Configure MFA and conditional access
- Set up the mailbox (shared, room, or standard) per the client’s requirements
- Create or update the user’s entry in the documentation platform
- Deploy the RMM agent to the user’s device (or instruct the user)
- Apply security policies (endpoint protection, DNS filtering, email security)
- Update the PSA with the new contact and configuration
- Notify the client contact that the user is ready
- Close the ticket with detailed notes
Average time per onboarding: 30-60 minutes for a tech who knows the client. Longer for a tech who has to look up the SOP and figure out Client C’s specific requirements. At 20 onboardings per month, that’s 10-20 hours of tech time — time that doesn’t require deep technical skill but does require attention to detail and access to multiple tools.
The error rate matters too. Miss a security group and the user can’t access a shared drive. Forget the MFA enrollment and you’ve created a security gap. Skip the documentation update and the next tech who touches this user’s ticket starts from zero. Manual onboarding is slow and fragile.
How to Automate User Onboarding Step by Step
Here’s the workflow when you automate user onboarding across your MSP client base with an AI-driven platform like Junto.
Step 1: Ticket intake and parsing
A client emails or submits a ticket: “Please set up a new user — Sarah Chen, starting Monday, Marketing department, standard laptop.”
The AI reads the ticket, extracts the structured data (user name, start date, department, device type), identifies the client, and pulls the client-specific onboarding SOP from ITGlue. It now knows exactly which steps apply to this client and this department.
Step 2: Pre-flight checks
Before executing anything, the AI verifies prerequisites. Does the client have available M365 licenses? Is the license tier in the SOP still valid? Are there any notes in ITGlue about onboarding exceptions for this department? Is the client’s NinjaOne organization active?
If something doesn’t check out — no available E3 licenses, for example — the AI flags it for the tech before wasting time on downstream steps.
Step 3: Account creation
The AI creates the M365 user with the attributes specified in the client’s SOP: display name, UPN format (some clients use first.last, others use firstlast), department, job title, usage location. It assigns the correct license tier and adds the user to the security groups and distribution lists defined for that department in the SOP.
Step 4: Security configuration
MFA enrollment is initiated. Conditional access policies are applied based on the client’s security baseline. If the client uses a specific email security tool (Avanan, Proofpoint), the user is added there. DNS filtering policies are applied if the client runs Cisco Umbrella or similar.
Step 5: Tech approval checkpoint
At this point, the tech gets a Slack notification with a summary: “Onboarding Sarah Chen for Acme Corp (Marketing). M365 E3 assigned, added to Marketing-SG and Marketing-DL, MFA initiated, conditional access applied. Ready to proceed with RMM and documentation. Approve to continue?”
The tech reviews, confirms everything looks correct, and approves with one click. This is the human-in-the-loop gate — the AI did the work, but the tech validates before continuing.
Step 6: RMM and documentation
The AI creates the user entry in ITGlue with the standard fields populated. If the client’s SOP includes deploying the NinjaOne agent, the AI generates the deployment link or pushes the install to the specified device. The PSA contact record is created with the correct client, site, and configuration details.
Step 7: Notification and closure
The client contact (usually the office manager or HR) receives a templated email confirming the new user is set up, with first-login instructions and the IT support contact. The PSA ticket is updated with detailed internal notes documenting every action taken — which groups the user was added to, which license was assigned, which SOP was followed. The ticket is closed.
Total tech involvement: reviewing one Slack message and clicking approve. Total time: 3-5 minutes from ticket to completion, most of it automated execution.
Per-Client SOPs: The Key That Makes This Work
The critical piece isn’t the automation itself — it’s the per-client awareness. When you automate user onboarding across your MSP client base, every client’s process is different. A platform that runs the same script for every client will get it wrong more often than it gets it right.
Junto pulls the client’s onboarding SOP from ITGlue or Hudu at the start of every onboarding workflow. That SOP defines which license to assign, which groups to add, which security policies to apply, what notification to send, and any client-specific exceptions. If the SOP changes — a client upgrades from E3 to E5, or adds a new mandatory security tool — the next onboarding automatically follows the updated documentation.
This means your documentation platform becomes the source of truth for automation, not a separate set of scripts that drift out of sync over time.
Handling the Exceptions
Not every onboarding fits the standard SOP. The AI needs to handle three categories of exceptions gracefully.
Missing information. The ticket says “new user” but doesn’t include a department or device type. The AI identifies the gaps and asks the tech (or the client contact) for the missing details before proceeding.
SOP conflicts. The client’s SOP says to assign E3, but the request specifies a role that typically requires E5 (like a Power BI developer). The AI flags the discrepancy for the tech to resolve.
Tool availability. The client’s NinjaOne organization is in a maintenance window, or the M365 API is rate-limited. The AI queues the affected steps, completes what it can, and notifies the tech about what’s pending.
In all three cases, the system doesn’t guess. It pauses, informs, and waits for direction.
Offboarding: The Mirror Image
Everything that applies to onboarding applies to offboarding — disable the account, revoke licenses, remove from groups, archive the mailbox, update documentation, remove the RMM agent, update the PSA. The same per-client SOP logic applies, and the same approval gates protect against mistakes.
Offboarding is arguably more important to automate because the consequences of missing a step are more severe. A user who still has access after termination is a security incident. An unrecovered license is wasted spend. Automated offboarding with a checklist verified by AI and approved by a tech eliminates both risks.
Getting Started
You don’t have to automate every client’s onboarding on day one. The practical path:
- Document your top 5 clients’ onboarding SOPs in ITGlue with structured, consistent formatting.
- Connect your tools — M365, NinjaOne (or your RMM), ITGlue (or your documentation platform), and your PSA.
- Run the first onboarding with AI assistance — let the AI propose the steps and the tech approve each one.
- Expand to more clients as you build confidence in the process.
Most MSPs running Junto have their first automated onboarding completing within the first week of setup. By month two, onboarding is a 5-minute task instead of a 45-minute task, across their entire client base.
Want to see automated onboarding on your actual client stack? Book a demo with Junto — we’ll walk through a real onboarding workflow using your tools and your client SOPs.