Key takeaways
- Start with a workflow that runs at least weekly, has one person accountable for the result, uses records that already live in your tools, and stalls at a handoff you can point to.
- Client onboarding, delivery handoffs and exception routing usually pass the five tests. Rare work, contested rules and decisions about people are better left for later.
- Reversibility decides how much review the first install needs: a wrong output should be catchable before it reaches a client or affects an employee.
- Record four numbers for two to four weeks before any build starts: runs, time from trigger to done, handoffs, and rework rate.
- The first workflow ends with a written acceptance test covering the real cases, the expected output for each, the approvals that stay with people, and what happens when something fails.
Which five tests should a candidate workflow pass?
Most first projects are picked because a demo looked impressive or because one person shouts loudest. Neither predicts whether the system will still be running six months later. A better filter is five plain tests that any operations lead can answer in an hour.
- Frequency: the workflow runs at least weekly, so a working system pays back often and problems surface quickly.
- Ownership: one named person is accountable for the result and can decide what "done" means.
- Records: the inputs and outputs already exist in systems such as the CRM, the project tool, shared drives or email, not only in someone's head.
- Handoff pain: there is a visible delay, re-ask or rework point where work passes between people or tools.
- Reversibility: a wrong output can be caught and corrected before it reaches a client or affects an employee.
What does a scored shortlist look like?
The table below scores five common candidates in a services firm of 10 to 250 people. It is illustrative. Your own scores depend on how the work actually runs today, which is why the map comes before the build.
| Workflow | Weekly or more | One owner | Records exist | Clear handoff pain | Easy to reverse | Verdict |
|---|---|---|---|---|---|---|
| Client onboarding | Yes | Yes | Yes | Yes | Yes | Strong first candidate |
| Delivery handoff from sales to project team | Yes | Usually | Yes | Yes | Yes | Strong first candidate |
| Monthly client reporting pack | No | Yes | Yes | Sometimes | Yes | Good second project |
| Proposal drafting | Yes | Often unclear | Partly | Sometimes | Yes | Only with a named owner |
| Assigning work by staff performance | Yes | Yes | Yes | Yes | No | Not first: regulated area in the EU |
Why does client onboarding usually qualify?
Onboarding happens with every new contract and crosses sales, delivery and finance. The records already exist: the signed agreement, the CRM deal, the kickoff notes and the access requests. The failure modes are familiar to anyone who has run a services firm: details agreed in the sales process do not reach the delivery team, access requests go out late, and the client is asked the same questions twice.
Those failures are visible to the client in the first week, which makes the result easy to judge. A system that collects the required inputs, checks them against the agreement, routes gaps to the right person and confirms readiness before kickoff can be tested case by case.
Which workflows should you leave for later?
Some work looks attractive and still makes a poor first project.
- Rare workflows, such as a quarterly process. You will wait months to learn whether the system works.
- Work where the rule itself is disputed, such as pricing exceptions. Automation freezes an argument that has not been settled.
- Hiring, task allocation based on individual performance, and staff evaluation. Under the EU AI Act these uses are listed as high-risk, and GDPR restricts decisions based solely on automated processing. See the guide on the EU AI Act and internal automation.
- Anything where the only record is one person's memory. Capture the knowledge first, then automate.
What should you measure before you build?
Record four numbers for two to four weeks before any build starts: how many times the workflow runs, how long it takes from trigger to done, how many handoffs or touches it needs, and how often it needs rework or an exception. Without a baseline nobody can say whether the installed system improved anything, and the project is judged on opinion.
What does done mean for the first workflow?
The first workflow should end with a written acceptance test: the real cases the system must handle, the expected output for each, the approvals that stay with people, and what happens when something fails. One workflow, one owner and one written definition of done keep the first project small enough to finish and clear enough to judge.
Frequently asked questions
Should we automate the most time-consuming task first?
Only if it also passes the ownership, records and reversibility tests. A large task with no owner or no records tends to become an open-ended project. A smaller workflow that runs weekly and has clear records is usually the better first install.
How many workflows should the first project cover?
One. A single workflow with a written acceptance test is small enough to finish, measure and hand over. Later workflows reuse the connections, context and controls built for the first.
What if our records are messy?
Messy records are normal. The mapping step shows which fields the workflow actually needs and which sources are trusted. If a required record does not exist anywhere, that gap has to be fixed before automation will help.
Who owns the system after launch?
Someone has to watch errors, renew credentials, adapt to tool changes and handle new exception types. The handover plan names who operates the system, and managed operation and documented handover are both valid outcomes.
What happens when the system gets something wrong?
When a consequential action is uncertain the system creates a visible exception instead of guessing. A queue that waits is cheaper than an automated mistake nobody sees until a customer does.
What if we want to hand the system to our own team?
Ownership, credentials, code, data, documentation, hosting and support responsibility are written into the engagement, so the system keeps running in accounts you own if the relationship ends.
How do we know the installed system improved anything?
Record how many times the workflow runs, how long it takes from trigger to done, how many handoffs it needs, and how often it needs rework, for two to four weeks before any build starts. Without a baseline the project is judged on opinion.
Sources
This article describes operating principles and public sources. It is not a client result. Build Records carry the basis for every Outproduce system claim.