Online store automation does not start with picking a tool, it starts with the list of things your support team clicks by hand for the hundredth time this month. Almost every store owner I talk to keeps that list in their head and has never written it down. And as long as it stays unwritten, the conversation drifts to tools: Zapier or an ERP, cloud or self-hosted. That is the wrong order. A tool is cheap and replaceable. Your team’s hours are not.
This post is about sequence. Not about what can be automated in a store, because almost everything can, but about what to take off people’s hands first so the effect shows up this month rather than next quarter.
Online store automation - what to take off your team first
I always run it the same way. I ask for one week of note taking: every action performed in the store admin or the shared inbox, with a tally mark for each repeat. After a week there is a list with numbers on it, and everything from there is arithmetic.
From that list I only look at the items that meet three conditions at once:
- They repeat at least a few times a week. Something done once a quarter will never pay back the cost of building it, no matter how irritating it is.
- They follow a clear rule. “Order paid, so issue the invoice” is a rule. “Depends on what the customer wrote in the notes” is not a rule, it is a decision.
- They cost something when a person gets them wrong. A typo in a tax number on an invoice, or a tracking number nobody sent, comes back as an email, a phone call and a complaint.
Items that meet two out of three go on the “later” pile. Not because they are impossible, but because on the budget a typical store has, the first automation has to justify itself. Start with the hardest process and the money runs out before anyone sees a result, which is how the whole subject quietly dies.
Invoices, statuses, emails, stock - the four that pay back fastest
The same four almost always come out on top of that week of notes. I am listing them in the order I usually build them, because each one is harder and more expensive than the one before.
First: automatic invoicing. This is the simplest and most rewarding place to start. The store does not issue invoices itself, it hands the data to your accounting system, which creates the document and emails it to the customer. A plugin exists for every common accounting platform, setup is measured in hours, and an entire category of work disappears from support along with the “when do I get my invoice” questions. I wrote the details up, including receipts and credit notes, in the post on automatic invoices in WooCommerce.
Second: order statuses and customer notifications. Order automation at this level means one thing: the customer hears about a change before they think to ask. Order packed, label printed, parcel on its way - each of those moments is a ready-made message as soon as your store talks to the courier system. The effect is visible right in the inbox, because “where is my parcel” is usually the single largest category of tickets in a shipping business.
Third: transactional emails that actually arrive. People skip this one because it looks already done. The store does send emails, after all. Except some of them land in spam or never leave at all, and support resends them by hand without realising they are patching a hole. Before you add another automation, check whether the previous one is being delivered. The usual causes and the order to check them are in the post on a store that stops sending order emails.
Fourth: stock levels. The most profitable one, and also the first one where you can genuinely hurt yourself. As long as you sell in a single channel, it is enough that the store subtracts units when an order comes in. Add a supplier, a marketplace or a brick-and-mortar till and you are into real synchronisation with its classic traps, including the update loop where two systems keep correcting each other forever. I covered those in the post on keeping stock in sync.
Sequence matters more than the choice of tool
I see one repeating mistake. Automation gets started on the process that annoys the owner most, rather than the one that hits the support team most often. Those are two different things. The owner is annoyed by the sales report compiled once a month. The team is eaten alive by retyping the same data twenty times a day.
The second rule is simpler still: one automation at a time, with a week of watching it. Roll out three at once and when something drifts, you have no idea which one drifted. Roll out one and the first odd order tells you exactly where to look. A week of delay at the start is cheaper than a week of hunting through three connected systems.
The third point follows from the first two and concerns tools. Store automation has three levels: a ready-made plugin from the vendor, a connector such as Zapier or n8n, and finally an integration written for your company. You always start at the highest level of readiness, which is the plugin, and you drop a level only when the ready-made option cannot do what you need. Where each level makes sense and how the bills look after a year is something I compared in the post on connecting a store to a CRM with Zapier and n8n.
What I do not automate
The list of things I leave to people matters as much as the list of things to build. Replies to unusual complaints, decisions to make an exception to your own terms, conversations with a wholesale customer about conditions - all of it looks repeatable until you write down the actual cases from the last quarter and discover every one of them was different.
I also avoid automating a process that is still taking shape. If the way you pack orders changed three times this year, building an automation around it is work destined for the bin. The process settles in human hands first, then it moves to the machine. The reverse order is the most expensive way to discover that the process was wrong.
And one more: I do not automate anything on a store with no backups and no test environment. An automation runs unsupervised by definition, so the mistake a person would catch on the third order gets repeated across every order all weekend.
What it costs and where to start
Concretely, because everyone asks. A single automation built on a ready-made plugin is a matter of hours of configuration and testing, not weeks. Larger projects, where the store talks to accounting, the warehouse and the courier, I quote fixed-bid and they usually land between 5000 and 10000 PLN net for a scope agreed in writing before we start. Keeping what already runs alive goes into a technical care plan: Basic 1000 PLN, Pro 2000 PLN, Premium 3500 PLN net per month.
When does it pay back? Work it out yourself, because only you have the numbers. Take one item off the list, multiply the time of a single run by the number of repeats per month and by the hourly cost of the person doing it. Put that next to the one-off price of building it. For invoices and statuses the arithmetic is usually decisive enough that it needs no polishing. For stock, add the cost of one bad day: goods sold that you do not have, and a customer who will not come back.
Where to start in practice: write down one week of your team’s work, pick a single item from the top of the list, check whether a ready-made plugin covers it, and give it a week on live traffic before you move to the next. If you would rather not guess which item to take first, that is exactly the kind of work I do under development and optimisation - I go through the list with you and say plainly what is an afternoon with a plugin and what has to be written.
Frequently asked questions
Does automating the store mean I have to let someone go? In practice, no. At the clients I know, the same person stops retyping data and starts answering pre-sales questions or handling wholesale accounts. Automation removes mechanical work, not contact with people, and contact with people is usually where the sales are.
Where do I start if the budget is genuinely small? With invoices. It is the only one of the four that most stores can switch on with a ready-made plugin and verify within a single day, and the effect shows up immediately in the support calendar.
Will automations slow my store down? Done properly, no, because they run in the background and do not make the customer wait on an external system. The ones that do slow things down are those polling the store constantly or running a heavy operation the moment a customer clicks. If the store is already sluggish today, reverse the order: performance first, automation second.
Can I start with a ready-made tool and move to a custom integration later? Yes, and that is the normal path. The ready-made version shows you whether the process works the way you assumed and writes you a list of gaps along the way. That list is then the best possible scope description for an integration built for your company.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.