Automating business processes: a guide for SMEs

Automating business processes means that software takes over the fixed, recurring steps of a process: copying data, checking it and passing it on between systems. Your employees keep only the steps that really need judgement, such as an exception without a fixed rule, customer contact or a decision. It pays off mainly for work with high volume, fixed rules and digital input. Start with one small process, and be honest about the exceptions, the management and the licences in your calculation.

This guide gives a short answer for each topic and refers to the article that covers the topic in detail. One example runs through the whole guide: a manufacturing company that receives orders by email and enters them by hand into its ERP system. An ERP system is the business system for customers, orders, stock and invoicing, among other things.

What is process automation?

A business process is a fixed series of steps with a beginning and an end. Something comes in, such as an order, an invoice or a request. Someone does something with it in one or more systems. A result comes out: an order in the ERP, a posted invoice, a reply to the customer.

With process automation, software takes over the steps of that series that follow fixed rules. Many processes can run automatically from beginning to end this way. If an employee really has to decide halfway, you automate what comes before and after that decision. This is called human in the loop: an option when it is needed, not a fixed part of every automation. Working digitally is not the same as automating: if an order arrives by email and someone retypes it into the ERP, that is digital manual work.

This is about digital business processes and information flows: in a manufacturing company, from engineering to administration and from order to delivery. Controlling production lines, PLCs (the control computers of machines) and industrial robots is outside this scope. That is industrial automation, a different field. A software robot works only in software, not on the shop floor.

There are five ways to deal with recurring work. They do not exclude each other.

Five ways to organise recurring work
Approach	What happens	Strong at	Limitations
By hand	An employee reads, retypes and checks	Flexible, no build costs, good for low volume or a lot of judgement	Costs time every day; errors when it is busy; the knowledge sits in one person's head
Change the way of working	You remove the cause: a fixed order form, dropping an unnecessary step, a function your software already has	Often the cheapest step; no extra software to maintain	Needs cooperation from customers, suppliers or colleagues; does not solve everything
Integration	Two systems exchange data directly, through an API (a fixed technical entry point for other software) or a fixed file format	Stable, fast, also with large volumes	Both systems need a usable entry point; build work and sometimes a licence
Workflow	A series of actions starts on an event (an email arrives) or at a fixed time	Email, forms, approvals and alerts	Relies on ready-made connections (connectors) to other systems; not intended for screen work
Software robot (RPA)	Software operates the screens like an employee: clicking, typing, copying	Systems without an integration, including old programs and third-party portals	Sensitive to screen changes; slower than an integration; licence and management

RPA stands for robotic process automation. It is one technique within process automation, and not always the best one. An integration or a change in the way of working is often the better first choice.

Which processes are suitable?

A process is a good candidate if it meets most of these six conditions. Each condition has a test question that you can ask internally.

Volume. Does the work come back daily or weekly, in a recognisable quantity? A task of ten minutes a month rarely earns back the build and the management.
Fixed rules. Can the employee explain when they do what? "If the customer number is missing, I search by VAT number" is a rule. "You get a feel for it" is not a rule.
Digital input. Does the input arrive as a file, form or system export? An Excel file with fixed columns is much simpler than a scan or a free-form email.
Clear exceptions. Do the exceptions also follow fixed rules? Then the number matters little: a process with two hundred clear rules can run well automatically. The difficult ones are exceptions that need interpretation case by case. The software must recognise those and pass them on to an employee.
Stable systems. Will the systems involved stay as they are for the next few years? An ERP that will be replaced next year is a poor basis.
An owner. Is there one person who decides on the rules and who notices when the process changes? Without an owner, every automation falls behind actual practice after a while.

Recognisable candidates are order entry, order confirmations from suppliers, bills of materials (BOMs: the lists of parts and quantities of a product), invoice processing, checks between systems and recurring reports. They are worked out in 12 examples of work companies can automate, with what stays with a person. If you want to test one of your own tasks quickly, go through the four questions on the services page. With those four short questions, you judge for yourself whether a process is suitable, without a tool or a calculation. How to test a process more thoroughly is explained in can my process be automated?

