Saturday, around midday, shortly before the shop closes. A woman comes in and asks for the blue dress in a size 38. She tries it on, it fits, she pays and leaves happy. It was the last one.
On the e-shop, though, the dress still shows as available. Nobody updated it. And who would? It is Saturday, the shop is closing, everyone is in a hurry to leave.
In the evening an order for the same dress arrives through the e-shop, paid by card. On Monday morning someone opens it, goes to the shelf, and the shelf is empty.
You know what comes next: a phone call nobody wants to make, the money back on the card, and a customer who may shop somewhere else next time. And “may” is the polite version.
It is not the fault of the person who forgot
The first reaction is to find out who forgot to take the product off the e-shop. Someone always forgets. But when people update stock by hand in two different places, the mistake is not an accident. It is a matter of time.
The shop’s till knows the dress was sold. The e-shop does not. Two systems, two truths, and the e-shop customer sees the wrong one.
That is usually when someone says: “Let’s connect the e-shop to the stock system."
"Connecting to the stock system” is not just a cable
The idea is right. The wording, though, hides half the problem. It makes it sound as if you just run a cable between two machines and everything works on its own from then on.
In reality, the connection is first of all an agreement: which system holds the truth about stock, and what happens with every movement that changes it. A sale is the easy case. The hard cases are the ones before a sale is complete, or after it:
- The order that has not been paid yet, for example when the customer chose bank transfer. Does it reserve the item? And for how many days?
- The order that was cancelled. Does the item go back into available stock at once, or does it wait for someone to look at it?
- The return. Does the returned item go back on sale at once, or is it first checked to see if it is in good condition?
None of these is a technical question. They are decisions for your business. If you do not make them, they will be made silently by whoever builds the connection, or, worse, by the default setting of some piece of software. And for returns in particular, your rules also have to match what the law says about the customer’s right of withdrawal.
The three questions before you commission the connection
You do not need to know how such a connection is built. You need to know what to ask the person who will build it. Three questions are enough, if you listen carefully to the answers.
1. Which system keeps the official count of available stock?
One system must hold the truth and all the others must follow it. If the answer is “both”, then in practice the truth lives in neither.
Ask one more thing: how much time passes between a sale in the shop and the moment the e-shop knows about it. If the answer is “a few seconds”, good. If it is “a few hours”, then you know that for those hours the last item can be sold twice, and it is your decision whether that is acceptable.
The principle that one system holds the truth also applies to the room booked on two platforms. There the stock is nights; here it is items. The logic does not change.
2. What happens when an order is cancelled or returned?
Ask them to describe, in plain language, the journey of an item that was sold and then cancelled, and of one that was sold and then returned. At what point does it leave available stock, and at what point does it come back?
And do not stop at the description. Ask to test these scenarios together, with a real product, before the day the connection goes live. Cancellations and returns are the moments when stock starts “losing” items that exist or “finding” items that do not.
3. Who is alerted and deals with it when the systems stop talking to each other?
At some point it will happen. The internet goes down, a program is upgraded, a password expires. The question is not whether it will happen, but who will find out and when.
If the answer is “you’ll notice”, you probably will: on Monday morning, in front of an empty shelf. Insist on agreeing in advance who receives the alert, what they do, and what you do in the meantime.
What two connections taught me
I have done this work before. About fifteen years ago, long before myDATA, I connected an e-shop to WinWay, a Greek business management package. The e-shop produced a file every day, or whenever the user asked for one, and WinWay updated the warehouse stock from it. So the update did not happen at the moment of sale, and whether that kind of delay is acceptable for a business is exactly what you ask under the first question.
Later I connected a piece of invoicing software from 2003, which cannot even go online on its own, to myDATA, the Greek tax authority’s e-invoicing platform. I have told that story in the myDATA case study.
Every pair of systems has its own quirks. But one lesson from both jobs holds everywhere: a connection is not judged on the days when everything goes well. It is judged on the day something goes wrong. And there is one test: does someone find out before the customer does?
Two shop windows, one shelf
The shop and the e-shop are two shop windows in front of the same shelf. As long as each keeps count on its own, sooner or later the last item will have two buyers, and you will have a phone call you do not want to make.
If you update stock separately in the shop and in the e-shop, tell us through the form which systems you use and where the mismatches appear. We will look at whether they can work together and what their connection needs to include. This work is part of our web applications and integrations service.
The whole picture: this article covers one part of a larger subject. If you are after the whole of it, from the platform to returns, it is in the guide to your e-shop.
