On this page
Why client onboarding needs a defined process
Onboarding is the client's first experience of working with you. It is also where most of the information your team will rely on for years gets collected. When it runs from a technician's memory and a long email thread, credentials arrive in plain text, documents go missing, and the client has no idea whether they are on schedule or holding things up.
A defined process fixes both sides. Your team works from the same plan for every new client, and the client sees a short list of what they need to do and by when.
The phases of MSP client onboarding
| Phase | Your team | The client |
|---|---|---|
| Kickoff | Confirm scope, contacts and dates | Name a main contact and approvers |
| Discovery | Inventory devices, network, accounts, licenses and key applications | Answer the discovery questionnaire, list vendors |
| Access | Request admin access to systems and vendor accounts | Hand over credentials through a secure channel |
| Documentation | Record the environment in your documentation tool | Upload contracts, policies and diagrams |
| Deployment | Install monitoring, security and backup tools; apply baselines | Schedule access to offices and devices |
| Users and support | Set up portal access, explain how to get help | Attend the introduction, complete training |
| Handover | Confirm open items, move to normal support | Sign off, book the first review |
The order can overlap, but discovery and access usually block everything after them.
A client onboarding checklist you can copy
- Signed agreement and confirmed start date
- Main contact, technical contact and approvers named
- Discovery questionnaire completed
- Device and user inventory reconciled with the client's list
- Network, internet and line-of-business application details recorded
- Software licenses and renewal dates captured
- Admin credentials received through a secure handoff, never by email
- Vendor contacts and support contracts recorded
- Monitoring, security and backup tools deployed and reporting
- Documentation built and reviewed
- Client users invited to the portal and shown how to raise a ticket
- Security awareness training assigned
- Sign-off from the client's main contact
- First review meeting booked
Assign each item to someone and give it a date relative to the start date, so the plan works for any client.
Common client onboarding mistakes
- Credentials by email. Passwords sent in email or chat stay in inboxes long after onboarding ends.
- No owner for client tasks. "The client will send it" is not an owner. Name the contact.
- Status only in your PSA. If the client cannot see progress, they will ask for it, and you will answer the same question every week.
- Rebuilding the plan each time. A template you improve after each onboarding gets better; a fresh checklist does not.
- No formal handover. Without a sign-off, onboarding drifts into normal support and nobody notices what was missed.
How MSPortal runs client onboarding
MSPortal's client onboarding portal is built for onboarding new client companies, not a client's new employees. Your organization turns Client Onboarding on, then builds a template with phases, tasks, owners and due dates that count from the phase start, the portal start or a finished prerequisite. For each new client you create a portal from the template. Each portal is its own copy, so changes for one client leave the template alone.
Tasks belong to your team or to the client, and can be limited to a specific contact. There are 14 task types, including document uploads, forms and questionnaires, approvals, signatures, meetings, training, credential handoff, secure file drops and access verification. Forms can map answers into Hudu or IT Glue, and your team's tasks can create PSA tickets.
The client's contacts open the portal from an emailed invitation and confirm their email address. They do not need a regular portal account. They see your logo and welcome message, their own tasks grouped by phase, overall progress and the key dates you set, and they can ask a question from the portal.
- Credentials. A credential handoff task encrypts what the client sends. Only staff with onboarding settings access can reveal it, the submission and reveal are logged, and the stored value is deleted after the reveal.
- Signatures. A signature task records the drawn signature, the signer's name and email, the time and a copy of what they signed. It does not replace a dedicated e-signature service.
- Tracking. Overdue and blocked tasks collect in a Needs attention list for your team, and an activity feed that only your team sees records each change.
The AI Template Designer can draft a template from a description of your process, and you accept or reject each section before it saves. The client onboarding guide covers setup, and you can see a sample onboarding in a demo.
Related questions
How long should MSP client onboarding take?
It depends on the client's size, the number of sites and how quickly they return information. Set target dates per phase in your template and track blocked tasks, rather than promising a fixed number of days.
How should clients send passwords during onboarding?
Through a secure handoff, never by email or chat. In MSPortal, a credential handoff task encrypts the value on arrival, logs the reveal and deletes the stored value once a staff member has revealed it.
Do clients need an account to complete onboarding tasks in MSPortal?
No. Each contact opens the onboarding portal from their own invitation and confirms their email address. Contacts who already have a portal account can also return through My onboarding after signing in.
How do clients follow progress after onboarding becomes a project?
The same principles apply: shared milestones, updates and decisions in one place. See how MSPs share project progress with clients.
How do you get clients to keep using the portal after onboarding?
Make it the place where their requests, documents and reports live from day one. See how MSPs get clients to use a client portal.