Automation playbook
How we decide what to automate first, how we map a process without annoying the people who run it, and the rules that keep automations trustworthy.
Finding the first one
The best first automation is frequent, boring, well understood, and owned by someone who wants it gone. Score candidates on four questions:
- How often does it happen, and how long does it take each time?
- How often does it go wrong, and what does a mistake cost?
- Does the same person do it the same way every time?
- Will that person sit with us for an hour and show us?
Pick the highest score that passes question 4. Do not start with the most complex process; start with the one that will be visibly gone in two weeks. Trust comes from that.
Mapping it
We watch it being done, once, on a screen share. We write it down as steps, inputs, outputs, decisions and exceptions, and we send that back for correction. The exceptions list is the real spec: the automation is the happy path plus a plan for every exception, where "ask a human" is a perfectly good plan.
Rules for trustworthy automations
- Every run is visible. A log a non-engineer can read: when it ran, what it did, what it skipped, what it asked about.
- Failures are loud. A failed run notifies a named person in the channel they read. Silence means success and nothing else.
- Humans in the loop where judgement lives. Approvals, unusual amounts, new counterparties, anything irreversible.
- Idempotent by construction. Running it twice does not do the thing twice.
- Resumable. A failure at step six continues from step six, not from step one.
- Reversible where possible. Drafts before sends, staging tables before writes, soft deletes.
- Owned. Someone on your side knows it exists, knows how to pause it, and knows who to call.
Browser automation
When a system has no API, we drive its interface. We write these to locate things by meaning (labels, roles) rather than pixel positions, to take a screenshot on every failure, and to stop and tell someone rather than guess when the page looks different. They are a last resort and we say so, and we keep a list of which systems should be replaced for that reason.
Documents in, data out
Scans, PDFs and spreadsheets are read with a combination of structural parsing and language models with a schema. Every extracted field carries a confidence; below a threshold it goes to a review screen that shows the source next to the field. Review corrections feed the evaluation set, so the threshold can move down over time with evidence.