The team checks whether the purchase is needed. Finance checks the budget. Someone checks the supplier. Then everything waits for the founder, including the same routine purchases they approved last month.
The owner is busy, so people chase through messages. Eventually the request becomes urgent. The business starts treating reminders as a purchasing process.
The answer is not to remove every approval. It is to define which decisions genuinely need the owner and delegate the rest under clear rules.
That is a practical business process improvement problem, not a character flaw in the founder or the team.

Find out what each approval actually does
Before changing the purchase approval process, follow a few recent requests from the initial need to the final decision. Use actual records, not the version everyone remembers following.
For each approval, ask what it checks. Is it business need, budget availability, supplier eligibility, specification, risk, or payment authority? Does the reviewer have information the previous person did not?
Sometimes two approvals cover genuinely different concerns. Sometimes three people repeat the same check because nobody trusts the previous step. Those situations should not produce the same redesign.
Record when the request was submitted, when it became complete, when each person reviewed it, and when the decision was made. Separate waiting time from review time. If the request spent days in a queue and minutes being reviewed, making the review form prettier will not address the main delay.
Separate routine decisions from exceptions
A routine purchase is one that meets the company's agreed conditions. That might mean an approved supplier, known specification, available budget, permitted category, and a value within the responsible person's authority.
An exception might involve an unapproved supplier, unusual commitment, changed specification, budget overrun, related-party concern, or contract terms requiring specialist review.
Define those conditions before choosing thresholds. An inexpensive purchase can still carry substantial data, safety, or contractual risk. Price is useful, but it is not the whole approval policy.
For an owner-led SME, a simple routing matrix can be enough:
| Request condition | Decision route | Required record |
|---|---|---|
| Complete and within delegated authority | Named routine approver | Evidence, decision, approver, date |
| Missing required information | Back to requester | Specific gap and next-action owner |
| Outside authority or budget | Named escalation owner | Exception and decision needed |
| Specialist risk or terms | Relevant finance, legal, or technical reviewer | Review outcome before commitment |
The owner remains accountable for the authority they delegate. They no longer need to repeat every decision themselves.
Delegation needs a boundary people can use
"Use your judgment" sounds flexible. It can also leave a manager unsure whether they are allowed to act.
Specify who can approve which categories, under which conditions, and with what limits. Identify the evidence required, prohibited exceptions, substitute approver, and review process. Use limits appropriate to the business and its obligations. There is no universal amount that works for every company.
Do not let requesters approve their own purchases unless a deliberate, reviewed control design permits it. Keep payment release separate where your finance controls require it. A purchasing approval does not automatically establish that an invoice should be paid.
Make the rules accessible and version-controlled. If the authority matrix lives in an old attachment, employees will keep asking the founder because asking feels safer than guessing.
These rules can be configured in software. For example, Microsoft's purchase approval workflow walkthrough covers approval limits and substitute approvers. The business still has to agree who should hold that authority.
A practical owner-led business example
Imagine a small services company making repeat purchases from existing suppliers. This is an illustrative scenario, not a reported client outcome.
Every request currently passes through an operations manager and then the owner. The operations manager already checks business need, budget, and supplier status. The owner's routine approval usually repeats that information.
The company reviews its obligations and agrees a delegated route for specified routine categories. The operations manager can approve complete requests within that authority. Exceptions still go to the owner or relevant specialist. Finance applies the agreed payment controls separately.
The owner receives a regular summary and reviews selected decisions and exceptions. That gives them visibility without making their inbox the only route through the business.
The important change is not the removed click. It is the explicit transfer of a decision, together with its conditions and evidence.
Make the request complete before it enters the queue
An approval form should help someone decide. Include what is being bought, why it is needed, the current quote, budget context, timing, and any exception.
Ask for information that serves a decision. Do not add fields because the software allows them. If a field is never used, find out whether it belongs there.
Incomplete requests should return with a specific reason and an owner for the next action. Avoid leaving them in an ambiguous "pending" state alongside requests that are ready for a decision.
Agree a response expectation and a fallback route. The exact timing should reflect business needs and risk. A missed response must not turn into automatic approval unless the company has deliberately adopted and controlled that rule.
Configure the tool after agreeing the route
Workflow software can route requests, record decisions, send reminders, and report queues. It cannot resolve a disagreement about who owns the decision.
Document the current route and the agreed future route before configuration. Test routine cases, missing information, absences, rejected requests, and exceptions. Make sure the tool preserves the evidence and applies the right permissions.
Blackwing's workflow systems implementation work starts with those operating rules. Otherwise you automate the waiting and give it a dashboard.
Measure time to a valid decision, incomplete requests, escalations, repeated checks, and policy exceptions. Review the results with the decision owners. A faster route that routinely bypasses necessary controls is not an improvement.
Keep the owner involved where their judgment matters
Founder delegation is not disappearing from the process. It is moving attention toward decisions that need the founder's judgment instead of using that judgment on every repeat purchase.
You can start with one purchase category. Map the route, clarify the controls, agree authority, and test the change before expanding it.
If every routine request still waits for one person, book an operations review. Blackwing helps turn informal approvals into clear, owned business processes that do not depend on chasing the owner.
Frequently Asked Questions
What is a purchase approval workflow?
A purchase approval workflow routes a buying request to authorized decision makers, records supporting evidence and the decision, and defines the next step. It distinguishes complete requests, exceptions, rejections, and missing information. Purchasing authorization and payment release remain separate where finance controls require it.
How can a business reduce approval delays without losing control?
Identify which checks are necessary, remove genuine duplication, make requests complete, and delegate defined routine decisions. Retain specialist reviews and exception routes. Measure waiting time and control failures together.
Should every purchase need the founder's approval?
Not necessarily. A business can delegate routine decisions within agreed authority while retaining founder involvement for specified exceptions or higher-risk commitments. The appropriate route depends on the company's controls, obligations, and operating model.
What is the difference between purchasing approval and payment approval?
Purchasing approval authorizes a requirement or commitment under company rules. Payment approval confirms that a payable transaction should be released after the applicable checks. The same person or system should not automatically treat them as equivalent.
