What Should I Automate First in My Business? A Practical Guide for SMEs

Someone is updating the same Excel file every week. A supplier has to be chased again. A customer asks where an order is, and three people need to check before anyone can give a reliable answer. A report that should take five minutes somehow takes half a morning.

Information exists somewhere, but somebody still has to find it, check it and put the answer together.

We should automate some of this.

That part is easy. The harder question is: what should we actually automate first? If you don't know where to start, don't start by choosing an AI tool. And don't start by shopping for another piece of software.

Start by looking for work that happens repeatedly, follows roughly the same steps, depends on people moving or checking information, and creates delays or mistakes when somebody forgets what needs to happen next. That is where some of the best automation opportunities are hiding.

The objective is not to automate everything. It is to find the work that is quietly consuming your team's time, slowing decisions and eating into profitability, and remove the unnecessary effort around it.

Why is it so difficult to know what to automate?

Because most businesses don't have one spectacularly broken process. They have dozens of small inefficiencies that have accumulated over time.

A spreadsheet was created because the ERP report wasn't quite right. A manager started sending a weekly email because people needed an update. Someone began copying information from one system into another because the two systems didn't communicate. A supplier follow-up process developed through email or WhatsApp because that was the quickest way to solve the problem at the time.

None of those decisions were necessarily bad. Most made perfect sense when they started. The problem comes later.

The company grows. More customers. More orders. More suppliers. More people. More information. But the workaround grows with it. What took one person 15 minutes when you had 20 orders becomes several hours when you have 200.

And eventually everyone is busy. Yet the owner still feels: "Why does this business need so much effort just to keep moving?"

This can happen even after a company has invested heavily in technology.

Fifty-four percent reported manual and repetitive tasks as a challenge, 45% cited inadequate reporting, and 43% reported integration problems between systems.

That's an important distinction. The problem is often not: "We don't have software." It is: "We have software, but people still have to hold everything together manually."

The business needs to do more. But asking the same people to work harder is not a serious growth strategy.

So before asking "Which AI tool should we buy?", ask: "Where is our existing team spending time on work that should not require this much human effort?"

What should I automate first? Look for these 7 signs

You don't need a technology background to find good automation opportunities. Look at how work actually happens inside your business. These seven signs are usually much more useful than starting with "Where can we use AI?"

1. The same task happens again and again

Repetition is the obvious starting point. Every Monday, somebody exports data and rebuilds a report. Every new order requires the same information to be copied. Every supplier confirmation needs to be checked manually. Every invoice follows the same review process. Every month, the same people chase the same documents.

One occurrence might only take ten minutes. That sounds harmless. But ten minutes multiplied by 20 customers, 50 purchase orders or 200 transactions becomes a very different problem.

Don't only look at how long a task takes. Look at how often it happens.

Something small that happens hundreds of times can consume far more capacity than one obviously painful task that happens twice a year.

2. The steps are mostly predictable

Good automation candidates usually have a recognisable path. Something happens. Someone checks something. Information moves somewhere else. A condition is met. Someone follows up. An exception gets escalated.

If the normal process is reasonably predictable, parts of it can often be automated even when people still need to handle decisions or unusual cases. McKinsey has estimated that large portions of predictable work, data processing and data collection are technically automatable.

That does not mean removing people from the process. Often it means removing the boring part so people can focus on what genuinely requires judgment.

3. Someone is copying information from one place to another

This is one of the easiest problems to spot. Someone takes information from ERP → Excel. Excel → CRM. Email → ERP. Supplier PDF → spreadsheet. Spreadsheet → management report.

One system already knows the information. Another person or system needs it. And a human being has become the connection between the two. Sometimes there is a good reason for that. Often, there isn't. It is simply how the business evolved.

Humans are very expensive APIs.

4. People constantly chase somebody for an update

Listen to the language inside your business. How often do you hear: "Any update?" "Did they reply?" "Have you followed up?" "When is it arriving?" "Has this been approved?" "Did the customer send the document?"

If the same follow-up needs to happen again and again, you may not have a people problem. You may have a workflow problem. The person doing the chasing is not producing the information. They are spending time discovering whether something happened. Those are two completely different kinds of work. And as volume grows, chasing grows with it.

