5 automations that save 10 hours a month in a small e-shop

Conversations about e-shop automation almost always start at the wrong end: platforms, integrations, «AI agents». In practice, the time a small store loses is not lost in one big place. It is lost across five or six small jobs you do by hand every week, always the same way, and that nobody ever writes down because each one is «ten minutes».

This article is not a list of ideas. These are five automations running in production on antoniadis.com.cy, a PrestaShop store with more than 6,000 active SKUs, our own e-shop, where we test everything before we charge anyone else for it. For each one: what problem it solved, roughly how many hours it used to eat, what it takes to set up, and whether it already exists or has to be built.

A note on the numbers: the hours are our own estimates from our own use, not stopwatch data. In your store they will be different. We give them rounded, because we do not have the precision that would justify decimals.

The short answer

• The five automations together add up to roughly 10 hours a month on our store: not from one big job, but from five small ones that keep coming back.
• Three of the five are ready-made subscription tools: the sold-out report, account statements, and marketplace order monitoring. Starter €19 and Pro €39 per month excluding VAT, with free setup until 31/12/2026.
• Two are custom and we do not sell them off the shelf: availability monitoring at a supplier with no API, and price comparison across suppliers. Every supplier has a different site, a different currency, different rules.
• The most profitable one is not the most impressive one. The sold-out report is a single email per week, and it is the one that changed the most.
• The most dangerous one is the one that writes to your stock. Set up without safeguards, it will close products that are selling, and you will not notice for days.

1. A weekly sold-out report, grouped by supplier

The problem. Every Friday you opened the admin, filtered the week’s sales, looked at which products had dropped to zero, then grouped them by supplier so you could send five purchase orders. The work was always identical: one filter, one sort, copy into a spreadsheet. The difficulty was never the issue. The issue was that when you skipped a week, you found out from the customer asking when something would arrive.

How many hours. About half an hour a week, so roughly 2 hours a month. Counting the weeks it got skipped and paid for later in lost sales, more.

What it takes. API access to the store, a reporting period, and, if you want the grouping, a supplier field on your products. There is a real platform difference here: PrestaShop has a proper supplier field, WooCommerce does not, so the report comes back as one flat list instead of five groups. It also needs a clear definition: «out of stock» means nothing on its own, it means «sold during the period and is now at zero».

This one exists. The Sold-Out Products Report is one of our Everyday Tools, for PrestaShop and WooCommerce, with a choice of frequency and file format: Excel, CSV or PDF.

2. Account statements as PDFs, one per customer

The problem. If you also sell wholesale, month end carries a job that does not tolerate improvisation: one account statement per customer, with the open invoices, the total and the payment details. With thirty customers that is the same motion thirty times: filter, copy, export a PDF, write an email, send. And if you get one wrong, you hear about it by phone.

How many hours. Roughly 2 hours a month, concentrated into an afternoon that cannot be moved.

What it takes. An invoice export from your accounting software, and this is where the work hides. The columns are never the same, amounts arrive as «€ 18,944.73» with whatever decimal separator your software prefers, and dates are sometimes day-first and sometimes not. An automation that guesses here is worse than doing it by hand: the column mapping is suggested automatically but always confirmed by you, and anything that does not parse cleanly stops with an error instead of sliding through on a silent assumption. It also needs SMTP for delivery, your logo, and, non-negotiably, an approval step: you see what is about to go out and to whom, and then it goes.

This one exists. Account Statements produces one PDF per customer with your own branding, and sends them after you approve.

3. Availability from a supplier with no API

The problem. The large suppliers give you an API. The local one, who stocks half of what you sell, gives you a website. The result is products that look available on your store and do not actually exist, until somebody orders one and you are the one making the phone call.

How many hours. This is the hardest number to estimate, because it is not one job but a constant interruption: spot checks on the supplier’s pages, phone calls, cancellations, explanations. Roughly 3 hours a month, and it is the most unpleasant hour of the five, because it lands on top of a customer.

What it takes, and this one is not a product. It is not sold off the shelf and it cannot be: every supplier has a different site. Three things are needed:

