Pick the process that repeats often, follows written rules, costs little when it goes wrong, has its data on hand and has one named owner. Then check it is not work a person must keep. If a candidate fails any of those six tests, leave it for later and pick another.
#Key takeaways
- A good first process repeats often enough that a saving shows up in the numbers.
- Written rules matter more than clever tools, because AI can only follow what the team can describe.
- Start where a mistake is cheap to catch and cheap to fix.
- A first process needs data you already hold and one person who signs off on the output.
- Write down the work AI may not touch before you start, not after the first problem.
#Which process should we automate with AI first?
Start with one process, not a programme. Score each candidate on how often it repeats, how much it varies, what an error costs and whether you hold the data. Then pick the single best one. This is Stennir's working method, not a published benchmark.
Look for work that is repeated often, costly, error-prone and documentable. One-off work is a poor fit: if the work happens twice a year, the saving is too small to notice, however clever the tool.
#How often does the work need to repeat?
Often enough that you can see a change. A task that comes in dozens of times a day gives you a clear before and after. Pick the one with volume.
Volume also gives you a baseline. Count how many items the team handles now, how many need rework and how long a person spends on each. Without that baseline, nobody can say later whether the automation helped. Write the numbers down before anything changes.
#Does the process follow rules we can write down?
If two experienced people in your team handle the same item differently, the process is not ready. Variability is the first thing to score, and work you can document is the second.
A quick test helps. Ask one person to explain the steps to a new hire in a page. If the page needs the phrase "it depends" in every paragraph, tidy the process first. Stennir does this tidying inside AI consulting, before any build starts.
#What does a mistake cost, and who catches it?
Choose a process where a wrong output is cheap to find and cheap to fix. Drafting a first reply, sorting incoming documents or preparing a summary for review all fit. Releasing a payment or answering a regulator does not. Cost of error is a scoring factor in its own right.
Name the person who approves what the AI produces. One person, by name, with the authority to reject it. A review step with no owner turns into a rubber stamp, and the first bad output reaches a customer.
#Do we have the data, and can the AI read it?
Check that the documents, records or emails the process needs already exist and can be reached. Historical data is a scoring factor too. For companies in the UAE and Saudi Arabia, add one question. Are the documents in Arabic, English or both? Arabic and English are fully supported, others on request.
Hosting is a second check. Hosting is flexible: where your rules require, in the country, cloud or system that fits. Settle it with your compliance lead early. The glossary explains the terms.
For the UAE, the federal data protection law, decree-law no. 45 of 2021, is summarised on the UAE government portal; Saudi Arabia has its own personal data protection law, which your compliance lead should confirm applies. This post makes no legal claim. For the risk side of scoring a process, the nist AI risk management framework, published in january 2023, is a neutral reference.
#Which work should we refuse to automate?
Every first-process list needs a second list. Write down what the AI may not touch. Anything that needs judgement about a person, such as hiring decisions, disciplinary action or exceptions to policy, stays with a person. Anything that moves money or goes to a regulator stays with a person too.
We are
Stennir is an AI consulting partner that helps you choose one process, set the limits and measure the result against your own baseline.
We aren't
Stennir is not a tool vendor that scores your processes with a fixed formula and then sells you the tool that fits the score.
For a worked view by team, see AI for operations. If the process turns out to be a good fit, the build is AI implementation, where you pay for finished work.
#What should an operations lead do next?
List five to ten candidate processes. Score each on the six tests in this post and keep the best one. Then write down the owner, the baseline and the work the AI may not touch. Stennir's AI consulting service helps with exactly this step, and the readiness assessment is a free way to start on your own. When you want a second view, book a 30-minute call.
#Common questions
What do we need to have documented before we start?
The steps of the process in plain language, the rules for exceptions, a sample of real items with the correct outcome, and the current volume and rework count. One page is enough. If the team cannot write it, the process needs tidying before any AI is added.
Which work should stay with a person?
Decisions about people, such as hiring or discipline, exceptions to policy, anything that moves money, and anything sent to a regulator. The AI can prepare a draft or a summary for these. A named person reads it, decides and signs. The line is written down before the work starts.
Who signs off on what the AI produces?
One named person in the team that owns the process, usually the operations lead or a delegate. They have the authority to reject output and the context to spot an error. A shared inbox or a committee is not an owner. Name the person and the backup.
Does it work when our documents are in Arabic?
Yes. Arabic and English are fully supported, others on request. Test it on a sample of your real documents, including scans and mixed-language pages, before you commit. Quality depends on the document type, so measure it against the correct answers your team already holds.
What could go wrong with a first automation, and how is it caught?
The AI can misread a document, apply a rule to the wrong case or miss an exception. It is caught by a named reviewer, a sample of outputs checked against known answers, and a baseline you wrote down before launch. Problems appear in the numbers early, while the process is still small.