5. The information exists, but somebody has to rebuild the answer

This is extremely common. The data is technically there. But answering a simple business question means checking three systems, opening an Excel file and asking two people.

• Which orders are late?
• Which customers will be affected by this supplier delay?
• What stock is actually available?
• Which proposals have had no follow-up?
• Which invoices are still waiting for documents?
• What do we need to act on today?

If management needs somebody to manually reconstruct the business every time it wants an answer, that deserves attention. The problem isn't lack of information. It is that the information isn't usable when somebody needs it.

6. Nothing happens until someone remembers what comes next

Some workflows aren't difficult. They're fragile. The process moves because somebody remembers: "I need to chase this tomorrow." "I should check that order on Friday." "I need to send this for approval." "I promised that customer an answer."

And surprisingly, this works. Until volumes increase. Someone goes on holiday. The person gets interrupted. Or one item simply gets forgotten.

A process that depends on somebody's memory is worth reviewing — not because people are unreliable, but because memory was never designed to be a workflow-management system.

7. A small delay creates a much bigger business consequence

Not all wasted time is equally valuable to remove. A repetitive ten-minute task may be irritating but commercially harmless. Another ten-minute delay might mean a customer receives the wrong commitment, a shipment issue is discovered too late, production waits, cash collection gets pushed back, or management makes a decision using outdated information.

This is why your first automation should not necessarily be the task everybody complains about most. Ask: what happens to the business when this task is late, forgotten or wrong? That's where priority becomes much clearer.

What does a good automation opportunity look like in a real business?

Generic examples are useful. Real ones are better. Here are three situations from operational businesses where the problem wasn't lack of technology. It was what people still had to do around the technology they already had.

What should you NOT automate first?

This matters just as much as identifying what to automate. Not everything manual deserves automation. And technology will not rescue a process nobody understands.

Nobody agrees how the process should work

If three people perform the same task in three completely different ways, don't automate the confusion. First decide what the normal workflow should be. Then automate the parts that make sense.

The underlying information is unreliable

If your source data is consistently wrong, automating decisions based on it simply allows you to make mistakes faster. Fix the information first.

The process changes constantly

A workflow that is reinvented every week may simply be too immature to automate deeply. You need some stability before you can reliably remove manual steps.

Almost every case is an exception

Automation works best when there is a normal path and identifiable exceptions. If every transaction requires a completely different judgment, human involvement may remain the right answer.

The task genuinely requires judgment

Some things should remain human. Negotiating with a strategic supplier. Making an unusual commitment to an important customer. Handling a sensitive employee issue. Deciding whether to accept a commercial risk.

Technology can collect the information. It can highlight what needs attention. It can help somebody make the decision. That doesn't mean it should always make the decision.

Automating a bad process just makes the bad process run faster.

How do I decide which workflow to automate first?

Don't start with the biggest project. Don't start with the fanciest technology. Start with the problem that combines frequency, cost, predictability and business impact. Take one recurring workflow and ask seven questions.

1. How often does this happen?

Every hour? Every day? Every week? Once a month? A mediocre process happening 200 times a week may be much more valuable to fix than a terrible process happening twice a year.

2. How much time does it really consume?

Don't just count the main task. Count the checking, the follow-up, the corrections, the management interruptions, the report preparation, the duplicated work, the time spent asking somebody else for information. Those small pieces are often where the real cost lives.

3. How many people touch the process?

A 15-minute task involving six people can be more expensive than a one-hour task handled by one. And every handoff is another opportunity for waiting, misunderstanding, duplication, or something simply being forgotten.

4. Are the steps predictable?

Can somebody explain what normally happens? If the normal path is clear, you probably have something worth investigating. You don't need every exception to be automated. Often, the best design is to automate the normal work and make sure humans immediately see the exceptions requiring attention.

5. What happens when the process is late or wrong?

This is where automation priorities become business priorities. Does somebody lose 15 minutes? Or does a customer receive a wrong delivery promise? Does an invoice get paid later? Does production wait for material? Does management discover a problem only after it becomes urgent? The consequence matters more than the inconvenience.

6. Does the information already exist digitally?

