Example System — we built this to show the shape of the work. Calloway Wholesale Supply is a made-up company, the requests in it are made up, and this is not a client engagement.
Example System · you can click it
Purchase approvals, out of the inbox
Most of this site describes systems. This one runs. It is a working purchase-approval system for an invented distributor: three roles, real routing logic, an approval threshold you can change and watch take effect. Nothing is a screenshot and nothing is a rendering.
We show it because the honest answer to “who else have you done this for?” is: not this, not yet. So instead of a client logo we will hand you the software and let you judge it. It is the same job as approvals trapped in email, and it is the shape of a Medium build — a real workflow, start to finish.
Try it
Use the Signed in as menu at the top right of the frame to switch between the three people who use it. Submit a request as the office manager, approve it as purchasing, then set your own threshold as the owner and watch where requests go. Your changes stay in your browser and affect nobody else.
Sample system with invented data. Calloway Wholesale Supply does not exist and is not a customer of ours.
Cramped in the frame? Open the sample full screen. It works on a phone, but it is built for the desk it would live on.
The problem it addresses
An approval is not a message
Someone needs to buy something. They email whoever they think approves it. That person is on a job site, or on vacation, or has four hundred unread messages. Two days later the requester walks down the hall to ask. Nobody can say what is waiting, who has it, or how long it has been sitting — because the record of the decision is scattered across three inboxes and none of them is the system.
The fix is not a faster inbox. It is treating the request as a record with a state and an owner: routed by a rule instead of a guess, visible to the person who submitted it, and closed with a reason attached. That is a workflow system, and it is one of the most common first builds in wholesale distribution.
Three people, three screens
Nobody gets a screen full of things that are not theirs. That is most of the design.
- Submits requests
Office manager
The form shows where the request will go before it is submitted. Nobody chooses an approver, and nobody starts an email thread. After submitting, the requester watches the status and the full history without phoning anyone.
- Reviews the queue
Purchasing
One queue, oldest first, each row with an age. Approving is one click. The routing rule is printed on the screen rather than buried in a policy document, so the person applying it can see it.
- Sees only the exceptions
Owner
Only requests that cross the approval threshold reach this screen, and they arrive already reviewed. Declining requires a reason, and the requester sees that reason immediately.
The routing, written down
One rule decides everything: requests at or under the threshold are final when purchasing approves them, and anything over it goes to the owner. In the sample the threshold starts at $2,500 and the owner can change it. That is the point — the rule belongs to the business, so it is a setting, not something we hard-code and you call us to change.
The routing in the sample above — not a client implementation.
What it would change
Outcome categories, not invented numbers
We have not run this in anyone's business, so we have no before-and-after to quote and we are not going to invent one. These are the things a system like this is built to move — the ones worth measuring before the build starts, not after.
Approval turnaround
A request has a state and an owner instead of sitting in an inbox behind someone's unread mail. The category to watch is how long a request waits before someone decides.
Status interruptions
The requester can see where their own request is, so the “did this get approved?” conversations stop happening. The category to watch is how often people ask.
Unowned exceptions
Every request above the threshold lands on exactly one named screen. The category to watch is requests with nobody accountable for the next step.
Spend visibility
Approvals are records rather than replies, so what was approved, by whom, and why is a lookup. The category to watch is spend nobody can trace back to a decision.
Do your approvals live in email?
A Workflow Review maps how one of your processes runs today and shows what a purpose-built system would change.