Workflow automation · not an app

A signed proposal goes in. A fully set-up client comes out.

Most of the work on this site is software you open. This one is different: nobody opens it. A professional services firm was setting up every new client by hand across five systems - the accounting file, the practice management record, the shared address book, the folder structure, the payment tracker - plus the welcome email and the internal notes. It took a person the better part of an hour, and a missed step was only ever found weeks later. Now a signed proposal starts the run, one person answers one question, and everything else happens on its own.

Built on n8n · 11 stages · 5 systems · 1 human approval

5systems set up per client
1question a human has to answer
11stages, start to summary email
0steps anyone can forget

The workflow

Press run and watch it work.

Every stage below is a real step in the live automation. Click one to see what it does and which system it touches, or press run to send an invented client through the whole thing - including the point where the run stops and waits for a person.

Client onboarding · live workflow

Sample run. Every name, identifier and address in it is invented.

What it does

Two ways in, one path through.

The normal path is hands-off: a signed proposal lands in a watched folder and the run starts itself. When someone is set up another way - a call, a referral, a client adding a second entity - the same workflow serves an intake form and everything downstream is identical. One process, not two that drift apart.

It reads the document

The signed proposal is put through document understanding to pull out the client's details, rather than anyone retyping them. What comes out is validated before it is used.

It works out who this is

Checks the accounting system and the client database first, then generates the client identifier - including the case where an existing client is adding another entity.

It asks when it should

One detail cannot be read reliably off the document. Rather than guess, the run emails a person and pauses until they reply.

It sets up five systems

Accounting customer and receipt, practice-management records and the onboarding job, address book entry, the folder tree with starter documents, and the payment tracker.

It closes the loop

Welcome email to the client, client database updated, meeting-transcript routing switched on, and a summary to the team saying exactly what was created.

It leaves a record

Every run is logged, successes and failures alike, so "did that client get set up?" is a question with an answer.

The software it uses

Nothing was replaced. Everything was connected.

The firm kept every tool it already paid for. The automation is the layer between them - which is usually the cheaper answer than migrating a business onto one platform that does all of it badly.

Orchestration

n8n

Runs the whole workflow, self-hosted. The main flow plus four callable subworkflows for the pieces that deserve to be fixed independently.

Document understanding

Google Document AI

Pulls the text out of the signed proposal so the client's details are read from the document rather than retyped.

Accounting

QuickBooks Online

Customer record created, and a sales receipt raised when a fee was collected with the proposal.

Practice management

Karbon

Client group, organization and contact, the custom fields and client identifier, and the onboarding work item that puts the job in someone's queue.

Files

Google Drive + Apps Script

Builds the client's folder tree, names every folder with the client identifier so they sort, and copies in the starter documents.

Records

Google Sheets

The client database and the run log - the two places anyone looks to answer "is this client set up, and what happened?"

Contacts + mail

Google Contacts, Gmail

Address book entry with the right labels; the approval question, the welcome email and the summary.

Meetings

Fathom

Transcript routing switched on for the new client, so meeting notes file themselves from the first call.

Capabilities

The parts that make it safe to leave running.

Connecting five systems is the easy half. The half that decides whether anyone trusts it is what happens when something is already there, or missing, or wrong.

Check before create, everywhere

Customer, client group, organization, contact, work item - each one is looked up before anything is created. Running the same proposal twice cannot produce two clients.

A pause, not a notification

The approval step genuinely halts the run and resumes on the reply. Nothing downstream happens on a guess, and nothing sits in an inbox being ignored while the setup completes wrongly.

It fails loudly

If the document cannot be read, the run stops and says so instead of writing a half-configured client across five systems for someone to unpick later.

Handles the second entity

An existing client adding another company gets the right identifier rather than colliding with the first one - the case that breaks most naive setups.

Self-healing assignment

Team assignment recovers when a member has been archived, instead of failing the run - a real failure this workflow hit and now absorbs.

Built from the live template

The payment tracker is generated by the maintained engine, not copied from a file that silently goes stale - which is exactly how the earlier version produced trackers with blank names and last year's dates.

Separable pieces

Accounting, practice management, receipts and transcripts are each their own callable workflow. One can be changed or repaired without touching the other four.

Every run logged

A success row per run, a summary email, and a separate branch for errors. The record is the thing that turns an automation from a black box into something you can audit.

Where the time goes

The work did not get faster. It stopped being work.

The saving is not that someone types quicker. It is that a sequence of small, boring, forgettable steps - each one cheap on its own and expensive when missed - stopped needing a person at all.

Before, per new client

  • Read the signed proposal and retype the details
  • Create the customer in the accounting system
  • Raise a receipt if a fee was collected
  • Create the practice-management records and the onboarding job
  • Add the contact and label it
  • Build the folder tree and copy in the starter documents
  • Make this year's payment tracker from a template
  • Send the welcome email
  • Update the client database, and remember the client identifier convention

After

  • The proposal lands in a folder
  • One person answers one question by email
  • Everything above happens, in order, unattended
  • A summary email says what was created
  • The run is logged whether it worked or not

The second-order saving is bigger than the first. Nothing is half-done, so nobody spends an afternoon three weeks later working out why a client has a folder but no work item - and every client is set up the same way, which is what makes the rest of the firm's automation possible at all.

How it was built

One flow, four subworkflows, and a lot of edge cases.

The shape is simple and the value is in the exceptions. Most of the build was the second half of each step: what happens when it already exists, when a person has left, when the document is unreadable, when the client is not new after all.

Self-hosted orchestration

n8n on the firm's own infrastructure rather than a per-task SaaS, so the run cost does not scale with the number of clients.

Subworkflows, not one giant canvas

The accounting, practice-management, receipt and transcript pieces are callable workflows with their own inputs and outputs.

Idempotent by construction

The check-then-create pattern is used at every object rather than bolted on afterwards, which is what makes a re-run safe.

Errors go somewhere

A dedicated failure path and a shared error handler, so a broken run reaches a person instead of disappearing.

Documented and revisable

The workflow, its subworkflows and the folder script are committed with their history, so a change can be reviewed and reverted like any other code.

Built to be handed over

Nothing here depends on the person who built it. Another developer can open the flow, read the stages, and change one without breaking the others.

What happens in your business every time a client signs?

If the answer is a checklist someone works through - and occasionally doesn't - that is usually a few days of work to remove permanently. Worth an hour to map it.

Book a call with David