If the answer is yes, that's encouraging. You may not need another huge system. The information might already exist in Odoo, SAP Business One, HubSpot, Xero, Excel, supplier documents, your CRM, your accounting platform, or another tool you're already paying for. The problem may simply be that the information doesn't move or become visible when somebody needs it.

7. What would your team do with the time they get back?

This question is frequently forgotten. Saving three hours is nice. But what happens to those three hours? More customers handled? More supplier negotiations? More sales activity? Faster customer responses? Better planning? Less overtime? Better management decisions?

The best first automation is usually not the most impressive one. It is the repetitive, expensive, predictable problem that happens so often that everybody has stopped questioning why they still do it manually.

Do I need to buy new software to automate my business?

Often, no. This is one of the biggest misconceptions around automation. Many business owners hear "automation" and immediately imagine another platform, another subscription, a new ERP, a massive IT project, six months of implementation, and employees complaining that yet another system has been added to their day.

Sometimes new software is necessary. But very often, the first question should be: are we actually getting enough value from the systems we already have?

Before buying software number eleven, look at the first ten. Your ERP may already know the order. Your CRM already knows the customer. Your accounting software already knows the invoice. Your spreadsheet may already contain the logic your team uses every day. Your supplier already sends the information. The data exists. But somebody still has to connect it all manually.

That is why many STREVIO projects do not begin by replacing systems already embedded in the business. We connect them. The objective isn't more software. It's more value from what you already have.

Can I just use Zapier, Make or another low-code automation tool?

This is where an important distinction needs to be made. If you are a solopreneur and want to automate a personal task, a low-code or no-code tool can be sufficient. You receive a form. You add a contact. You send yourself a notification. You copy information into a spreadsheet. One person depends on it. The consequences of failure are limited.

That is one problem. Running the operational processes of an SME is another one entirely. Once customers, orders, suppliers, inventory, finance and multiple employees depend on a workflow, you are no longer asking "Can I connect application A to application B?" You are asking: "Can the business depend on this process every day?" That requires a very different architecture.

A business process is not just a chain of triggers and actions

Imagine a trading company. A supplier confirms only 70% of a purchase order. Part of the stock is held at the supplier. Three customer orders depend on that purchase order. A shipment date changes. The ERP shows one quantity. A supplier document shows another. One customer has already been promised delivery next week.

Now the process needs to know: what quantity is really available? Which customers are affected? Which order has priority? Has this supplier already been chased? Has somebody already approved the exception? What if the supplier API fails? What if the same message arrives twice? What if one action succeeds but the next one doesn't? Who owns the exception? Who needs to be notified? What happens tomorrow when the situation changes again?

That isn't a Zap. That is business operations.

Execution limits matter when workflows become operational

Low-code platforms are built around individual scenario or workflow executions. Those executions have boundaries. Make's current documentation states that most module requests have runtime limits of roughly 40 or 60 seconds, and a paid scenario running beyond roughly 45 minutes is interrupted. Make itself suggests splitting large scenarios or reducing the amount of data processed when those limits are reached.

Zapier has similarly expanded its execution capabilities over time, but Zaps still have structural limits — a Zap is currently limited to 100 steps.

That may sound generous. Until your workflow needs to wait several hours, resume after approval, process hundreds or thousands of records, pause because a supplier has not replied, retry a failed external system, continue tomorrow, and retain the context of everything that happened previously.

That kind of work should not depend on keeping one visual execution alive. A properly orchestrated process persists independently of any individual task. Activities can start, stop, wait, retry, resume — and the business process itself remains intact.

Sequential processing becomes a real bottleneck

This is one of the most important architectural differences. Make's own documentation states that when multiple bundles are returned, the next bundle does not begin processing through the downstream modules until the previous bundle has gone through them. Its Router branches are also explicitly processed sequentially, not in parallel.

Imagine you need to process 150 records. Or check 150 orders. Or enrich 150 prospects. Or recalculate 150 supplier positions. With a standard sequential flow, the workflow moves through those items one after another.

A proper orchestration architecture can instead distribute independent work across a controlled worker pool: 150 jobs → queue → controlled parallel execution → individual results → aggregation. You might decide that 20 jobs can run concurrently because an external system allows 20 requests at a time. If job number 73 fails, you retry job 73 — you don't need to reconstruct the entire process. This is not merely "going faster." It is a fundamentally different approach to managing work.

