Most automation goes wrong at the choosing.
When an automation project goes badly in a school, the build usually takes the blame. The tool was clunky. The vendor overpromised. The pilot lost steam.
Look closer and a different pattern shows up. The process was never a good candidate. It ran twice a year. It depended on a judgment only one person could make. Nobody owned it, or nobody wanted it. The tool did what it was asked to do, and what it was asked to do was the wrong thing.
AI has made the first version of almost anything cheap to build. That makes choosing more important, not less. It is now easy to build the wrong thing quickly.
This paper is a way to choose. It is seven questions, a rule for scoring them, and six worked examples. It takes about ten minutes to apply to a process, and it is designed to say no as readily as yes. That is deliberate. A filter that always approves is not a filter.
Find the queue, not the complaint.
Before the seven questions, a word on where to point them. The instinct is to start with whatever feels slowest. Resist it. Perceived slowness tracks effort and irritation, and the loudest step is often a fast person working very hard.
The better guide is simple: every system has a bottleneck, and work waits in front of it. Three rules follow, and they apply to an office as well as a factory.
- Automate where work waits, not where it feels slow. Look for the pile, the backlog, the thing that is always “in progress.”
- Check which side of the constraint you are on. Speeding up a step before the bottleneck deepens the pile. It does not help.
- If the constraint is a person, do not make them faster. Take work off them.
Once you have a short list of places where work waits, the seven questions tell you which of them are worth building anything for.
Seven questions.
Answer each one yes, not sure, or no, about one process at a time. Four of the questions are gates: a “no” on any of them means the process is not ready, however strong the rest looks.
Frequent Gate
Does this happen at least monthly, often enough that the time adds up?
Automation has a fixed cost. Someone builds it, checks it, and keeps it running. That cost only pays back across repetitions. A process that runs once a year is usually better served by a good checklist and a calendar reminder.
Rule-bound Gate
Could you write the rules down so two different people would reach the same answer?
Automation applies rules. Where the outcome depends on judgment, relationships, or context only one person has, a tool either gets it wrong or quietly turns one person’s judgment into policy. Try it: give two staff the same case and the written rules. Where they would land differently, that is judgment. Keep a person there, and automate only the preparation around it.
Already instrumented
Is there already a record of it (a system, a sheet, a log) that someone could read without asking anyone?
Automation needs something to read. If the only record of a process lives in someone’s head or inbox, the first job is not automation. It is keeping a record.
Has a wanting owner Gate
Is there a named person who wants this to get easier and would actually use the new way?
Tools without an owner become shelfware. The owner is not whoever approved the project. It is the person who feels this pain every week and will notice the day it gets better.
Fails visibly
When it goes wrong, does someone notice quickly (a late report, a family complaint, a missed deadline)?
You can only trust an automated process if you can see when it misses. A failure that is silent today stays silent after automation, and now it is also faster.
Moves a named goal
Does it move a goal your organization has already named (a deadline, a target, a renewal measure)?
Work tied to a goal keeps its priority when the year gets busy. Work tied to nothing gets dropped the first week it competes with something urgent.
Has run for real, twice Gate
Has it actually been done, start to finish, at least twice? Not planned, not piloted on paper.
Plans do not get automated. Processes do. You cannot automate what has not happened, and you cannot show it worked without a before. Running it twice by hand also surfaces the exceptions that no plan mentions.
How the verdict works.
Each process ends up with one of three verdicts. The rules are short enough to apply in your head.
No “no” answers, and at most one “not sure.” A strong candidate. Next step: map it, put numbers on it, and get a written recommendation. What a diagnostic is.
One “no” on a non-gate question, or two or more “not sure.” Promising, with open questions. Settle them, then decide whether it is worth building. What a scoping conversation is.
A “no” on any gate, or two “no” answers among the other three. Do not automate this yet.
“Not yet” is a complete answer. It comes with what would change it, and it is often the most useful result on the list. An afternoon that ends with three processes correctly left alone has paid for itself.
Six processes, scored.
These six are invented for illustration and are not drawn from any organization. Your answers will differ, which is the point.
| Process | Freq. | Rules | Record | Owner | Visible | Goal | Ran 2× | Verdict |
|---|---|---|---|---|---|---|---|---|
| Notification letters when a student passes an absence threshold | Y | Y | Y | Y | Y | Y | Y | Ready to map |
| Monthly attendance reconciliation for state reporting | Y | Y | ? | Y | Y | Y | Y | Ready to map |
| Tracking special-education review and reevaluation deadlines | Y | Y | ? | Y | Y | ? | Y | Settle questions first |
| Running the annual enrollment lottery | N | Y | Y | Y | Y | Y | Y | Not yet |
| Deciding how to support a struggling student | Y | N | Y | Y | Y | Y | Y | Not yet |
| A family-survey process planned for next semester | ? | Y | N | Y | ? | Y | N | Not yet |
Three of the six are not ready. They fail in three different ways, and each is worth a closer look.
The one that fails on frequency
The annual enrollment lottery is painful, rule-bound, visible, and owned. It is still not a candidate, because it happens once a year. The cost of building and maintaining a tool would be spread over a single run. A well-made checklist beats a tool here.
The one that fails on rules
Deciding how to support a struggling student scores “yes” everywhere but one place, and that place is the point. Two experienced staff would reasonably disagree. Keep the person. The preparation is a different process: gathering the record and making the pattern visible before the conversation. That one may be a good candidate on its own.
The one that has never run
A survey process that is planned for next semester has no history, no baseline, and no exceptions discovered yet. There is nothing to automate. Run it twice by hand, note what went wrong, and score it again.
A note on the one in the middle
Tracking special-education deadlines gets “settle questions first” because two answers are “not sure,” and both are cheap to settle. It is also a reminder that passing the filter is not the same as being low-risk. A process that touches protected student records needs a second person to check any tool that reads them before that tool is trusted.
Passing is where the work starts.
A process that passes the filter is worth a closer look. It is not yet easy, cheap, or safe. The next steps are the same for every process that passes.
- Map it. Write down who does what, in what order, with what.
- Baseline it. How long does it take now, and how often does it fail? Without a before, you cannot show that anything got better.
- Name the owner and a successor. If the process only works while one person is here, it has not been made durable, only faster.
- Have someone other than the builder run it before it is trusted.
If you take one thing from this paper, take this: pick three to five processes where work waits, score them honestly, and talk to the person who owns each. You will probably find that one or two are worth building for and that the rest are better left alone. Both are good answers.
Try it on your own list