1. The supplier’s pages have to be readable. In the best case they carry Product structured data inside server-rendered HTML, with sku and offers.availability: then a plain HTTP request is enough, with no browser automation. It is the same technology we describe in structured data for an e-shop, here from the other side: you are reading it instead of emitting it. If the supplier loads availability with JavaScript, the cost triples.
2. A mapping from supplier code to product. If the supplier’s reference is already stored on your products and the site’s search works in plain HTML, the mapping can fill itself in, but only after confirming that the page’s code is exactly the one you expected. Otherwise, by hand, once.
3. Safeguards, far more than you would expect. This is the only automation on the list that writes to your store, so the only one that can do real damage. What works in practice: two canary pages with a known answer before every run, and if they do not come back correct the supplier is skipped with no writes at all; closing a product only after two consecutive runs that agree, but reopening it immediately; a cap on how many products may change in a single pass; and a network error or a 403 always meaning «no change», never «out of stock».

The right standard here is not completeness, it is conservatism. A monitor that catches 80% of changes and is never wrong is worth far more than one that catches everything and once a month closes fifty products because a CSS class changed.

4. Price and availability comparison across suppliers

The problem. The same component exists at four suppliers. One has it cheaper but on backorder, another more expensive but in stock, and the prices are in three currencies. To answer «where do I buy this one this week» you open four portals.

How many hours. Roughly 1.5 hours a month, fewer than you would think, because in reality you were not doing it. The most common answer was «same place as last time», which is a silent cost rather than hours on a clock.

What it takes, also custom. An API or feed per supplier, and that is the expensive part: different authentication, different response shapes, different rate limits. It also needs currency conversion at the official rate for the day, not a constant in a config file, otherwise the comparison starts lying within six months. And a field that answers «which supplier is syncing this product right now», because without it the report shows you options you cannot use.

The most important decision here is that the report changes nothing. It is strictly read-only: it produces the table, and switching a product to another supplier is done by a human, with one field in the admin. An automation that picked the supplier by itself on price would be more impressive and clearly worse.

5. A notification for every new order, where you will actually see it

The problem. A marketplace order does not always send an email, or it sends one that gets buried. If you sell on two or three platforms, the solution everybody lands on is opening the panels five times a day. Meanwhile response time matters, and on some platforms it is formally measured.

How many hours. Two or three minutes at a time, five times a day, for nothing most of the time: roughly 1.5 hours a month of clock time, and considerably more in broken concentration.

What it takes. API access to the platform and a channel you actually read. Email is the worst choice here, precisely because your email is already full. A Telegram group or a Slack channel works far better, for the simple reason that it is empty until it pings.

This one exists. The Marketplace Order Monitor covers Jinius and any Mirakl platform, with notifications to Telegram, Viber, Slack or email.

Notifications to the customer are a separate conversation. There the subject is not your time but questions that never get asked: in the 100 conversations from our own chatbot, «where is my order» was only 6%, but 53% of conversations started outside opening hours, meaning anything answered automatically is answered the moment it is asked. For communication inside the store itself, our PrestaShop Modules cover the most common cases: a WhatsApp/Viber button at €19, and a back-in-stock notification that is currently in development.

What each one saves, at a glance

Automation	Hours/month (estimate)	Off the shelf?	What it takes
Sold-out report by supplier	~2	Yes, €19 / €39	Store API, supplier field
Account statements as PDFs	~2	Yes, €19 / €39	Invoice export, SMTP, approval step
Supplier availability monitor	~3	No, custom	Readable pages, code mapping, safeguards
Supplier price comparison	~1.5	No, custom	API per supplier, official exchange rate
New order notification	~1.5	Yes, €19 / €39	Platform API, a channel you read
Total	~10

Prices are monthly subscriptions excluding VAT, in a Starter and a Pro tier, with free setup until 31/12/2026.

Where to start

Do not start with the automation carrying the biggest number. Start with the one you already do by hand, every week, always the same way. Two reasons: you know exactly what the correct output looks like, so you will catch a mistake immediately; and you have a real baseline, so in a month you will know whether it was worth it.

The rule of thumb we apply: if a job takes you more than half an hour a month and its shape does not change, it is worth automating. If it changes every time, it is not an automation: it is a decision, and decisions stay with a human.

And one warning nobody selling automation tends to offer: every automation is code, and code breaks. The supplier’s site will change, the API will ship a new version, the accounting export will grow a column. That is not a reason to skip it: it is a reason to build it with safeguards and with an email that tells you when something went wrong, instead of staying quiet. An automation that fails loudly is an asset. One that fails silently is a liability.

If you want to work out which of these fit your own setup, our Everyday Tools are the cheapest place to start, or get in touch with the job you want to stop doing.