Why Your Workflow Breaks When the Real Problem Is Unclear Decision Rights

The workflow is not failing because people are lazy

A lot of operational problems get blamed on the wrong thing.

A manager says jobs are sitting too long waiting for approval. The office team says field staff keep making decisions they should not make. Supervisors complain that work gets escalated unnecessarily. Someone suggests the software needs replacing because the workflow feels messy and inconsistent.

Sometimes the system does need work. But often the real problem is simpler and more structural: nobody has clearly defined who is allowed to decide what.

That is a decision rights problem.

When decision rights are unclear, the workflow becomes dependent on habit, personality and workarounds. Staff either stop and wait because they do not want to overstep, or they push ahead because the job needs to move. Both behaviours create problems. One creates bottlenecks. The other creates inconsistent outcomes, rework and arguments after the fact.

If you want a workflow to move reliably, it is not enough to assign tasks. You also need to define authority.

Task ownership and decision rights are not the same thing

This is where many businesses get caught.

They have assigned responsibility for doing the work, but they have not assigned responsibility for making decisions about the work.

Those are different things.

Task ownership answers questions like:

• Who prepares the quote?
• Who schedules the technician?
• Who sends the invoice?
• Who closes the job in the system?

Decision rights answer different questions:

• Who can approve a discount?
• Who can reschedule a job without customer sign-off?
• Who can add scope once work has started?
• Who can write off a variation that was missed?
• Who can mark a job complete if required documents are missing?
• Who can override the normal process when something goes wrong?

A staff member can own a task without having the authority to make every decision connected to that task.

For example, a project coordinator may own the scheduling function, but that does not automatically mean they can move a job that affects another crew, changes promised dates or increases cost. A technician may own job completion in the field, but that does not necessarily mean they can decide incomplete documentation is acceptable.

When businesses confuse task ownership with decision rights, the process looks defined on paper but breaks down in practice.

What unclear decision rights look like in day-to-day operations

You do not usually hear staff describe this as a governance issue.

What you hear instead is:

• “I wasn’t sure if I was allowed to approve that.”
• “We had to wait for one person to come back to us.”
• “Different managers handle it differently.”
• “We just did it this way because the customer was pushing.”
• “That should have been escalated earlier.”
• “I thought someone else had signed off on it.”
• “We had to reopen the job because it should not have been closed.”
• “The team keeps bypassing the process.”

These symptoms often show up as:

• approval delays
• repeated overrides
• inconsistent customer outcomes
• staff workarounds
• friction between office and field teams
• jobs stuck in status limbo
• rework after the wrong decision was made
• poor auditability when something goes wrong

The visible issue may look like a slow workflow. The actual issue is that the business has not defined authority well enough for the workflow to run without constant interpretation.

The decisions that usually need explicit authority rules

Not every choice needs a formal approval path. If you force every small decision upwards, you create a different problem.

But there are recurring decision types that usually need to be made explicit.

Approvals that affect money

This includes decisions such as:

• discounts
• credits
• write-offs
• scope reductions
• unbilled extras
• variations
• out-of-policy purchases
• overtime approvals
• customer goodwill decisions

If no authority threshold exists, staff either freeze and escalate everything or make inconsistent judgement calls.

A practical model might define authority by value, job type or customer risk. For example, small commercial adjustments may sit with a service manager, while larger write-offs require director approval.

The point is not bureaucracy. The point is consistency and speed.

Decisions that change commitments

These include:

• rescheduling booked work
• changing installation dates
• moving priority between jobs
• reallocating crews
• extending deadlines
• changing promised customer outcomes

These decisions affect more than one person or team. If the authority to make them is unclear, the business starts creating downstream disruption without anyone fully owning the consequence.

Scope changes after work has started

This is one of the most common operational failure points.

A technician finds additional work on site. An installer discovers the quoted scope does not match site conditions. A project team needs to substitute materials or change the sequence of work.

If the team does not know who can authorise changes, one of three things happens:

1. the work stops while someone tries to find the right person
2. the field team makes the call themselves
3. the work continues informally and the commercial record gets fixed later, if at all

All three can be expensive. Clear decision rights reduce that ambiguity.

Exceptions to normal closure rules

Job closure often looks administrative, but it is really a control point.

Who can close a job if photos are missing? Who can sign off practical completion if the customer has not responded? Who can complete a stage if supplier invoices are still pending? Who can release a handover when there is a minor defect outstanding?

If nobody defines this, jobs get closed inconsistently or remain open far longer than necessary because staff are worried about doing the wrong thing.

Why software permissions do not solve this by themselves

A common mistake is to treat system permissions as if they are the governance model.

They are not.

A platform may let you restrict who can edit a field, approve a status or close a task. That can be useful. But software permissions only enforce rules that have already been thought through.

If the business itself is unclear on authority, the software will not fix that confusion. It will usually do one of two things:

• allow too much, which creates inconsistent decisions and poor control
• restrict too much, which creates bottlenecks and side-channel workarounds

This is why some workflows technically work in the software but still fail operationally.

People start using phone calls, text messages, verbal approvals and “just do it for now” instructions because the actual decision path lives outside the system. At that point, your workflow may be automated on paper, but the real process is still informal.

System permissions matter. But they should reflect operational governance, not substitute for it.

Bottlenecks often come from authority being too centralised

Some businesses know they have an authority model, but it still causes delays because nearly every exception or approval flows back to one person.

