The short answer
Pick a process that scores high on volume and clarity and low on risk. In practice, a good first candidate has these traits:
- It happens at least weekly.
- Someone currently re-types, copies or chases something.
- The rule can be written in one or two sentences.
- The data it depends on is already reliable.
- A mistake would be noticed quickly and could be undone.
- You can count it today.
A first automation has two jobs. It should save time, and it should teach your team how to run automation safely. A small, clear process does both. A large, critical one puts the lesson and the risk in the same place.
A short selection method
- List candidates. Ask the people who do the work what they repeat every week. Aim for five to ten items.
- Remove the unsafe ones. Strike anything that is irreversible, safety-related or legally sensitive. These can come later, with controls.
- Score the rest using the nine factors below.
- Check the top two against the question of whether the process should be fixed first.
- Pilot one for 30 days against a baseline.
The nine scoring factors
Score each candidate from 1 to 5 on every factor. For the first five, a higher score means a stronger candidate. For the last four, the scale is written so that a higher score is also better.
| Factor | What to ask | Score 1 | Score 5 |
|---|---|---|---|
| Frequency | How often does it happen? | A few times a year | Many times a day |
| Manual effort | How much time does each instance take? | Seconds | Many minutes, or several people |
| Rule clarity | Can the decision be written as a rule? | Depends on judgment | One clear rule |
| Data quality | Are the inputs complete and consistent? | Often missing or wrong | Reliable and structured |
| Measurement potential | Can you count time, errors or delay today? | No way to measure | Already tracked |
| Exception rate | How often does it not follow the normal path? | Most cases are exceptions | Exceptions are rare and known |
| Reversibility | Can a mistake be undone? | Irreversible | Easily corrected |
| Risk | What happens if it goes wrong? | Financial, legal or safety harm | Minor inconvenience |
| Delay cost | Does waiting on this step hold up other work? | Nothing waits on it | Orders, cash or crews wait |
Add the scores. The maximum is 45. As a working guide:
| Total | Reading |
|---|---|
| 36 to 45 | Strong first candidate |
| 27 to 35 | Reasonable. Check the lowest-scoring factor before starting |
| 18 to 26 | Fix the process or the data first |
| Under 18 | Leave it for now |
Two rules override the total. If risk or reversibility scores 1, do not automate the action itself. You may still automate the preparation, with a person approving the final step. And if rule clarity or data quality scores 1 or 2, stop and fix that first, whatever the total says.
A worked scorecard
Here are four common candidates scored with the method. The scores are illustrative. Yours will differ, and the value is in the discussion the scoring forces.
| Factor | Purchase approval routing | Re-typing web orders into the ERP | Month-end accrual decisions | Drafting replies to supplier emails |
|---|---|---|---|---|
| Frequency | 4 | 5 | 1 | 4 |
| Manual effort | 3 | 4 | 4 | 3 |
| Rule clarity | 5 | 4 | 2 | 2 |
| Data quality | 4 | 3 | 3 | 3 |
| Measurement potential | 4 | 5 | 2 | 2 |
| Exception rate | 4 | 3 | 2 | 3 |
| Reversibility | 4 | 4 | 2 | 4 |
| Risk | 4 | 3 | 1 | 3 |
| Delay cost | 4 | 4 | 3 | 2 |
| Total | 36 | 35 | 20 | 26 |
Reading the table: approval routing is the strongest first candidate. The rule is clear, the audit trail is a benefit in itself, and a mistake is easy to correct. Order re-entry is close behind but its data-quality score says to check product codes and customer matching first. Accrual decisions involve judgment and financial risk, so they stay with a person. Drafting supplier replies is a possible AI-assisted task later, with a person sending the final message, but it is not where to start.
How to run the scoring session
The scorecard works when the people who do the work are in the room. Plan about an hour.
- Invite three to five people. Include someone who performs each candidate process, someone who receives its output, and a decision-maker.
- Describe each candidate in one sentence. For example: "When a purchase request is raised, it waits for a manager to approve it by email."
- Score silently first. Each person writes their scores before discussion. This stops the most senior voice setting the numbers.
- Compare and discuss the gaps. If one person scores rule clarity at 5 and another at 2, you have found something important. The process is less clear than leadership thinks.
- Agree a score and note the reason. The notes are worth as much as the totals.
Large disagreements on rule clarity, data quality or exception rate are themselves a result. They tell you the process needs to be defined before anything is built.
Estimating value without inventing numbers
You do not need a business case with precise savings. You need an honest order of magnitude, from numbers you can count.
- Volume: how many times a week does it happen? Count for one week.
- Time per instance: time a few real examples. Do not ask people to guess.
- Waiting time: how long does an item sit before someone acts?
- Rework: how many items come back because something was wrong?
Multiply volume by time to see the weekly effort. Compare candidates on that figure and on waiting time. Avoid converting hours into money at this stage. It adds false precision and invites argument.
When to fix the process before automating it
Automation locks a process in. If the process is wrong, you get the wrong result faster and more consistently. Fix first when:
- People describe the steps differently. Agree on one version before building it.
- The rule has many unwritten exceptions. Write them down. If the list keeps growing, the process is not stable.
- The data is unreliable. Duplicate customers, inconsistent product codes and missing fields will break a rule or an integration on day one.
- No one owns it. An automation without an owner fails quietly.
- The step should not exist. Sometimes the right answer is to remove an approval or a report, not to automate it.
A useful question is: if a new employee had to do this tomorrow, could you hand them written instructions? If not, write the instructions first. They become the specification.
Good first candidates
These tend to score well in the businesses we work with. Each is a deterministic rule or a standard feature, not AI.
| Candidate | Why it works first | Typical approach |
|---|---|---|
| Approval routing for purchases or expenses | Clear thresholds, visible audit trail, easy to reverse | Configured approval steps by amount and role |
| Notifications when a status changes | Removes chasing, low risk | Automation rule that creates an activity or sends an email |
| Reorder proposals when stock is low | Rule-based and reviewed by a buyer before sending | Standard reordering rules |
| Creating a project or task from a confirmed order | Removes re-keying between sales and delivery | Standard order-to-project setup |
| Moving approved hours into the ERP | High volume and a clear rule once approval exists | Integration with validation and an exception queue |
| Sending documents when a delivery is validated | Triggered by a clear event | Automation rule plus document template |
In our construction ERP case study, two of these patterns carried much of the value: purchase and vendor bill approvals routed by threshold and role, and field hours flowing from a workforce app into project costing. Neither involved AI.
Poor first candidates
- Rare processes. If it happens four times a year, the build and support cost is hard to justify.
- Processes that are mostly exceptions. The automation handles the easy cases and people still handle the rest, now with two paths to maintain.
- Anything depending on data you do not trust.
- Cross-department processes with no agreed owner.
- A process you are about to change. Automate the new version, not the old one.
- The most politically visible process. A first project should be allowed to be small.
Tasks unsuitable for unsupervised AI
Some tasks can be assisted by AI but should not be completed by it without a person. Odoo's own documentation on AI server actions notes that the AI action does not enforce business rules or guarantee the correctness of the operation. That is a fair description of language models in general. Keep a named human decision in front of:
- Posting or approving financial entries and payments.
- Changing prices, discounts or credit terms.
- Committing to delivery dates or contractual terms.
- Releasing production or purchasing commitments.
- Anything involving safety, compliance or employment decisions.
- Deleting or merging records.
- Sending external messages that create an obligation.
For these, AI can prepare a draft, extract fields or flag a likely issue. The person approves. The ERP AI readiness checklist sets out the review level by risk.
The 30-day pilot
A pilot should be small enough to stop and clear enough to judge.
- Week 0: baselineFor one or two weeks before the change, record volume, time per item, errors or rework, and how long items wait. Use a simple tally if nothing is tracked.
- Week 1: build and testBuild the smallest version. Test with real examples, including the exceptions you listed. Agree who receives alerts.
- Weeks 2 and 3: run alongsideRun the automation for a defined group or record type. Keep the manual path available. Log every exception.
- Week 4: compare and decideCompare against the baseline in the same units. Decide to extend, adjust or stop.
Write the stop condition before you start. For example: if the error rate is higher than the manual process after two weeks, turn it off and review. A pilot that cannot fail is not a pilot.
What to measure
| Measure | Why it matters |
|---|---|
| Cycle time per item | Shows whether work moves faster |
| Touches per item | Shows whether re-entry and chasing fell |
| Error or rework rate | Shows whether quality held |
| Items waiting | Shows whether a queue moved somewhere else |
| Exceptions per week | Shows whether the rule fits reality |
Do not report only hours saved. Hours are easy to overstate, and they hide the more important question of whether the result is correct.
Examples by industry
These are illustrations of how the scoring tends to fall. They are not results.
Manufacturing. Reorder proposals and quality-failure notifications usually score high: frequent, rule-based and reversible. Automatically releasing production orders scores low on risk and should stay with a planner. More in the Odoo manufacturing ERP hub.
Construction. Purchase approvals and field-time posting score high. Automatic approval of subcontractor invoices scores low, because the amounts are large and disputes are costly.
Engineering. Deadline reminders for bids score high. Deciding whether to bid is a judgment call and stays with a principal.
Fulfillment. Pulling marketplace orders into one queue scores high on frequency and delay cost, but depends on clean product matching, so data quality decides the timing.
Three traps to avoid
The sunk-cost trap. A process that took effort to automate is kept even when the pilot shows it is no better. Write the stop condition first, and honour it.
The moving-queue trap. The automated step gets faster and the queue moves to the next step. Measure items waiting across the whole process, not only at the step you changed.
The invisible-exception trap. The automation handles the normal case, and exceptions go to someone's inbox with no record. Within a month nobody trusts the numbers. Every exception needs a visible queue and an owner from day one.
What comes after the first one
When the pilot works, resist adding five more at once. Extend the same process to more record types or teams, then pick the next candidate from the scorecard. Keep one list of what is automated, who owns each item, and where its exceptions go. If the next candidate connects two systems, read the Odoo and n8n integration guide first. For how the levels of automation fit together, go back to the Odoo automation and practical AI hub.
Frequently asked questions
Should the first automation be the process that hurts most?
Not usually. The most painful process is often painful because it is unclear, full of exceptions or built on poor data. Those are reasons to fix it, not to automate it first. Start with something clear, then use what you learn.
How many processes should we automate at once?
One. A single pilot gives a clean comparison against the baseline and lets the team learn how exceptions and ownership work.
Do we need new software to start?
Often not. Approval steps, notifications and reorder proposals are standard or configured features in Odoo. Integrations and AI come later, where a rule cannot do the job.
What if nobody measures the process today?
Measure it by hand for one to two weeks before changing anything. A tally of items, minutes and errors is enough. Without a baseline you cannot tell whether the change helped.
Where does AI fit in this method?
At the end. Use the scorecard to find rule-based candidates first. Consider AI assistance only for tasks with unstructured input, and keep a person reviewing the output.
Next step
Run the scorecard with the people who do the work, then bring your top two candidates to a free 30-minute ERP fit call. We will tell you which one we would start with and what it would take.
Sources and review
- Odoo automation rules, Odoo 17 documentation, for what rules can trigger and do.
- Odoo 19 AI server actions, Odoo S.A., for the stated limits of AI-driven actions.
- NGYN's published construction ERP case study for the approval and field-time examples.
- The scoring method is NGYN's own working framework. It is a decision aid, not a published standard.
Published October 2026. Last reviewed October 2026 by NGYN Solutions Inc.. Product capabilities change between Odoo versions, so confirm version-specific details against the linked documentation before relying on them.