First week with a new client
First week with a new client: onboard without the spreadsheet
A new client just said yes, and the spreadsheet everybody used to track onboarding by hand is not what makes this one stick. One client record carries the whole first week: day one creates the client, its board and pod, and a real contact with portal access; day two starts the onboarding checklist and points a dedicated tech at the account; day three puts them on a plan and shows exactly what will and will not bill on its own; day four confirms what they will actually see once they sign in themselves; day five watches their first ticket land exactly where Settings already said it should. Nothing about the first week depends on anyone remembering it - the client record already carries all of it.
What you will have
- Create a client organization and see exactly what it defaults to: a board, a pod, and the tenant's own SLA targets, with no extra setup.
- Tell a plain-text Primary Contact apart from a real Contact record, and check the one door that actually grants portal access.
- Start a client on its onboarding template, mark a step complete, and know what one active onboarding really means.
- Point a dedicated tech at a client from Edit > Settings, ahead of the pod's own dispatch waterfall.
- Subscribe a client to a Core plan starting this month, and read exactly what the Approval Queue will and will not do with that first period.
- Know which of a client's own tabs carry over to their own sign-in, and watch their first ticket land on the tech Settings already locked in.
Why it works this way
Contacts and Portal Access are two separate lists that happen to hold the same people. Users > Contacts is a record only - billing, tickets, meeting attendees - and grants no sign-in by itself. Users > Portal Access is the one door that actually lets someone log in.
A client's Default Ticket Assignee outranks its own pod. Once it is set, every new ticket for that client - however it arrives - locks to that one person ahead of the pod's dispatch waterfall, whether or not that pod's waterfall would have picked someone else.
A client can have only one onboarding in progress at a time. Re-onboarding means canceling the current checklist first, not starting a second one alongside it.
Steps
Create the client with Clients > New Client.
Company Name, Domain, Billing Email, and the billing Street Address / City / State / ZIP are the only required fields. Primary Contact and Contact Email here are plain text on the client record itself - not a Contact record, and no login comes from filling them in. Harbor Point Physio, a physiotherapy clinic, is entered with Client Type left on its default, Managed, and Identity Provider set to None since nothing is connected yet.
Create the client with Clients > New Client. See what the new client defaulted to, with nothing else clicked.
The client's Overview tab already shows Pod: Help Desk and No Plan under its name - the instance's one pod picked it up automatically, no prompt asked. The Primary Contact card on the right already reads Sam Okafor, pulled straight from the plain-text field on the New Client form. The tenant's own business hours and SLA response targets already cover this client without anything set per client.
See what the new client defaulted to, with nothing else clicked. Add Sam Okafor as a real Contact on Users > Contacts.
The tab states its own limit up front: "Manual contacts for billing, tickets, and meetings. No portal login required." Filling in Name, Email, Type (Primary), and Job Title (Clinic Manager) and clicking Create Contact makes a Contact record for him - a separate fact from the plain-text Primary Contact field the client record already carried from step 1. The Type field pictured here is captured as Primary; the same option is relabeled Owner (Designated) Contact in the current build, without changing what it does - see the next step for exactly what it does and does not grant.
Add Sam Okafor as a real Contact on Users > Contacts. Check Users > Portal Access - it already lists him.
Sam Okafor shows up here as Owner with Full Access, with no Add User click in between - because he was named as this client's Primary Contact on Edit back in step 1, he is this client's portal owner, and that badge lands on him automatically the moment his Contact record exists. The Type he was given on the Contacts tab in the step before this one, Primary, is a label on that record only and is not what made him the owner; newer builds rename that value "Owner (Designated) Contact" without changing what it does. That is not the door the getting-started walkthrough uses for a second contact - there, Portal Access starts empty until someone searches a name and clicks it. If a contact on your own instance does not show up here the same way, Users > Portal Access > Add User, searching their name and clicking their result, is the door that invites them.
Check Users > Portal Access - it already lists him. Open the Onboarding tab and start the default template.
Template already reads "New Client Onboarding (Default)" with nothing else to pick. Clicking Start onboarding copies eight steps onto this client's own checklist: Kickoff call, Gather documentation & credentials, Provision Microsoft 365 access, Deploy RMM agent, Deploy EDR, Verify backup, Security baseline, and Welcome & handoff, each with its own due date counted from the moment it started. Deploy RMM agent and Deploy EDR each carry a script reference - deploy-rmm-agent and deploy-edr - a pointer for whoever runs them, not something the portal runs on its own.
Open the Onboarding tab and start the default template. Mark the Kickoff call step complete.
Clicking Complete on the first row struck it through and flipped its badge to Completed; the card no longer carries an open count of its own beside its title, so the remaining rows are the count. Every other step stays Pending exactly where it was - marking one step complete never touches the others.
Mark the Kickoff call step complete. Point a dedicated tech at this client from Edit > Settings.
Default Ticket Assignee started on None (use board notification rules); setting it to jordan.reyes locks every new ticket for this client to him ahead of every other assignment mechanism, skipping the pod's own dispatch waterfall entirely - the page's own text spells out that the lock persists for the life of each ticket. Owning Pod stays Help Desk underneath it, the pod that would otherwise have run the waterfall.
Point a dedicated tech at this client from Edit > Settings. Subscribe the client to a Core plan, starting this month.
Add Core on the client's Billing > Plans tab, then picking the Managed Desktop plan - built the same way Set up an agreement and bill a period walks in full - opens its own Contract Terms: Billing Frequency Monthly, Billing Cycle Mode 1st of Month, and Billing Start Date left blank. The helper text underneath spells out why: leaving it blank bills starting today, a future date avoids a prorated charge, and a date in the past would bill every period since then into the approval queue instead.
Subscribe the client to a Core plan, starting this month. See the subscription land: Active, this month's period already priced.
Managed Desktop now shows Active, Next bill: Oct 1, 2026, with its Sep 1 - Oct 1, 2026 period already lined up: Managed Desktop Support, Base Rate $150.00, quantity 1, Monthly Total $150.00. A 1 unbilled period flag sits right on the row - this period exists but nothing has charged it yet.
See the subscription land: Active, this month's period already priced. Check the Approval Queue - it will not touch that period on its own.
Generate Invoices, clicked right after the subscription above was created, still leaves Queue is clear, No invoices pending approval, and the same No billing activity yet banner. A subscription's first, already-in-progress period does not wait in this queue for a scheduled run to pick it up - it sits on the subscription's own row as an unbilled period, reviewed and charged from there with Backfill, not from here. What this queue will pick up on its own is the period after: Next bill: Oct 1, 2026, generated and queued for approval the normal way once that date arrives.
Check the Approval Queue - it will not touch that period on its own. Know which of these tabs carry over to the client's own sign-in.
Three of the tabs on this same strip have a matching page on the client's own side: Documentation holds what staff know about this client, and only the pieces marked visible or linked to the client surface on their own Documents page; Billing is where their own invoices show up, worded in the simpler Outstanding / Overdue / Paid / Void the client-facing walkthrough describes; Tickets is where their own requests and replies live. Meetings, Users, and Devices sit on this same strip for staff use.
Know which of these tabs carry over to the client's own sign-in. Log the first ticket and see exactly where it lands.
A new ticket for Sam Okafor - Front desk check-in tablet will not connect to Wi-Fi - landed Assigned To jordan.reyes the moment it was created, on the Help desk board, Priority Low, Billing None. The ticket's own Communication log spells out why: "Ticket assigned to jordan.reyes," the Default Ticket Assignee locked in on day two, not a pod waterfall pick.
Log the first ticket and see exactly where it lands.
The pages behind each click
Other ways to do this
Skip an onboarding step
Click the skip icon next to Complete on any pending step instead of completing it. The checklist moves on the same way completing it would, just without marking that step done.
Elise
Ask her, in chat, to create the client, generate a health briefing, or dispatch a ticket - the same underlying actions this walkthrough clicks through by hand. Elise cannot add a manual Contact, start onboarding, or subscribe a client to a plan; those stay UI-only.
If it did not work
- If a new contact does not show up on Portal Access the way Sam Okafor did here, grant it yourself: Users > Portal Access > Add User, search their name, and click their result.
- If a client's tickets keep landing somewhere other than the tech set on Default Ticket Assignee, check that field again on Edit > Settings - it outranks the pod's own dispatch waterfall until it is cleared.
- If Generate Invoices leaves a brand-new subscription's first period alone, that is expected, not stuck - the unbilled period flag stays on the subscription's own row, and Run Backfill from that row's menu is what reviews and charges it, not the queue.
- If Start onboarding will not run a second time for the same client, cancel the current checklist first - a client can have only one onboarding in progress.
Questions this page answers
How do I set up a new client?
Use New Client on the clients list. The form asks for the company name and domain, a primary contact, an email and a phone, and a billing email and address. When the MSP module is on you also pick a Client Type and an identity provider. Saving creates the client. There is no wizard, and no Onboarding item in the sidebar. Guided steps live on the client's own Onboarding tab. Build a template first, then use Start onboarding there. Each step is then marked Complete or Skip.
What happens when I create a client?
Saving the form writes the client record. If QuickBooks is connected, the portal looks there for a matching customer first. It links to that one when it finds a single clear match. It creates one when it finds none. It refuses to guess when two look alike. Nothing is created in Microsoft 365, your RMM, your PSA or your docs system. You link those afterwards, from the client's Integrations tab. No payment card is set up here.
How do onboarding templates work?
A template is a reusable list of steps. Use "Manage templates" to create or edit them, drag to reorder steps, and mark one template as the default. When you start onboarding for a client, the template's steps are copied into that client's checklist - later edits to the template do not change checklists already in progress.
What does "Mark onboarding complete" do?
It closes out the checklist even if some steps are still open, then prompts you to set the client's status from Onboarding to Active. Completing every step does the same. Setting the client Active is your confirmation - it is never done silently.
Can a client have more than one onboarding at a time?
No - a client has at most one onboarding in progress. To re-onboard, cancel the current checklist and start a new one.
Do people added here get a portal login?
Contacts are the people on file for this client. Most never get a login. The client's portal owner is the person you name with "Edit" on the client, under "Primary Contact". That person carries the "Owner" and "Full Access" badges on "Portal Access" and keeps every right. The "Type" picker on this tab is only a label on the record. That includes "Owner (Designated) Contact". It grants nothing. Anyone else gets a login only when you invite them on "Portal Access".
Was this helpful?