Built for every operation

A hospital and a twelve-seat restaurant look nothing alike on paper, and they break in the same place: the moment someone needs something, and the person who can approve it is not standing next to them. Every use case below runs the same chain underneath. Only the names on the roles change.

Someone raises a request. It goes to whoever is allowed to approve that department — a chef for the kitchen, a department head for front of house or cleaning. They can approve the whole thing or part of it, which is what actually happens: a real kitchen rarely approves every line. Each item carries its own status and its own approved quantity, so a partial approval moves on without waiting for the rest.

Approved items then get routed one of two ways. Anything already in the building goes to the storekeeper as an issuance. Anything that has to be bought is grouped by supplier into purchase orders — one request can split across several suppliers, each getting only their own order. The order reaches them as a WhatsApp message and an email, and they confirm from a link without installing anything.

When the delivery turns up, the storekeeper photographs the delivery note and OCR fills in the quantities. What arrived is checked against what was ordered, and a shortfall is flagged and held rather than quietly absorbed. Stock updates, the items are issued to the department that asked, and the request closes.

Every step of that is logged with a user, a timestamp and a reason, and every permission is enforced in the database rather than the interface — twelve capabilities you can set per person, including how much money someone may approve. That is the part that matters when an auditor asks who agreed to a number, or when the person who knew the answer has left.