Client onboarding without the inbox archaeology

Client onboarding rarely fails because nobody cares. It fails because the work is scattered: a contract in one thread, an invoice in another, files in a third, and a kickoff date that exists mainly in somebody's head.

This is the pattern we mapped inside a publishing-services operation before turning it into a Runation Sprint shape.

The pressure

A new client saying “yes” started a chain of small jobs:

• prepare the agreement;
• request the right files;
• raise the first invoice;
• collect project information;
• create the internal work packet;
• book the kickoff;
• tell the team what had changed.

Every task was reasonable. The problem was the handoff between them. A good operator could keep the sequence moving, but the process depended too heavily on that operator remembering what came next.

The system map

We designed the workflow around one rule: automation may prepare and route the work, but it must never hide an exception.

The sequence is deliberately plain:

1. A confirmed deal creates one onboarding record.
2. The record holds the client, owner, checklist, dates, and source documents.
3. Templates prepare the agreement, invoice request, and information form.
4. A human checks anything commercially sensitive before it is sent.
5. Completion events move the record forward.
6. Missing items create a dated follow-up task rather than a silent wait.
7. The internal handoff is posted only when the minimum inputs exist.

The useful part is not the number of tools. It is that everybody can see the current state and the next action.

Where the workflow stops

Good automation has brakes.

This onboarding pattern stops for human review when:

• the scope differs from the signed proposal;
• a client requests unusual payment terms;
• the required files contain sensitive data;
• the commercial owner changes the delivery date;
• an automated send fails;
• the client replies with a question rather than completing the expected step.

Those cases are not “edge cases” to be smoothed over. They are the work that needs judgement.

What we would measure

We do not publish illustrative figures as measured results. A live implementation should establish its own baseline and then track:

• elapsed time from signed agreement to ready-to-start;
• number of manual follow-ups;
• missing-input rate at handoff;
• exceptions requiring founder involvement;
• failed sends and retries;
• client questions caused by unclear instructions.

The baseline belongs in the project record before the build starts. The comparison belongs there after the workflow has run long enough to be meaningful.

The first Sprint

A sensible first Sprint would cover one service line, one agreement template, one payment path, one intake form, and one internal handoff. It would not attempt to redesign the entire client journey at once.

That boundary keeps the build testable. It also makes the handover useful: the team learns one reliable pattern, then decides whether it should be extended.

The operator lesson

The strongest onboarding workflow is not the one with the most automation. It is the one where a new team member can answer three questions without asking the founder:

1. What has happened?
2. What is waiting?
3. Who owns the next decision?

If your onboarding process cannot answer those questions, a 20-minute audit is enough to map the first fix.