Parallel execution alone is not orchestration either

Modern automation platforms do provide some parallel capabilities. Zapier's current Looping feature, for example, executes loop iterations concurrently. But it also has a maximum of 500 iterations, does not support nested loops, and has restrictions when combined with Paths and Sub-Zaps. Every action after the loop is also billed once for every iteration — a 500-item loop followed by one billable action therefore uses 500 tasks for that action alone.

So the question isn't simply "Can the platform run things in parallel?" The question is whether you have proper control over concurrency, queues, dependencies, rate limits, individual task state, retries, duplicate prevention, priorities, and the point at which all distributed work has completed. That is orchestration.

Real business workflows need memory and state

A normal trigger-action workflow does not remember your business. It remembers what you explicitly give it. If you want a low-code workflow to know what happened yesterday, whether something has already been attempted, who approved an exception or what the last supplier response was, you have to build and maintain that state somewhere.

Make offers Data Stores, which its own documentation describes as being similar to a simple database. But the storage allocation is tied to plan usage, and Make warns that changing a Data Store's structure can make existing information inaccessible. Its documentation also states there is no automated process to restore deleted Data Store records.

Storage is not the same thing as memory. And memory is not the same thing as business context.

A real operational system may need to know: what happened before? What action did we already take? What was the previous supplier commitment? Has this problem happened before? Who approved the last exception? What was the result? What should happen differently this time? That state needs to be intentionally designed. At STREVIO, operational context is part of the solution architecture — it is not something added afterwards because a trigger needs to remember what happened in another trigger.

Failure is not an edge case

APIs fail. Authentication expires. External applications go offline. Rate limits are reached. Network requests time out. Fields change. Connectors are updated. A service returns an unexpected response. This happens in every real system.

Make's own error documentation lists connection errors, authentication failures, rate-limit errors, module timeouts, incomplete data, duplicate data, storage problems and other failure modes. Some errors pause scenarios. Some require retries. Some can ultimately require manual resolution. Make also limits automatic incomplete-execution retries to three parallel retries per scenario. Zapier likewise maintains monitoring, replay and reconnection mechanisms because business automations fail in production — it also notes that a deprecated connector version may eventually cause affected Zaps to be paused if they cannot be automatically migrated.

The issue isn't that APIs are unreliable — all software depends on APIs. The issue is what happens when the API fails. A business-critical process needs to know what completed, what didn't, what should be retried, what should never be repeated, what requires a person, what customer or order is affected, and whether the process can safely resume. That's a business continuity problem — not a visual-automation problem.

Long waits expose another limitation

Real business processes don't always finish in minutes. A supplier may respond tomorrow. A manager may approve something after lunch. A customer might send a missing document next week. A shipment may need to be checked again in two days.

Zapier's Delay tool currently allows an item to be held for no more than 30 days. More importantly, Zapier states that if the Zap is changed while an item is waiting in a Delay, that run will not continue when the delay expires. That is perfectly manageable for a marketing reminder. It is a much less attractive property for a process representing a live customer order or business obligation.

In a durable orchestration architecture, waiting is part of the process state. You should be able to improve the system tomorrow without destroying the state of a customer workflow that started yesterday.

No-code history is not an operational audit trail

When something important happened six months ago, a business may need to know which information was available, which decision was made, which step failed, which employee intervened, and what the system did.

Zapier's current documentation says it guarantees a maximum of 60 days of Zap-run data in Zap History and displays up to 10,000 runs. Longer-term records need to be exported separately. For a personal automation, that may be perfectly acceptable. For core operational processes, the business may need a much more deliberate audit history. Operational visibility should be designed around the needs of the business — not around the retention limits of the automation tool.

"Just connect it to an LLM" creates another set of problems

AI makes this even more important. Today it is easy to connect a low-code platform to OpenAI, Anthropic, Gemini or another model. A document arrives. Send it to the LLM. Ask it what to do. Use the result in the next module. Now it looks intelligent.

Intelligence without architecture is not an operational system.

You still need to ask: what context did the model receive? What business information left your environment? Which provider processed it? What history does the model have? What happens if the model produces a bad response? Does somebody approve consequential actions? How do you trace why something happened? How does yesterday's outcome influence tomorrow's behaviour?

