People
Checklist before you automate a process
Tobiloba Odejinmi · 15 Jan 2026 · 6 min · 986 words
Direct answer
Do not automate a process you cannot write down, count, and staff with a named owner. Before I build, I want the steps on one page, a week of real volume, the exceptions a person must still see, the tools we can actually reach, and a clear risk call on money, people, and regulators. If those boxes are empty, the honest move is to wait.
- If the steps need a meeting to exist, the process is not ready.
- Count a real week. Hopes are not volume.
- Exceptions need an owner before go-live, not after the first miss.
- Risk is a yes/no on money, hiring, health, and legal promises.
Can you write the steps without a meeting?
I start with a page, not a workshop. Trigger, inputs, the three or four steps a person does with their hands, the output, and the cases they already send to someone else. If that page will not come out of one owner’s head, we are not choosing tools. We are discovering that there is no process yet.
This is the same test I use for APIs. If another team cannot use the door before lunch, the door is not done. If another teammate cannot follow the steps on a Wednesday without calling you, the process is not done. Automating it will only make the fog faster.
Volume and sameness
Count a real week. How many times the work happens. How many of those are the same three shapes. How many are snowflakes. I want the snowflakes written down, not waved away as “edge cases.” Edge cases are the job if they are 40 percent of the pile.
Sameness is what makes an AI employee worth a week of build. Unique art every time is a person. At Zeeh the integrations that stuck were the ones other companies could repeat. The same is true inside a company. If every ticket is a new species, you need a better intake, not a model.
Exceptions and who sees them
List the cases a person must still see. Refunds over a limit. A candidate who worked here before. A clinic that is already in arrears. A customer who mentioned a lawyer. If that list is empty, you have not looked. If that list has no names next to it, you have looked and then refused the staffing part.
Escalation-as-state belongs on this checklist. Where does the exception live. Who is on the hook. What is the clock. I will not accept “we’ll see it in Slack.” Slack is where work goes to become a feeling.
Tools and data you already have
Write the systems of record. Not the systems people mention in a pitch. The ones they actually open. Can we read the ticket. Can we draft without sending. Can we attach the source document. If the answer is a CSV emailed on Fridays, say so. That is a project before it is a workflow.
I will plug into what you already use. I will not add a new religion so the demo looks modern. The checklist item is simple: is there a door a program can use, and is the data the job needs behind that door. Everything else is costume.
Risk: money, people, regulators
Three yes/no questions. Can this move money or make a promise about money. Can this change someone’s job prospects. Can this touch health or a regulated record. A yes does not kill the project. A yes without a reviewer, a log, and a stop condition does.
If the process is hiring, read NYC LL144 and the EU AI Act before you fall in love with a ranking demo. Bias audits, notice, human oversight — those are checklist items, not legal theatre after launch. I would rather lose a week on paper than explain a silent ranking to a candidate’s lawyer.
The one-page go / no-go
If the steps exist, the week is counted, exceptions have names, the tools have doors, and the risk has a reviewer, we can build. If two of those are missing, we fix the process first. That is not caution for its own sake. It is how you avoid a live system that nobody will defend.
IBM’s frontier-firm number is still about 9 percent. Plenty of the other 91 percent have a pilot. Fewer have a page like this. I would rather you keep the pile for another month than automate a fog. The week only works when the process can stand still long enough to be written down.
- Steps on one page, from one owner.
- A counted week of volume and snowflakes.
- Named people on exceptions, with a clock.
- Tools we can reach without a new login.
- A risk call: money, hiring, health, legal language.
- A stop condition written before go-live.
Questions people ask
What is the first thing to check before automating?
Whether someone can write the steps without a workshop. If the process only lives in one person’s head, you will automate their folklore and then argue about the output.
How much volume is enough?
Enough that a person is tired of it, and enough that you can measure a week. A task that happens twice a month is usually a checklist, not an AI employee.
What if our process is messy?
Most of them are. Messy is fine if the mess is visible. Hidden mess — unofficial spreadsheets, side inboxes, “ask Kemi” — has to be on the page first.
When should we not automate?
When you cannot name an owner, when the data is not there, when the action can harm a person and no reviewer exists, or when you are using the project to avoid fixing the process.
Do we need clean data first?
You need the fields the job actually uses, in a place a system can read. You do not need a lake. You do need to stop pretending a shared drive of unmarked PDFs is a knowledge base.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
