Which Business Processes Should You Automate With AI First?
Automate the task that is repeated every week, already written down, and easy to check. That is the whole test. Rank your candidates by hours lost multiplied by how repeatable the task is, then build the top two or three and leave the rest. Elshorafa Co. runs a week audit to find them and a Data Readiness Check on the data behind them, because most failed AI projects failed on thin data, not on the model.
Every business now has a list of things it could automate, and that list is the problem. It is long, everything on it sounds reasonable, and nothing on it is ranked. So the project starts with the most impressive-sounding item, runs into thin data or a process nobody wrote down, and quietly stops. The way out is unglamorous and it works: find the tasks your team actually repeats, rank them by hours lost and repeatability, check the data behind the top two or three, build those, then measure the same tasks again thirty days later. This guide sets out that method, step by step.
Which Processes Are Worth Automating, and Which Are Not?
Business process automation means handing a repeated task to software so a person no longer performs it step by step. AI extends that to tasks involving language, judgement and pattern reading, which older automation could not handle.
A task is worth automating when it passes three tests. It is repeated every week. It is written down, or could be written down in an afternoon. And its output can be checked by someone who will notice when it is wrong. Fail any one of the three and the project consumes more time than it returns.
The third test is the one companies skip. If nobody can tell a good output from a bad one, automation does not save work. It moves the work to the person who now has to verify every result by hand.
| Task type | Automate now | Why |
|---|---|---|
| Weekly reporting pulled from the same sources | Yes | Repeated, written down, and obviously wrong when it is wrong |
| First-draft copy, briefs and summaries | Yes | High volume, a person still edits, and quality is easy to judge |
| Tier one customer replies to known questions | Yes | The answers already exist somewhere, they are simply being retyped |
| Data entry, sorting, tagging and chasing | Yes | Pure repetition with a checkable output |
| Pricing decisions and commercial negotiation | Not yet | Judgement with real money attached and no clean signal to learn from |
| A process three people perform three different ways | Not yet | Fix the process first. Automating chaos gives you faster chaos |
| Anything needing legal or medical sign-off | Not yet | A person still has to own the decision, so the saving is small |
How Do You Rank Them by Payback?
Hours lost multiplied by how repeatable the task is. That is the ranking. Not how advanced it sounds, not what a competitor announced, not which department asked loudest.
Elshorafa Co. runs this as a week audit. We log where the team's hours actually went last week, task by task, then score each task on those two axes. The top two or three become the build list. Everything else waits, and waiting is a decision, not a delay.
- 1.Log one real week, task by task, in hours. Estimates from memory are consistently wrong and consistently flattering.
- 2.Score each task for repeatability. Does it run the same way every time, or does every instance need a fresh decision?
- 3.Multiply hours by repeatability, then sort from the top.
- 4.Cut anything whose output cannot be checked, however high it scored.
- 5.Take the top two or three, and write down what working would look like in numbers before anyone builds.
The highest-scoring task is almost never the most interesting one. It is usually somebody re-typing numbers from one system into another, every Monday, for three hours. Build that first and the rest of the programme earns its budget.
What Breaks When You Automate Too Early?
The data, almost every time. Most failed AI projects did not fail on the model, they failed on what was fed into it. Elshorafa Co. runs a Data Readiness Check before anything is built: what data you already hold, how clean it is, and which of it a tool could actually use.
- The data is thinner than anyone said. It exists, but only for the last four months, or only for one region.
- The data sits in three systems that disagree with each other, so the tool learns the disagreement.
- The process was never written down, so the tool automates one person's version of it and the other two reject the output.
- Nobody agreed what a good output looks like, so there is no way to tell whether it is working.
- Staff quietly revert to the old way, because the new tool is slower on the first attempt and nobody trained them past that point.
Automating a broken process does not fix it. It makes the process fail faster and at greater volume, and it puts your name on the failure. Map the process, agree one version of it, then automate that version.
What Should You Measure Before and After?
The same task, measured the same way, thirty days apart. Take the baseline before the build starts, because after launch nobody remembers what the old number was and everyone remembers it generously.
- Hours spent on the task each week, counted by the people who actually do it
- Rework rate, meaning how often the output has to be corrected before it can be used
- Turnaround time from request to finished output
- Volume handled without adding a person, which is where growth shows up
- Adoption, meaning what share of the team uses the tool as the default route rather than the fallback
If the Hours Did Not Move, Say So
The thirty-day remeasure only has value if a bad result is allowed to be reported. If the hours did not move, the honest response is to say so and change the build, not to redefine the metric until the project looks successful.
This is also the cheapest quality gate available. A build that failed on one task in six weeks costs a fraction of a programme that ran for a year on the assumption that it must be working.
What Does a First Project Look Like?
Small, dated, and measured. A diagnostic of about two weeks, a first tool running four to six weeks after that, then a remeasure at thirty days. Anything larger as a first project is a bet, not a build.
| Stage | Timing | What happens |
|---|---|---|
| Week audit and Data Readiness Check | About 2 weeks | Log the hours, rank the tasks, check the data behind the top candidates, agree the build order |
| Build the first tool | Weeks 3 to 6 | Build against the real process, test the prompts on your own cases, agree what working means in numbers |
| Train and hand over | Weeks 6 to 8 | Sit with the people who will use it, write the AI use policy, hand over the prompt library |
| Remeasure | 30 days after launch | Measure the same task the same way. If the hours did not move, change the build |
Write the Prompts Once, Not Ten Times
Prompt engineering means writing the instructions you give an AI tool so it produces the same good answer every time. Left to individuals, ten people write ten different instructions and get ten different qualities of answer, which is why output quality collapses the moment the enthusiastic person goes on leave.
Write the prompts once, test them against your real cases, and hand the team a library they can run without you. That library is the deliverable that keeps paying after the project closes.
Where Should You Start This Week?
Log one week. That is the whole first action, and it is the one most companies skip on the way to buying a tool.
- 1.Ask each person on the team to log this week in hours, task by task, as it happens rather than from memory.
- 2.Circle every task that appears in more than one person's log. Those are your repeatable candidates.
- 3.For the top three, ask one question: where does the data for this live, and is it current?
- 4.Write down what success would look like in numbers, before anyone shows you a tool.
- 5.Publish a one-page AI use policy covering what staff may put into a public AI tool and what must never leave the company. It costs nothing and prevents the expensive mistake.
Automation moves work, it does not remove people. Companies that buy AI to cut headcount tend to lose the institutional knowledge that made the process work, then discover the tool was relying on it.
- Automate a task only if it is repeated weekly, written down, and its output can be checked
- Rank candidates by hours lost multiplied by repeatability, then build only the top two or three
- Run a Data Readiness Check first. Most failed AI projects failed on thin or scattered data, not on the model
- Never automate a process that three people perform three different ways. Agree one version, then automate it
- Take the baseline before the build and remeasure the same task thirty days after launch
- Write the prompts once and hand over a tested library, so quality does not depend on one enthusiastic person
- Publish a one-page AI use policy before the first tool goes live
This guide follows the process Elshorafa Co. applies in AI and process optimisation engagements: the week audit to rank tasks by hours lost and repeatability, the Data Readiness Check on the data behind the top candidates, a scoped build with prompts tested on the client's own cases, and a remeasure of the same tasks thirty days after launch. No client-specific results are estimated or extrapolated.
