Ecommerce automation — what to automate first and how to calculate ROI

Ecommerce automation works best where a process is event-driven and rule-based — an order status change triggers an email, a payment triggers an invoice, a stock drop triggers an alert. Where a process needs human judgement — negotiating with a B2B customer, deciding on a discount, handling a complaint without a clear rule — automation will not replace the person doing it, only hand them the data faster. This article covers what genuinely belongs in an automated workflow, what the tools that run it cost, and how to calculate the return on that investment in hours, not in a promised percentage.

What is worth automating, and what is not

The rule is simple: you automate events, not decisions. An event has a clear trigger and a clear outcome — "order paid" triggers "generate a shipping label and send the tracking link"; "order fulfilled" triggers "generate an invoice and email the PDF"; "stock below threshold X" triggers "notify whoever is responsible for reordering." In each case, the system is not judging anything — it checks a condition and runs a predefined action.

A decision needs judgement: whether to give a customer a discount outside the price list, whether to accept an unusual complaint, whether to accept non-standard B2B order terms. Trying to automate these with if-this-then-that rules tends to go one of two ways — either the system rejects cases the rule did not anticipate (and the customer still writes to support, just later and more frustrated), or the rule grows so complex that maintaining it costs more time than handling those cases manually.

The practical test before automating any given process is two questions: how often does it happen, and can it be described with one fixed rule? High frequency and a clear rule — automate it first. High frequency but a rule that changes case by case — automate only part of it (generate a template, let a person adapt it). Low frequency — automation will not pay back the implementation cost regardless of how clear the rule is.

Examples that satisfy both criteria at once:

• Order status changes — "paid" triggers generating a shipping label; "shipped" triggers an email or SMS with the tracking number; "delivered" triggers a review request a few days later.
• Invoices — "order fulfilled" in your ERP triggers generating an invoice and emailing the PDF to the customer, with no one clicking through the admin panel once a day.
• Stock alerts — a specific SKU dropping below a set threshold triggers a notification to whoever reorders from the supplier, before the product disappears from the storefront.
• Post-event communication — an email or SMS sent automatically after a specific event (not in response to a customer question), such as an order confirmation or an abandoned-cart reminder (with the consent caveat covered in the section on marketing consent below).

The common thread across these four examples: the trigger is unambiguous (a specific change in a system), and the action needs no situational judgement at all — just the same step, every time.

Ecommerce automation tools — what Zapier, Make and n8n cost

Before you pick a tool, it is worth knowing what you are actually paying for on the higher plans — not the number of supported integrations. On Zapier and Make, higher plans mainly differ by how often the system checks whether something has changed; n8n differentiates plans by the number of workflow executions.

Zapier bills in "tasks" and shows prices billed annually by default. In Zapier's words, "each successful action in a Zap counts as a separate task"; failed actions are not counted, "triggers don't count toward your task limit", and Zapier "never charges you a task to check for new data". The Free plan is $0/month, 100 tasks a month, two-step Zaps only. The Professional plan starts at $19.99/month billed annually ($29.99/month billed monthly) at the lowest tier of 750 tasks, with multi-step Zaps. The Team plan starts at $69/month billed annually ($103.50/month billed monthly) at the 2,000-task tier, with 25 team seats. Enterprise is quoted individually. Polling frequency (how fast Zapier notices a new event) improves with the plan: 15 minutes on Free, 2 minutes on Professional, 1 minute on Team and Enterprise. Source: zapier.com/pricing, read 2026-10-05.

Make (formerly Integromat) bills in "credits". According to the price list, each module action in a scenario — such as adding a row to a Google Sheet or fetching data from a Gmail account — "counts as one credit", including reading data from an app or a webhook; the page no longer uses the older term "operations." At the default tier of 10,000 credits a month: Free — 1,000 credits, $0; Core — $9/month billed annually ($10.59/month billed monthly); Pro — $16/month; Teams — $29/month; Enterprise — quoted individually. The minimum schedule interval (how often a scenario can run) is 15 minutes on Free and 1 minute from Core upward — the same differentiation mechanism as Zapier. Source: make.com/en/pricing, read 2026-10-01 (the $9/$16/$29 prices at the 10,000-credit tier re-confirmed 2026-10-05).

