The automation conversation almost always starts in the wrong place. Someone has seen a demo, and the question arrives as "can we use AI for X?" — where X is whatever the demo did.
The better question is: what does this business spend the most time on that a machine could do reliably? Those are rarely the same thing, and the gap between them is where most automation budgets go to die.
Interesting tasks are usually rare, high-judgment and low-volume. Expensive tasks are usually dull, frequent and invisible — the fifteenth time this week someone has typed the same answer, copied a number between two systems, or checked whether a thing arrived.
Here is a way to rank them that survives the enthusiasm.
The four factors
Score each candidate task from 1 to 5 on four axes. The arithmetic is deliberately crude; the point is the conversation it forces.
Frequency — how often does this happen?
Daily beats monthly. Something done forty times a day by three people is worth more attention than a quarterly report everyone complains about.
Score 5 if it happens many times a day. Score 1 if it is monthly or less.
Time — how long does each instance take, end to end?
Include the switching cost. A task that takes four minutes but pulls someone out of focused work costs more than four minutes.
Score 5 for half an hour or more. Score 1 for under a minute.
Cost of being wrong — what happens if the machine gets it wrong?
This is the factor that inverts the ranking, and it is the one most often left out.
Score 5 if a mistake is cheap and instantly visible — a draft someone reads before sending, a suggestion, a classification that a person confirms.
Score 1 if a mistake is expensive, silent, or hard to reverse: money moved, a price quoted, a legal commitment, a message sent to a customer with no review.
Note the direction. High cost of error scores low, because it makes the task a bad first candidate — not a bad candidate forever.
Stability — does the task have rules that hold?
A process that has been the same for two years is automatable. A process that changes with every client, every season, or every manager's preference is not — you will automate a snapshot and spend the next year maintaining a divergence.
Score 5 for a stable, describable procedure. Score 1 for something that is different every time.
The score
Priority = Frequency × Time × Cost-of-being-wrong × Stability
Multiply rather than add. Multiplication means a 1 on any axis drags the whole thing down, which is the correct behavior: a frequent, slow, stable task where errors are catastrophic is not your first automation, however tempting the time saving.
Run it across eight or ten candidates. The ranking is usually uncomfortable, because the top of the list is boring and the thing that started the conversation is somewhere in the middle.
What tends to win
Across the systems we have built, the same shapes keep coming out on top.
Answering the same question. A support inbox where a large share of messages are the same eight questions. High frequency, moderate time, cheap errors if there is a human escape route, and stable because the questions are about your own business.
Moving data between systems that do not talk. An order in one place that has to become a row in another. Frequent, error-prone when done by hand, and completely stable.
Notifying the right person at the right time. Not a new capability — just the removal of someone checking.
Drafting rather than sending. The highest-value category and the most under-used. A draft reply, a draft description, a draft summary, reviewed by a person in seconds instead of written in minutes. The cost of being wrong is near zero because nothing leaves without a human.
The score, worked
An example, using a small clinic with four reception staff. Six candidates went on the list. Here is how they scored.
| Task | Freq | Time | Cost-of-error | Stability | Score |
|---|---|---|---|---|---|
| Answering "are you open / where are you" | 5 | 1 | 5 | 5 | 125 |
| Appointment reminders | 5 | 2 | 4 | 5 | 200 |
| Copying bookings into the accounting sheet | 4 | 3 | 4 | 5 | 240 |
| Drafting replies to new enquiries | 4 | 3 | 5 | 4 | 240 |
| Deciding which specialist a case goes to | 3 | 3 | 1 | 2 | 18 |
| Writing the monthly performance report | 1 | 5 | 3 | 3 | 45 |
Three things fall out of that table, and they are the three things this exercise exists to produce.
The most interesting task scored lowest. Routing a case to the right specialist is the one everybody wanted to talk about, because it is the one that feels like intelligence. It scores 18 — a mistake is expensive and hard to reverse, and the rules are not stable because they depend on judgment that varies by case. It is not a bad candidate forever. It is a bad candidate first.
The winners are dull. Copying bookings into a spreadsheet is nobody's idea of an AI project, and it is not one — it is an integration. That is the correct answer, and recognizing it saves the budget.
Drafting scores as high as the integration. Not sending — drafting. The cost of being wrong is near zero because a human reads every one before it goes, which is what lifts a language-model task to the top of a list otherwise dominated by plumbing.
Run the same table on your own six candidates before you commission anything. It takes an hour and it usually reorders the roadmap.
What should not be first
Three categories, each with a real example of why.
Anything that commits money. A price, a discount, a refund, a deadline. On Nomadeo, an AI sales agent for WhatsApp and Telegram, the rule is explicit: anything that commits the business to money — a price, a discount, a deadline — stops and waits for a person to confirm. We built it that way because the failure that destroys a business is not a wrong answer, it is an authoritative one. That argument is the whole of never let an AI quote a price.
Anything irreversible and unobserved. If the mistake is discovered by a customer rather than by you, the cost of being wrong is not 1, it is 0, and the task should not be on the list yet.
Anything nobody can describe. If two people in your company do the task differently and both are right, you do not have a process, you have judgment. Automating it means choosing one person's version and imposing it, which is a management decision wearing a technology costume.
The cost side nobody quotes
A demo shows the benefit. The proposal shows the build price. Neither shows the three costs that arrive afterwards.
Per-use cost. Every AI call has a price, and at volume it stops being a rounding error. This deserves its own treatment and gets one in AI features have a unit cost.
Maintenance. The process changes, the source system changes its format, the model behind your provider gets replaced. Automation is not a fixed asset; it is a small ongoing obligation.
The escalation tax. Every automated process needs a path back to a person, and that path has a cost: someone has to watch the queue, and the handovers that arrive are by definition the hard cases. Automation does not remove the human; it changes what the human is doing to only-the-difficult-parts, which is more valuable work and also more tiring.
Budget all three or the savings you calculated will not appear.
Start narrower than feels worthwhile
The most reliable pattern we know: pick one intent, automate it completely, measure it, then widen.
One question answered end to end is worth more than a system that half-handles twelve, because it is measurable, its failure modes are visible, and it builds the operational habits — the review queue, the escalation path, the logging — that everything after it will reuse.
Bronjoy's help bot is a good shape to copy. It is trilingual, answers from a knowledge base imported from the product's own documentation, and it is defined as much by what it cannot do as by what it does: it holds no write tools at all. It cannot change anything. It escalates to a person on request, after repeated unhelpful answers, or on error. Billing and account replies are held for human approval.
That is a deliberately small surface, and it is why it works. The narrower version shipped; the broad one would still be in design.
The one-page exercise
Do this with the people who do the work, not only the people who manage it.
- For one week, have each person note every task they do more than twice. No judgment, just the list.
- Collapse duplicates. You will have fifteen to thirty candidates.
- Score each on the four factors, together.
- Multiply. Sort.
- Take the top item and ask the disqualifying question: can we describe this precisely enough that a new employee could do it from the description? If not, it is not ready — write the description first, which is valuable on its own.
- Automate that one. Measure for a month. Then return to the list.
Step 5 is where most candidates fail, and the failure is useful. A process you cannot write down is not blocked by technology.
Our AI integration and automation work starts at $299 and runs one to three weeks, and the process begins with a workflow audit for exactly this reason — the audit usually changes what gets built.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Does this need AI, or just software?
Ask it every time, and be willing to hear "no". A great deal of what gets proposed as an AI project is a form, a scheduled job, an integration, or a notification. Those are cheaper, faster, more reliable and easier to debug. AI earns its place where the input is genuinely unstructured — language, images, messy documents — and not before.
How do we measure whether it worked?
Decide before you build, and pick something countable: time per case, cases handled without a person, error rate, response time. The trap is measuring the wrong thing — the most common one in support automation is deflection rate, which rewards hiding the exit. We explain why in the deflection arithmetic.
What if our processes are not documented at all?
Then the documentation is the first project, and it is worth doing even if you never automate anything. Every process worth automating has to be written down first, and writing it down routinely reveals that two people do it differently — which is a finding worth more than the automation.
Should we start with customer-facing or internal automation?
Internal, almost always. The cost of being wrong is lower, the feedback is faster and more honest, and your team will tell you what is broken in a way customers will not. Get the operational habits right where mistakes are cheap.
How long before it pays for itself?
If you cannot sketch the answer on one page before starting, the project is not ready. Take the frequency, the time saved per instance and the loaded cost of the person doing it, and set that against the build plus a year of per-use cost and maintenance. If the answer is close, do the smaller version first.
