Automate the first handover
Client onboarding automation: what to automate and what still needs a conversation
Client onboarding automation moves an agreed new engagement into the systems and tasks needed to begin work. Automate stable handovers after the agreement and first deliverable are clear. The downloadable sample demonstrates those checks, an approval boundary and a retry after a failed action.
Automate confirmed information and repeatable handovers; hold unclear scope, missing access and approval decisions for the responsible person.
Begin with an approved engagement
Choose the event that genuinely authorises onboarding. An approved agreement is different from a new lead, a verbal possibility or a contact added to a CRM. Define the evidence for that event and who can supply it.
Confirm the first deliverable, account owner, client approver and information access. The onboarding checklist helps establish those inputs. Software can move the information once it is confirmed; a conversation may still be needed to clarify what the client expects.
Keep non-standard scope visible. A returning client or an unusual engagement may need a different route. Treating every request as the standard package can create a tidy set of tasks for the wrong job.
Run the sample integration locally
Open a terminal in the unzipped example folder and run:
node --version node --test demo.test.mjs node demo.mjs
The sample checks an invented approved engagement and creates three records through an in-memory adapter: a private-folder record, a first-task record and a welcome-message draft. The draft requires human approval.
The printed output shows the records and their client-specific action keys. The example does not create a real folder, update a CRM or send an email. Those integrations belong in an adapter connected to your actual systems.
The seven tests cover the normal route, unapproved agreements, missing first-job inputs, unconfirmed access or unusual scope, repeated events, partial failure and separate client keys. Inspect the tests to see what each result should be.
Follow the checks before the actions
Software
Receive the event
Identify the client, event and account owner.
Software
Check confirmed inputs
Require approved agreement, first deliverable, approver, access and standard scope.
Account owner
Hold exceptions
Resolve missing information or non-standard scope before continuing.
Integration adapter
Create the records
Use stable action keys for a private folder, first task and welcome draft.
Person
Approve the outgoing message
Review the welcome draft before any real sending integration is allowed.
The local example stops at creating the draft record. Human approval is a trusted input that a real implementation must obtain from an authenticated person.
Change a field in sampleRequest and run the example again. An unapproved agreement or missing approver should produce a held result with no actions. This is a useful first check before connecting a tool that can change real records.
Connect real systems through a tested adapter
The adapter is the small part that translates a planned action into your system’s supported API call. Check its permissions, field mapping and client identity in a test environment. Keep credentials outside input records and prompts.
Persist the action keys and completed events. The in-memory adapter loses its state when the program ends, so it is unsuitable for live operation. Check concurrent events, audit records and how agreement changes affect prior approval.
A partial failure test stops after the first action, then retries the job. The sample avoids duplicating that first action because its adapter recognises the same key. A real external service must support an equivalent safe retry or a reliable reconciliation step; adding a key in your code alone cannot guarantee that.
Review the entire handover with the account team. An automation is useful when the right first job begins with the required information, and the team can recover from a missing input or failed system.
Write down the integration and exception routes
Worked example
The sample first content job
Invented teaching example. No client outcome is claimed.
CONFIRMED INPUTS
Client A, an approved agreement, account owner A, reviewed content outline and client contact A as approver.
ACTIONS
Create a private-folder record, first-task record and welcome-message draft.
EXCEPTION
Unconfirmed access holds the job before any records are created.
RETRY
A failed second action leaves the event retryable; the stable action key prevents the first record being duplicated in the sample adapter.
LIMIT
All records and integrations are invented and local. Production concurrency and real API behaviour need separate tests.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.