Ask ten store owners what ecommerce automation costs and you will hear ten different numbers, because they are describing ten different things. One owner is paying nine dollars a month for an email add-on. Another paid an agency twenty thousand dollars for a rebuilt back office. A third spends four hours every Sunday copying order data into a spreadsheet and has never put a price on that time. All three are doing ecommerce automation, or failing to, and all three have a true cost that is easy to misjudge.
This guide gives you a way to put real numbers on the question for your own store. It explains the three ways automation is bought, what a build fee actually pays for, where the running costs hide, how to estimate payback with assumptions you can defend, and how to compare quotes without being dazzled by the lowest one. Where we quote prices, they are the published prices of Checkout Loom builds, because those are the numbers we can stand behind. Where we discuss other tools, we describe how they charge rather than quoting figures that change every few months.
The three ways store automation is priced
Almost every offer on the market falls into one of three models, and mixing them up is the commonest reason a budget goes wrong.
| Model | How you pay | Where it fits | Where it hurts |
|---|---|---|---|
| Subscription software | Monthly plan, often scaled by contacts, orders or tasks | A standard job that the product already does well, such as sending a welcome email | Cost grows with your volume and the software still needs someone to configure and watch it |
| Hourly or retainer work | Time spent, billed weekly or monthly | Open-ended improvement, ongoing advice, work whose scope you cannot define yet | The final cost is unknown until the work ends, and the incentive is to keep working |
| Fixed-price build | One agreed fee for a written scope, paid once | A job with a clear outcome, such as recovering carts or answering order questions | You must agree the scope up front, and changes outside it are priced separately |
None of these is better in the abstract. A store with a tidy process and a standard need should use software. A store that wants to experiment should pay for time. A store that knows exactly what should happen between its tools, and wants it tested, handed over and left alone, should buy a fixed-price build. Our own pricing page follows the third model, which is why every service shows its packages and its extras before you commit.
What a build fee actually pays for
A common mistake is to think of a build fee as the price of writing some automation. The writing is the smallest part. Most of the effort goes into things that are invisible when the work goes well and painfully obvious when it is skipped.
- Reading your setup first. Someone has to learn which apps you use, how orders move, which fields are reliable and which are not. This is where most hidden problems are found.
- Designing the rules. What triggers the automation, what stops it, what happens when two events arrive at once, and what a person decides rather than a machine.
- Building and connecting. The part people picture: connecting the platforms, writing the logic, drafting the messages or templates.
- Testing on your own records. Real orders, real edge cases, a refund in the middle of a sequence, an address that fails. A tidy demo never finds these.
- Monitoring and alerts. A job that fails silently is worse than no job. Alerts that name the step, the record and the cause take real design time.
- Handover. A written explanation of what was built, where the keys live and how to change a rule, so that you are not dependent on the person who built it.
When you see a very low quote, the useful question is which of those six items has been left out. Often it is testing and handover, and the cost reappears later as a failure on your busiest day or a bill to understand your own system.
Price bands for common store automations
The bands below come from the published packages of Checkout Loom services. Each service has three packages, and the calculator on its page adds options such as the store platform and optional extras. Use them as a map of how price scales with scope, not as a quote.
| Job | Entry package | Mid package | Largest package | Typical delivery |
|---|---|---|---|---|
| Abandoned cart recovery | $1,450 | $2,950 | $5,400 | 5 to 20 days |
| Order status updates | $1,640 | $2,990 | $5,300 | 10 to 42 days |
| Review request automation | $990 | $1,950 | $3,490 | 5 to 18 days |
| Customer support chatbot | $1,790 | $3,590 | $6,600 | 10 to 35 days |
| Inventory sync | $890 | $3,960 | $6,480 | 5 to 19 days |
| Returns and refund handling | $2,180 | $4,180 | $7,300 | 21 to 49 days |
| Ecommerce workflow automation | $2,260 | $4,260 | $7,300 | 15 to 70 days |
Package prices are the published Checkout Loom prices at the time of writing. The calculator on each service page shows the exact total for your platform and options.
Three patterns stand out. First, the entry package is a real, working automation, not a demo, and it is built for one store and one main platform. Second, price steps up with the number of moving parts: a second channel, a second language, an approval step, a warehouse system. Third, delivery time rises with price because testing takes longer when there are more systems to test against, not because anyone is slow.
Running costs: the part people forget
A fixed build fee is a one-off, but the automation then runs on tools that cost money, and it needs someone to notice when something changes. These running costs are usually modest next to the build, but a realistic budget includes them.
Platform and tool plans
Most automation runs on one or more services: your store platform, an email or text provider, a helpdesk, and sometimes a workflow engine such as Zapier, Make or n8n. These charge in different ways. Zapier counts tasks, Make counts credits, n8n counts workflow executions on its cloud plans or lets you host it yourself, and email providers usually charge by contacts or sends. The practical consequence is that the same automation costs different amounts on different engines, and volume matters. A good builder models your monthly volume on each option before choosing one, and writes the monthly cost beside the build fee. If a quote does not show the running cost, ask for it.
Message and usage costs
Text messages cost money per message, and the price varies by country and carrier route. Email is cheaper but is not free at volume. AI features, such as drafting a reply or summarising a ticket, are usually billed by usage. None of these is large for a small store, and all of them grow with sales, which is the correct direction: a cost that rises when revenue rises is easier to carry than a fixed cost that does not.
Monitoring and upkeep
Platforms change their interfaces, tokens expire, a supplier alters a file format. An automation that nobody looks at will eventually stop doing its job without telling anyone. Budget a small monthly amount for watching it, either your own time or a care plan. Our care plans start at $149 a month for the Watch plan, with Tune at $449 and Grow at $949 adding more hours and more review. They are month to month, so you can stop when you no longer need them.
A worked payback example
Costs only make sense next to what the automation earns or saves. Here is a worked example for abandoned cart recovery. Every input is an assumption, labelled as one, and you should replace them with your own figures before you rely on the result.
| Input (assumed) | Value | Why this value |
|---|---|---|
| Abandoned checkouts with an email captured | 2,400 a month | A store of about 1,600 orders a month where roughly 60 percent of started checkouts include an email |
| Average order value | $62 | Illustrative; use your own figure |
| Contribution margin after product, shipping and fees | 35 percent | Illustrative; recovery should be judged on margin, not revenue |
| Extra running cost | $120 a month | An email and text allowance plus a share of tool plans |
| Build fee | $2,950 | The Growth package of the abandoned cart recovery service |
The result depends heavily on the recovery rate, which is the share of abandoned checkouts that end in an order because of the sequence. Published figures vary widely and depend on the starting point, so the table shows a range rather than pretending to know yours.
| Recovery rate | Orders recovered a month | Contribution a month | After running cost | Payback on $2,950 |
|---|---|---|---|---|
| 1 percent | 24 | $521 | $401 | About 7.4 months |
| 2.5 percent | 60 | $1,302 | $1,182 | About 2.5 months |
| 5 percent | 120 | $2,604 | $2,484 | About 1.2 months |
Contribution = orders recovered x $62 x 35 percent. Payback = build fee divided by contribution after running cost. These are illustrative numbers, not a forecast.
Look at what the table says. Even at a pessimistic one percent, the build pays back inside a year. At five percent it pays back in about five weeks. But notice the assumption that does the heavy lifting: orders recovered must be incremental, meaning they would not have happened without the sequence. A cautious store measures this against a small group that receives no messages, so that the figure it reports is the extra revenue and not merely the orders that arrived after an email was sent. If you want to see how that sequence is built, our guide to why one abandoned cart email is not enough walks through it.
What pushes a price up or down
When two quotes for the same job differ, the difference almost always sits in one of these seven drivers. Knowing them lets you ask better questions and lets you reduce the price by simplifying the right thing.
| Driver | Raises the price when | You can lower it by |
|---|---|---|
| Number of systems | Five tools must agree on one fact | Choosing one source of truth and connecting fewer tools first |
| Data quality | Fields are missing, duplicated or inconsistent | Cleaning the worst fields before the build starts |
| Exceptions | Many special cases, such as bundles, preorders or split shipments | Starting with the common case and listing exceptions for phase two |
| Approvals | A person must check before anything is sent | Approving only risky cases, not every case |
| Languages and regions | Several languages, currencies or tax rules | Launching one market and copying the pattern later |
| Volume and speed | Bursts that hit API limits, or near real-time needs | Accepting a delay of a few minutes where it does not hurt |
| Compliance | Consent, retention and regional rules apply to the messages | Deciding policies before the build so they are not rebuilt |
The DIY option and what it really costs
Doing it yourself is a legitimate route, and for many small stores the right one at the start. The mistake is to treat your own time as free. Suppose you value an hour of your time at forty dollars, a modest figure for an owner who could otherwise be sourcing products or serving customers. A first automation that takes twelve hours to learn, build and test costs about $480 of your time, and a second one costs less. That is cheap compared with a build fee. The picture changes when the job is complicated, when it touches money or customer data, or when a failure is expensive, because your time is then spent on debugging rather than on the business.
- DIY works well when the task is standard, the failure cost is small and you enjoy the learning.
- DIY works badly when an error can double-charge, double-ship or email the wrong people, or when it must keep running through a busy season with nobody watching.
- A middle route is to build the simple parts yourself and buy the delicate ones, such as refunds, disputes and payouts, where a mistake costs more than the fee.
If you are weighing the two routes for a specific job, our short guide on how to brief a store automation shows what to prepare either way, and it makes a DIY attempt faster too.
How to compare quotes without being fooled
Quotes for automation are hard to compare because they describe the work differently. Ask every provider the same questions and put the answers side by side.
- What exactly will it do, in one paragraph? If the answer is vague, so will the work be.
- Is the price fixed, and what is outside it? Look for a written scope and a clear list of what counts as a change.
- What will it cost to run each month, on which tools? A provider who cannot answer has not modelled your volume.
- How will it be tested, and on what data? Testing on your real records is a sign of care; testing on sample data is a sign of haste.
- What happens when something fails? You want alerts that name the problem, and a stated way to re-run safely.
- What do I receive at the end? A handover document, access to what was built and no lock-in.
- What do you do after launch? Look for a fix period for mistakes in the work, stated in writing.
Where to start with a limited budget
You do not need a large budget to begin, and you should not spend a large one before you have evidence. These three stages describe how stores commonly sequence the work.
| Budget stage | What it buys | Examples |
|---|---|---|
| Under $1,500 | One narrow, high-return job, or an audit that ranks your options | A review request flow, a deadline board for disputes, a catalogue audit |
| About $1,500 to $5,000 | One complete automation with testing, alerts and handover | Cart recovery, order status updates, a support chatbot answering from your policies |
| $5,000 and above | A connected system where several jobs share data and rules | Orders, inventory and suppliers working from one stock truth, or a full returns programme |
Choosing the first job matters more than the size of the budget. Pick the one where the cost of the problem is easy to measure: recovered orders, support tickets removed, hours saved on a weekly task. Our companion guide, what to automate first in an online store, ranks jobs by payback so that the first build earns the right to fund the second.
When automation is not worth buying yet
Honesty about this helps you more than a sales pitch. Automation is not worth paying for when a process is still changing every month, because you will pay to rebuild it. It is not worth paying for when volume is so low that a person handles the job in minutes, such as a store that ships three orders a week. And it is not worth paying for when the underlying problem is not a process at all but a product, price or traffic problem that a better workflow will not fix. In those cases, spend the money where it will move the numbers, and revisit automation when the same task has become a weekly chore that you dread.
A budget template you can copy
To turn this guide into a decision, fill in this short list for the one job you are considering. It takes about ten minutes and it is the same information any serious provider will ask for.
- The job in one sentence, for example: send a helpful sequence to shoppers who leave a checkout with an email address.
- The monthly volume, such as abandoned checkouts, support tickets, orders to route or refunds to process.
- The current cost, in hours a week multiplied by the value of those hours, or in revenue lost.
- The expected gain, as a low and a high case with your assumptions written beside each.
- The build fee and the monthly running cost, from the quotes you gathered.
- The payback in months, with a note on what you will measure to confirm it.
If the payback is under about six months in the cautious case, the job is a strong candidate. If it only works in the optimistic case, either shrink the scope until it works in the cautious one, or pick a different job first. Either way you now have a written case, and that is what protects you from paying for activity.
Sources and further reading
We name the pages used so that you can check them. Tool prices change often, so read the current page before you budget.
- Baymard Institute, cart abandonment rate statistics, context for abandonment and why recovery rates vary
- Zapier pricing, how task-based billing works
- Make pricing, how credit-based billing works
- n8n pricing, how execution-based billing works