n8n bills in euros, by the number of workflow executions per month, regardless of how many steps are inside — "pricing based on monthly workflow executions, regardless of complexity." The Starter plan: EUR 20/month billed annually, 2,500 executions, up to 5 concurrent. The Pro plan: EUR 50/month billed annually, 10,000 executions, up to 50 concurrent. The Business plan: EUR 667/month billed annually, 40,000 executions — but available self-hosted only, not as a hosted Cloud plan, even though it is listed on the same price page. The pricing page describes the Community Edition as "a standard, self-hosted version of n8n" that "is available on GitHub", with no price shown. Source: n8n.io/pricing, read 2026-10-05.

Base.com, a Polish integration and warehouse aggregator for marketplaces, also differentiates its plans by sync frequency. The Freemium plan (PLN 0) syncs stock hourly, handles up to 100 orders a month and 1,000 products, and keeps data for 6 months. The Business plan (PLN 279 fixed fee + PLN 0.99 per order, net) syncs in real time, with no product limit, a repricer and 24 months of data retention. Enterprise is quoted individually for stores with more than 5,000 orders or PLN 1 million GMV a month. Source: base.com/pl-PL/cennik/, read 2026-10-05.

The practical conclusion: if you are choosing between these tools, do not count only the number of supported integrations — check how often the higher plan actually checks for changes. For a store with high stock turnover, the difference between a 15-minute and a 1-minute check can matter more than the subscription price itself.

Before paying for any of these tools, check your store platform's own documentation for built-in "if event, then action" rules — for a simple event touching one external system, an outside tool can turn out to be unnecessary.

One process, three price lists — how to compare them

The same workflow uses up a different billing unit in each tool, so list prices are not directly comparable. Take an example process: new order (trigger) → shipping label from the carrier → email with the tracking number → a row in a reporting spreadsheet. That is one trigger and three actions. The breakdown below is our illustration based on the rules in each price list, not a quote for any particular store.

• Zapier counts tasks, and the trigger uses none. Three actions are 3 tasks per order; at 1,000 orders a month, 3,000 tasks. That is four times the lowest Professional tier (750) and above the Team starting tier (2,000), so check the price of the higher tier on the pricing slider.
• Make charges a credit for every module action, including reading data from an app. If the trigger module fetches the order and three more modules perform actions, that is at least 4 credits per order, so around 4,000 credits a month — within the 10,000-credit tier at which the price list quotes plan prices. How many credits polling the store itself consumes depends on how the scenario is configured; check the execution history after the first week.
• n8n counts one execution for the whole run of a workflow, however many steps it has: 1,000 orders are 1,000 executions, within the Starter plan's limit (2,500).

The takeaway: the more steps your typical process has, the more a per-execution model pays off; the fewer events you have, the less it matters which tool you pick.

How to calculate automation ROI — time, not a promise

The ROI of sales automation is not a percentage you can quote upfront — it depends on how many events touch the process, how many minutes it takes to do manually, and the hourly rate of the person doing it. The formula below uses explicit variables you fill in with your own numbers — there is no result for any specific store here.

Input variables:

• N — number of events per month (e.g. orders going through a given process)
• m — minutes of manual work per event today
• R — hourly rate of the person doing that work (PLN/h)
• K — monthly cost of the tool that would automate it (PLN/month)

Formula:

Monthly saving (PLN) = (N x m / 60 x R) − K

If you want to add a second effect — fewer support tickets thanks to faster status communication — add an analogous term with the number of events, the handling time per ticket, and the same rate R. The sum of both terms minus the tool cost is the full monthly gross gain; dividing the one-off implementation cost by that gain gives you the number of months to payback.

A purely illustrative substitution, to fill in with your own numbers — not data from any specific store: at N = 1,000 events, m = 2 minutes, R = PLN 70/h and K = PLN 300/month, the monthly saving is (1,000 x 2 / 60 x 70) − 300 = PLN 2,333 − PLN 300 = PLN 2,033. If implementation (setting up the automation) cost, say, PLN 2,000 once, payback comes out under a month — but that follows purely from the substituted numbers, not from observing any client; your own N, m, R and K can produce a completely different result, and that is the point of this formula: calculate on your own data, not someone else's.