What does it look like in practice?

Example (illustrative)

Now. A manufacturing company receives about 80 orders by email every working day, as a PDF or Excel file. A member of the inside sales team opens each order, looks up the customer in the ERP, checks the item numbers and prices and retypes the lines. That takes about 4 minutes per order. When it is busy, the orders run half a day behind, and a typo in a quantity only comes to light when the customer calls.

After automation. Software reads the new emails in a fixed folder, extracts the order data from the attachment and looks up the customer and the items. It compares the prices with the price agreements and checks whether the customer's order number has come in before. If everything is correct, it creates the order in the ERP. About 15% of the orders are exceptions: an unknown item, a price that differs from the agreement, a comment in free text. Those orders go to the inside sales team, with the reason. The inside sales team now only assesses the exceptions and checks briefly every day whether the automation ran correctly.

The employee does not disappear from the process. She does the part that needs judgement. The check also becomes stricter: the software checks every order in the same way, even on a Friday afternoon. You can read how this process works step by step in automating manual order processing.

Three other recognisable situations, briefly:

Order confirmations from suppliers. Now a buyer compares each confirmation line by line with the purchase order. After automation, software compares item, quantity, price and delivery date, and the buyer only gets the confirmations with a difference.
An Excel list that has to go into the ERP. Now someone copies supplier price lists or order lines from Excel every week. First check whether the import function of the ERP can do this, with a fixed template and a check beforehand. The available routes are in Connecting Excel to ERP.
Items and BOMs from engineering to the ERP. Now, after each release in the PDM system (where engineering manages drawings and revisions), a process planner retypes the new items and the BOM into the ERP. After automation, software prepares them in the ERP, and the process planner only gets the lines that do not match, such as an unknown material code. A safe first step is a nightly comparison of PDM and ERP that only emails the differences and changes nothing.

Which techniques are there?

Only choose the technique once the process is clear. Go through the options in this order: first what your own software can already do, then an integration, then a workflow, and only after that a software robot. The higher in that order, the less you build and maintain yourself.

In practice you combine them. In the order example, a workflow collects the email and a template or AI model reads the PDF. An integration or software robot then puts the order into the ERP. A software robot is mainly useful if the ERP has no usable integration. How to make that choice is explained in RPA or API integration: which is the best choice?

AI helps with input that has no fixed form, such as PDFs with varying layouts or free-form emails. The result is a proposal, not a certainty. UiPath calls a human check of extracted data optional, but strongly recommended. That applies especially if the data must be 100% correct, or if you cannot compare it with another reliable source. Comparing, copying and passing on data is more reliable with fixed rules.

Two well-known platforms are UiPath and Microsoft Power Automate. UiPath is a platform for software robots, with a central management environment (Orchestrator) for things such as work queues and stored login details. Power Automate has cloud flows for workflows that start on an event or at a set time, and desktop flows for screen work. The differences in cost and use are in UiPath or Power Automate.

How do you choose the right approach?

Ask these questions in this order. The first yes usually gives you the approach.

Is the volume small, or does each case need its own judgement? Then do not automate, or automate only the preparation.
Can the cause be removed? Can customers use a fixed order form, or is a step unnecessary? Then change the way of working first.
Can your own software already do it? An import function, a standard integration or a built-in rule? Use it. The supplier maintains it.
Do both systems have a usable API or a fixed file format? Then an integration is usually the most stable choice.
Is it about email, forms, approvals or alerts? Then a workflow often fits.
Can it only be done through the screens, and are those screens stable? Then a software robot is a good option. If the screens change often, none of the techniques fits well, and the work stays manual or you look for another route.

Three factors weigh most: how stable the systems and the input are, whether the exceptions follow fixed rules, and who manages the solution after go-live. Also ask internally whether one of the systems will be replaced within a year. If so, it is better to wait.

