A new client has said yes. Someone now needs to collect the right details, confirm what was agreed and make sure the work reaches the right person. That's a useful place for automation, provided the workflow can tell the difference between an accepted proposal and a job that's actually ready to start.
Start by automating the preparation and the handoff. Keep decisions about scope, unusual terms and promised dates with the people responsible for them.
Decide what starts onboarding
“New customer” is often too vague. A contact can exist in your CRM long before they buy anything. An email saying “sounds good” might still leave the price or start date unresolved.
Choose a specific event that the business already recognises. For example, a member of staff marks the agreed proposal as accepted after checking its terms. Record the proposal reference, version, customer and person who confirmed it. If your process also requires a deposit or signed agreement, make that a separate condition rather than quietly assuming it has happened.
This is process design before tool selection. Microsoft's business process guidance describes mapping the existing work before designing the improved process. You don't need a complicated diagram to do that.
Build the smallest useful onboarding record
For a fictional design studio, the onboarding record could contain:
- the accepted proposal and the services included.
- the customer's nominated contact and agreed communication route.
- the information or files still needed.
- the person responsible for the job.
- the agreed next step and its due date.
- any dependency that prevents work from starting.
These are example fields, not a universal list. Ask the people delivering your service which information they repeatedly have to chase. Remove fields that nobody uses. Don't ask customers to submit passwords in an onboarding form. If access is needed, arrange an appropriate invitation or access process separately.
Give the customer one clear request for outstanding information. A form that asks for everything the company could possibly need tends to turn a small handoff into another project.
Separate collected, checked and ready
A completed form proves that someone submitted a form. It doesn't establish that its contents are complete or suitable for the job.
Use a few statuses with clear meanings:
- Waiting for information: the request has been sent and specific items are outstanding.
- Ready for checking: the required items have arrived, but a person still needs to check them.
- Ready for delivery: the agreed checks are complete and a named owner has accepted the handoff.
For the fictional studio, a customer might upload a logo successfully but supply the wrong organisation's brand files. The submission can move to checking without automatically starting design work or telling the customer that production has begun.
Keep a visible exception list for missing, contradictory or unusual information. Each item needs an owner and a next action. Sending the same form request repeatedly doesn't resolve a disagreement about what the customer bought.
Send reminders that match the current situation
Before any reminder, check whether the item is still outstanding, whether someone has replied through another channel and whether a colleague has paused onboarding. Set a limit on reminders and hand overdue cases to a person.
The reminder should say what is missing and how to provide it. It shouldn't invent a deadline, threaten cancellation or promise a start date that the delivery team hasn't agreed.
An internal task can be the better first version. Let the system tell the account owner that two items are overdue, with links to the customer record and original request. You can consider automatic customer reminders once the team trusts the status information.
Test the handoff, including the awkward cases
Use fictional customers to demonstrate an ordinary onboarding, a partly completed form, a changed proposal, a cancelled job and a repeated submission. Check that a repeated event doesn't create a second project or send another welcome message.
Then ask the person receiving the work to begin the fictional job using only the handoff record. If they still need to search several inboxes to understand the scope, the process isn't finished.
Measure the time from acceptance to a checked handoff, the number of jobs waiting without an owner and how often missing information sends work backwards. These tell you more than the number of welcome emails sent.
If you're choosing where to begin, our guide to a first business automation helps compare onboarding with other repeated tasks. For an onboarding project, bring one normal job and one difficult job to the discussion. The useful build is the one that makes both easier to manage.