A team can know every step in a process and still send every meaningful decision to the founder. The proposal is prepared, the supplier is ready, or the customer is waiting. Then the work stops because nobody knows who can approve the discount, accept the risk, change the scope, or commit the business.
Telling people to “use your judgment” does not solve this. Neither does adding another approval step. The team needs decision rights: a clear statement of who may decide, within which limit, using what evidence, and when the case must escalate.
The goal is to reserve founder attention for consequential decisions while giving routine decisions clear, bounded authority.
Quick answer: what are decision rights in a small business?
Decision rights define who can make a recurring business decision, the limit of that authority, the evidence they must use, who they must consult, and the condition that requires escalation. They turn vague delegation into an operating rule the team can use without asking the founder about every ordinary case.
One recurring workflow is enough to begin. List the decisions that repeatedly pause it, separate routine choices from material commitments, and name one decider for each. Then add a boundary that makes escalation predictable rather than personal.
Why does work still wait for the founder after tasks are delegated?
Work still waits because task responsibility and decision authority are different. A person may own the preparation, communication, and follow-up while lacking permission to make the choice that moves the case forward.
Consider a sales lead who can prepare a proposal but cannot approve any discount. Even a standard 5% adjustment goes back to the founder. The founder may answer quickly at first, so the arrangement appears harmless. As volume grows, the same small decision competes with hiring, cash, delivery, and customer-risk decisions. The delay is built into the authority design, not the proposal process.
This is narrower than the broader founder-dependency pattern. That article helps diagnose why the business repeatedly depends on one person for knowledge, relationships, decisions, and exceptions. Here, the job is practical: release a defined class of recurring decisions without releasing unlimited authority.
An SOP can explain how to assemble the proposal. A checklist can confirm required inputs. A process map can show where approval occurs. None of those artifacts decides who may approve a 5% discount, what evidence controls that choice, or when a nonstandard commitment must stop. If the documentation format itself is unclear, the guide to SOPs, process maps, and checklists owns that choice.
Which decisions should stay with the founder?
Founder approval should remain where the decision creates a material, unusual, or hard-to-reverse commitment that the business has not delegated elsewhere. Routine choices that fit an agreed rule and limit should usually sit with the role closest to the work.
A useful first classification is:
| Decision class | Operating treatment | Example |
|---|---|---|
| Routine within a rule | Named role decides and records the result | Apply a standard delivery date from the current capacity plan |
| Bounded by a threshold | Named role decides inside a written limit | Approve a discount up to 5% when margin remains above the stated floor |
| Consultation required | Named decider gathers specified input but retains the decision | Delivery lead confirms feasibility with finance before accepting a timing change |
| Escalation required | Work pauses before a material commitment and moves to the named authority | Approve a nonstandard liability term or discount beyond the delegated limit |
Consultation is input, not an undeclared approval layer. Even when several people contribute evidence, the rule should identify the role that makes the call; otherwise routine work simply moves from founder delay to committee delay.
The founder is not automatically the destination for every escalation. A delivery risk may belong to a process owner when that decision right is explicitly assigned in the owner charter or matrix. A legal commitment may belong to counsel or a named executive. A credit exception may belong to finance. The correct destination is the role with legitimate authority for that consequence.
How do you create a decision-rights matrix?
Create a decision-rights matrix by choosing one workflow, identifying the decisions that actually interrupt it, and assigning each decision a decider, limit, evidence source, consultation rule, escalation trigger, destination, and record. The matrix should be small enough to use during live work.
Recent cases are a better starting point than the org chart. Find five to ten moments when work waited for approval, returned to the founder, moved without clear authority, or produced an argument about who could commit the business. Name the decision in each case as specifically as possible.
“Approve deal” is too broad. A proposal may contain several different decisions:
- whether the work fits the standard service;
- whether the requested start date is feasible;
- whether a discount remains inside the commercial limit;
- whether a nonstandard promise creates delivery risk;
- whether a contract term creates a material obligation.
A pricing concession, a delivery promise, and a contract term create different risks, so they need different owners and limits.
Use these fields for each recurring decision:
| Matrix field | Question to answer | Proposal example |
|---|---|---|
| Decision category | What exact choice moves the work? | Approve a commercial discount |
| Trigger | When does this decision occur? | Customer requests a change from standard pricing |
| Decider | Which one role has authority to decide? | Account lead |
| Ordinary rule | What rule applies to a normal case? | Use the approved pricing schedule |
| Authority limit | How far may the role go without escalation? | Up to 5%, with margin above the stated floor |
| Required evidence | Which current facts or records control the decision? | Approved price, calculated margin, current scope, payment terms |
| Consulted role | Whose input is required before the decider acts? | Delivery lead if timing or scope changes |
| Escalation trigger | What condition removes delegated authority? | Discount above 5%, margin below floor, nonstandard liability, or unpriced scope |
| Escalation destination | Who has authority over that consequence? | Commercial owner or founder, as named in the rule |
| Decision record | Where are the choice, evidence, and decider visible? | Current proposal record |
| Review signal | What would justify changing the rule? | Frequent escalations, margin leakage, delivery disputes, or unused authority |
The evidence field matters because an authority limit without a trusted fact source is unreliable. A role cannot apply a margin floor if the current cost assumptions live in several spreadsheets. If the team cannot agree which record controls the decision, resolve the source-of-truth problem rather than pretending the matrix is complete.
A decision record should be proportionate. A routine date selection may need only the chosen date, source plan, and decider. A material exception may need the alternatives considered, evidence used, and reason for escalation. Recordkeeping should match the consequence: routine choices need a light record, while material exceptions need enough context for later review.
The University of York’s “Scheme of delegated approvals” is a university governance document, not evidence about small-business performance. It illustrates a narrower principle relevant here: decisions should sit at the appropriate authority level rather than rising to senior bodies by default; complex or high-risk matters may need escalation; and key decisions should retain an audit trail showing how, why, when, and by whom they were made. This article adapts that governance logic into a small, workflow-level tool; it does not present the university’s formal structure as an SMB template.
A worked example: release routine proposal decisions
Suppose every proposal returns to the founder before it can be sent. Recent cases show that the founder is answering four different questions under one label called “proposal approval.”
A first matrix might look like this:
| Recurring decision | Decider | Delegated boundary | Escalate when |
|---|---|---|---|
| Standard scope fit | Account lead | All deliverables match the current service definition | Work adds an unpriced deliverable or changes the service model |
| Start-date commitment | Delivery lead | Date fits current capacity and standard lead time | Requested date displaces committed work or requires external capacity |
| Commercial discount | Account lead | Up to 5% and above the current margin floor | Limit or margin floor is crossed |
| Payment terms | Finance lead | Current approved terms | Customer requests nonstandard timing, credit, or liability |
| Material contractual commitment | Named commercial authority | None unless separately delegated | Always route before commitment |
This design does not treat proposal approval as one vague bundle of authority. It places each choice with the role that has the relevant operating evidence and reserves the decisions that can materially bind the company.
An account lead can apply a standard 3% adjustment within the stated boundary. A delivery lead can commit a date already supported by the capacity plan. The founder receives only cases that depart materially from ordinary commitments.
How should decision rights connect to process ownership and handoffs?
Decision rights allocate particular choices; process ownership governs the end-to-end result; a handoff contract governs whether work is valid when responsibility moves between stages. The same person does not need to hold all three roles.
A process owner may maintain the decision matrix, watch where the process stalls, and sponsor changes to its rules. Process ownership alone does not convey approval authority; any decision right held by the owner still needs to be explicit in the charter or matrix.
Likewise, a receiving team may accept a valid handoff without approving the commercial decision again. Acceptance confirms that the work package meets the agreed entry criteria. Decision authority confirms that the underlying commitment was made by an authorized role.
Keeping these layers separate prevents accidental veto points. The person who checks completeness should not quietly become a second approver unless the consequence genuinely requires their authority.
What should happen when a decision crosses its authority limit?
When a case crosses the limit, the current decider should stop before making the commitment and send a defined evidence package to the named escalation authority. The rule should show the trigger, destination, interim state, and expected response.
For the proposal example, an escalation package might contain the current scope, requested departure, margin effect, delivery impact, customer deadline, recommendation, and decision due time. The case remains pending authority until the named person decides. It does not become approved because the request was sent or discussed.
The matrix ends at the escalation boundary. Queue design, resolution, resumption, and recurring-pattern review belong to the planned business-process exception-management guide. The distinction matters: decision rights define who may choose; exception management operates the case after it has left the normal path.
Pilot the matrix before changing systems
Run the matrix through one workflow for two to four weeks, or through a meaningful set of recurring cases. What matters is whether the rules predict real decisions during live work, not whether the document appears complete.
The most useful signals are:
- routine cases still returning to the founder;
- people acting inside the limit but using the wrong evidence;
- consultation turning into an unofficial approval queue;
- decisions crossing the limit without escalation;
- too many cases reaching the boundary;
- and decisions waiting because the escalation destination is unavailable.
Bring the roles who used the matrix into the case review. A repeated founder question may mean the limit is vague. Frequent escalation may show that the threshold is too low, that the underlying offer is unstable, or that two decision categories were combined. An unauthorized commitment may mean the consequence was not understood, the evidence was missing, or the limit was too generous.
When the evidence supports a revision, change one rule at a time. The aim is not zero escalation. Healthy decision rights let ordinary work move while making consequential judgment visible before the business is committed.
Automation comes later. A system can route a case, calculate a threshold, request evidence, and record a decision after the authority rule works. It should not infer who may bind the business from old approval behavior. The broader workflow-automation architecture owns that implementation question.
If the pilot exposes trapped judgment, conflicting records, unclear ownership, and repeated founder rescue across several workflows, Download the Operational Drag Diagnostic Kit. Use it to determine whether the issue is one missing authority rule or a broader operating-design problem.
FAQ
Can decision authority be temporary?
Yes. A matrix can grant authority for a defined period, project, absence, or operating condition. State when the authority begins and ends, which decisions it covers, and whether open cases return to the usual authority when the temporary period closes.
How do you find an undeclared approval layer?
Review cases that were within the stated limit but still waited for a second person to agree. If that person can delay or veto the decision, the workflow contains an approval role that the matrix has not named. Either formalize that authority with a clear purpose or remove the extra gate.
Does every business decision need one decider?
Every recurring decision should have one role accountable for making the choice or escalating it. Other people may provide evidence or consultation, but shared input should not obscure who makes the final decision inside the defined boundary.
How do you choose an approval threshold?
Start with recent cases and the consequence the business can safely delegate. Consider financial exposure, reversibility, customer impact, delivery capacity, legal or regulatory obligations, and the quality of available evidence. Pilot the threshold and adjust it from observed cases rather than intuition alone.
Should the founder approve all large decisions?
Not necessarily. A large or consequential decision should go to the role with legitimate authority over that consequence. In a small company that may still be the founder, but finance, a commercial owner, counsel, or a process owner may hold specific authority when it has been explicitly assigned.
Is consultation the same as approval?
No. Consultation supplies required expertise or context to the named decider. Approval means another role holds the authority to accept or reject the decision. If consultation can silently veto the choice, the matrix has an undeclared approval layer.
Can decision rights be automated?
The routing and evidence checks can be automated after the rule works in live cases. Consequential commitments should remain with an authorized human decision-maker. Automation should enforce explicit limits and records, not invent authority from historical behavior.
Release routine decisions without releasing control
Begin with one recurring workflow where ordinary work repeatedly waits for the founder. Reconstruct recent decisions, separate them by consequence, and publish a small matrix for the next live case.
If the authority problem crosses several teams, systems, commercial commitments, and disputed records, Book a SYSIPHANY discovery call. We can help turn founder-held judgment into bounded operating rules without pushing consequential responsibility into a checklist.