Retail & e-commerce Usage scenario

Knowing what to order each week, per shop, before the stock-out

A distributor with three shops and a warehouse brings sales and stock into one tool, receives a weekly order proposal and a WhatsApp alert before the stock-out.

Describe your project See the solution

Project overview

This scenario illustrates what we build; it is not a client reference.

This scenario shows how a distributor with three shops and a warehouse can order products based on actual sales rather than by feel. Sales and stock are brought into one simple tool, an order proposal comes out every week per product and per shop, and the manager gets a WhatsApp alert when a fast-moving product drops below its threshold.

Client challenges & requirements

A distributor of food and hygiene products runs three shops in Conakry and a warehouse, with around 400 product lines. Supplier orders are placed from memory, by WhatsApp message, based on what the manager saw on the shelves that week.

The result: powdered milk and cooking oil run out three days before the next delivery, while boxes of slow-selling products have been sitting in the warehouse for months. Each shop records its sales in a notebook or in a till that is not connected to anything. On a Monday morning, nobody knows how much of each product is left in each shop, nor how much to order.

Main objectives

Record sales and stock for the three shops and the warehouse in one tool, usable on a phone

Receive a weekly order proposal per product and per shop, calculated from past sales and seasonality

Be alerted by WhatsApp or SMS when a fast-moving product drops below its threshold in a shop

Spot products that are not moving, to stop ordering them or to clear them

Project solution

We start with sales

A Laravel application with a PostgreSQL database becomes the only place where a sale, a supplier delivery and a transfer between the warehouse and a shop are recorded. It works on a phone or a computer, and each shop keeps a local copy so it can keep recording when the connection drops; sales go to the server as soon as the network returns.
Once the sales history is long enough, the calculation can begin. A Python script runs every Sunday evening and produces, per product and per shop, a quantity to order. The rule is simple: if the average weekly sales of recent weeks, adjusted for the season (Ramadan, back to school, end-of-year holidays), exceed the remaining stock plus what is already on its way, then the script proposes the difference, rounded up to the carton. Otherwise it proposes nothing.
We start with moving averages; a more elaborate model only comes in if the history justifies it. The manager receives the proposal on Monday morning, corrects it if they know something the figures do not, and sends the order.
Example
A shop sells an average of 30 bags of rice a week, 12 are left and nothing is on its way, so the proposal is 18 bags, rounded up to two cartons.
Between two proposals, a WhatsApp or SMS alert goes out as soon as a fast-moving product drops below its threshold in a shop. A Metabase dashboard shows stock per shop, the products that move fast and those that have not moved in two months.

Indicators to track

Number of stock-out days per product and per shop
Gap between the proposed quantity and the quantity actually ordered
Share of orders placed from the proposal
Value of stock that has not moved in two months
Gap between counted stock and displayed stock
Time spent each week preparing orders

Tech stack

Application ventes et stock: Laravel Livewire PostgreSQL
Saisie en boutique: Application web installable (PWA) Stockage local Synchronisation différée
Calcul des commandes: Python Pandas Moyennes mobiles Ajustement saisonnier
Alertes: WhatsApp Business API Passerelle SMS
Tableaux de bord: Metabase
Exploitation: Docker Sauvegardes quotidiennes

Frequently asked questions

With data entry. At first, the tool is only used to record sales and deliveries, and to see stock per shop. Order proposals start when the history is enough to calculate an average that means something. If you already have notebooks or a till export, we take them in to save time.

No. The proposal is a starting point calculated from the figures. The manager corrects it when they know something the figures do not: a late supplier, a promotion, roadworks closing the street. Each correction is recorded, which makes it possible to see later whether the calculation rule needs to change.

The sales assistant keeps entering sales on the shop phone or computer: the catalogue and stock are copied locally. Sales go to the server as soon as the network returns. Threshold alerts and the Monday proposal are calculated on what has reached the server; if a shop has sent nothing for more than a day, the manager is told.