Slow approvals are a product state teams can operate

A slow approval is often described as if it were weather: finance has not replied, legal is busy, or the client has gone quiet. That framing hides the product decision. Once a request has been submitted, it enters a real state with an owner, required evidence, a time expectation, and possible exits. If the system records none of those, waiting becomes invisible work. The answer is not simply more notifications. It is a workflow that makes waiting observable and gives the team a safe way to act.

Model waiting as an explicit state

“Pending” is too vague to operate. It might mean the request has not been assigned, the approver has not opened it, evidence is missing, changes were requested, or a deadline has passed. Each condition calls for a different response.

Use a small state model that distinguishes at least:

• ready for review;
• assigned and awaiting a decision;
• changes requested;
• approved or rejected;
• expired or escalated;
• cancelled or superseded.

Transitions matter as much as labels. Define who can move a request, what information is required, and what downstream action becomes available. Approval should attach to a specific version of the work. If that version changes materially, the previous decision may no longer apply.

This principle is visible in software delivery. GitHub’s protected-branch documentation explains that approvals can be dismissed when the reviewed diff changes, and that rules can require a designated code owner or a review of the most recent update. The broader product lesson is simple: store what was approved, not only that somebody once clicked approve.

Assign one accountable owner

A request sent to “the leadership team” may have many recipients but no owner. Decide whether the workflow needs one named approver, any qualified member of a group, every member, or a sequence of roles. Make that rule visible before submission.

The requester also needs an owner. That person supplies missing material, answers questions, and handles requested changes. Without ownership on both sides, a rejected or incomplete request can drift between teams.

For each approval type, define:

• the accountable approver or approver rule;
• a substitute for absence or conflict;
• the requester responsible for remediation;
• who may reassign, cancel, or override;
• the reason an override is permitted.

A shared inbox can remain a delivery channel, but it should not be the ownership model. The product should resolve a group assignment into an accountable person or an explicit first-response rule.

Put the evidence beside the decision

An approver should not have to reconstruct the request from chat messages, documents, and dashboard tabs. Present a decision packet: the item being approved, its version, material changes since the last review, supporting evidence, known exceptions, and the consequence of approval or rejection.

The interface should also ask for evidence from the approver. Record identity, timestamp, decision, version, and any reason or conditions. A rejection without a reason creates another round of clarification. An approval with conditions needs a state of its own or a follow-up task; otherwise it will be mistaken for unconditional sign-off.

Evidence rules should be proportional. A routine content check may need a preview and short comment. A financial sign-off may require source records, calculation details, exceptions, and a durable decision history. More fields do not automatically create better control. Require the smallest packet that lets the approver decide responsibly and lets another person understand that decision later.

Make time part of the workflow

A deadline is not decorative metadata. It determines when reminders fire, when the request becomes at risk, and when another person gains responsibility. Set it when the request is created, using the approval type and business calendar rather than an arbitrary universal duration.

Reminders should report the current state and the action needed. A useful reminder says what is waiting, who owns it, when it is due, and where the evidence lives. It should stop when the request is decided, cancelled, superseded, or reassigned.

Escalation is a state transition, not a louder reminder. It might reassign to a delegate, notify the request owner, add a second reviewer, or pause the dependent work. The correct action depends on risk. Silence must not become approval unless the policy explicitly permits that outcome.

Official Microsoft workflow documentation provides a useful implementation reference: approval activities can distinguish first-response from unanimous decisions, assign requests to people or groups, schedule reminders, set expiry, and notify a chosen recipient after expiry. Those controls are useful because they encode operating policy, not because automation itself guarantees a timely decision.

Keep reminders and escalation proportional

Notification volume is a poor substitute for workflow design. Repeating the same message teaches people to ignore the system while giving operators little insight into the blockage.

Use a staged policy instead. Confirm assignment immediately. Remind the owner when enough time remains to act. Mark the request at risk before its deadline. Escalate only when the deadline or risk rule is met. Show the requester each transition so they do not create duplicate requests through private channels.

Escalation should preserve context and authority. The substitute must receive the same evidence packet, while the history should show why responsibility changed. If an executive can override a blocked decision, capture the reason and scope. An override that erases the original review trail weakens the workflow precisely when scrutiny is highest.

Apply the pattern to consequential sign-off

In Alfcode’s product work, BackendOS grounds this pattern in a concrete domain. Its verified scope brings payout approvals, rep statements, disputes, and audit-ready finance workflows into one command center, covering a commission run from import to sign-off. That product boundary is instructive: an approval is not an isolated button. It sits between the underlying records, questions or disputes, the decision, and the resulting statement.

The same design test applies outside compensation. For any approval screen, temporarily remove the chat history and the people who built the process. Can a qualified substitute see what is waiting, who owns it, which version and evidence are in scope, when action is due, and what happens after the deadline? If any answer is missing, the product has not yet made waiting operable.