Client Onboarding Checklist for Service Businesses (Plus How to Automate It)
Onboarding is where the delivery clock starts and where most of it gets quietly spent.
The contract is signed, the project is counted as started, and then four days pass waiting for a login. Those days come out of the delivery window, and the client doesn't experience them as their delay.
Below is a checklist that works for most service businesses, and the parts worth automating once you've run it manually a few times.
The four things that don't vary
Whatever the service, these hold:
One named person on the client side. Not "the team." A person, with a phone number, who can get you what you need.
Read access before day one. Not write access — that comes later. Read access is enough to begin and attracts far less resistance.
One sentence describing the work. Written down, agreed by both sides. "Improve their marketing" is not that sentence.
The start date moves if access doesn't arrive. Said at signature, not at the first delay. This is the only mechanism that stops client delay becoming your cost.
Phase 0 · Signature to day one
Target: five working days. Past seven, move the start.
Same day as signature
- Welcome email sent — scope, proposed start date, you as single point of contact
- Named contact confirmed, with phone number
- Identified who actually does the work day to day, if different
- Access list sent, filtered to what this engagement needs
- Stated plainly: if access isn't complete by [date], the start moves
- Project created in your own tracking
Days two to six
- Chased what's missing on days 2, 4 and 6 — only what's outstanding
- Tested each access as it arrives, not on day one
- Discovery session booked with the person who does the work — 90 minutes
- Confirmation session booked in the same invitation
Before you start
Every box, or the start moves:
- Named contact confirmed
- Real executor identified
- All read access working, tested by you
- Scope in one agreed sentence
- Discovery session in both calendars
- At least three recent real cases available to review
Phase 1 · Days one to four
Day 1 — Discovery
- Re-confirm scope in the first five minutes: what's in, what isn't
- Ask for a live demonstration, not a description
- Note separately: what they do · what they say they do · where they hesitate · where they say "depends"
- Follow up every "it depends" with "what makes you choose?"
- Close with: "What should I have asked that I didn't?"
Day 2 — Evidence
- Walk three real cases in the actual data, including one that went wrong
- Record volumes: how often, how long, how many fail
- Note every handoff and what happens when it fails
- Mark explicitly what you couldn't verify
Day 3 — Write it up
- Map written: trigger, steps, decisions, exceptions, output
- Separated into: confirmed · assumed · proposed · unknown
- Failure points listed with observed frequency
- Sent 24 hours before the confirmation session
Day 4 — Confirm
- Reviewed with the person who does the work, not their manager
- They marked what's wrong — asked for corrections specifically, not "does this look right"
- Corrected and confirmed in writing: "confirmed [date] by [name]"
- Decision made and recorded on what gets tackled first
- Written down what is not in scope for this engagement
If the map isn't confirmed on day four, don't proceed. Report it and renegotiate the timeline.
Access list, by business type
Send only the relevant rows. A long list produces delay, and every day of delay costs you.
E-commerce
| System | Level |
|---|---|
| Store platform | Read: orders, products, customers |
| Analytics | Viewer |
| Ad accounts | Read-only |
| Merchant/feed accounts | Read-only |
| Email platform | Read-only |
| Marketplaces | Read: orders and listings |
Local services
| System | Level |
|---|---|
| CRM or wherever leads live | Read-only on the relevant account |
| Ad accounts | Read-only |
| Business profile | Manager or export |
| Messaging (WhatsApp Business etc.) | Conversation export |
| Booking system | Read-only |
Any business
| System | Level |
|---|---|
| Existing automation tools | Read: workflows |
| Document storage | The relevant folder only |
| Main contact inbox | Export, last 30 days |
Three rules: read access, not admin. Invitations to their own account, never shared passwords. Test every access on arrival.
What to automate
Run it manually three times first. The checklist will change, and you don't want to have built on the first version.
Worth automating
1 · The welcome sequence. Triggered when the opportunity moves to Won. Welcome email, access list filtered by service type, tracking record created.
Why: identical every time, and the access list assembled from memory is where things get forgotten.
2 · The access chase. Days 2, 4 and 6, covering only what's still outstanding. Escalation on day 7 — to you, with a prompt to move the start date.
Why this is the one that matters most: it converts a client delay from something you absorb into a documented decision. Without it, the fourteen days you sold become eleven.
3 · Session scheduling. Discovery and confirmation booked together, with the confirmation three days after discovery.
Why: booking the second one later means it slips.
4 · The internal checklist. Generated per project from a template, so nothing depends on memory.
Don't automate
The discovery session. Obviously.
The scope sentence. It needs a conversation, and a template produces something nobody has actually agreed to.
Anything client-facing beyond the first email. Timing is the risk. An automated "how's it going?" arriving during a difficult week does damage that's hard to see and harder to undo.
The decision about what to tackle first. That's judgement, and it's what they're paying for.
The decision point on day four
Once the map is confirmed, choose what gets worked on. A rule that holds more often than not:
Pick the step with the highest frequency among the eligible ones — not the one with the most visible pain.
Visible pain is usually a rare, memorable incident. Frequency is what actually consumes the week. Four minutes forty times a week beats two hours once a month, by a wide margin.
A step is eligible only if it: has run the same way for four weeks, has a clear trigger, uses data that already exists in a system, fails detectably, and has someone to notify when it does.
If nothing is eligible, say so. You deliver the documentation and the simplification, without the automation. That's a legitimate outcome, and it's more honest than building something that will break.
What the client has at the end of onboarding
- A confirmed map of how their process actually works
- A list of what couldn't be verified
- The decision on what gets tackled first, with the reasoning
- An explicit statement of what isn't included
- The schedule for the rest of the engagement
Point four prevents the most common dispute at handover: the client remembers the conversation about everything that could be done, not the document about what was agreed.
Onboarding isn't admin before the work. It's the part that determines whether the work has a chance of going well.
Want your onboarding to stop eating your delivery time?
A free systems audit covers how work actually starts in your business and where it stalls.