Business automation often starts with a shopping list: CRM, ERP, inventory software, finance tools, a chatbot or analytics. That is the wrong starting point. Software is only an instrument. A result appears when the company knows which process it is changing, where time or money is lost and what work should look like after implementation.
Do not automatically choose the largest process or the task that annoys the owner most. A strong first candidate happens frequently, follows stable rules, creates visible delays or errors and produces an outcome that can be measured before and after the change.
Start with a business problem, not a system name
“We need a CRM” does not define a problem. Useful statements are specific:
- sales staff re-enter website orders into the accounting system;
- the warehouse receives order changes in chat and picks an outdated version;
- the owner cannot see overdue enquiries without a manual report;
- purchasing orders stock without considering reservations and confirmed inbound supply;
- invoice, payment and dispatch are reconciled by different people in separate spreadsheets.
Each statement identifies an event, a participant, a loss and a source of data. Only then can the company decide whether it needs an integration, a rule change, an automatic control or a full module.
Six criteria for the first process
| Criterion | What to check | Sign of a strong candidate |
|---|---|---|
| Frequency | How often the operation occurs | The same actions recur every day or week |
| Staff time | Active work, waiting and duplicate entry | The process consumes many hours in total |
| Error cost | Returns, rework, penalties and lost sales | An error has a measurable consequence |
| Rule stability | Whether decisions can be expressed as conditions | Most cases follow the same logic |
| Data readiness | Where orders, products, customers and statuses live | A source and a data owner exist |
| Manageable scope | Whether one part can be piloted | The pilot does not require rebuilding the company |
If a process is rare, every case is unique and the rules change continually, automation may cost more than manual handling. Standardise it first.
Build a candidate list in one working week
There is no need to document the whole company for months. For five working days, managers record operations where at least one of these events occurs:
- data is copied between the website, spreadsheets, CRM and accounting;
- a person waits for approval even though data can determine the condition;
- a status must be checked by telephone or chat;
- an error is found only at the next stage;
- a report is assembled manually from several sources;
- the operation depends on one person's memory;
- a task queue has no deadline or accountable owner.
For each item, record frequency, participants, approximate time, the common error and its consequence. That is enough for an initial ranking.
Score every candidate on the same scale
Use a score from 1 to 5 for frequency, time, error cost, rule readiness and data readiness. Score implementation complexity separately, where 5 means highly complex.
Priority = Frequency + Time + Errors + Rules + Data − Complexity.
This is a comparison tool, not a financial formula. Investigate the top two or three candidates in greater detail.
| Candidate | Frequency | Time | Errors | Rules | Data | Complexity | Priority |
|---|---|---|---|---|---|---|---|
| Re-entering online orders | 5 | 4 | 4 | 5 | 5 | 2 | 21 |
| Approving an exceptional discount | 3 | 3 | 3 | 2 | 4 | 3 | 12 |
| Producing the monthly report | 1 | 5 | 3 | 4 | 3 | 3 | 13 |
Order re-entry scores highest because it is frequent, rules are clear, data sources exist and the pilot can be limited to one sales channel.
Confirm the problem with facts
Measure the baseline for at least two to four representative weeks:
- number of transactions;
- average active staff time;
- waiting time between stages;
- corrections and returns;
- share completed on time;
- lost sales or another cost of delay.
Do not combine active time with waiting. Automatic transfer may reduce a two-hour wait to one minute while saving only five minutes of labour. Both outcomes matter, but they have different economic meanings.
Example: from web order to warehouse task
A company receives 80 orders per day. A sales employee spends four minutes checking and re-entering each one, more than five hours daily. Roughly 3% contain an address, quantity or variant error, and the warehouse starts only after manual confirmation.
A pilot can cover one channel and standard orders. The system creates the document, validates mandatory fields, reserves available stock and sends a picking task. Exceptional discounts, doubtful addresses and shortages remain in the manager's queue. The predictable flow is automated without hiding exceptions.
What not to automate first
- An undefined process. Staff disagree about its start, result and rules.
- A rare, low-impact operation. Development will not repay ongoing support.
- A process due to be removed. Make the organisational decision first.
- Dirty master data. Duplicate products and customers will spread automatically.
- Every exception at once. The first release should cover the main flow and hand exceptions to a person transparently.
- Control for its own sake. Unnecessary approvals automate bureaucracy, not performance.
Set a clear first-release boundary
A pilot needs an explicit start and finish, for example from receiving a paid website order to creating a picking task. Do not include procurement, delivery, returns, finance and the whole CRM unless they are necessary to test the main hypothesis.
- Choose one channel, team or operation type.
- Define input data and mandatory fields.
- Write the automatic-path rules.
- List exceptions and their owner.
- Set target time, error and completion measures.
- Set an observation period after launch.
- Define the condition for expansion or stopping.
Signs that the choice is sound
The team can explain the problem in one sentence, show it in the data and name a measurable outcome. Participants agree on the main sequence, sources are available and exceptions are visible. The first version can run without replacing every system at once.
If the case relies only on broad promises about digital transformation, the candidate is not ready. Return to the real workflow and identify a specific delay, duplication or error.
How the choice relates to Business Reactor
Business Reactor Core connects roles, operations, statuses and permissions in one managed environment. A company can start with one process and later connect catalogue, inventory, sales, finance, manufacturing and analytics without recreating the same master data.
Before configuring an automatic action, describe the process: its trigger, participants, data, rules, exceptions and expected result. The next article explains how to create that map.
Conclusion
Automate a frequent, stable process with measurable time loss or errors first. Compare candidates consistently, prove the problem with baseline data and keep the pilot within one manageable flow.
The next step is to describe the chosen process so business users and developers understand the same boundaries, rules and exceptions. Business Reactor Core.
