Build an Escalation Policy for Routine Work

Your team should not need the founder to weigh in on every customer exception, vendor issue, hiring wrinkle, or delivery delay. But in many companies, that is exactly what happens: small decisions get routed upward because no one knows where the line is. The result is predictable. Managers hesitate, response times slow, and the founder becomes the default approver for work that should have been handled two levels down.

The fix is not “delegate more.” It is an escalation policy for routine work. That policy defines which decisions should be made locally, which ones need a second look, and which ones must reach the founder or executive team. A good policy creates speed without losing control. It protects judgment where it matters and removes noise everywhere else.

The real problem is not escalation. It is undefined thresholds.

Escalation becomes toxic when it is used as a substitute for decision rights. If people do not know what they are allowed to approve, they escalate anything that feels uncomfortable. That creates two failure modes at once: harmless decisions clog leadership attention, and truly risky decisions still slip through because no one has a clean rule for identifying them.

A useful escalation policy starts with the opposite assumption: most routine work should be decided where the work happens. The policy should answer three questions for each recurring issue category: what is the normal approval path, what threshold triggers escalation, and what evidence must accompany the request.

Example: customer exceptions

Imagine a services company where account managers frequently discount a fee, extend a deadline, or re-scope a deliverable. Without policy, every exception lands in the founder’s inbox with a vague subject line like “Need approval.” The founder has to reconstruct the context, ask for more detail, and then decide whether the request is urgent, fair, or risky.

With an escalation policy, the team knows the difference between routine and exceptional. An account manager can approve a one-time deadline extension if the delay is under a set number of days and the client has already accepted the revised plan. A project lead can approve a small discount if margin stays above the floor. Anything outside those bounds requires a brief escalation packet with the facts, the options considered, and the recommendation.

Use a four-part decision framework to define what escalates.

The policy should be written as a practical decision framework, not a manifesto. Use four filters to determine whether a routine issue stays local or moves up: impact, reversibility, exception level, and evidence quality.

These filters work because they keep the policy tied to operational reality. A low-impact reversible decision should rarely rise. A high-impact irreversible decision should almost always rise. In between is where judgment lives, and that is where your policy needs explicit thresholds.

The point is not to eliminate discretion. It is to make discretion visible. If your managers know the thresholds, they can make better calls faster and spend less time asking permission.

Write the policy around categories, not personalities.

Many companies fail because escalation rules are informal and personality-driven. One leader wants every issue escalated. Another wants nothing escalated unless it is catastrophic. Teams adapt by reading the mood of the manager instead of following a system. That creates inconsistency and trains people to seek the most cautious decision-maker.

A better policy is category-based. Write separate rules for the recurring situations that generate friction in your business:

• Customer credits, refunds, and concessions
• Hiring exceptions and compensation changes
• Vendor changes, purchase overruns, and contract deviations
• Delivery delays, quality failures, and scope changes
• Compliance, safety, and legal exceptions

For each category, define the owner, the local approval limit, the escalation trigger, the required evidence, and the response time. If a decision comes in outside the policy, it should be escalated with a recommendation, not dumped upward as an open question.

What a strong escalation request looks like

A strong escalation is concise and decision-ready. It states the issue, the policy threshold, the facts, the options, the recommendation, and the deadline. It does not ask the founder to investigate. It asks the founder to decide.

If the person escalating cannot explain why the issue crossed the threshold, the issue is usually not ready for escalation.

Common failure modes are usually structural, not behavioral.

When escalation breaks down, leaders often blame the team for being indecisive. That diagnosis is usually too shallow. The deeper problem is that the operating system makes escalation the safest behavior. People escalate because the policy is unclear, the local authority is too narrow, or past decisions were second-guessed without any standard.

Watch for these failure modes:

1. 1Everything escalates because no one trusts local judgment.
2. 2Only bad news escalates because people fear being seen as difficult.
3. 3Escalations arrive without evidence, forcing leadership to become the analyst.
4. 4Thresholds are so high that managers hide problems until they are expensive.
5. 5The founder is copied on every request, which turns notification into pseudo-escalation.

Each failure mode points to a system defect. If everything escalates, decision rights are too narrow. If only bad news escalates, the organization has no safe standard for surfacing risk early. If requests arrive without evidence, the workflow is missing a required input. If the founder is copied on everything, the team is confusing visibility with authority.

Fixing these issues requires tighter design, not more reminders. People follow the system you make available to them.

Implement the policy in a strict order.

Do not publish an enterprise-wide escalation policy all at once and hope people comply. Start with the work that already creates the most friction. The sequence matters because you need proof that the policy improves speed and judgment before you expand it.

1. 1Identify the top five recurring decisions that reach the founder or executive team too often.
2. 2Define the owner, local approval limit, escalation threshold, and required evidence for each one.
3. 3Write a one-page policy per category in plain language.
4. 4Test the policy with the managers who handle those decisions most often.
5. 5Set a review cadence to inspect real escalations, exceptions, and misses.
6. 6Adjust thresholds where the policy is too loose, too tight, or unclear.
7. 7Roll the policy into onboarding, manager training, and operating cadence.
8. 8Track whether escalations are becoming faster, cleaner, and more appropriate over time.

The review cadence is essential. Without it, a policy becomes stale and the organization drifts back to habit. In the review, look at three things: escalations that should not have risen, escalations that arrived too late, and decisions that were handled locally but should have been escalated. That gives you evidence for tightening the system.

A good escalation policy protects speed, accountability, and founder attention.

The best companies do not escalate more carefully because they are more bureaucratic. They escalate more carefully because they respect decision time as a scarce resource. The founder should only be involved when the issue requires their judgment, risk tolerance, or authority. Everyone else should operate inside clear boundaries.

That is the practical test. If a policy lets routine work move faster, gives managers confidence to decide, and surfaces true exceptions with enough evidence to act quickly, it is working. If it creates more waiting, more copying, or more ambiguity, the policy is not guiding decisions. It is adding another layer of confusion.

Build the escalation policy now, while the company is still small enough to standardize. Waiting until the founder is overwhelmed only guarantees that everyone will keep treating escalation as a habit instead of a decision system.