You can often build a simple flow that sorts emails yourself, with tools you already have. Outside help makes sense if the automation writes to your ERP or accounting system. That also applies if a software robot is needed, or if nobody in-house has time for the management.

What does automation cost?

An automation takes one-off time for analysis, building, testing and go-live. After that, there are ongoing costs: licences, a machine or cloud environment on which the automation runs, management and changes. Also count your own time: for the analysis, the testing, the exceptions and the daily check.

The amount depends less on the technique than on the process. These cost drivers make the difference:

the number of variants in the input (one fixed Excel format or twenty different PDFs);
the number of exceptions that the software has to recognise;
the integration options of your systems;
the requirements for checks, logging and security.

Licence prices change regularly. Always check them on the supplier's pricing page. The cost items and four scenarios are in what it costs to automate a business process. What comes on top after go-live is explained in what maintaining a software robot costs.

When does it pay off?

Start with the time the process takes now. Subtract the time that remains: the exceptions and the check. What is left is the time you actually free up. Set that against the costs.

Worked example (illustrative): orders from email into the ERP
Item	Calculation	Per day	Per year (230 working days)
Manual work now	80 orders × 4 minutes	320 minutes	≈ 1,227 hours
Exceptions stay manual	15% = 12 orders × 4 minutes	− 48 minutes	≈ − 184 hours
Daily check	fixed time	− 15 minutes	≈ − 58 hours
Actually freed up	320 − 48 − 15	257 minutes	≈ 985 hours

Assumptions: 80 orders per working day, 4 minutes per order, 230 working days per year (46 weeks × 5 days), 15% exceptions and 15 minutes of checking per day. Fill in your own numbers.

The full 320 minutes never count as savings. The exceptions remain human work, and they are often the difficult orders. Someone also has to check every day whether the automation ran correctly. Licences, maintenance and the build are costs, not time savings. Calculate them separately.

A simple rule of thumb for the payback period in years: one-off costs ÷ (hours freed up per year × your cost per hour − annual costs). If the part in brackets is zero or less, you will never earn the automation back. If the result is very long, it does not pay off in this form. Time is not the only return: fewer errors, a shorter lead time and less dependence on one colleague also count. How to calculate this for your own process is explained in when automation pays off for a small business.

What are the risks?

Most problems arise before the technology comes in: the wrong process, missed exceptions or no owner. These are the risks you need to know in advance:

The wrong process. A process that is still changing, or in which many exceptions need interpretation case by case, mainly produces build work for exceptions.
Incorrect data. If customer data, item numbers or price agreements in the ERP are not correct, the software continues with those errors.
Screen changes. A software robot recognises a field by technical characteristics. If such a characteristic changes through an update, the robot can no longer find the field. Microsoft also warns about the screen resolution. An unattended robot starts automatically and does the work without an employee having to be present. It follows predefined rules. On an error or exception it can stop, send an alert or put the case to an employee. The run stays traceable. The opposite is an attended robot, which an employee starts on their own computer. If an unattended robot runs at a different resolution than during the build, it can miss an element or even operate the wrong element.
An error repeats itself. An employee usually makes an error once. Software with a wrong rule makes the same error in every case, until someone notices.
No management. An automation without an owner and without monitoring works until the first system update that affects it. After that it stops, sometimes without anyone noticing.
Access and login details. A robot that works with the account and password of an employee makes it unclear afterwards who did what.
A cumbersome process stays cumbersome. If you automate a detour, you have a fast detour.

How to prevent these risks is explained in why RPA projects fail. Sometimes the honest answer is that it is better not to automate now. The signs for that are in when it is better not to automate a process.

How does implementation work?

Choose a small first process. Not the process with the most pain, but the process with the best balance between return and risk. A check that only reads can break little.
Map the process with the people who do the work. Write down what really happens, with the exceptions and how often they occur.
Collect real examples: normal cases and difficult ones. You use that set later for testing.
Test with real cases, including exceptions. Also test incorrect input, a system that cannot be reached and a restart halfway through. Is anything processed twice then?
Run in parallel for a period. The automation works alongside the normal process, or first prepares its results as drafts. An employee checks them and compares them with what they would do themselves.
Go live once the owner has approved the test results. Arrange in advance a separate account for the automation, a work instruction for exceptions and a fallback plan for a day when the automation does not run.

