Key takeaways
- Score candidates on eight factors rather than debating them, because the debate always favors whichever process is most annoying rather than most automatable.
- Two factors are disqualifiers on their own: no named owner, and no permitted access to the data the process runs on.
- A process that mostly needs judgment is a poor first candidate, but the information gathering around that judgment is often a good one.
- Record a baseline for volume, handling time and error rate before you build, or you will have no way to prove the result.
- Scope the winner as one workflow with a defined start, end and exception path, not as a department wide program.
Most automation programs stall at the same point. Leadership agrees that AI should take work off the team, then nobody can agree on which work. Everyone nominates the process that annoys them most, which is rarely the process that is easiest to automate or the one that pays back soonest. A short scoring exercise settles the argument in a couple of afternoons and leaves you with something a finance lead can read.
What makes a process a good first automation candidate?
A process here means a repeatable sequence of steps with a trigger, an output and a person accountable for the result, such as "purchase invoice arrives" through to "invoice approved for payment". Eight factors decide whether it is a sensible place to start.
- Volume. How often does it happen? Daily or weekly work turns small time savings into real capacity. Something that runs four times a year will not repay the effort of automating it.
- Repetition. Do the steps look the same each time? Similar steps with varied inputs are the sweet spot, because that variation is exactly what defeated the rules based automation you probably already tried.
- Rules versus judgment. What share of the work follows a policy you could write down, and what share needs professional judgment? A process that is mostly judgment is a poor first candidate, although the information gathering that surrounds the judgment is often an excellent one.
- Data availability. Does the information the process needs actually exist in a system, or does it live in someone's head and a spreadsheet on their desktop? Missing reference data, such as clean supplier records or product codes, is the most common reason a promising project slows down.
- Systems access. Can the systems involved be read and written through an API or a supported export? An API is the documented way one system lets another read or write its data. Older on premises software may only offer a database connection or a file drop.
- Cost of errors. What happens when the output is wrong, and would anyone notice? Medium consequence work with a natural review point is ideal. Work where a mistake is expensive and invisible should stay with people, with AI limited to preparing information for them.
- A named owner. Is there one person who owns the process and can decide how it should change? Without an owner there is nobody to approve the design, resolve exceptions or defend the change to their team.
- Measurability. Can you count how long the work takes today and how often it goes wrong? If not, you will have no way to show whether the project worked.
How do you score candidates against each other?
Score three to five processes on each factor from 1 to 5, multiply by the weight, and add up. Copy the table below and fill it in with the process owners in the room. The automation priority scorer runs the same method online.
| Factor | The question to ask | Score 1 | Score 5 | Weight |
|---|---|---|---|---|
| Volume | How many times a month does this run? | Under 20 | Several hundred or more | 3 |
| Repetition | How similar is each instance? | Every case is different | Same shape, varied inputs | 3 |
| Rules versus judgment | What share follows written policy? | Mostly professional judgment | Mostly documented rules | 2 |
| Data availability | Is the data the process needs in a system? | Scattered across inboxes and desktops | In the ERP, CRM or document store | 3 |
| Systems access | Can we read and write to those systems? | No API, no export, licensing blocks it | Documented APIs we already use | 3 |
| Cost of errors | What happens when output is wrong? | Expensive and hard to detect | Caught at an existing review step | 2 |
| Named owner | Who owns this process? | Nobody, or a committee | One accountable manager who wants it | 3 |
| Measurability | Can we baseline it in four weeks? | No timestamps, no counts | Timestamps in source systems | 2 |
Two factors act as disqualifiers regardless of the total. If nobody owns the process, stop. If you cannot get permitted access to the data, stop. A high score everywhere else will not survive either gap.
Treat the weighted total as a way to structure the conversation rather than as a verdict. The most useful output is usually the disagreement it exposes, for example when an operations lead scores data availability at 5 and the IT manager scores it at 2. That gap is the thing to resolve before anyone writes a proposal.
Which processes are good first candidates, by department?
The pattern repeats across functions. Intake, checking and routing work well. Negotiation, judgment and relationship work does not. This table is Kastling's view, a judgment about where information arrives unstructured and decisions carry medium consequences, not survey research.
| Department | Strong first candidate | Weak first candidate |
|---|---|---|
| Finance | Supplier invoice capture, coding and matching against purchase orders | Month end close, which is periodic and full of judgment |
| Customer service | Classifying and routing inbound requests, drafting first replies for review | Handling escalations and retention conversations |
| Sales operations | Qualifying inbound inquiries and creating structured CRM records | Pricing approvals and contract negotiation |
| HR | Collecting and checking new starter documents, answering policy questions from approved sources | Performance reviews and grievance handling |
| Operations | Order intake from emailed purchase orders, exception routing | Capacity planning, which changes shape every quarter |
| Procurement | Supplier onboarding document checks and reminder chasing | Supplier selection and commercial terms |
| IT service desk | Ticket classification, routing and standard request fulfillment | Root cause analysis on incidents |
Across departments, the best first candidates sit at the front of a process, where information arrives in an inconsistent format and has to be understood, checked and put somewhere structured before anyone can act.
Which processes are good first candidates, by industry?
This table is also Kastling's view, based on how these workflows are structured rather than on research.
| Industry | Strong first candidate | Usually better left for later |
|---|---|---|
| Retail | Product catalog data checks before listing, order exception triage | Demand forecasting across the full assortment |
| Logistics | Shipping document checks, delivery exception classification and customer updates | Network design and carrier rate negotiation |
| Telecommunications | Service activation handoffs between sales, provisioning and field teams | Field engineer scheduling across a whole region |
| Real estate | Inquiry qualification, leasing application document checks, maintenance request routing | Valuation and investment decisions |
| Fast moving consumer goods | Distributor order validation against price lists and trade terms | Trade promotion strategy and range decisions |
| Professional services | Client onboarding document collection, conflict and completeness checks | Advisory work and any professional sign off |
Which processes should not be automated first?
Saying no early is cheaper than stopping a project at month four. Push a candidate down the list when any of the following is true.
- The process is about to change. A system replacement, a reorganization or a regulatory change in the next two quarters will invalidate whatever you build.
- Three people do it three different ways. Agree the standard path first. Automation encodes one version of the work, and the other versions become exceptions nobody expected.
- The pain is real but the volume is not. A monthly task that everyone hates is a process design problem, not an automation opportunity.
- The output is a judgment call with legal or professional weight. Credit decisions, clinical decisions, legal advice and safety sign offs stay with qualified people. AI can retrieve and summarize the inputs.
- Nobody can name what success looks like. If the only stated goal is "use AI", the project has no finish line.
It also helps to keep the technology choice simple at this stage. Anthropic's engineering guidance recommends "finding the simplest solution possible, and only increasing complexity when needed", and distinguishes workflows, where models and tools follow paths defined in code, from agents, which direct their own process (Anthropic). A first project is almost always the former.
How do you turn the top candidate into a scoped first project?
Winning the scoring exercise is not the same as being ready to build. Six steps turn a candidate into something a partner can quote and a finance team can assess.
- Draw the current process with the people who run it. Every step, every system, every point where work waits. Include what happens when something is wrong, because that path is usually where the time goes.
- Record a baseline. Two to four weeks of volume, handling time, cycle time and error rate. Use system timestamps where they exist and a short time sample where they do not. Value the time at loaded cost rather than base salary: the US Bureau of Labor Statistics reported private industry employer compensation costs averaging $46.89 per hour worked in June 2026, against $32.82 in wages and salaries (BLS). How to calculate the ROI of AI automation covers the method, and your own payroll numbers should replace the national averages.
- Collect real examples. Fifty to a hundred genuine cases, including the messy ones. Scanned documents, incomplete submissions and the odd case everyone remembers. Clean samples produce demos that fail in production.
- Decide the control points. Which steps run automatically, which are prepared for a person to approve, and which never get automated at all. Write it down before anyone builds.
- Confirm access. Named service accounts, API scopes, license tiers and any data that cannot leave a particular environment. This is where projects discover that an integration is not available on the plan the company pays for.
- Agree the measures and the stop conditions. The same metrics as the baseline, plus the result that would cause you to pause or stop.
Illustrative example: Consider a mid sized distributor deciding between three candidates. Purchase order intake scores highest: around 1,800 emailed orders a month, similar structure, clear rules for matching customers and products, data already in the ERP, and an order desk manager who wants the change. Customer complaint handling scores lower because each case is different and much of the work is judgment. Month end reporting scores lowest because it runs twelve times a year. The distributor scopes purchase order intake as one workflow: read the emailed order, match customer and product codes, prepare the ERP entry, send clean orders to a one click check and route unknown product codes or price mismatches to a named person. Baseline recorded over three weeks: 1,800 orders, nine minutes of handling each, around sixty corrections a month.
Keeping the first project narrow also protects the people who will use it. In a study of 5,179 customer support agents, access to a generative AI assistant raised issues resolved per hour by 14 percent on average and by 34 percent for novice and low skilled workers, with minimal impact on the most experienced (NBER). The gains came from supporting people doing the work, which is a more realistic goal for a first project than removing them from it.
Once you have a candidate, how to calculate the ROI of AI automation sets out the business case method, and what AI workflow automation costs to run and what it saves covers the recurring costs. For the broader picture of where AI fits in an operations function, read the practical guide to AI workflow automation.
How Kastling approaches choosing the first process
We start with the work rather than the technology. A discovery call covers the processes on your shortlist, who owns each one and which systems are involved. For AI and operations work, a separately scoped paid audit is common: we interview the people who do the work, review the workflows, systems and data pipelines, and identify where time and money are being lost. Not every project needs one, and a well defined brief can move straight to a proposal.
The proposal sets out scope, dependencies, milestones and how success will be measured before development starts. We connect existing systems rather than replacing them, keep a named person in control of consequential decisions, involve the people who will use the solution, and agree data access and ownership up front. When the scoring says a process is not worth automating yet, that is a useful answer too. Read more about our AI Integration & Automation service.
Automation priority scorer
List up to five processes and see them ranked for automation, with a score, the hours each takes today and the reason for its place.
Questions
How many processes should we score before choosing one?
Three to five is usually enough. Fewer than three and you have no comparison, more than five and the exercise becomes a project of its own. Draw the shortlist from the people who do the work rather than from a management workshop, because they know which steps are genuinely repetitive.
Should we start with the process that costs the most?
Not automatically. The most expensive process is often the most complex, the most political and the hardest to measure, which makes it a poor first project. A smaller process that you can build, measure and prove in a few months usually buys the credibility needed to tackle the expensive one next.
What if the highest scoring process belongs to another department?
Then the sponsor for the project is that department head, not you. Automation changes how a team works, so the owner of the process has to want the change and be willing to put time into testing and rollout. If they will not sponsor it, score the next candidate instead.
Can we automate a process that nobody has documented?
You can, but document it first. Ask the owner to walk through the last twenty instances of the work. If three people handle it three different ways, the automation will encode one of those ways and break the other two, so agreeing the standard path is part of the project rather than a prerequisite you can skip.
What is the best first process to automate with AI?
Look for a frequent, well understood process with medium consequences and one accountable owner. In practice that is often an intake, checking or routing step, such as capturing supplier invoices, classifying inbound requests or reading emailed purchase orders. The most painful process is rarely the right first one, because pain usually signals complexity or politics rather than automatability.