Client onboarding and document automation.

The same document could arrive by email and by WhatsApp, and nothing anywhere knew that. The clearest instance of it: the same WhatsApp document arrived twice, two seconds apart, and got processed twice.

That is the whole shape of the problem. Not a hard task done badly, but a set of easy tasks with no shared record of which of them had already happened.

The onboarding path was built first and on its own. The rest arrived because once one process is tracked, the next one being untracked starts to show: trackers kept in step with the calendar, performance and finance figures carried automatically, a support desk over WhatsApp with a daily summary of how long people waited for an answer.

The last group exists only to notice when something has stopped. It is the one I would build first if I were starting again.

A workflow can stop without anyone noticing. The same document can arrive twice, once by email and once by WhatsApp. A sync can run into the write limits of the API underneath it. A document can arrive that no rule and no classifier should be trusted to place. Each of those is handled where it happens rather than discovered later by whoever was waiting for the result.

A Files Registry prevents the same document being processed twice across channels. Writes to the spreadsheet layer are throttled under the API quota, which ended the sync failures that had been losing records earlier in the year.

The reliability layer is not one setting. It is five workflows that run whether or not anyone is watching.

There are four AI steps and they do two different jobs. Two read documents: an image or a PDF arrives and the model says what it is. One turns a sentence a person typed in Slack into structured JSON, so a person can write a sentence instead of filling a form.

The fourth is the interesting one. It is a validator: it takes what the person wrote and what they actually attached, and reports where the two disagree. It does not file anything. Nothing downstream trusts it to be right, only to be worth checking.

It is allowed to read, to suggest and to disagree. What it is not allowed to do is be the last step before something is filed under a client’s name.

Unclear cases go to a person.

More on how I put AI into an operational workflow

Before: a separate inbox, a separate board and a Slack thread across every service line, and somebody had to remember what happened next. Onboarding worked because specific people held it in their heads.

After: the same work runs through one tracked process across every service line. A document arriving by email or by WhatsApp is deduplicated against a shared registry, classified, filed and attached to the right client record. Unclear cases still go to a person, deliberately.

• The historical documents were backfilled out of the old inboxes into the correct client records, so the new process started with the history rather than beside it, and the existing board cards were given an owner.
• The booking and consultant trackers sync on a schedule instead of being cross-referenced by hand.
• All three live trackers are copied to a separate folder every night.
• Writes to the spreadsheet layer are throttled under the API quota, which ended the sync failures that had been losing records earlier in the year.

The part that matters is not that it runs. It is that when it does not run, one error handler catches it, one alert reaches one person, and the work in flight is preserved rather than lost.

The system does not answer anyone. It makes the queue visible, puts the reply one keystroke away, and publishes the number every morning. That is the whole mechanism, and it is worth saying plainly rather than implying that a bot got faster.

Two weeks later the median first reply had gone from ten hours to nine minutes, and the number of customers left waiting more than an hour was zero. The figures are read off the summary tab the system writes for itself, on a rolling seven-day window.

The count of conversations over an hour went up before it went down, from nine to twenty-nine in the first week. That is what making a queue visible does: it finds the queue before it drains it. A version of this page that quietly skipped that row would be describing a different system.

The system reported success while it was throwing client documents away. A size check read the platform's display string, the text "96.4 kB", instead of the byte count. Converting that to a number gives NaN, so the guard failed open and every file whose name had been seen before was counted as a duplicate. Forty customer documents were discarded over five weeks, while every run reported success. Found in a day and fixed the same day; fourteen were recovered out of the platform's own execution history, and the rest were reported as unrecoverable rather than quietly written off. The test that pins it runs the real production code and fails on the old version.

One button press cost five minutes and billed a customer three times. A lookup node sat behind a node emitting a 133-row registry, so a single reaction fired 133 full-table reads and exhausted the read quota on the API underneath. The latency that caused then defeated the workflow's own already-sent guard, and a customer received the same paid message three times. One flag fixed it, and the pattern it belongs to is a written rule now rather than something I remember.

A green test that could not fail. A guard stopping one supplier from claiming another's package was tested against a string that did not contain the words being matched. The test passed by construction, and the bug shipped underneath it. The rule since: a negative test case comes out of production data, never out of imagination.

A test that has never been watched failing is not evidence that the thing it guards works. It is evidence that the test ran.

What made this system worth keeping is what happens around it: a failure that raises an alert instead of going quiet, a duplicate that is recognised before it is processed, and a document that goes to a person instead of being guessed at.