A request can pass through several reviews without reaching anyone authorised to resolve the central disagreement. Each reviewer adds a reasonable question, the requester supplies more information, and the workflow continues. The organisation has a record of activity while the decision remains open.
This is one way process can become a means of avoiding conflict. The issue may concern who can commit money, which risk is acceptable, or whose priority takes precedence. A form can collect the relevant evidence, but it cannot settle a choice that the participants have not agreed how to make.
The existence of a long process does not establish avoidance. Some decisions genuinely require several kinds of expertise or independent scrutiny. The useful question is what each step contributes and whether the combined process produces a clear, defensible answer in time for the work that depends on it.
Identify the Choice the Workflow Is Supposed to Resolve
Consider a company reviewing customer discounts. Sales wants flexibility to retain a valuable account. Finance wants to protect the economics of the contract. Operations needs to know whether the service promise can be delivered at the proposed price. Those interests can differ without any participant acting unreasonably.
The process begins to struggle when the company has not decided how those considerations should be weighed. A finance review establishes the margin, an operations review identifies additional effort, and a sales manager explains the commercial opportunity. None of those findings, on its own, determines whether the deal should proceed.
A decision owner needs authority to weigh the relevant options within agreed boundaries. Those options might include accepting the discount, changing the service scope, offering a different term, or declining the request. The reviewer should know which conditions are fixed and where judgement is permitted.
If every unfavourable finding automatically returns the request for revision, the workflow may be concealing the absence of that authority. The requester keeps changing the proposal without knowing what would make it acceptable. A direct refusal with an explanation may be more useful than another cycle of work.
Start the review by stating the actual choice. In this case, it is whether the commercial value justifies the proposed terms and delivery commitment. That description helps separate information gathering from approval and prevents every participant from being treated as the final decision-maker.
Distinguish Expertise From Approval
Several people may need to contribute without each holding a general veto. Finance can explain the financial assumptions. Operations can assess capacity. A specialist can identify a condition that must be satisfied. The final approval can then use those contributions within the company’s delegated authority.
Some requirements do impose genuine limits. A proposed contract may include a service the company cannot provide or a term outside its permitted arrangements. The process should identify those limits clearly, rather than describe all concerns as either optional advice or absolute barriers.
Atlassian’s DACI framework distinguishes a decision’s driver, approver, contributors, and informed participants. It offers a practical way to discuss these roles. Applying the labels is only a starting point; the approver still needs actual authority over the commitment being made.
The discount process should also establish what happens when contributors disagree. A request may be commercially attractive but operationally expensive. Asking Sales and Operations to reach consensus can help them develop a better option, but it should not leave them negotiating indefinitely if they cannot agree.
A workable route brings the unresolved choice to someone authorised to decide it. The escalation should include the alternatives, consequences, and remaining uncertainty. It should return a decision that the teams can apply, rather than another instruction to align.
Examine What Each Step Changes
To assess an existing workflow, follow a few recent requests. Record where they waited, what information was requested, what changed after each review, and who eventually decided. Include an ordinary request, an exception, and a case that was declined or abandoned.
This can reveal different problems. A step may catch important omissions but wait unnecessarily for a monthly meeting. Another may duplicate a check already completed. A third may appear redundant because its purpose is to provide independent assurance rather than new information. These findings call for different responses.
A useful review asks what would be lost if the step changed. Would a risk go unexamined? Would the decision-maker lack information? Would an obligation become unclear? If nobody can identify the purpose, that is a reason to investigate the rule’s history, rather than proof that it is safe to remove.
Checklists can support this work by making important conditions visible and reducing reliance on memory. Their limitations arise when completed fields are treated as sufficient evidence that a proposal is sound. A checklist should help a reviewer examine the decision, with a route for cases that do not fit its assumptions.
Delay also needs interpretation. Time spent waiting for an unavailable approver differs from time spent developing a genuinely incomplete proposal. Looking only at the total duration can encourage the wrong change, such as removing a useful review while leaving the queue untouched.
Make the Disagreement Discussable
Process can give people a less personal way to raise concerns. A common set of criteria can reduce arbitrary treatment and help a requester understand an unwelcome answer. Those are useful functions, particularly where individuals would otherwise have to negotiate every exception informally.
The difficulty is allowing the procedure to stand in for an explanation. Telling an account manager that a request failed a policy check may be accurate, but it should be possible to explain the relevant condition and whether an alternative exists. Where judgement was exercised, someone should own that judgement.
For the discount request, the disagreement might be about a forecast of future revenue. Sales considers renewal likely; Finance considers the evidence weak. Naming that difference allows the company to test assumptions, compare scenarios, or choose a shorter commitment. Adding another signature without identifying the disputed assumption would contribute less.
The discussion should remain about the decision and the work. Attributing reluctance to territorial behaviour or lack of trust may be tempting, but those explanations need evidence. A cautious reviewer may know about a cost or obligation the requester has not considered.
Equally, a genuine concern should not become a permanent reason to avoid a decision. If further analysis is requested, specify what question it will answer and how the answer could affect the choice. That gives the additional work a purpose and a point at which the matter can return for decision.
Test a Simpler Route Without Losing Necessary Controls
Improvement need not begin with a wholesale redesign. The company could identify a class of routine discounts that falls within known commercial and operational limits. Those requests might be delegated to a manager, with unusual cases continuing through the wider review.
Before changing the route, establish the boundaries, required evidence, and escalation conditions. People need to know when the simpler process applies and when a request must move elsewhere. They also need support to use the delegated authority, including examples of acceptable and unacceptable cases.
A limited trial can compare decision time, rework, consistency, and the quality of resulting commitments. Review a sample of approved requests to see whether the assumptions held. Faster approval is useful only if the company can still fulfil the agreement and understand its implications.
Exceptions should provide information about the design. Repeated requests for the same departure may indicate a changing customer need, an unrealistic threshold, or poor understanding of the existing rule. The response should follow the evidence rather than automatically tightening the process.
Unclear authority can remain hidden inside a simplified workflow just as easily as a complicated one. Removing steps will not help if nobody can settle the remaining trade-off. The trial should therefore examine whether decisions are made at the intended level and whether escalations reach a person able to act.
Maintain the Reasoning Alongside the Rule
Once a process changes, preserve why it works that way. A short explanation of the risk, the decision owner, and the conditions for exceptions helps future staff apply it. It also provides a basis for later revision when the circumstances change.
Review should be prompted by evidence from the work: repeated delays, avoidable rework, inconsistent decisions, or a change in the obligations the process serves. Routine maintenance can prevent old steps from remaining solely because nobody knows what they protect.
A useful process does not eliminate disagreement. It makes the disagreement easier to understand and provides a way to reach an authorised answer. The practical test is whether a requester can discover what is required, obtain a decision, and understand the reason for it. Where that connection is missing, the next improvement should address the unresolved choice as well as the workflow around it.