Make's own documentation distinguishes between its own AI provider, custom third-party AI connections and automatic provider connections. With custom connections, the customer pays the external AI provider separately for token usage; with some automatic connections, Make selects the AI provider. That doesn't automatically make the architecture insecure. But it does mean data governance must be deliberately designed. Adding an LLM module does not magically give the workflow secure business memory, accountability or a feedback loop. Those have to be engineered.

Low-code costs also change when volume changes

Another reason these tools look attractive initially is price. At small volume, the entry price can appear very low. But the economics of operational automation are driven by activity.

Make bills most non-AI modules according to the number of operations or credits consumed. Its own documentation gives a simple example: when a trigger produces 10 records and three subsequent modules process each one, those downstream actions multiply across the 10 bundles. Make's pricing page explicitly notes that a single scenario can consume anything from two credits to thousands of credits in a single run, depending on complexity and volume.

Zapier similarly charges successful action steps as tasks, and Looping multiplies downstream task consumption by the number of items processed. Collaboration and governance also move users into higher plan tiers — Zapier's current published plans, for example, separate the one-user Professional plan from Team and Enterprise tiers that add shared connections, SSO, permissions, observability and other controls.

The important question is not "How much does this automation cost with 100 transactions?" It is "What does this architecture cost and look like when our business is doing five or ten times the volume?"

Because the ideal automation should make growth easier. Not become progressively more expensive and fragile as soon as it succeeds.

The biggest danger: automation spaghetti

This is where many businesses eventually end up. One scenario handles leads. Another updates Excel. Another watches suppliers. Another sends reminders. Another stores temporary state. Another retries failed actions. Another checks whether the previous scenario ran. A database is added. Then some custom JavaScript. Then another webhook. Then a second scenario because the first is too large. Then someone who built the whole thing leaves the company.

And suddenly nobody completely understands what happens if one module is changed. You have removed some manual work. But you have created another operational system that itself needs to be babysat. That is the exact opposite of what automation should achieve.

Low-code automation and business orchestration are not the same thing

This is the distinction we believe matters. A low-code platform is fundamentally very good at saying: when this happens, do that.

An operational orchestration layer needs to understand something much bigger: what is happening across the whole business process, what state is it in, what should happen next, what can happen in parallel, what failed, what needs human intervention, and what is the business consequence.

For a solopreneur automating personal productivity, that difference may not matter. For an SME where employees, customers, orders, inventory, suppliers and cash flow depend on the process, it matters enormously.

A properly designed operational system needs:

• Persistent state — the process knows where it is and what has already happened
• Controlled concurrency — independent work can run in parallel without overwhelming external systems
• Queues and backpressure — work waits safely when a dependency cannot handle more load
• Idempotency — a retry doesn't accidentally create the same order, invoice or customer action twice
• Exception handling — problems are surfaced to the right person instead of silently stopping a scenario
• Recovery — individual activities can fail and resume without losing the entire workflow
• Human accountability — people remain responsible for decisions that genuinely require judgment
• Auditability — the business can understand what happened and why
• Operational visibility — managers see the state of the business, not merely whether a technical workflow ran successfully
• Business context — the system understands the relationship between the supplier delay, the purchase order, the stock position and the affected customer commitment

That is what STREVIO is built to deliver. We are not interested in building a clever collection of shortcuts. We build the operational layer that connects the systems, information and workflows your business already uses so the company can actually depend on them.

There is a difference between automating a task and orchestrating a business.

The real goal isn't automation

This is where a lot of technology conversations go wrong. Automation is not the business objective. AI isn't the business objective either. And orchestration is not the business objective. They are tools.

The objective is to make the business capable of doing more without its operational workload growing at the same rate. At STREVIO, we call that Operational Capacity: the ability to handle more customers, orders and work without proportionally increasing people, cost or complexity.

If an automation saves somebody three hours but those three hours create no useful business value, that's not particularly exciting. But if changing a workflow allows the same team to manage more orders, spot supplier problems earlier, answer customers faster, reduce mistakes, make decisions sooner, or spend more time selling — that's different.

The value isn't the automation. The value is what the business can do afterwards.

That is why STREVIO starts with the business problem. Not the technology.