At the start it works. You receive the order, open the invoicing program and write the invoice by hand. You copy the address into the courier’s platform, guess the weight, print the shipping label. You send an email to the supplier with what they have to prepare. Every now and then you update the stock from the spreadsheet. At five orders a day, all of this takes an hour and you do not feel it.
At thirty orders a day it no longer works. Not only because you run out of time. Mistakes grow with volume: an address copied wrong means a returned parcel and a customer on the phone, an invoice with the wrong VAT means a credit note, an outdated stock means an order for a product you no longer have. Each mistake costs more than it would have cost to make it impossible.
Below you will see the criterion for ordering your automations, the order that works in practice for a small store, the traps of each step, when to choose a plugin and when custom code, and how you measure that the investment has come back.
The criterion: how often, how long, how much a mistake costs
You do not automate what is most spectacular, but what you have the most to gain from. For every manual operation in the store, you look at three things:
- Frequency. How many times a day you do it. One operation per order at 30 orders means 30 repetitions a day. A monthly operation means one.
- Time. How long one repetition takes, including opening programs, copying, checking.
- The cost of a mistake. A returned parcel, a cancelled invoice, a lost customer, a fine.
Multiply the three and you have an order. You do not need precision, it is enough to see what comes out on top. And almost always the same thing comes out: the operations you do for every order. Then the daily ones, then the monthly ones. The most expensive mistakes are also in the per-order operations: a wrong report you redo, a wrongly issued invoice stays in the accounts.
What you do for every order: the first four automations
1. The invoice issued from the order
The order already has all the invoice data: customer, products, prices, discounts, shipping. Retyping them into another program is double work and the classic source of errors. The invoicing programs used in Romania (SmartBill, Oblio, FGO and similar ones) have an API, meaning the store sends them the order directly and receives the invoice back.
What the automation has to do: issue the invoice at the moment you choose (on confirmation or on dispatch), with the correct series, with the correct VAT on every line, with the company details when the customer is a business, and issue a credit note on return. The invoice arrives attached to the dispatch email, without anyone sending it by hand.
The trap is in the prices. The store may keep prices with VAT included, the invoicing program may expect prices without VAT, and the rounding differs. Discounts, coupons and gift cards must appear on the invoice exactly as they were applied in the cart, otherwise the invoice total does not match the amount collected. Test every combination before you go live: a discounted product, an order with a coupon, a partial payment with a gift card, free shipping.
2. The shipping label generated from the order
The second thing copied by hand for every order: the address into the courier’s platform. Sameday, FAN Courier, Cargus, DPD and the other large couriers in Romania have an API for generating the AWB, the shipping label with the tracking number. The automation takes the validated address, the phone number, the weight calculated from the products, the number of parcels, the pickup point and the cash on delivery amount from the order, the last one only when payment is on delivery. You receive back the tracking number and the label to print.
The most common trap is the locality. The customer writes “Sector 2” or “sector 2”, the courier has a single form in its list and rejects the others, sometimes silently, with no visible error message. The automation has to match the locality and the county against the courier’s list, not send the raw text. The second trap: orders with several parcels or with products from different suppliers, which leave from different places. A standard plugin makes one AWB per order. If you need one AWB per parcel or per supplier, this is your first specific rule.
3. Automatic statuses and emails
The customer who does not know where the parcel is calls or writes. Every call of this kind is lost time. The order goes through clear states: “processing”, “shipped”, “delivered”. Every transition sends an email. The dispatch one contains the tracking number and the courier’s link. The delivery one comes from the courier’s response, not from someone’s memory.
This step ties into the previous one: if the AWB is generated automatically, the tracking number is already in the order and the dispatch email goes out on its own. If the AWB is made by hand, someone has to copy the number back, and usually they do not.
4. Notifications to suppliers or the warehouse
If not all products ship from you, every supplier or warehouse has to find out what they have to prepare. The manual email gets forgotten and contains too much. The t-shirt supplier does not need to see that the same customer also ordered a mug from someone else, nor the address and phone number if they are not the one delivering.
The automation sends each supplier only their products, with the production details: size, colour, personalisation text, the artwork file, quantity, deadline. When they do not confirm within the agreed time, you get an alert, instead of the customer getting a late parcel.
What you do daily and monthly: the next three
5. Stock and prices from supplier feeds
If you sell products from someone else’s stock, the supplier gives you a feed: a file or an API with products, prices and stock, updated periodically. Checking it by hand, every now and then, means you sell products that have disappeared and display old prices.
The automation reads the feed at a set interval, updates the stock, applies your pricing rules (markup per category, VAT, rounding) and deactivates the products that have disappeared from the feed. It does not publish new products on its own, it puts them in a list to review.
Two traps, both expensive. First: many feeds contain list prices without VAT. If you take them as they are, you either sell below cost or apply VAT twice. The pricing rule is written once and tested on a few products with a calculator in hand. Second: the import that overwrites prices set by hand. You have a promotion or a negotiated price, the overnight import comes and wipes it. You need a “price set manually” checkbox on the product, which the import respects.
6. Abandoned carts and post-delivery emails
Only now comes the marketing part, because it pays off more slowly and assumes the previous steps work. A cart recovery email does not help if the parcel then arrives at the wrong place.
What is worth switching on: one or two emails after an abandoned cart, with the products from the cart and a direct link to checkout; a review request a few days after the delivery confirmed by the courier; for consumables, a restock reminder at the interval at which the product runs out. All of them go out from the store’s data, through an email marketing tool connected to it, not from a monthly export of addresses.
7. Reports straight from the database
Last on the list, because you do them once a month and a mistake gets corrected without consequences. But the report built from manual exports stops getting made after the third month.
What you want to see without working for it: sales per product and per supplier, the real margin after purchase and shipping costs, products with no movement for more than 60 or 90 days, orders late for dispatch. All of it exists in the store’s database. A report that reads it from there tells you what to order, what to take off the shelf and where margin is being lost.
Plugin or custom code
For every step above there are plugins. The question is not whether they are good, but whether your process is the one they were made for. At the start of an online store processes are usually standard and plugins cover a lot.
| Situation | Plugin | Custom code |
|---|---|---|
| One supplier, one parcel per order | Yes, usually enough | Not needed |
| Several suppliers, separate parcels, different pickup points | Hard or impossible | Yes |
| Personalisation with a price per option (text, dimensions, materials) | Partly, with compromises | Yes |
| Specific pricing rules, protected manual prices | Rarely | Yes |
| Invoicing with gift cards, partial payments, automatic credit notes | Depends on the plugin, test it | Yes |
The practical rule: a plugin when your process is standard, custom code when you have rules the plugin does not know. Custom code does not mean rewriting everything, it usually means a small module that sits on top of the plugin and solves exactly your rule: AWB per supplier, notification per supplier, the manual price checkbox. This is where API integrations with the courier, the invoicing program or the supplier come in.
One thing to clarify before you order custom code: ownership of the code. Code written for you has to be yours, with the source in your hands, documented enough that someone else can take it over if whoever wrote it leaves or closes the company. Ask this in writing, beforehand.
When you test integrations, watch what is live. A test copy of the store with the real API keys issues real invoices and real AWBs. Use test keys, and where none exist, a “check only” mode that shows what it would send without sending it.
How you see that it has paid for itself
You need three numbers measured before and after each step:
- Minutes per order. One person’s working time, from the order coming in to handing over the parcel. You time it on ten orders and take the average.
- Mistakes per month. Wrong addresses, returned parcels, corrected invoices, products sold without stock, “where is my parcel” emails. You count them, you do not estimate them.
- Time from order to dispatch. In hours. The store already has it in the order data.
An automation has paid for itself when its cost has been covered by the minutes saved and the mistakes that no longer happened. For invoicing and AWBs, at a few dozen orders a day, this usually shows within the first months. If after three months the numbers have not gone down, the automation is not doing what it should, or the process has stayed manual somewhere you have not looked.
A small store that automated in the order above got to the point where a single person processes in an hour what used to take a day, with AWB per supplier and invoices issued automatically. It is not a rule, it is an example of what you can expect. You will find more in the case studies.
Checklist
- Write down every manual operation you do for an order, from the moment it comes in to handing over the parcel.
- Next to each one put: how many times a day, how long it takes, what happens when it goes wrong.
- Start with invoicing from the order: the series, the VAT, the discounts, the gift cards and the credit note, all tested.
- Continue with the AWB from the order: locality matched against the courier’s list, weight from the products, cash on delivery only when payment is on delivery.
- Tie the statuses to the AWB: “shipped” with a tracking number, “delivered” from the courier’s response.
- Give each supplier only their products, with the production details, and an alert when they do not confirm.
- Switch on the feed import with the pricing rule written once and the manual price checkbox on the product.
- Only then abandoned carts, review requests and reports.
- For any rule the plugin does not know, ask for custom code, with the source in your hands.
- Measure minutes per order, mistakes per month and time to dispatch, before and after each step.
Take the next order that comes in and time it from the moment it arrives to handing over the parcel. Write down every manual operation and how long it took. That list is your automation plan, in the order in which it pays off.