A plasterer waiting while the counter phones head office
A good customer comes in for forty boards and a pallet of multi-finish. The till flags the account: over limit. The counter can't release it, so they ring the credit controller, who is on another call. The customer waits. Another two trade customers queue behind him. Ten minutes later the credit controller rings back, pulls up the ledger, sees an invoice from last month that is actually in dispute over a short delivery, and releases the order. Everyone is annoyed, and none of it was necessary.
Multiply that by every branch and every morning, and the credit desk becomes a phone switchboard between seven and nine.
Why holds take so long to clear
The limit is not the problem. A limit is a sensible control. The delay comes from what the person releasing the order has to piece together before they can decide.
- The ledger shows what is overdue, but not why. Disputed invoices, missing proof of delivery and payments promised on Friday live in emails and notes.
- The branch knows the customer well, but that knowledge is not in front of the credit controller.
- Payments received that morning may not be allocated yet, so the account looks worse than it is.
- Release authority is unclear, so branches either wait for head office or release things they should not.
- Nobody records why an order was released, so the same conversation happens again next week.
The cost is lost orders and unsafe releases
When holds are slow, customers walk. A contractor with a crew standing idle on site will buy from whichever merchant gives him the goods. When holds are slow, branches also learn workarounds: cash sales on a card that is then disputed, orders split to fit under the limit, or releases on a promise that nobody writes down. Both outcomes are worse than a quick, informed decision.
A hold queue with the facts attached
- When your merchant system puts an order on hold, we pick it up through its API, a database view or a report, depending on what the system allows.
- The hold appears in a queue for the right approver, based on rules you set: branch manager up to a certain level over limit, credit controller above that, finance director for accounts on stop.
- The approver sees the order value, the ledger by age, any disputed invoices flagged, payments received but not yet allocated, and notes from the branch and credit desk.
- They release, part release, ask for payment or decline, from a phone or desktop, and the decision goes back to the till.
- Every decision is recorded with the reason, so patterns show up: the account that is released every week needs a limit review, not another phone call.
| Question at the till | Where the answer lives now | In the hold queue |
|---|---|---|
| Is the overdue amount genuine? | Emails about disputes | Disputed invoices flagged |
| Has the customer paid today? | Unallocated cash in the bank | Shown against the account |
| Who can release this? | Whoever answers the phone | Routed by your rules |
| Why was it released last time? | Nobody remembers | Reason recorded on each release |
After the change
The counter sees the hold and knows it has gone to the right person. The approver's phone buzzes with everything needed to decide. Most holds clear while the customer is still loading his van. The credit controller spends the early morning on genuine risk rather than switchboard work, and the monthly review shows which limits need changing.
Signs this is your branch
- Counter staff ring head office to release orders most mornings.
- Customers wait at the counter while someone checks the ledger.
- Disputes and payment promises are tracked in email, not on the account.
- Branches have their own unofficial ways around the hold.
- Nobody can say which accounts are released every week.