Why the question is rarely framed well
The usual question is: can AI do this? The answer is almost always yes, making it useless. The useful question is: does automating this process deliver more than managing it costs, and what happens when the model is wrong? Together, those questions form the framework below.
Question 1 — How often does this occur?
A process recurring twenty times weekly repays setup. One occurring four times annually almost never does: you build something nobody maintains, and by the fourth time its surrounding system has changed.
Frequency is also a quality condition. With twenty cases weekly, you see within a week whether proposals are good. With four yearly, learning anything takes two years.
Question 2 — How fixed are the rules?
This is the most important dividing line, and not the one people expect.
- Completely fixed rules — "invoices above 10,000 euros go to the controller" — do not belong with a model. That is a rule; write it as one. A model applying a threshold is more expensive, slower and less reliable than a comparison.
- No rules, only judgment — "is this client angry?" — is precisely where a model adds something and a person must be able to intervene.
- The mixture describes most real processes: fixed rules with judgment at one or two points. Separate those points. Give the model judgment and keep the rest deterministic. That makes it testable, explainable and cheaper.
Question 3 — What does an error cost?
This determines control level, not technology. For each step, write what happens if the result is wrong and who notices.
- An error is invisible and irreversible — a wrong accounting amount, a sent proposal. Human approval, always.
- An error is visible and easily reversed — a mislabeled task. Automatic execution with every step logged is enough.
- An error directly affects a client. Human approval, even if the model is usually right. "Usually" here is a risk profile, not a quality level.
Question 4 — Is the source somewhere accessible?
A workflow is as good as its input. If the answer is in one colleague's head, an unstructured shared inbox or a system nobody dares grant read access to, you are automating a problem you must first solve. Start by making that source accessible rather than building the surrounding workflow.
When automation is the wrong answer
These cases occur often enough to name explicitly:
- The process is broken. Running a poor method faster makes it harder to fix, not better. Redesign first.
- The process changes quarterly. Then you maintain a workflow instead of saving work.
- Contact is the value. For a complaint, cancellation or difficult conversation, human contact is the product rather than overhead.
- Nobody owns it. A workflow without an owner reviewing exceptions quietly deteriorates until someone turns it off.
The framework in one pass
Run your process list through these four questions and record for each: frequency, which part requires judgment, error cost and source location. High-frequency processes with a small but real judgment component, reversible errors and accessible sources are your first three candidates. The rest come later or never, a valid outcome.