Automate the process that scores highest on four factors: how often it happens, how long it takes each time, how much a mistake costs, and how closely it follows fixed rules. Frequent, slow, error-prone, rule-based work pays back first. Rare or judgment-heavy work should stay manual, or get a checklist instead of a program.
Most of the tools we run started as a chore somebody was tired of. A law firm site needed the same design change on every practice page. Doing it by hand meant sixty edits, each one a chance to miss something. We wrote a template system instead, and now a design change rolls across the site in one run.
That is the rule we work by: if a job is done sixty times, write the program. The harder question is which job to pick first, because most businesses have a dozen candidates and the budget for one or two.
We use a simple score. It needs a pen, a list, and an honest conversation.
How do you decide which process to automate first?
Decide which process to automate first by scoring every candidate on four factors: frequency, time per run, cost of an error, and how rule-based the work is. Add the scores and start with the highest total. The score matters less than the conversation it forces about what the work really involves.
Write down every repeated task that annoys someone. Do not filter yet. Then score each one from 1 to 3 on each factor:
| Factor | Score 1 | Score 2 | Score 3 |
|---|---|---|---|
| Frequency | A few times a year | Weekly | Daily or many times a day |
| Time per run | Under a minute | Several minutes | Long enough to break someone's focus |
| Cost of an error | Mildly annoying | Costs money or rework | Costs a client, a deadline, or trust |
| Rule-based | Needs judgment every time | Mostly rules, some exceptions | Same steps every time |
A total of 10 or more is a strong candidate. A total under 7 usually is not worth a program yet.
What do the four factors mean in practice?
The four factors measure payback and risk. Frequency and time per run tell you how many hours automation returns. Error cost tells you how much a mistake hurts when a tired person makes it. Rule-based tells you whether software can do the job at all without constant supervision.
Frequency. A task done daily repays a program quickly. A task done twice a year almost never does, however painful it is on the day.
Time per run. Count the interruption, not only the minutes. A two minute task that pulls someone out of real work costs more than two minutes.
Error cost. This is the factor people forget. Our Firm Mail Intake tool checks any court date mentioned in an email against the firm's calendar. Reading an email is quick. Missing a hearing is not a small mistake, so that task earns a 3 on error cost however little time it takes.
Rule-based. Software is good at rules and poor at taste. Filling a caption, the parties, and the judge into a court filing is pure rules, which is why the Motion Generator worked. Deciding what the motion should argue is not.
Which processes usually score highest?
The processes that usually score highest are the ones that move the same information from one place to another: filing documents, filling templates, sending routine messages, checking one system against another, and publishing on a schedule. They happen constantly, follow fixed steps, and fail quietly when a person is rushed.
From our own list of tools, these fit the pattern:
- Filing incoming documents. Attachments arrive by email and have to land in the right client folder. Same steps every time, many times a day.
- Assembling documents from data. A template plus case data becomes a finished filing. We cover the mechanics in how document generation software works.
- Checking one record against another. Dates in email against the calendar. Public court records against the last check.
- Publishing on a schedule. Our Content Engine researches, writes, lays out, and publishes a daily article, and a human reviews the output.
None of these involved a new idea. Each one took a task people were already doing correctly, most of the time, and made it happen correctly every time.
Which processes should you not automate?
Do not automate a process that is rare, still changing, or dependent on judgment. A task you have done only twice is not understood well enough to encode. A task whose steps change every month will break the program every month. Work that needs judgment needs a person, possibly with better tools.
A few specific warnings:
- Do not automate a broken process. If the manual version produces bad results, the program will produce bad results faster. Fix the steps first.
- Do not automate the conversation. Software can draft, sort, and remind. The call to an upset customer belongs to a person.
- Do not automate what a checklist would fix. Some tasks score low on frequency and high on error cost. A written checklist is cheaper than code and often enough.
For work that sits in the middle, mostly rules with some judgment, the answer is usually to let software prepare and let a person approve. We describe that pattern in human in the loop AI.
How do you start a first automation project?
Start a first automation project by writing down the manual steps exactly as they are done today, including the exceptions. Then automate the smallest complete version, run it beside the manual process for a while, and compare results before anyone stops doing the work by hand.
- Pick the top scorer from your table.
- Have the person who does the job write out every step and every "unless".
- Decide whether a no-code tool is enough. For simple glue it often is, as we explain in no-code automation vs custom code.
- Build the narrowest version that finishes the job end to end.
- Run it in parallel with the manual process and check its output.
- Only then turn the manual process off, and keep a way to see what the program did.
Step 2 is where projects are won. The written steps almost always reveal an exception nobody mentioned, and it is far cheaper to find it on paper than in production.
Frequently asked questions
How much does it cost to automate a business process?
Cost follows the number of systems involved, the number of exceptions, and how bad a mistake would be. A scheduled script that reads one source and writes one report is small. A tool that reads, decides, files, and alerts across several systems is a real project. Every project is quoted on its own.
Is automation only worth it for large companies?
No. Small teams often gain the most, because one person's hour matters more when there are five people than five hundred. Our mail intake tool serves a single law firm and runs unattended.
Will automation replace my staff?
The tools we have built replace the parts of a job nobody wanted: retyping, filing, refreshing a web page to see if something changed. The people stay and spend their time on work that needs them. Plan for that openly with your team before you build anything.
Should I use AI or ordinary code for automation?
Use ordinary code wherever the rules are fixed, because it is cheaper, faster, and predictable. Use AI for the steps that involve reading or writing natural language, and check its output.
If you have a list of chores and are not sure which one to hand to software, send us the list. We will tell you which one we would build first, and which ones we would leave alone.