Guide
Write the rules before you automate
Automation is only as good as the rules it follows. How to turn the way your team already works into rules that are clear enough to hand off, including the most important one: when to stop and ask.
Key takeaways
- Most back-office rules already exist. They just live in people's heads.
- A good rule names the trigger, the check, the action and the person who decides when it doesn't fit.
- The rule that matters most is the one that says when to stop and ask.
- Start strict, then loosen the rules as the work proves itself.
Why rules come first
When automation goes wrong in a back office, it's rarely because the software couldn't do the task. It's because nobody told it what "right" looks like. A person handling supplier bills knows that the cleaning company always invoices on the first of the month, that anything from a new supplier needs the director's eye, and that the coffee order never needs approval. None of that is written down.
Writing it down is the work that makes everything after it simple. It also tends to fix things on its own: two people often turn out to follow two different rules for the same task.
Start from what already happens
Don't design the process you wish you had. Sit with whoever does the work today and write down what they actually do, step by step, for one task. Ask the same questions each time.
- What starts it? An email, a date, a form, a message.
- What do you check before you act? Which system, which numbers, which document.
- What do you do when it checks out?
- What makes you stop and ask someone? Who do you ask?
- Where do you record that it's done?
What a good rule looks like
A rule you can hand off has four parts: a trigger, a check, an action and an exception. "When a supplier bill arrives, check the supplier is known and the amount matches the purchase order; if so, record it against the right account; if not, send it to the finance lead with the difference shown."
Compare that with "process supplier bills". The second is a job title. The first is something anyone, or anything, can do the same way every time, and that you can check afterwards.
Good rules use numbers and names rather than adjectives. "Large amounts" is a judgement call. "Over €2,000" isn't. "Ask the manager" is vague when there are four managers. "Ask the person's line manager in the HR system" isn't.
The most important rule: when to stop
Every task needs a clear point where the work stops and a person decides. This is what keeps automation safe, and it's where most of the value of writing rules sits. The usual places to draw the line are the same in almost every company.
- Someone new: a supplier, employee or customer it hasn't seen before
- Big amounts: anything above a threshold you set
- Bank details that change: always checked with a person, by a known phone number
- Anything personal: pay, health, performance and disciplinary matters
- Anything that doesn't match: a document that disagrees with the record
Who approves what
Write the approvals as a short table: what kind of decision, up to what amount, and who signs it off. Keep it to the decisions that actually come up. A table with five lines that people use beats a policy with fifty that nobody reads.
This is also where you separate preparing from doing. OFFHOURS, for example, prepares payments but never sends money: the payment waits in your bank for your own people to approve it. Writing that line down early saves a lot of conversations later.
Start strict, then loosen
The first version of your rules should send more to a person than it needs to. That's fine. After a few weeks you'll see which exceptions are always approved without changes, and you can turn those into rules. The new supplier who's now invoiced six times is no longer new. The monthly software bill that never changes can go through on its own.
This is how an OFFHOURS role starts work. In its first days it works on probation: every output is reviewed, and the rules are tightened wherever it hesitated or a person would have decided differently. Only then does it work around the clock, supervised by our engineers, with every action logged and able to be undone.
A one-page template
For each recurring task, one page is enough. If you can fill it in, the task is ready to hand off.
- Task: what it is, in one line
- Trigger: what starts it, and how often
- Systems: where the information comes from and where the result goes
- Checks: what must be true before acting
- Action: what to do when the checks pass
- Stop and ask: the cases that go to a person, and which person
- Record: where the work is logged, so anyone can see what happened and why
