Apparel Orders Construction — internal operations 2026
One field decides the route, and the person approving never has to log in.
Ordering company clothing meant a catalogue PDF emailed around, filled in, emailed back, forwarded for approval, forwarded again — and chased. A document passed around by email has no state, so nobody could say what was approved or where an order had got to. This replaced it with something that knows.
- Products in the catalogue
- 14
- Logins required to approve an order
- 0
- Steps a person forwards by hand
- 0
- What it replaced
- A PDF, by email
The problem
Everybody at a construction company wears the company's clothing, and every few months everybody needs more of it.
Here is how it worked. A catalogue went out as a document attached to an email. People filled it in, or replied with a paragraph describing what they wanted. Those replies went to somebody who collated them, and each was forwarded to a supervisor for a yes, then forwarded again to whoever places the order with the printer. Sizes were typed, so sizes were mistyped.
The failure underneath it is one sentence: a document passed around by email has no state. Nobody can tell whether an order was approved or ever sent on, because the answer lives in an inbox. So orders vanished between the approval and the person placing them, and the supervisor became somebody to chase rather than a step that happens.
One field decides the route
There is no approval matrix here, and no workflow builder. Each employee record carries an optional supervisor. That is the whole configuration.
When an order is submitted, the tool reads that one field and branches. If the person has a supervisor, the order is held and sent to them for a decision. If not, it goes straight to whoever places orders. Same button, two routes, decided by one field. When the company changes, somebody edits a field.
The person approving never logs in
A supervisor uses this four times a year, so there is no account and no password to hold. The approval arrives as an email with a link in it.
The link opens a page showing the order, the note the employee wrote, and the items with their colours and sizes, and it has two buttons: approve, or reject with a reason. It is unguessable, it expires by itself, and it can only decide the one order it was made for. That is enough security for a jacket.
The rest of it
- It is a shop, not a form. The store shows what is available, photographed properly, with the colours and fits that exist and the sizes in stock; pick, add a note, submit, and your own screen says where each order stands in plain words.
- A rejection is not a dead end. A reason is required and goes back attached to the employee's own order, to be revised and resubmitted from there — four jackets against an allowance of two, on the record rather than in a reply nobody else can see.
- Approved orders go where they are going, by themselves. They route onward to the person who places orders, with a copy to whoever else needs it — precisely the step where things used to be lost.
- Every state change is on the order. Submitted, approved, rejected, resubmitted, each with who did it and when, so "where is this?" has an answer on the order itself.
- Batching is the default, not a rule. Ordering everything at once saves real money with the printer, so the store opens on a schedule and closes again — but a torn jacket can still be ordered outside a window, marked off-cycle.
What changed
- The process gained a state. Every order says where it is — pending, approved, needs changes — with a full history of who did what and when. "Was this approved?" stopped requiring a search of somebody's inbox.
- The approval stopped needing an account. A signed link that expires, no login. The step that used to be the bottleneck takes as long as reading it.
- Nothing is forwarded by hand. Approved orders route to the person placing them automatically, removing the exact step where orders used to disappear.
- Sizes stopped being typed. They are selected from what actually exists, which removes an entire category of reorder.
- Rejections became useful. A required reason, attached to the order, with a revise-and-resubmit path from the same screen.
- Batching held. Windows are the default and off-cycle requests stay possible and visibly marked, so nobody routes around the tool to get a torn jacket replaced.
Nobody was going to write a business case about jackets. The whole thing replaced a PDF, and the reasoning is the same as the largest project here: find the step where the state is lost, and put the state there.