Look at every exception in the first weeks. You then see patterns: a customer who keeps sending a different format, a rule that is too strict. A detailed start plan for the manufacturing industry is in Process automation in a manufacturing company: where to start?

How do management and maintenance work?

An automation works in an environment that changes. Systems get updates, passwords expire, customers change their forms and new exceptions appear. Management therefore consists of fixed tasks:

checking every day whether the automation has run and whether there are alerts;
handling exceptions and looking at whether a recurring exception is worth a new rule;
adjusting and testing the automation when a system changes, preferably before the update goes into production;
managing accounts and login details, with only the rights that the process needs;
updating the documentation: what does the automation do, which rules does it follow, and who is the owner?

Agree before go-live who does these tasks and how quickly a failure is fixed. An integration usually needs less maintenance than a software robot, but an integration also has to keep up when a supplier changes its API. What maintenance involves and how to limit it is explained in what maintaining a software robot costs.

How do you assess an automation specialist?

Reviews say little about your process. Instead, ask questions whose answers you can check. The table gives a good answer and a warning sign for each question.

Eight questions for an automation specialist
Question	A good answer	Watch out for
Can you show work?	A demo or a delivered process, shown with the customer's permission, with an explanation of the exceptions	Only logos or vague stories, or confidential data of other customers
When do you advise against automation?	Concrete situations: low volume, a system that is being replaced, a process without fixed rules	"Everything can be automated"
Who owns the code and the accounts?	You do: the workflows, the source code, the licences and the accounts are in your company's name	Everything runs in the developer's environment
What is in the documentation?	The steps, the rules, the exceptions, the systems and accounts, and what you do in case of a failure	No documentation, or only technical notes
How do you test?	With real cases, including exceptions, incorrect input, failures and a restart; the owner approves	Only testing whether the normal case works
What happens to exceptions?	Every case that does not match goes to a fixed place with a reason; an error in one case does not stop the rest	The automation stops completely, or guesses
Which maintenance agreement do you propose?	What it covers, how quickly they respond, what a change costs and how you end the agreement	No agreement, or an agreement you cannot get out of
How do you secure login details?	A separate account for each automation with minimal rights; passwords in a secure store, not in a script or Excel	The robot works with the account of an employee

For that last question, it helps to know what the platforms offer. UiPath lets an administrator set up the login details for an unattended robot, so developers do not have them in their own hands. Those details are kept in a credential store: a secure store, by default the Orchestrator database, or an external vault such as Azure Key Vault.

A small specialist or a larger agency?

With a small, independent specialist, you talk directly to the person who looks at your process and builds the solution. The lines are short and the knowledge is not spread across a team. There are real disadvantages too. The capacity is limited: large projects with many parts at the same time fit less well. In case of illness or holiday, there is no colleague who takes over immediately.

A larger agency has more capacity and cover. There you talk more often to an account manager or project manager than to the developer, and the team can change. Which form fits depends on the size of your project and on how quickly you need help in case of a failure.

You can limit the risk of a small specialist with three agreements. Every delivery includes documentation. The solution runs in your own environment, with your own licences and accounts. And you keep access to everything, so another specialist can take over the work. MeeuseSolutions is such a small specialist and therefore works with these three agreements.

Where do you start?

You do not need to know which technique you need in order to start. Start with the work:

Ask the people who do the work what they retype or check every day or week, for example in inside sales, purchasing, process planning and the accounts team.
Choose two or three candidates and count for two weeks how often they occur and how long they take.
Test them against the six conditions above and calculate the time freed up as in the worked example.

Then you know which process can go first, and you can discuss the technique with figures to hand.

Automating business processes: the complete guide for SMEs