The Client Onboarding Checklist That Runs Itself

Every time you sign a new client, someone right-clicks the “TEMPLATE - onboarding” tab, chooses duplicate, and renames it after the client. By now there are 63 tabs. Twelve of them are copies of an older template that still has the step for the welcome pack you stopped sending in 2024, and nobody can tell you which clients are actually finished.

The checklist itself is fine. The problem is that each copy starts drifting the moment it is made.

What goes wrong with copied checklists

A duplicated tab feels like a process, but it has three weaknesses that compound as you grow.

The template and the copies are disconnected. Improve the template and every existing copy stays exactly as it was. Six months later you are running five versions of your own process.

Nobody owns a step. The tab has a column for “done” and maybe a column for initials. It rarely says who is supposed to do each step before it is done, so tasks sit unticked while three people assume someone else has it.

You cannot see across clients. To answer “what onboarding work is overdue this week?” you would have to open 63 tabs. So nobody asks, and the overdue work stays invisible until a client complains.

Split the template from the instances

The fix is to treat the checklist as data rather than as a document. You need four record types:

• Clients: the client, their start date, the account lead, and an onboarding status.
• Onboarding templates: one record per type of onboarding (standard, enterprise, renewal with new scope).
• Template steps: the steps in each template, with a default owner role, a due-date offset and any dependencies.
• Tasks: the actual work for one client, generated from the template steps.

The template steps are where the thinking goes. A standard template might look like this:

Note that owners are roles, not names. The account lead for one client is Marcus; for another it is Aisha. The task picks up the right person from the client record when it is created.

Make the tasks spawn themselves

Once the template exists, the automation is short. When a client record moves to “Signed” (or when someone ticks “start onboarding”), the system:

1. Looks up the template for that client type.
2. Creates one task per template step, linked to the client.
3. Sets each task’s owner from the role on the client record.
4. Calculates each due date from the client’s start date plus the offset.

Most no-code database platforms and automation platforms can do this with a “for each step, create a record” action. If yours cannot, an internal app builder can, and so can a small script your technical team writes once. Connecting Your Tools: A Plain-English Guide to APIs, Webhooks and Integrations covers what to ask for.

Dependencies are worth handling simply. Rather than a full project-planning engine, give dependent tasks no due date until the step they depend on is complete. When “Collect billing details” is marked done, the system sets “Set up client in billing system” to due in two days. Good enough, and far easier to maintain.

Give people a queue, not a tab

Each person should open the tool and see one list: their tasks, across every client, sorted by due date. That single view does more for onboarding than any number of reminder emails.

Add two more views:

• Overdue by client: for the account lead, showing which clients have anything late.
• Onboarding board: every active client with a count of open and overdue tasks, for whoever runs the team.

The question that used to need 63 tabs now takes one glance. Notifications vs. Queues: How People Should Find Out There’s Work to Do explains why the list should be the main channel and notifications the exception. A single daily digest of what is due today is usually plenty.

Improving the template without breaking live clients

The best part of this setup is that improving your process becomes a single edit. Add a step to the template and every future client gets it.

Existing clients are a judgement call. For a new compliance step, you probably want to add it to all active onboardings; a small “apply to in-progress clients” automation can do that. For a cosmetic change, leave live clients alone. Either way, keep a version number or effective date on the template so you can tell later which process a client went through. Changing a Live System Without Breaking Trust has more on this.

Once a quarter, look at which steps are most often late or skipped. A step that is skipped on 80% of clients is either unnecessary or badly owned, and both are worth fixing.

Closing the loop

Decide what “onboarding complete” means and let the system set it. Typically that is all required tasks done, at which point the client status moves to “Active” and the account lead gets a short note. You now have a real completion date per client, which means you can finally answer how long onboarding takes and whether it is getting faster.

Where to start this week

1. Take the most recent template tab and rewrite each row as a step with an owner role and a due-date offset.
2. Delete any steps nobody has done in the last ten onboardings.
3. Build the templates, steps and tasks records, and run the next new client through the new setup while existing clients finish in their tabs.
4. Create each person’s “my tasks” view and show it to them in a ten-minute walkthrough.