Client onboarding: the workflow nobody designs until it hurts

A client says yes on Tuesday. By the following Friday you have their logo in a WhatsApp chat, half the page text in an email, a photo of the M-Pesa confirmation from someone you don't recognise, and no idea whether the contract came back signed. Nobody has started the work, and nobody can quite say why.

That stretch between "we won the client" and "work has started" is onboarding. Most service businesses never design it. They design the sale, because that's where the money is, and they design the delivery, because that's the job. The bit in the middle gets done from memory, slightly differently every time.

This post is about designing it once. We'll use our own setup as the worked example, because it's the one we can show you honestly: what we ask, when we ask it, and which parts a machine handles so nobody has to remember.

Why onboarding gets skipped

It belongs to nobody. Sales feels finished when the client agrees, and delivery feels like it starts when the materials arrive. Onboarding sits between the two, so in a small team it lands on whoever happens to be holding the phone that week.

It also happens rarely compared with the work itself. A business might deliver every day but take on a new client once or twice a month. Anything you do twice a month never becomes a habit, so each time it's rebuilt from scratch, and each time something different gets forgotten.

And it looks like admin, which makes it easy to postpone. The cost arrives quietly, as a project that starts eight days late because the deposit was never chased, or a website held up for a week waiting on a logo that the client assumed you already had.

The framework: one trigger, one intake, one checklist

Good onboarding comes down to four decisions, made once and then reused for every client.

1. Pick the single moment that starts everything

Onboarding needs a starting gun: one specific, recorded event that means "this person is now a client". "Sometime after the call" is too vague to build on.

In our own system that moment is a dropdown. Our pipeline lives in a Google Sheet we built for ourselves, where a lead and a client are the same row at different stages. Changing that row's stage to "Accepted" does four things on its own: it gives the client an ID, builds their folder tree in Google Drive (contracts, assets, images, documents, final delivery, meeting notes), opens the first project row, and writes the onboarding checklist. That works because a Google Sheet can run a small script whenever a cell changes, using what Google calls triggers in Apps Script.

You don't need a script to get the main benefit, though. What matters is that there is exactly one moment, written down, after which the onboarding steps begin. A paper diary entry that says "Accepted, 7 October" does the same job if everyone knows to look for it.

2. Ask for everything once, in one place

The most common onboarding failure is drip-feeding questions. You ask for the logo on Monday, the domain login on Wednesday, the opening hours on Friday. Each message gets a reply eventually, and the whole thing takes three weeks.

Busy owners answer one message. They don't answer six. So we ask once.

For project work, that means a short form per service. We run separate forms for websites, for business systems and for content, because a website client and an automation client need almost nothing in common. Each one says up front that it takes about six minutes, and most questions are a single click. The website form asks things like "Do you have a logo file?", "Do you have photos of your work, team or premises?" and "What do you want a visitor to do on the site?" Most yes-or-no questions have a third answer: "Need help deciding". That answer tells us more than a guess would.

For smaller setup jobs, a single WhatsApp message does the same work. When we set up a domain and business email, we send one numbered message with every question we will need answered: the official business name, a phone number that can receive codes, who the main admin is, which addresses they want, paid or free email, who will pay the provider, and the physical address and KRA PIN (Kenya Revenue Authority personal identification number) for the domain registration record. We don't start any signup until the answers are back.

One small technical detail saves a lot of confusion. Our form links arrive with the client's ID already filled in, so every answer knows which client it belongs to. Google Forms supports this directly as a pre-filled link. Without it, form answers turn up with nothing tying them to a client, and someone has to work out by hand who sent what.

3. Send a welcome that answers "what happens now?"

A new client has just committed money and trust. The welcome message exists to tell them three things: what happens next, who to contact, and what you need from them by when.

It doesn't need to be long, and it shouldn't read like a brochure. We keep ours as a written template, because the facts in it are the same every time, but a person sends it. It goes out the day after acceptance, once the form and the deposit invoice have already gone.

4. Turn the steps into a dated checklist

Here is our onboarding run, exactly as the system writes it for every new client, with the day counted from acceptance:

Each row has a date, and every morning at 7am an email lists anything due or overdue. That's what turns a checklist into something that gets done: nobody has to remember to look at it.

