We recently had some work to do which focused on getting stock more real time on the website. Here I’m going to take you on the journey of this piece of work.
We started with the above “requirement”, the real problem however, was subtle different – overselling on the website. This has the following impact on the customer and business:
- The customer is annoyed because the order is cancelled, because it can’t be fulfilled
- The cancellation process is slow, and is time consuming for Customer Services.
So how does stock get on the website? Stock is calculated every 5 minutes with a batch job then read in two ways on the website:
- Through our search system
- Through a direct call to our ERP system
The first slice was to make stock come from a single source, this would be easier to change in the future. So we set about reading the data directly from the ERP system and publishing this to our new stock service, then subsequently reading it in the website. This was live for a brand within a day or two. There was still some latency in this as we were still reliant on another batch job finishing before reading directly from the ERP system.
While delivering something quickly, this was the wrong slice as we didn’t really understand how we much we oversold by or when it happened (more on this later).
We started on the second obvious slice, making the stock real tiem, as we were still reliant on the batch job finishing for our stock levels to be up to date. We decided to “baseline” our stock and then just deal with “goods out” – i.e. what was sold on the site.
During this second slice, which was now much bigger, and more complicated. There were some product launches – this meant we had an opportunity to measure the impact of what we had been doing. We quickly realised that this second slice was wrong as we couldn’t measure the impact of it.
We pivoted to what our first slice should have been – understand overselling. We created numerous apps to let us monitor during these product launches so we could understand overselling. These where manual and needed us to watch them run. So after the first product launch, once we were happy this data was trustworthy. We enhanced these to not have to be manually run, so we monitor oversells and unknown product sales 24/7 now. We also started to capture when people entered the checkout on the website.
From this we could see a number of things about overselling:
- About 80% of people where in our checkout; once we’d sold out
- About 15% of people where still shopping on the site; once we’d sold out
- About 5% where due to the non-real time nature of stock
Even if we’d completed our original second slice – “real time stock” we wouldn’t have solved the problem – overselling!
We came up with a list of things we could do, and worked with the stakeholder to narrow it down to the following:
- Before placing the order – do a stock check
- When people enter the checkout – do a stock check
Unfortunately, we’d already made another improvement which we didn’t know the impact of. Making the stock come from a single place. This was quantifiable as we’d not been measuring before we’d made any changes.
We made the changes outlined above and continuously released them and tried to monitor their impact.
We had some bad/good luck our new stock service started failing just before the weekend, so we had to turn it off. This was a blessing as we could now see how the site actually performed without any of our changes. Below is overselling over the weekend:
The coming weeks will be interesting as there are product launches, which tend to increase our overselling. Our plan is to monitor these and see if we need to do any more work.
Some things we learned:
- Metrics – understand the problem & measure the impact of changes
- Pivot quickly
- Deliver every commit
- Logging in apps – understand what your applications are doing, business and application wise