You have already picked the task. You can name the job, the person who does it, and the hours it eats. From here the work is to automate the steps without turning a simple process into a second job.
The point of the work is to automate a repetitive task, not to install a platform. Most teams start by shopping for a tool. We’d suggest you start with a page of steps, a trigger, and a named person who still owns the cases a rule cannot see. The model, if you need one, comes last.
Write the current steps on one page
Sit with the person who actually does the work and write every step, in order, on a single page. Include the ugly ones. The side spreadsheet. The message they send when a field is blank. The “we just know” check that has never been written down. The copy-paste between two systems that were supposed to talk to each other and never have.
If you cannot get it onto one page, you do not understand it yet. Automating a process you cannot describe is how you ship a workflow that copies the confusion, only faster. The page is the brief. Until it exists, nothing else is worth building.
Name the trigger and the done state
Two sentences, written on that same page: it starts when… it is done when…
“When the invoice PDF lands in that mailbox” is a trigger. “When someone remembers to look” is not. “The client is on the books, the folder is in the shared drive, and the person who needs to know has been told” is a done state. “We have handled it” is not.
If those two sentences are vague, the automation will either fire too often or never quite finish. Be specific enough to test.
Prefer a connection over a robot that clicks
Look at the systems that already hold the data. Accounting, inbox, CRM, shared drive. Most of them already offer an API, an export, or a webhook. Use that.
A robot that clicks through a screen will work until the vendor moves a button. A connection to the same data the person was copying by hand will keep working when the interface changes. We reach for a workflow tool, a small script, or the existing API first. n8n, Make, or a bit of Python are options we actually use. They are not a stack you need to buy. The right one is whichever talks to the systems you already run, without inventing a new place for the data to live.
If the only way in is a person clicking, say so. The honest move is often to wait, or to change the tool, not to paper over it with a clicker.
Automate the happy path only
Most of the volume is the ordinary case. Same fields, same destination, same outcome. Automate that path. Everything else goes to a named person, in a queue they already watch, with enough context to finish the job.
Do not encode every exception on day one. That is how a six-step process becomes a diagram nobody can debug. Name the exceptions, route them, and leave them alone until the happy path has shown you which ones are actually common.
If being wrong is expensive, the person stays on that step. Put a name on the exception path, not a shared inbox. When it skips, that person should see why.
Add a heartbeat before you call it finished
It has to say when it ran, what it did, and what it skipped. A log, a message in the channel the team already uses, a line in a sheet. Something a person can read on a Monday without opening the workflow.
An automation that fails silently is not finished. Build the heartbeat in the same pass as the happy path. Keep it boring: timestamp, count processed, count skipped with a reason, and a link to pick the skip up. If nobody would notice the heartbeat going quiet, it is in the wrong place.
Run it next to the old method, then cut over
For a short window, let both run. The person who used to do the job still does it, and they compare. A week or two is usually enough to see whether the ordinary cases match and whether the exceptions land with the right person.
Then you cut over. Leaving both methods in place is how the old one quietly becomes the real one again. Pick a date, say it out loud, and stop doing it by hand.
On an audio software marketplace we work with, the weekly email used to be a Monday rebuild. The system now assembles it. The check is fifteen minutes. That came from writing the steps, connecting what was already there, and leaving a person on the bits a rule cannot see.
When not to automate yet
Three reasons to wait, even if the task is annoying.
The exception rate is high. If a large share of cases need a judgement call, you are not automating a task. You are trying to build a decision engine you do not have the rules for. Fix the process first, or wait until the ordinary case is actually ordinary.
There is no owner. Someone has to be responsible when it skips a row, when the API changes, when the heartbeat goes quiet. If that person does not exist, do not start. An orphaned workflow is worse than a manual one, because it fails where nobody is looking.
The process is about to change. Automating a workflow you plan to replace next quarter is paying twice. Write the new steps first. Then automate those.
What to do this week
You do not need a new stack. You need one page of steps, a trigger, a done state, a connection to the tools you already have, a happy path, a named person for the rest, and a heartbeat. Then a short parallel run, and a cutover.
That is how you automate the task. If you cannot write the steps, you are not ready, and that is cheaper to learn on a page than inside a workflow that copies the mess. The tools are whatever already holds the data. The model is optional, and late.
