How to pick the first process
The most common mistake is starting with the most visible process, or the one a tool happens to have just been bought for. It is better to weigh three things side by side: frequency, time and error risk.
A process that recurs weekly, costs half an hour each time, and upsets a customer the moment it goes wrong belongs at the top of the list. A process that happens once a quarter and has little impact when it fails belongs at the bottom, even if it sounds more interesting to build.
Do not turn this into a complicated formula. A simple score on these three points, per process, usually gives a clear order already. And deliberately choose a process with a bounded scope: one trigger, one clear outcome. Processes that branch out across the whole company are a project in themselves, not a good first step.
Seven processes that often make good first candidates
- Invoices and reminders. Sending invoices and following up on payment reminders is repetitive, follows fixed rules and usually connects well to your accounting package. A good first candidate, provided the rules for who gets a reminder and when are clear.
- Moving quote and order data between systems. Many companies retype the same data from CRM into accounting, or from webshop into inventory. That retyping is error-prone and never feels like meaningful work.
- Time tracking and recharging. Hours that need to move from a timesheet tool into invoicing or project administration lend themselves well to automation once the connection between the two systems is in place.
- Onboarding new customers or employees. A fixed sequence of steps — creating an account, granting access, sending a welcome email, recording details — is exactly the kind of predictable chain that automates well.
- Recurring reports and distribution. A report that gets assembled the same way every week or month and sent to the same people does not need to be built and emailed by hand.
- Stock or purchasing signals. An alert when a stock level drops below a threshold, or when a purchase order takes longer than expected, is a good example of a signal that can be generated automatically instead of relying on someone to check.
- Data quality checks and alerts. Checking whether required fields are filled in, whether a customer name is spelled the same way in two systems, or whether an import arrived without errors — those checks are better run automatically than trusted to someone noticing.
This is not an exhaustive list, and not every process fits every company. It is a starting point for recognising the type of work that lends itself to automation: repetitive, rule-based, with a clear start and end.
What you need before you start
Before a single step gets built, three things need to be in order first.
Clear steps. Can you write the process down as a series of concrete steps, without "and then someone takes a look"? If the answer is yes at every step, it is a good fit. If a step can only be explained with "Karin knows how that works", that step needs to be documented before you automate.
An owner. Every automated workflow needs someone who keeps an eye on it, knows when it was last changed, and decides on updates. Without an owner, an automation runs fine for a while and then quietly breaks without anyone noticing.
API access. Can you reach the systems involved through an API, or does someone need to log in and click manually? Not every package offers the same options. That is exactly where integrations come in: figure out what a system allows first, then design the process around it.
Skip any of these three and you are building on sand. The technology might work fine, but the outcome is unreliable, or nobody feels responsible when it breaks.
Monitoring: what happens when something fails
A workflow that fails silently is worse than no workflow at all. If nobody does the task manually anymore because "the system handles it", and the system gets stuck, you often only find out when a customer calls.
So arrange a few things upfront. What happens when a step fails: does the whole workflow stop, or does it continue with an error logged elsewhere? Who gets notified when that happens, and through which channel? And how do you recover a task that got stuck halfway, without, say, sending the same invoice twice?
This does not need to be an elaborate monitoring system. Often a simple alert in a channel people actually read, combined with a clear owner, is enough. What matters more than the tooling is the agreement: someone is responsible, and that person knows what to do when something breaks.
People and change
An automated process almost always touches someone's job. That can create tension, especially if people feel their task is being made "redundant". It helps to be clear upfront about what changes: which task disappears, what replaces it, and who stays responsible for what.
Involve the people who currently do the process manually in the design. They know the exceptions that are written down nowhere and that can quietly break a workflow. An automation dropped on someone's desk without consultation rarely lands well, even when it works perfectly on a technical level.
This mirrors our approach: start small, show a result, then expand. The same principle applies to the people side. Show first that it works on a small, well-understood process before moving on.
When you are better off not automating
Not every process deserves automation, and that is not a failure, it is simply a good call. Keep a process manual as long as it is not stable itself: if the steps change every few weeks, you end up rebuilding the workflow just as often.
Processes that need a lot of human judgement — weighing an exception, reassuring a customer, reading a difficult situation — do not lend themselves well to full automation either. Agentic AI can sometimes help with the groundwork there, but the decision itself stays with a person.
And sometimes the simplest conclusion is the right one: if a process happens only a few times a year and takes little time, the effort of building an automation is out of proportion to what it delivers. In that case, doing it manually is perfectly fine.
Structural automation works best when it rests on a solid data foundation and on processes you understand well. So start workflow automation with the process you know best, not the one that sounds most impressive.