If, after substituting your own numbers, payback comes out longer than a few months for a process that touches every order, that is a signal that either the process is too small (low N) or the chosen tool is oversized for the need (high K relative to the saving). In both cases it is better to change the variable than to settle for a weak return.

It is also worth costing implementation more broadly than just the tool subscription. Besides the monthly K, the one-off implementation cost (configuring the scenario, testing, any outside help) also belongs in the payback formula — and that cost, not the subscription itself, can decide whether automation pays back in months or in a year. Add maintenance cost on top: every API integration you connect can "break" after an update on either side (a change in a carrier's API, a change in your ERP) — the time needed to fix such an outage is a real, recurring cost, even though it has no line item in the tool's price list. Good practice: set up a simple failure check (an alert when the automation has not run in the expected window), so you spot an outage before your customers do.

Marketplaces — a separate automation

If you also sell on Allegro, Amazon.pl or another marketplace, automating order statuses and stock levels there works under different rules than in your own store — synchronization has to account for feed delays, the platform's API limits and the risk of a duplicate order if the same item sells in parallel in two places. It is a separate enough topic, with its own integrators (in Poland, for example, Base, Sellasist and Apilo) and its own synchronization logic, that it does not belong condensed into one paragraph here — a full look at Allegro integration and stock-sync frequency is in our Allegro and marketplace integration article.

Consent for automated marketing emails and SMS

Automating post-event communication (such as an email or SMS after an order status change) rests on two different grounds that are easy to confuse. If a message is purely transactional — an order confirmation, a tracking number, an invoice — it is communication necessary to perform the contract, with no extra consent requirement on the channel itself. If a message is marketing in nature — an abandoned-cart reminder with an incentive to finish the purchase, a product recommendation, a promo code — the EU ePrivacy Directive (2002/58/EC) applies, and in Poland it is implemented by the Electronic Communications Law (Prawo komunikacji elektronicznej, Journal of Laws 2024, item 1221). Article 398(1) bans using automated calling systems and telecommunications terminal equipment to send commercial information, including direct marketing, to a subscriber or end user unless they have given their prior consent.

The Polish text does not copy the Directive's soft opt-in for existing customers. Under Art. 398(2), consent can be given by providing an electronic address for the purpose of receiving commercial information at that address — what counts is the purpose, so an email address entered in the order form without a stated marketing purpose is not that consent. Sending must not be at the end user's or subscriber's expense (Art. 398(3)), and a breach is an act of unfair competition (Art. 398(4)) — a ground for liability separate from the GDPR.

The practical takeaway for automation: before you connect a marketing flow to an event like "added to cart," check that the customer ticked consent to commercial communication on that channel — it is not enough that their email address reached your system during checkout.

When you need a custom integration

The no/low-code tools described above make sense as long as a process can be assembled from ready-made blocks — trigger, condition, action. The point at which a custom-built integration (a dedicated API, event queues) is worth considering is when: the number of events per month is large enough that the per-execution cost in a no-code tool (as in n8n or Make) exceeds the cost of your own integration over a year; the process needs conditional logic too complex to maintain reliably in a visual editor; or you need a delivery guarantee (no status change can ever "get lost" during a brief outage of one of the systems involved), which off-the-shelf connectors do not always provide. In those cases, a dedicated process automation build can pay back faster than keeping on expanding a scenario inside a no-code tool.

A warning sign that a no-code scenario has "outgrown" its tool: the same process is split across several separate scenarios that have to run in a specific order, and an error in one of them (such as a carrier API timeout) stops the entire chain with no clear record of which orders were processed and which were not. That is the point at which a dedicated integration with its own error handling and event queue starts costing less to maintain than one more layer of scenarios in Zapier or Make.

Where to start

Before picking a tool, do a short review of your own processes: which events are the most frequent, which of them have a clear, stable rule, and how many minutes of manual work they actually take today. Pick the one process with the highest product of frequency and rule simplicity — labels and tracking, or invoice generation, are common choices — and run the ROI formula above for it before connecting any tool. If the result looks favourable, roll out one automation at a time, measure the effect after a month, and only then add the next layer.

This article covers automation specific to ecommerce — events tied to an order, stock levels and communication with the buyer. If you are looking for a broader view of business process automation beyond the store itself (document handling, internal processes, HR), see our general article on business process automation — that article is not limited to ecommerce and draws examples from other industries.