Somewhere in most businesses there is a sentence like this one:
“Managers may authorise expenditure of reasonable amounts at their discretion.”
It reads like a policy. It has the vocabulary of a policy. It is not a rule, because it cannot be followed – and the proof is that the question still gets asked out loud several times a month by people who have read it.
What the vagueness actually costs
Three things, and none of them is theoretical.
The interruption never stops. Every time somebody needs to spend money, they have to find whoever looks free and ask. That is two people’s attention, several times a week, for a question that has a fixed answer.
Two members of staff operate to different rules. One reads “reasonable” as fifty dollars and asks about everything above it. Another reads it as five hundred. Both believe they are compliant. Neither is wrong, because the document did not say.
Nobody can be held to it. If somebody authorises something you would not have, you cannot point at a breach – you can only express disappointment, which is corrosive and teaches people to ask about everything, which brings you back to the first cost.
The uncomfortable reason it is vague
Ask an owner to put a number on it and the hesitation is usually not about wording. It is that the number has never been decided.
That is the actual work. Writing it down takes thirty seconds; deciding it means confronting a question you have been answering case by case, differently, for years – probably with more latitude for the people you trust and less for the ones you do not, which is a reasonable instinct and an unwriteable policy.
So the vagueness is not laziness. It is an undecided rule wearing the costume of a decided one. Recognising that is most of the fix.
How to decide it in ten minutes
You do not need the perfect number. You need a defensible one you can change.
- Look at the last ten things somebody asked you to approve. Real ones, from your messages.
- Mark the ones you would have been happy for them to handle alone. Usually most of them.
- Take the largest of those and round it down. That is your first-tier limit.
- Add a second tier if you need one – a manager band above the staff band.
- Write it, date it, and say it is reviewable. “From September, up to $500 without asking” is infinitely better than “reasonable amounts”, even if you change it in November.
The finished thing should look like this:
What can I approve without asking?
Up to $500, go ahead – just tell us in your end-of-day update.
$500 to $2,000, ask a manager first.
Above $2,000, ask the owner.
Anything from a supplier we have not used before, ask regardless of the amount.
Four lines. Answers the question completely. Findable on a phone in four seconds.
Write the condition, not a hedge
Notice the last line of that example. Most real rules have a condition, and the temptation is to handle it with softening language – “use judgement with new suppliers”. That puts you back where you started.
Conditions are fine. Write them as conditions:
- “Above $500, ask a manager” – not “larger amounts need approval”
- “A new supplier, ask regardless of amount” – not “exercise caution with unfamiliar suppliers”
- “Anything that stops a customer’s job today, go ahead up to $1,000” – not “use discretion in urgent cases”
Why this matters twice over if software answers questions
If you ever put an assistant in front of your procedures, the vague version becomes visibly useless. A well-built one will refuse to answer rather than invent a figure, because inventing a threshold is the worst thing it could do – and so the gap you had been tolerating becomes a daily, logged refusal.
That is uncomfortable and it is the right behaviour. Bosun quotes figures exactly as written and names the document; where the procedures do not state a figure, it says so and records the question for you. Which means the list of “rules we never actually decided” arrives whether you wanted it or not.
The wider method is in writing procedures staff will use, and the first five pages to write are in the five procedures to write first.