12 examples of work companies can automate

Work that you can often automate well is work where employees retype, compare or forward data between systems. Think of orders, order confirmations, invoices, emails, certificates, bills of materials (BOMs), production papers, stock, status messages, checks and reports. Software then takes over the work that follows fixed rules, including exceptions with a clear rule. The employee keeps only what needs judgement. Below are twelve examples, each with the current situation, what automation takes over, what stays with a person and the usual technique.

How to read these examples

Find the example that resembles your work and look especially at what stays with a person. That is where the exceptions that need judgement are: cases that the software cannot handle with a fixed rule and therefore passes on to an employee. If an exception does follow a fixed rule, the software handles it itself. In some processes, little is then left for a person. The technique always comes last, because you only choose it once the process is clear. How the techniques differ is explained in the guide to automating business processes.

In the table, "robot" means a software robot (RPA, robotic process automation): software that operates the screens of a program like an employee. It is not an industrial robot. An ERP system is the business system for customers, orders, stock and invoicing, among other things.

The last column names a few kinds of solutions. They do not exclude each other, and sometimes the best step is no new software at all.

1. Order entry

Now: customers send orders as a PDF, an Excel file or an email. A member of the inside sales team looks up the customer, checks items and prices and retypes the lines into the ERP system.

After automation: software reads the order, looks up the customer and the items, compares the price with the price agreement and checks whether the customer's order number has come in before. If everything is correct, it creates the order. Otherwise the order goes to the inside sales team with the reason.

Stays with a person: prices that differ from the agreement, unknown items, new customers and comments in free text.

Usual technique: the import function or API of the ERP, and a software robot if there is none. You extract PDFs with a template for each customer or with AI document recognition. The full process, with the checks and the choices, is in automating manual order processing.

2. Order confirmations from suppliers

Now: a buyer opens each confirmation and puts it line by line next to the purchase order: item, quantity, price and delivery date. When it is busy, confirmations are left waiting, and a later delivery date is only noticed when the material does not arrive.

After automation: software reads the confirmation, looks up the purchase order and compares each line using fixed rules, such as a price within an agreed margin. If everything is correct, it sets the order to confirmed and saves the PDF with the order. If something differs, the buyer gets a task with the differences listed.

Stays with a person: the contact with the supplier and the decision on what happens with a later delivery date.

Usual technique: extraction with a template for each supplier, and an integration or software robot for the ERP. If the confirmations come from many suppliers, each with its own layout, the extraction is the most expensive part. In that case, first ask whether suppliers can use a fixed format or a portal.

3. Purchase invoices

Now: invoices arrive as PDFs in an invoice mailbox. The accounts team records them, looks up the purchase order and asks a budget holder for approval. Most of the work is in the searching and comparing.

After automation: software records the invoice and compares it with the purchase order (item and price) and the goods receipt (quantity delivered). This comparison is called the three-way match. If the three match within an agreed margin, the invoice goes through. Only the differences reach the accounts team.

Stays with a person: the approval of invoices without a purchase order, investigating differences and every change to a bank account number. The Dutch Chamber of Commerce (KVK) advises you, if in doubt, to make contact using the contact details from your own records, not those on the invoice. So make the software stop if the bank account number differs from your supplier file.

Usual technique: invoice processing in your accounting or ERP system, or a separate invoicing package. According to the KVK, a PDF that you email as an attachment is not an e-invoice. An e-invoice contains data that software processes directly, without extraction. In the Netherlands, the central government (Rijksoverheid) already accepts only e-invoices. The Dutch cabinet wants to make e-invoicing between businesses mandatory from 1 July 2030, if the bill is passed.

4. A shared mailbox

Now: an address such as info@ or sales@ gets everything mixed together: orders, quote requests with drawings, questions, invoices, complaints. Someone reads every email, moves it to the right folder or colleague and saves the attachments.

After automation: software sorts emails by sender, subject and attachment, forwards them to the right folder or person and saves attachments in the right case file. If the software does not recognise an email with certainty, the email stays in a folder for manual review.

