Every business
Automate a recurring business process so it runs without you
Onboarding, month end close, dunning, weekly reporting, follow-ups. The system executes the process on schedule and flags only the exceptions. You spend your attention on the two decisions that were actually decisions.
Why recurring work still eats a person every month
Every company has a handful of processes that come back on a fixed rhythm. The month end close. The onboarding of a new client. The dunning run on Tuesdays and Thursdays. The weekly report at seven on Monday. Following up on an open offer at day three, day seven and day fourteen.
None of these are difficult. That is exactly the problem. They are long, they are shallow, and they consist of thirty small steps that each take four minutes and each require a person to be looking. The work is not skilled, but it cannot be skipped, and it cannot be half done. So it lands on whoever is reliable, which usually means whoever is most expensive.
The second problem is that the process lives in one head. There is a document somewhere, written two years ago, that describes the version of the process that existed then. The real process is the one the person does, including the four workarounds they never wrote down. When they are on holiday, the close takes twice as long. When they leave, it takes a quarter to rebuild.
And nobody sees the process while it runs. You find out on the fifth of the month that a step was missed on the second. There is no log, because the log would have been another manual step.
- The month end close blocks a day and a half of someone's time and always lands in the same week as everything else.
- The written procedure and the actual procedure drifted apart a long time ago, and only one of them is in a folder.
- Steps get skipped when the person doing them is busy, and the skip is discovered weeks later.
- Data is pulled out of one system by hand and typed into another, every single time, in the same order.
- Follow-ups happen when someone remembers, so some clients get three and some get none.
- When the person who owns the process is away, the process is away.
- There is no record of what ran, when it ran and what it produced, so a question about last quarter is an afternoon of reconstruction.
How process automation works when the system executes the steps
The system is not a reminder and not a checklist. It runs the process on schedule, does each step in your systems, and stops where a step is genuinely ambiguous. Everything unambiguous runs unattended. Everything unclear becomes an exception with a name, a number and a suggested next move.
- 01
The process is written down properly, once
The build starts by capturing what actually happens, in order: trigger, steps, owner per step, the data each step needs and where it comes from. Most of the value shows up here, before any automation exists, because this is usually the first time the real process has ever been on one page.
- 02
The trigger is the process, not a person
A date, an event, a signature, an inbound file. The run starts because the condition is met. Nobody has to notice that it is the first of the month, and nobody has to be at their desk at five in the morning for the close to be finished by half past five.
- 03
Each step is executed in your systems
Bank transactions pulled, receipts matched, invoices reconciled, project hours read from time tracking, margins calculated, the report built, the previous month archived, the accountant export produced. The system reads and writes in the tools you already run. There is no copying between windows because there is no window.
- 04
Exceptions are raised, not resolved by guessing
Fifteen bookings without a receipt does not become fifteen bookings assigned to a plausible account. It becomes one exception with the list attached and the pattern named. A project below its target margin is reported with the reason from the time tracking data, not smoothed into the average. The system says what it found and stops.
- 05
Money and commitments always go to a person
Anything that pays, promises, publishes or commits the business is a human decision by design. The system prepares it completely so the decision takes a minute instead of an hour, and then it waits. This rule does not have exceptions, because a rule with exceptions is not a rule you can trust unattended.
- 06
Every run leaves a log
Timestamp, step, result, exception. You can see what ran this morning and what ran in March. When someone asks why a figure looks the way it does, the answer is a line in a log rather than a reconstruction from memory.
- 07
You see the exceptions, not the runs
Over a month a process might run hundreds of times. The ones that ran clean do not need you. What reaches you is the short list of things that were genuinely unclear, with enough context attached to decide immediately.
Take this with you
Free prompt: turn a process you only describe verbally into a runbook
Describe a recurring process the way you would explain it to a new colleague, in loose sentences, and this prompt turns it into a runbook: trigger, numbered steps with an owner each, the data every step needs, and above all the exceptions. It forces you to say what happens when a value is missing or two answers are possible, and it marks the points where a human has to decide. Works in any capable chat assistant.
You are an operations engineer. Below I describe a recurring process in my company in loose, informal language. Turn it into a runbook that a new colleague could execute on their first day without asking me anything. RULES 1. Start with the TRIGGER. State exactly what causes this process to start: a date, an event, an incoming document, a signature. If my description does not say, write "TRIGGER UNCLEAR" and ask the one question that would settle it. 2. Break the process into numbered steps. One action per step. If a step contains the word "and", it is probably two steps. 3. For every step give exactly these four lines: DOES: the action, in the imperative. OWNER: the role that performs it, not a person's name. NEEDS: the specific data or documents required, and the system each one comes from. DONE WHEN: the observable condition that proves the step finished. 4. Then, for every step, add the line that matters most: IF UNCLEAR: what happens when a required value is missing, when two answers are possible, or when the data contradicts itself. Never write "use your judgement". Write who is told, what they are told, and whether the process pauses or continues. 5. Mark every step that touches money, an external promise, a published statement or a legal commitment with [HUMAN DECIDES]. These are never automated away, regardless of how obvious they look. 6. Do not invent steps I did not describe. If my description has a gap, do not fill it. Collect the gaps in a section OPEN QUESTIONS at the end, phrased so I can answer each in one sentence. 7. End with a section FRAGILE POINTS: the three steps most likely to fail silently, and how someone would notice. 8. Plain language. No consulting vocabulary. OUTPUT - Process name, trigger, rhythm, and roughly how long a full run takes today. - The numbered steps in the format above. - OPEN QUESTIONS. - FRAGILE POINTS. MY DESCRIPTION OF THE PROCESS: [DESCRIBE THE PROCESS AS YOU WOULD EXPLAIN IT OUT LOUD. RAMBLE. INCLUDE THE WORKAROUNDS AND THE "EXCEPT WHEN" PARTS. THEY ARE THE IMPORTANT BITS.]
- Describe the process out loud first, then paste the transcript or your rough notes into the last block. Do not tidy it up. The messy parts carry the exceptions.
- Read OPEN QUESTIONS before anything else. That list is the part of the process that currently only exists in one person's head.
- Give the runbook to someone who has never done the process and have them try to follow it. Every place they stop is a step that was underspecified.
- Fix those places and run the prompt again with the corrected description. Two passes usually get you to something usable.
- Keep it where the process is done, not in a documentation folder. A runbook nobody opens is a file, not a process.
The runbook is a document, and documents do not do anything. Someone still has to be there on the first of the month, open the same six systems, pull the same figures, notice the fifteen bookings without a receipt and decide what to do about them. It also starts going out of date the day you write it, because the process will change and the file will not. And it does not log anything: it tells you what should have happened, never what did happen. Written procedures fail in exactly the same way every time, quietly, when the person following them is busy.
Where the runbook stops and the running system starts
A good runbook is worth writing. It makes the process visible, it survives a holiday, and it turns a head full of habits into something a second person can do. What it cannot do is the process.
The built system takes the same runbook and executes it. It starts itself when the trigger fires, reads and writes in your actual systems, performs the steps in order and produces the same output every time, at five in the morning, in a week when everyone is at a conference. The steps that were unambiguous simply happen.
The difference you feel is in the exceptions. Instead of a person working through a process and occasionally hitting something odd, the process works through itself and hands you a short list of things that were genuinely unclear, each with the context needed to decide. Fifteen bookings without receipts arrive as a list with the pattern already identified, not as a discovery you make at eleven at night.
And the system does not quietly improve reality to keep moving. It does not book an entry to a plausible account because the receipt is missing. It does not average a margin into looking normal. If the answer is not clear, it stops and says so, and that is precisely why the runs it completes on its own can be left alone.
- The process starts from its own trigger: a date, an event, a signature, an arriving file.
- Steps are executed inside your existing systems, with no copying between tools by hand.
- Only exceptions reach you, with the data, the pattern and a suggested next step attached.
- Anything involving money, a promise or a public statement is prepared fully and then handed to a person.
- Every run is logged step by step, so last quarter is a query rather than a reconstruction.
- The process no longer depends on one person being present, awake and not on holiday.
- When the process changes, the system changes, so the documentation cannot drift away from what actually runs.
Frequently asked questions
How do I automate a recurring business process end to end?
Start by writing down what actually happens, step by step, including the workarounds nobody documented. Then separate the steps that are unambiguous from the ones that need a judgement call. The unambiguous ones can run unattended on a trigger, in your existing systems. The judgement calls stay with a person, but they get prepared so completely that they take a minute. Most processes turn out to be around ninety percent mechanical.
Can I not just do this with ChatGPT?
For the thinking parts, yes, and the prompt on this page is one of them. A chat window will happily write your runbook. What it will not do is wake up on the first of the month, log into your accounting system, pull the transactions, match the receipts, notice which ones have no receipt and file the export in the right folder. Every one of those steps needs a person sitting in front of the chat window. That person is the thing being removed.
What happens when a step in the process fails or the data is missing?
It becomes an exception. The system does not fill a gap with the most likely value and it does not skip ahead. It records what it was doing, what was missing, and what it found, then routes that to whoever owns the step. Depending on the process, the run either pauses at that point or completes the remaining independent steps and reports the open item. The behaviour is decided when the process is built, not improvised at runtime.
Is it safe to let a system run a financial process like the month end close unattended?
Only under a clear rule, and the rule is that anything committing money or making a promise is a human decision. The system does the gathering, matching, calculating and formatting, which is where the hours are, and then stops in front of the decisions. It also logs every step, so the run can be audited afterwards. Unattended does not mean unaccountable.
Where does the data stay, and who can see it?
In your systems, under your accounts. A process automation reads and writes in the tools you already run, so bank data, client records and internal reports do not need to be handed to a third party platform that keeps a copy. Hosting, model choice and how long anything is retained are decided during the build, in writing, rather than assumed.
What does it cost to automate a process, and when is it not worth it?
The cost is a one time build against your real sequence plus running costs, which for most processes come down to model usage and hosting and stay small. It stops being worth it when the process is short, runs rarely, or changes shape every time it runs. A three step process that happens twice a year should stay a checklist, and we will say so.
What if our process changes every few months?
Then the automated version changes with it, which is easier than keeping a written procedure current, because a wrong step in a running system shows up immediately and a wrong step in a document can sit there for a year. Processes that change in structure every single run are a different case: those are not processes yet, and automating them early just freezes the wrong version.
Does this replace the person who currently runs the process?
It replaces the mechanical part of their week, which is usually the part they least want. What is left is the exceptions, and exceptions are the part that needs a human anyway. In practice the person who knew the process best becomes the one who owns the decisions it raises.
Pick the process that comes back every month
Tell us what one of your recurring processes actually looks like, including the parts that live in one person's head. We will tell you which steps could run without anyone, which ones should never run without a person, and whether it is worth building at all.
Apply