Client Onboarding

Every practice knows the pattern. The engagement is signed, and then a second process begins: an email asking for ID, a reminder a week later, a form that never comes back, a Direct Debit mandate that takes three attempts. Work cannot start, the file sits open, and someone on your team owns the job of nagging a client who has already said yes.

None of that is a client problem. It is a timing problem. The request arrives days after the decision, when the client has moved on to their own work and your practice is no longer the thing in front of them.

When a client opens the link you sent, everything happens on one page, in one session, without a single extra email:

• Review the proposal and download a copy
• Sign the engagement letter - one signature covers both documents
• Set up a Direct Debit mandate
• Complete identity verification for AML
• Fill in whichever forms you have added to the flow

Each step is optional and configurable. Turn on only what your practice needs, and the client sees a progress bar with your step names on it, so they always know how much is left.

Direct Debit and AML are the obvious ones, but every practice has its own list. Bank details. Payroll starter information. UTRs and National Insurance numbers. Previous accountant details for professional clearance. Shareholders and directors. Whatever you currently email people for in week two.

Build it once as a form, then drop it into the onboarding flow. You can add as many as you like, drag them into the order you want them answered, and give each one a title that appears in the client's progress bar.

Answers land straight on the client record. Because forms map to real fields and custom fields, what the client types becomes client data - not a PDF attachment somebody has to read and re-key. You can review changes before they are applied, or let trusted answers save themselves.

Not every question deserves to block a signature. A form step can be marked as skippable, which gives the client an unobtrusive I'll do this later option. Use it for the long questionnaire that needs them to dig out paperwork, and leave it off for the three fields you genuinely cannot start work without.

Skipping is not the same as losing. Every form in the flow exists as a real request against the client from the moment they accept - so a skipped form is already sitting in your outstanding requests, and already on the chasing schedule.

Identity verification runs as part of the flow through Xama. The client completes their checks immediately after signing, while their passport is still in the drawer next to them rather than on a list of things to find at the weekend.

You choose which onboarding level applies, so a sole trader and a group of corporate shareholders are not put through the same process. Results come back onto the client record, and your reporting reflects a client who is verified rather than one who is pending.

Where verification has already been done - an existing client taking on a new service, say - leave it out for that proposal alone without changing your practice default.

A mandate set up during onboarding is a mandate you never have to ask for again. Direct Debit through GoCardless or Adfin can be part of the flow, so the client authorises payment in the same breath as agreeing the fee.

If client billing is switched on, the services they just signed up for are set to invoice automatically as they are activated. The client is billable the moment they are onboarded, with nobody having to remember to set it up.

While the client is working through their side of it, Sodium is doing yours. Acceptance is not a status change - it is a trigger:

• Every service on the proposal moves from Proposed to Active
• Onboarding tasks are created for each service that has just gone live
• Workflows are attached to those tasks, with every step ready to go
• The service's recurring work starts appearing on your task list
• A one-off acceptance task is raised from a template you nominate, for the checks you want a human to do on every new client
• Signed copies of the proposal and engagement letter are filed to the client's documents
• The client manager, partner and associate are notified - whichever of those you have asked for

By the time anyone on your team opens the client, the work is already laid out. Nobody sets up a new client by hand.

Taking on a payroll client is not the same as taking on a VAT client. So onboarding tasks are defined on the service itself, and only the ones relevant to what the client actually bought get created.

Each onboarding task template carries:

• A due date set as a number of days from the service start date, so deadlines land relative to the client rather than on some fixed calendar
• An owner - a named person, the manager of that service, or a team
• A workflow, materialised onto the task so it opens with its full step list rather than a blank checklist
• A time estimate and checklist, so the job is scoped before anyone starts it

Set this up once per service and every future client who takes it on is onboarded the same way, by whoever happens to be free that week.

The onboarding flow is defined once in your proposal settings: which steps run, which forms are asked, what order they come in, and which of them a client may defer.

Individual clients still differ. Every proposal shows your current defaults and lets you change them for that one client - skip the Direct Debit for the client who pays annually, drop identity verification for the one you verified last year. Your practice default is never touched.

Clients turn up by other routes: an existing client adds a service, a migration brings a hundred of them in at once, or a prospect comes through your sales pipeline.

Onboarding tasks are tied to a service going live, not to the proposal that sold it - so a service added by hand raises the same tasks, with the same workflows, as one that arrived through an acceptance. Pipelines carry their own onboarding task templates too, for the intake work that happens before anyone has signed anything.