Stays with a person: complaints, sensitive emails and everything that the software cannot sort with certainty.

Usual technique: a workflow, for example in Power Automate (the workflow service from Microsoft). Such a flow can start as soon as an email arrives, also in a shared mailbox. Note a detail from Microsoft's documentation: the trigger (the event that starts the flow) only looks in the folder that you set in the flow. If a mail rule first moves messages to another folder, the flow does not start.

5. Saving and extracting documents and certificates

Now: packing slips, material certificates and inspection reports arrive by email or as a scan. Someone names each file, puts it in the right folder and sometimes copies a few fields, such as the batch number.

After automation: software recognises the type of document, extracts the important fields and saves it with the right order or item, with a fixed name. Below a confidence threshold, it presents the document to an employee.

Stays with a person: poor scans, documents that do not match any order and the judgement on an exception, such as a different material grade than ordered.

Usual technique: document recognition, often with AI, and with a check. UiPath calls a human check optional, but strongly recommended. That applies especially if the data must be 100% correct, or if you cannot compare it with another source. That check can take place on the employee's workstation or as a task in Action Center (the place in UiPath where an employee assesses the cases put to them).

6. Items and bills of materials from PDM to ERP

Now: engineering releases a new product or a new revision in the PDM system (where engineering manages drawings and revisions). After that, a process planner retypes the new items and the bill of materials (BOM) into the ERP. A BOM is the list of parts and quantities of a product. With a large BOM, that is a lot of work, and a missed line or an old revision is only noticed in purchasing or in production.

After automation: after the release, software takes the items and the BOM lines from the PDM or from a fixed export. It checks whether an item already exists, whether the unit and the material code are known and whether the revision is newer than the one in the ERP. If everything is correct, it creates the items and the BOM, first as a draft. Anything that does not match goes to the process planner with the reason.

Stays with a person: what engineering does not record but the ERP needs, such as the choice between make and buy, the supplier and the operations. And the decision on what happens to open orders when there is a new revision.

Usual technique: first check whether your PDM or PLM package (a broader system for product data) has a standard integration or a fixed export to your ERP. If not, an import file, an integration or a software robot puts the BOM into the ERP. If you have doubts about the master data, start with the check from example 11.

7. Production papers for process planning

Now: for each production order, a process planner puts together a package: the job card from the ERP, the drawings from the PDM, the work instructions and sometimes a CNC program or a file for the 3D printer. They look up each document, check the revision and print or bundle everything. A drawing with an old revision on the shop floor can lead to rejects or rework.

After automation: as soon as the production order is released, software collects the documents that belong to the items and revisions in the order. It bundles them into one PDF or puts them in a fixed folder for each order. If a document is missing, or a revision is not yet released, it does not create the package and reports the reason.

Stays with a person: the planning, the choice of machine or workstation and the judgement on an order with a revision that is not yet released.

Usual technique: an integration or script that reads the ERP and the PDM, and a software robot if one of them only works through the screen. The automation does not write to the ERP or the PDM, so the risk is limited. But do test that it always chooses the released revision.

8. Quote preparation

Now: with a quote request that includes drawings, time first goes into preparation. An employee looks up the customer, searches for earlier quotes and orders for the same item, saves the drawings and creates a quote file.

After automation: software creates the quote file, puts the attachments in it and searches for earlier prices and orders for the same item number. It creates a draft quote with the customer details and the standard terms, and warns you if the same item was quoted earlier at a different price.

Stays with a person: the technical assessment, the price and the question of whether you want the job. Automate the preparation here, not the decision.

Usual technique: a workflow or software robot. If you work with a CPQ package (configure, price, quote: software that configures a product and calculates the price), the software prepares standard configurations in it.

9. Stock movements

Now: the ERP often posts receipts and deliveries itself. Stock counts, rejects and returns arrive on paper, as an Excel list or from a scanner without an integration. Someone posts them by hand, often with a delay.

