The Emergency That Skipped the Preferred Supplier
A burst pipe on a Friday night is a real emergency, and the plumber nobody has vetted is the right call. The trouble starts on Monday, when the same word gets used for a printer cartridge. How a requisition policy can let a genuine emergency through every block that should bend, hold the ones that must not, and put each exception in front of a second person afterwards.
The cold room failed at eleven on a Friday night. The preferred refrigeration contractor had an answering machine; the one that picked up was a firm nobody in purchasing had heard of. The night manager raised a requisition, called it an emergency, and the compressor was running again by two. Everyone agreed that was the right decision. Three weeks later, the same firm had been used four more times, twice for jobs the preferred contractor quoted for at half the price, and every one of those requisitions said emergency.
In one paragraph
A purchasing policy that cannot bend for a real emergency gets switched off, and one that bends for anything called an emergency is not a policy. The workable middle is narrow: a named permission to declare one, a written reason, a value ceiling above which the ordinary rules return, a short list of rules an emergency never passes, and a register where somebody other than the person who used the exception looks at it afterwards. That is how ours works, and every part of it is off until a workspace switches it on.
Three rules a requisition has to answer
Most organizations already run approval chains and a budget check on purchases. The three rules below sit beside those, and each one answers a question the other two cannot.
| Rule | The question it asks | Who can get past it |
|---|---|---|
| Preferred supplier | Is this item being bought from the supplier we agreed to buy it from? | A person with the override permission, with a written reason |
| Restricted item | Is this something only certain people may approve buying at all? | Nobody — it needs an approver who holds the restricted-purchase permission |
| Emergency purchase | Is there a genuine reason the first rule and the budget should bend this once? | Declared by a person with the emergency permission, within a value limit |
The preferred-supplier rule reads two things that already exist: the preferred supplier recorded on an item, and the preferred flag on a supplier. A workspace sets it to off, warn or block, and can add a stricter switch that only suppliers marked preferred may be used at all. At warn, the approver sees which lines break the rule and carries on. At block, the approval is refused unless someone holding the override permission writes a reason of at least ten characters — enough that "ok" and "urgent" do not count.
The restricted-item rule is a switch and a note on the item itself: controlled chemicals, weapons-adjacent security kit, prescription stock, anything where the question is not which supplier but who is allowed to say yes. Approving a requisition, RFQ or quote that buys one needs an approver holding the restricted-purchase permission. That approval is recorded on the requisition and carried down, so the RFQ and the quotes raised from the same requisition are not stopped a second time for the same items.
The emergency rule is the one that makes the other two survivable. A requisition flagged as an emergency, with a reason, by someone who holds the emergency permission, is let past a budget block and past a preferred-supplier block. A flag from someone without that permission is refused, not dropped, so nobody walks away believing they raised an emergency that was quietly ignored.
An emergency is permission to skip the rules that protect price. It is never permission to skip the rules that protect judgement.
What an emergency does not get past
The design question that matters is not what an emergency unlocks but what it leaves locked. Ours leaves two things exactly where they were.
Still enforced on an emergency requisition
- The approval chain. An emergency still needs every signature the chain asks for; it only stops the budget and the preferred supplier from refusing those signatures.
- Restricted items. Something that needs a restricted-purchase approver still needs one, however urgent the night.
- The value limit. Above the workspace’s emergency limit the ordinary rules apply, and the requisition says so in words on its policy card.
The value limit is what turns the cold-room story from a pattern into an incident. A workspace that sets its emergency limit at the size of a plausible night call-out lets the compressor repair through and sends the half-price-elsewhere job back to the ordinary path, where the preferred contractor and the budget both get their say.
The cold room, with the policy switched on
The second job is not refused for being an emergency. It is refused because, above the limit, it is not treated as one — and an override still needs a person with that permission and a reason they are prepared to sign.
The register is where the policy earns its keep
Every exception lands in one list: an emergency, a preferred-supplier override, a restricted item approved. Each row carries the document, the person, the reason they wrote and the rule they stepped past. A reviewer marks it reviewed, with a note if they want one, and two things are refused: reviewing it twice, and reviewing your own.
That last rule is the whole point. A buyer who overrides the preferred supplier on Tuesday and ticks their own override as reviewed on Wednesday has produced a register that is accurate and worthless. The review is a second pair of eyes after the fact, which is the only kind of control that does not slow the emergency down.
Where the checks are asked
At every door the budget check already guards: approving a requisition or an RFQ, awarding a whole quote, awarding by line, and the Reorder page — on the web, through the API, from the approvals hub and in the mobile app. The Reorder page is the one door that cannot override: a blocked reorder is refused and points you to a requisition, where an override can be reasoned and recorded.
Setting it up without a revolt
-
Start on warn
Run the preferred-supplier rule at warn for a month. Approvers see the breaks; nothing is refused; you learn which items have the wrong preferred supplier recorded before anyone is blocked by it.
-
Mark the restricted items
A short list, with the note saying why. Then decide who holds the restricted-purchase permission — usually fewer people than you first think.
-
Give the emergency permission to the people on call
Night managers, site leads, the duty engineer. Set the limit at the size of a believable out-of-hours call-out, not at the size of the largest purchase you can imagine.
-
Name the reviewer
Somebody who did not make the exceptions and reads the register weekly. The overview card shows the count waiting.
-
Then move to block
Once the preferred suppliers on your items are right, block stops being a source of complaints and starts being a source of exceptions worth reading.
Four extensions to the policy
The three rules, the override, the emergency limit and the register are in place at every approval door. These follow from how purchasing teams use it once it is on.
An override reason on the sourcing workbench award
So an award blocked by the preferred-supplier rule can be reasoned and recorded from the workbench, as it can from the line-award page today.
A weekly digest of unreviewed exceptions
Sent to the people who can review them, listing what has waited longest.
Preferred suppliers and restrictions per category
Set once on an item category and inherited by every item in it, with the item able to say otherwise.
An emergency-use report by person and supplier
Showing who declares emergencies, how often, and with which suppliers, so a habit is visible before it is a pattern.
Each sits on the policy service and the register that already run.
Tell us what your purchasing needsFour questions to ask about any purchasing policy
What happens when someone marks a purchase as an emergency?
What you will probably hear
It goes straight through.
How to read it
Ask through what. If the answer includes the approval chain or a restricted-item approval, the word emergency has become a master key.
Is there a ceiling on an emergency?
What you will probably hear
A pause, then "the approver would notice".
How to read it
A value limit above which the ordinary rules return is the cheapest control there is. Without one, the largest emergency is unbounded.
Who looks at the overrides afterwards?
What you will probably hear
The person who made them, or nobody in particular.
How to read it
An override reviewed by its author is a log entry, not a review. Insist that the system refuses it.
Can the reorder screen order from a non-preferred supplier?
What you will probably hear
Yes, it just uses the last supplier.
How to read it
An automated order path that skips the policy is where the policy quietly stops applying. It should refuse and send the order through a requisition.
What AWRA OpsHub does today
- A preferred-supplier rule set to off, warn or block, reading the item’s preferred supplier and the supplier’s preferred flag, with an optional preferred-list-only switch.
- Overrides that need the override permission and a written reason of at least ten characters, each recorded as an exception.
- Restricted items with a note, needing an approver who holds the restricted-purchase permission, and that approval carried down to the RFQ and quotes from the same requisition.
- Emergency purchases declared with a reason by people holding the emergency permission, passing a budget block and a preferred-supplier block within a workspace value limit, never the approval chain or a restricted item.
- An exceptions register reviewed once, by someone other than the person who made the exception, on the web, through the API and in the mobile app.
- The same checks at every approval door: requisition and RFQ approval, whole and line awards, the approvals hub, and the Reorder page, which refuses rather than overrides.
More we can add to your workspace
- A policy override reason on the sourcing workbench award, matching the line-award page.
- A weekly digest of exceptions waiting for review, sent to the people who can review them.
- Preferred suppliers and restrictions set per item category, inherited by the items in it.
- An emergency-use report by person and supplier over any period.
Where we point you to a specialist
- We will not let an emergency pass the approval chain or a restricted-item approval. Urgency is a reason to bend price controls; it is not a reason to remove the person whose judgement the purchase needs.
The award-form reason and the digest are small and would be quoted together; per-category settings are the larger piece.
See requests and approvals
Requisitions, value-based approval chains, budget control and the purchasing policy that sits beside them.
Explore requests & approvalsFrequently asked questions
Does an emergency purchase skip the approval chain?
No. An emergency gets past a budget block and a preferred-supplier block, within the workspace value limit. It still needs every signature the approval chain asks for, and a restricted item still needs an approver who holds the restricted-purchase permission.
Who can mark a requisition as an emergency?
Only people who hold the emergency purchase permission, and only once the workspace has switched emergency purchases on. A reason is required. A flag from someone without the permission is refused with a message rather than ignored.
What happens above the emergency limit?
The ordinary rules apply, exactly as if the requisition had not been flagged. The policy card on the requisition says so, so the approver knows why a block has come back.
Can someone review their own policy exception?
No. Each exception is reviewed once, and the reviewer has to be someone other than the person who made it. The review is written to the audit log with the reviewer and any note.
Is the purchasing policy on by default?
No. Each rule is off until a workspace switches it on in its procurement defaults, so existing workspaces behave exactly as before.
