The assistant runs the task manually for two to three weeks, documents each step, automates the parts that never vary, keeps a human check on the exceptions, and hands you the documentation.
Automation projects usually fail for one of two reasons. Either nobody understood the process well enough to encode it, or the person who built it left and took the knowledge with them. Both are avoidable.
The assistant runs the task manually and writes down every step, including the awkward ones nobody documents: the exception on Fridays, the supplier who always sends a PDF, the approval that exists only in someone's head.
Copying a value from one system to another never needs a person. Deciding whether an invoice is disputed does. Draw the line clearly and the automation gets simple.
Whatever gets built lives in software you own and pay for. No agency-owned black box, no credentials you cannot reach. If the engagement ends, the automation keeps running.
One working automation earns the right to the next. The assistant reports the time saved, fixes what breaks, and moves to the next process on the list rather than trying to boil the ocean on day one.
A first automation should take about two weeks of part-time attention, not a quarter. The sequence matters more than the tooling, and skipping the mapping stage is what turns a two week build into a three month project.
Every automation eventually breaks, usually because something upstream changed quietly. The workflows that survive are the ones designed with that assumption from the start.
That means logging what ran and what did not, surfacing exceptions to a person rather than swallowing them, and failing loudly enough that someone notices the same day rather than at month end.
Everything is built in your accounts, under your credentials, and documented in a place your team can reach. That is not a formality. It is the difference between an asset you own and a dependency you rent.
A proper handover includes the process map, the workflow itself, the standard operating procedure, and a short note on the decisions taken during the build and why.
The instinct is to start with the most painful process, which is usually the wrong choice. Painful processes are painful because they are complex, politically owned, or full of exceptions, and none of those characteristics suit a first build.
Pick something high frequency, low variation and forgiving of error. Weekly reporting, document filing, data transfer between two systems, or the routine part of a request intake process. The aim of the first build is to establish the pattern: how you map, where checkpoints go, how documentation is written, who owns the result.
Set a two week timebox and treat it as a real constraint. If the workflow cannot be built and run in parallel within a fortnight, the scope was too broad and should be cut rather than extended. A narrow automation running reliably is worth considerably more than an ambitious one that never leaves testing.
Once that first build is live and documented, the second becomes markedly easier. Access exists, conventions exist, and the business has seen that automation here looks like a small reliable improvement rather than a technology project.
How long before the first automation is live? Typically three to five weeks. The first few weeks are spent running the process manually so the automation reflects reality rather than an assumption.
Which automation tools do you use? Whatever fits the stack you already run, commonly n8n, Zapier or Make alongside native automations in your CRM and workspace tools.
What happens to the automations if we stop working together? You keep them. They are built in your accounts and documented, so another person can maintain them.
More insights | Alvara Partners