CleanCore · Consumables
Cleaning consumables, counted and reordered
Stock on hand against par per site, with every delivery, usage and stocktake in a ledger that explains how the count got to where it is.
The problem this solves
Consumables are the part of a cleaning contract that quietly costs money: nobody can say what is on site, the order is placed from memory, and the customer’s request for more hand towel arrives as a text message to a supervisor.
CleanCore holds a par level per site and a running count against it, and the count is explained rather than asserted — deliveries in, usage out, stocktakes as corrections — so a figure that looks wrong can be traced to the movement that made it wrong.
The shortfall list falls out of that: what is under par, where, and by how much. And the customer asks for supplies from their own portal against a catalogue you control, so the request lands in the same queue as everything else rather than in somebody’s phone.
Worked example
The customer needs more hand towel at their head office.
- 1
They ask from their own portal
Against a catalogue you control, so the request is for something you actually supply.
- 2
It lands in the operational queue
Not in a supervisor’s messages — the same queue as every other piece of work, with the site attached.
- 3
The count moves when the stock does
The delivery is a ledger movement, so on-hand against par is current rather than a number someone remembers updating.
- 4
The order is the shortfall list
What is under par, where, and by how much, across every site, in one place.
Reordering stops being a memory exercise, and the customer stops asking twice.
Capabilities
What consumables gives you
All 2 of these are in the product today. Each one names what it is built on.
Consumables and reorder
LiveStock on hand against par per site, every delivery, usage and stocktake in a ledger that explains the count, and the shortfall list that drives the order.
Customer supply requests
LiveThe customer asks for supplies from their own portal, against a catalogue you control, and the request lands in the same queue as everything else.
What backs these claims
Each capability names the decision record, module, route or table it is built on. Ask us for any of them in an evaluation and we will walk you through the code.
- Consumables and reorder
- src/server/imss-consumables.ts · /imss/consumables · v3 cleaning_stock
- Customer supply requests
- client-portal/supply-request · client-portal/supply-requests · client-portal/supply-catalogue · /api/imss/supply-requests
Where this sits
Back to
CleanCore — every capability in one place
The whole module: what is live, what is committed, what is only on the roadmap.
Read next
A cleaning client portal your customer opens themselves
Their sites, their cleans, their KPI and their invoices — with everything that is yours withheld in the door’s own SQL rather than hidden in the page.
Twenty minutes on a real contract.
Real data, four logins, nothing typed on the day — including the parts we have not built, which we will point out ourselves.