Restaurant Procurement Software

The request starts where the shortage is noticed. A line cook is prepping and sees the cream is down to two litres, so they raise it from whatever device is to hand. They are not filling in a purchase order — they are saying what the kitchen needs, in the units the kitchen actually uses.

It lands with the chef, who is the only person able to judge whether it is worth buying today. A chef almost never approves a request whole, and that is the part most systems get wrong: each item carries its own status and its own approved quantity, so cutting an order from twelve litres to four does not hold up the rest of the list. What gets approved moves on by itself.

Approved items then split two ways. Anything already in the building becomes an issuance for the storekeeper. Anything that has to be bought is grouped by supplier into purchase orders — one request can split across three suppliers, and each of them only ever sees their own order, which reaches them as a WhatsApp message and an email they confirm from a link.

When the van arrives, the storekeeper photographs the delivery note instead of copying it out. Quantities are read off it and checked against what was ordered, and a short delivery is flagged and held rather than absorbed and forgotten. Stock updates, the items are issued to the section that asked for them, and the cost reaches your food cost figure that day rather than at month end.