Most organisations have no shortage of candidates for automation. Finance teams re-key invoices, operations teams chase approvals by email, and customer service staff copy details between systems that were never designed to talk to each other. The harder question is where to start. Picking the wrong first project can consume budget, frustrate staff and make the next business case harder to win. This article sets out a practical way to choose a first automation that is valuable, achievable and a sound foundation for what follows.
Start with the work, not the tool
Automation programmes often begin with a platform decision: a robotic process automation licence, a workflow suite or an AI service. It is more useful to begin with a clear inventory of the work itself. Ask each function to list the tasks that are repetitive, rule-based and high in volume, and to describe how those tasks are triggered, what systems they touch and where they tend to go wrong. This exercise surfaces candidates that leadership may not see, and it grounds later tool choices in real requirements rather than vendor demonstrations.
Pay attention to the hidden steps. A process described as ‘approve a purchase order’ may in practice involve checking a spreadsheet, messaging a manager and waiting for a reply before anything is entered in the ERP. These informal steps are where delays and errors accumulate, and they are also where automation can deliver the clearest improvement. Mapping them honestly, including the workarounds people rarely mention, gives you a realistic picture of effort and benefit.
Score candidates on value and feasibility
Once you have a list, score each candidate against a small set of criteria. On the value side, consider volume, time spent per case, the cost of errors, customer impact and compliance exposure. On the feasibility side, consider how stable the rules are, whether the input data is structured, how many systems are involved and whether those systems offer reliable integration points. A simple view of value against feasibility is usually enough to separate the obvious first moves from ambitious ideas that need more groundwork.
The best first project tends to sit in the high-value, high-feasibility group but is not necessarily the single highest-value item. A process that touches a core system of record, crosses several departments and depends on unstructured documents may offer large returns, yet it carries more delivery risk. Choosing something slightly smaller that can go live within a few months builds confidence, proves the operating model and creates reusable components such as integrations, logging and exception handling.
Look for stable, well-understood processes
Automation amplifies whatever process it is applied to. If the process is inconsistent, poorly documented or under active redesign, automating it simply produces inconsistent outcomes faster. Before committing, confirm that the process owner can describe the rules clearly, that exceptions are known and reasonably rare, and that no major policy or system change is planned in the coming year. Where a process is still changing, it is often better to standardise it first and automate it later.
Regional context matters here. Organisations operating across the UAE, Saudi Arabia and Oman may run the same process differently in each country because of local regulation, language requirements or legacy systems. A first automation that works in one entity but cannot be extended elsewhere limits its value. Where possible, choose a process that is already harmonised, or treat harmonisation as an explicit part of the project scope.
Avoid common first-project pitfalls
Several pitfalls recur. The first is automating around a broken integration instead of fixing it, which creates fragile bots that fail whenever a screen changes. The second is neglecting exception handling, leaving staff to discover failed transactions days later. The third is measuring success only by hours saved, when the more important benefits may be accuracy, auditability or faster response to customers. Agree a small set of measures before you start, and capture a baseline so improvement can be demonstrated honestly.
Another pitfall is leaving the people who do the work out of the design. They understand the edge cases, and they will be the ones supervising the automation once it is live. Involve them early, explain how their role will change and give them a clear route to flag problems. Automation that staff trust tends to be used and improved; automation imposed without explanation is often quietly bypassed.
Building from the first win
A successful first project should leave behind more than a single working workflow. Document the governance model, the approach to testing and change control, the monitoring set-up and the criteria used to prioritise. These become the basis of a repeatable pipeline, so the second and third automations are faster and cheaper to deliver. Many organisations find it useful to establish a small centre of excellence at this point, even if it is only a few people, to own standards and the backlog.
A partner such as MomentumX can help run the discovery and scoring exercise, design integrations that suit your existing systems and set up the operating model alongside your own teams. The aim is to keep knowledge and ownership in-house as the programme grows, so that each new automation builds on the foundations and lessons learned from the one before it.
