Requesting Stock from Purchasing over WhatsApp: Sent, but Not Trackable

The Depo admin has already sent the stock request over WhatsApp, but still has to remind Purchasing and find out whether the goods have been ordered or are still awaited.

Illustration of stock requests scattered across separate chats shifting to a request, ordering, and receiving flow on a shared screen. — From messages that have to be traced to a fulfilment status everyone can see.

Conceptual illustration. The case is real; company details are disguised.

In the fresh food distribution operation I worked on together with my team, Depo stock requests started as private or group messages. The admin passed on the goods needed, then reminded Purchasing whenever a request had not yet become an order to the supplier. When the goods arrived, the receiving team kept its own record. Information about need, ordering, and arrival sat in different places, following whoever handled each stage.

A sent message does not answer the questions operations actually need answered: which part has been ordered, how much has been received, and what is still missing? To answer them, the team had to go back through conversations and reconcile records. While that status was not visible to everyone, a shortage risked being discovered only when the goods were needed for production. By then, the room to wait for supply had already narrowed.

Illustration of goods requirements being coordinated through messages between the storage area and the administration desk. — Stock requests depend on messages and reminders from the people who need the goods.

As head of the IT Division, I chose to move that status into a flow the whole team could monitor. Adding staff to watch the conversations would only keep the same dependence on reminders. Together with the team, I developed a link between the stock request, the supplier order, and goods receiving. Purchasing needed to see the requirement directly, while the Depo needed to know how far it had been fulfilled.

The change started with the stock request list. The Depo admin enters the requirement into the system, then Purchasing opens the same list to create the supplier order. The system compares the quantity requested with the quantity already ordered. Any shortfall is marked red on the item's row. Purchasing can review open work from that list without waiting for the admin to send a new reminder for each request.

I also had to distinguish goods that had been ordered from goods that had arrived. A supplier order does not close the Depo's need while the goods are still in transit or have only partly arrived. The receiving team records arrivals on a mobile screen and checks the specifications and physical quality of the goods at the same time. The quantity received and the quantity still missing become part of the fulfilment status, so monitoring continues after Purchasing has finished creating the order.

Illustration of a shortage on the shelves becoming visible while goods preparation is under way. — A shortage that only shows up once production has begun leaves less time to follow up on supply.

For needs that have been ordered but have not arrived, or have not arrived as ordered, Purchasing can create a replacement order through the shortfall-closing function. The flow still starts from the need that remains open. The receiving team continues recording when the goods arrive, and the head of the Depo oversees goods readiness and escalates delays. This division of roles keeps a stock request from being treated as done just because it has turned into an order document for the supplier.

Automatic reminders complement the list in the system. Every hour, the system sends requests that have not been ordered and orders that have not been received to the operational WhatsApp group. The two are kept separate because the follow-up differs: Purchasing handles ordering, while the receiving team traces arrival and its recording. Items that remain open appear again in the next reminder, and stop appearing once the shortfall is resolved. Anyone who receives a reminder can go back to the list to check the status.

I deliberately kept WhatsApp. The Depo team and field staff need to follow progress without having to open the system, so reminders go to the place they already use every day. The conversation reminds people of the work, while the main status is held in the system and can be opened directly. That access also serves as a fallback when an automatic reminder fails to send. The IT team maintains the list, the shortfall calculation, and the delivery of reminders so that everyone doing the work can use the same flow in their daily tasks.

Illustration of the request, ordering, and goods receiving flow with periodic reminders on a shared screen in the Depo area. — A shared status connects the work of the Depo, Purchasing, and the receiving team.

The menu and the reminders later became part of the operating procedure. The Depo admin creates the request, Purchasing follows up on ordering, and the receiving team completes the status of goods that arrive. The head of the Depo can see what needs attention without piecing the whole conversation back together. For the sales team, the status of goods that are ordered, received, and still missing is also visible earlier. Each role gets a clear point of action in fulfilling the same need.

A reminder is most useful when it points to clear work. A message can help people go back and check a request, but a shared status answers what is still missing and who needs to follow up. A sent message is the start of coordination; the work is done when the need is actually met.