Notice where onboarding ends. It finishes when three things are true: the deposit has landed, the materials are in the folder and the kickoff date is agreed. Our rule is short: no deposit, no build. Writing the finish line down stops onboarding drifting into the project and quietly eating its first fortnight.

What to automate and what to keep human

Automate the parts that are the same every time and only matter if they actually happen. Creating the folders, generating IDs, writing the checklist, stamping the date a stage changed, sending the morning reminder. A person forgets these. A script doesn't.

Keep people on the parts where tone or judgement matters. We have the system remind us to chase a late deposit on day five, but a person writes that message, because "just checking in on the invoice" lands very differently depending on who you're talking to and what's happened that week. The kickoff conversation stays human. So does any decision about scope.

One design choice from our own build is worth copying. The onboarding tasks carry dates, but the build checklist that appears later, one task per deliverable, deliberately has none. It defines what "done" means and leaves the timing to the project plan. The morning email only reports dated work, and a checklist that nagged us about eleven deliverables every single morning until launch would quickly become something we skimmed past. A reminder only works if it's rare enough to be read.

What this looks like in practice

Here is the shape of it for a small photography studio, as an illustrative example rather than a client story.

The owner closes a wedding booking on a call. Afterwards they change one field in their bookings sheet to "Confirmed". That's the trigger. Within the hour they send a pre-filled form: venue, timings, the names of the two people to coordinate with on the day, a must-have shot list, and whether the couple wants a printed album. The deposit request goes out the same day. The next morning a short welcome message confirms the date, says who will be shooting, and says the timeline is due back a week before the event.

Every one of those steps sits on a dated list. On day five, if the deposit hasn't arrived, the reminder appears and the owner writes a polite nudge in their own words. Nothing in that setup needs special software. It needs the steps written down once, in order, with dates.

Common mistakes

The mega form. One form that tries to cover every service ends up with sixty questions, half of them irrelevant, and gets abandoned halfway through. One short form per kind of work gets finished.

Asking before the client has agreed. Send the onboarding form only once someone has said yes and has a record. Collecting detailed information from people who are still deciding wastes their time, and leaves you holding personal data you didn't need.

Collecting more than the work needs. Kenya's Data Protection Act requires personal data to be "limited to what is necessary" for the purpose it's collected for (section 25). An onboarding form is a good place to apply that: if you can't say what an answer will be used for, drop the question.

Passwords in chat. Onboarding often involves account access. Don't ask for a password over WhatsApp or accept one in a screenshot. Where you have to set up an account for the client, set it up under their name and have them change the password at handover.

A checklist with no dates. "Collect assets" with no day attached gets done when someone remembers. "Day 7: collect assets" gets done on day seven, or shows up as overdue.

Automating the welcome. A welcome that's obviously a bot sets the wrong tone at the moment the client is most nervous. Template the content, but send it as a person.

Your next steps

1. Write down the one event that makes someone a client in your business. Make sure it gets recorded somewhere everyone can see.
2. List every piece of information you've had to chase from a new client in the past few months. That list is your intake form.
3. Cut anything from that list you can't name a use for, then split what's left by type of work.
4. Write your welcome message once: what happens next, who to contact, what you need and by when.
5. Put your onboarding steps in order and give each one a day, counted from acceptance.
6. Decide where onboarding ends. Write the finish line down.
7. Only then pick one repetitive step, such as creating folders or the morning reminder, and automate it.

If your client details currently live in one person's WhatsApp, start with the five-column customer list before any of this. And the order above follows the same principle as everything else we build: map the workflow before you automate it.

Sources and further reading

• Google Docs Editors Help: Publish and share your form with responders, including how to send a form with some answers already filled in.
• Google for Developers: Triggers in Apps Script, the feature that lets a sheet run a script when a cell changes.
• Kenya Law: Data Protection Act, 2019, section 25, principles of data protection.

Where we can help

Onboarding is exactly the kind of repeated, rule-shaped work our business systems service is built around. We map how a new client currently moves from yes to started, cut what isn't needed, and then automate the parts that should never depend on someone remembering, with people kept on the parts that need a human voice.

If new clients in your business take longer to get started than they should, book a 30-minute discovery call and we'll look at where the time goes.