That might be the owner, operations manager or senior estimator. Eventually that person becomes the unofficial processing engine for the business.

This creates familiar symptoms:

• jobs waiting for sign-off
• staff constantly interrupting the same manager
• customer response times depending on one person’s availability
• rushed approvals with limited context
• poor continuity when that person is away
• inconsistent decisions because everything is handled ad hoc

The business then thinks it has a workload problem when it actually has a delegated authority problem.

If every small variation, reschedule, write-off or exception requires senior review, the process will slow down no matter how good the software is.

The answer is not to remove control entirely. It is to define where authority can be delegated safely and under what conditions.

Good delegated authority is specific, not vague

Telling staff to “use common sense” is not a decision framework.

Delegated authority works when people understand:

• what they can approve
• under what conditions
• up to what limit
• what must be escalated
• what information must be recorded
• what happens if they override the standard path

For example, a service coordinator might be allowed to reschedule jobs within a defined window if no cost impact exists and the customer agrees. A site supervisor might approve minor scope adjustments up to a certain threshold if supporting photos and notes are attached. A project manager might close a stage with one missing document, but only if a follow-up task is automatically created and assigned.

These are operational rules. Once they are clear, technology can support them properly.

Escalation should be designed, not improvised

A process does not become robust just because it includes the word “escalate”.

Escalation only works when the path is defined.

If staff hit a decision outside their authority, they should know:

• who the next approver is
• what information that person needs
• how the request is raised
• what timeframe is expected
• what happens if there is no response
• whether work should pause or continue pending a decision

Without this, escalation becomes another source of delay.

A common operational gap is that staff do recognise a decision is outside their authority, but the mechanism for escalation is so unclear or slow that they either keep waiting or act anyway.

A workable escalation design removes guesswork. It also avoids the situation where senior people are asked to decide without the context they need, which is one reason approvals often get reversed later.

Repeated overrides are a signal that the authority model is wrong

If people constantly need exceptions, there are usually two possibilities:

1. the process is badly designed
2. the decision rights are misaligned with reality

For example, if jobs regularly require a manager to reopen, reassign or commercially adjust them after closure, that is worth examining. Either the closure criteria are unrealistic, or the wrong people are being asked to make closure decisions.

If a team routinely seeks unofficial approval through chat or phone rather than following the system path, that usually means the formal route is too slow, too rigid or disconnected from how work actually happens.

Repeated overrides should not be treated as just a discipline issue. They are useful evidence.

They tell you where the process and authority model no longer match the operational reality.

You need an audit trail for overrides and exceptions

Not every non-standard decision is bad. Operational work involves exceptions.

But if an exception changes cost, delivery, scope, risk or customer commitment, there should be a record of:

• what was changed
• who approved it
• when it was approved
• why the standard path was not followed
• what follow-up action is required

Without that audit trail, the business loses more than accountability.

It also loses the ability to learn.

You cannot improve authority rules if every override disappears into verbal conversations and memory. You also make it much harder to resolve disputes, trace margin leakage or understand why particular jobs became difficult to close or invoice.

An override record does not need to be complicated. It just needs to exist somewhere reliable and be tied to the job or workflow item.

What better operational authority looks like

A healthy workflow does not require constant interpretation about who is allowed to do what.

Good authority design usually includes:

• clear task ownership
• clear decision ownership
• authority thresholds where relevant
• defined escalation paths
• documented exceptions
• visible approval points
• practical delegation close to where the work happens
• system controls that reflect the real operating model

In practice, that means the business can answer questions like these without hesitation:

• Who can approve a variation once a crew is on site?
• Who can move a booked job if the customer asks for a change?
• Who can close a job with missing information?
• Who can write off a small discrepancy?
• Who can override the normal approval path in an urgent situation?
• What record is required when that happens?

If those answers vary depending on who happens to be asked, the workflow is still fragile.

How to fix it without creating more bureaucracy

The goal is not to produce a giant policy document nobody uses.

A better approach is to map the workflow and identify where decisions materially affect cost, timing, risk, customer commitments or data quality.

Then define, for each decision point:

1. what the decision is
2. who normally owns the task at that stage
3. who has authority to approve or change it
4. what conditions or limits apply
5. what must be escalated
6. how the decision is recorded
7. what the system should do next

This exercise often reveals why a workflow feels harder than it should. The process may be technically mapped, but the authority rules are missing.

Once those rules are clear, you can decide whether the current systems can support them through permissions, status changes, approval steps, notifications or exception logging. In many cases, the software is already capable. It just has not been configured around a clear operational model.

The real goal is faster decisions with less confusion

Clear decision rights are not about adding control for its own sake.

They are about making it easier for work to move without unnecessary chasing, guessing or rework.

When authority is designed properly:

• staff know when they can act
• managers are involved where judgement is genuinely needed
• approvals happen with the right context
• exceptions are visible
• overrides are traceable
• bottlenecks reduce because not everything flows to the top
• automation works better because the rules behind it are explicit

That is what makes a workflow reliable.

If your process keeps stalling, being overridden or producing different outcomes depending on who is involved, the problem may not be the platform at all. It may be that the business has never clearly defined who can approve, change, override or close the work.

That is an operational design issue, and it is usually worth fixing before adding more software or more automation.

If your workflow spans multiple teams, systems and exception paths, mapping the decisions alongside the process is often the fastest way to see where things are really breaking. That is the kind of operational design work 5M Consulting helps businesses untangle.