After automation: software reads the list or the scanner file and posts each line, with a reason such as count or reject. It does not post any movement that makes the stock negative. It presents a count difference above a threshold that you choose for each item group for review. Every processed file goes to an archive folder, so that nothing is posted twice.

Stays with a person: unexplained differences. A large count difference points to a problem in the process, and you do not solve that with a posting.

Usual technique: the import function of the ERP. If the stock has to stay in line with a web shop or an external warehouse, an integration fits better than a robot that copies figures.

10. Status messages to customers

Now: customers call or email to ask where their order is. Someone looks up the status in the ERP or with the carrier and emails the answer.

After automation: on a fixed event, such as order confirmed, ready or shipped, the software sends a message with the related details. Or it puts the status in a customer portal. It only sends a message if the status has really changed, and checks whether the email address belongs to the right customer. A message with order and contact details to the wrong recipient can be a data breach.

Stays with a person: bad news. You report a week's delay for an important customer yourself, with an explanation and a solution.

Usual technique: a workflow or integration that responds to a status change in the ERP. First check whether your ERP can send messages itself.

11. Check between systems

Now: the same data is in more than one system. An item is in the PDM system and in the ERP. After a while the two drift apart, and nobody notices until something goes wrong in production or invoicing.

After automation: software compares the systems every night using fixed rules and emails a list of differences to the owner of the data. For example: every released item in the PDM is also in the ERP, with the same revision. The software corrects nothing.

Stays with a person: the decision on which system is right. Agree on one leading system for each data item. That agreement is often worth more than the check itself.

Usual technique: a query or script on exports or databases, and a software robot if a system can only be read through the screen. Because the check only reads, the risk is small. That makes this a good first project.

12. Reports in Excel

Now: every Monday, someone exports data from the ERP, the time registration system and the planning system. They paste it into a workbook, refresh the pivot tables and email the result. It goes wrong when an export has one column more or one column less.

After automation: the workbook collects the data itself and combines it. A check beforehand looks at whether the number of rows is roughly right and whether columns are missing. A report that silently shows wrong figures is worse than a report that does not appear.

Stays with a person: the conclusions and the actions.

Usual technique: Power Query in Excel. It can combine all files in a folder into one table, as long as they have the same file type and the same structure, with the same columns. If Excel can read directly from the ERP, the export is no longer needed. A software robot is only needed for exports from systems without an integration. More routes are in Connecting Excel to ERP.

Which example do you start with?

Do not choose the biggest process, but the process with the best balance between return and risk. Ask four questions internally:

1. How often does it occur, and how long does it take? Count it for two weeks. Estimates from memory are often wrong.
2. Does the automation only read, or does it write to a system? A check or report (examples 11 and 12) can break little. Writing to the ERP or the accounting system needs more checks.
3. How fixed is the input? A system export or a fixed Excel format is faster and cheaper to automate than free-form emails or scans.
4. Is there one owner? A process within one department gets off the ground faster than a process that three departments decide on.

How to set the time freed up against the costs is explained in when automation pays off. You can find a start plan for the manufacturing industry in process automation in a manufacturing company.

You can often build a simple report or email flow yourself. 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 can do the management.

What these examples do not show

Each example describes the normal situation. Your process has its own exceptions, and those determine most of the work. Three things drop out of a short description:

• The quality of your data. If the item numbers, BOMs, price agreements and customer data in your systems are not correct, every automation runs into that. Expect clean-up work beforehand.
• The management. Systems get updates and customers change their forms. An automation needs an owner and maintenance for as long as it runs.
• The cause. Sometimes a fixed order form or an e-invoice yields more than software that learns to read messy input.

If a system will be replaced soon, or nobody can explain the rules, wait. The signs for that are in when it is better not to automate a process.

Sources

• KVK: E-invoicing is coming (in Dutch)
• KVK: Do not fall for invoice fraud (in Dutch)
• Dutch Data Protection Authority: What is a data breach? (in Dutch)
• Microsoft Learn: Office 365 Outlook connector
• Microsoft Learn: Combine files overview (Power Query)
• UiPath Documentation: Data Extraction Validation overview