Approval delays are a project control problem

A consulting project can be ready to move and still sit idle because one client decision is missing.

The team sends a deck for review. Someone at the client says they’ll get to it. A week passes. The project manager follows up, then follows up again. The approver may be out, the request may be buried in a long email thread, or nobody may know who has authority to sign off.

Meanwhile, the next workshop gets pushed, analysts wait for direction, and the delivery lead spends time reconstructing what was asked and when. The issue isn’t that clients don’t care. It’s that approval work is often managed through inboxes and memory instead of a clear process.

For a consulting firm, the answer isn’t to send more reminders by hand. It’s to make every approval request easy to understand, send it to the right person, follow up at sensible intervals, and record the decision where the project team can find it.

That’s the system this guide lays out. It gives you a practical way to use an AI agent for reminders, approval routing, escalation rules, and decision logs without handing client judgment over to automation.

Map the approvals that hold up delivery

Start by listing the client decisions that routinely block work. The list will differ by firm, but it often includes:

Signoff on a project plan, scope, or success measures
Approval of interview participants or workshop attendees
Review of research findings before the team moves into recommendations
Decisions about options, priorities, or tradeoffs
Acceptance of a deliverable or a change to the agreed scope

For each approval, note the deliverable or decision, the person who owns the request on your side, the client approver, the due date, and what work depends on the answer. Also record a backup contact and the person who should be told if the request goes overdue.

This inventory makes a hidden workflow visible. It can reveal that the project lead is sending requests to a broad distribution list when one named sponsor is responsible. Or that a client receives a request without the context needed to decide. Sometimes the approval itself is not the delay. The delay is figuring out what the client is being asked to approve.

Be specific about the decision. “Please review the deck” invites an open-ended task. “Please confirm whether we should use option A or option B for the pilot scope by Thursday” gives the approver something actionable.

A useful request includes the decision required, a short explanation of why it matters now, the relevant material, a clear response method, and the date by which the team needs an answer. If there are consequences to missing the date, explain them calmly. For example, the workshop may need to move, or the project team may proceed using the assumptions already documented in the plan.

Build a simple approval workflow

A repeatable workflow should have five stages.

1. Create the request. A project lead creates an approval item from a template. The item captures the client, project, decision, approver, due date, supporting files, and dependent work. This can begin from a project tool, a form, or a structured record. The key is that a request shouldn’t exist only as an email someone has to remember.

2. Route it to the right person. Send the request directly to the named approver, with relevant project contacts copied only when needed. If a decision requires more than one signoff, define whether approvals happen in sequence or in parallel. Don’t make the client guess who should respond.

3. Track the response. The system records when the request was sent, whether it was opened or acknowledged if that signal is available, and the current status. Statuses can stay simple: draft, sent, acknowledged, approved, changes requested, overdue, or escalated.

4. Remind and escalate. Send reminders based on the due date and the status, not as a fixed stream of messages. If there’s no response, follow the agreed escalation path. The agent can prepare or send a message according to your rules, but a person should review sensitive or high-impact escalations.

5. Log the decision. Record the approver, decision, date, comments, and any assumptions or conditions. Link the record to the relevant deliverable and project plan. That gives the delivery team one place to check what was agreed.

This workflow also connects naturally to the earlier steps in delivery. Clear project intake helps define who owns a decision before work starts, as covered in automating project intake for a consulting firm. And if meeting times and follow-ups are a recurring source of friction, this guide to automating client scheduling and reminders covers the adjacent admin work.

What the approval agent does from end to end

An approval agent works from your rules and project information. It doesn’t make the client’s business decision, decide whether a deliverable is good enough, or infer consent from silence.

Here’s a typical sequence.

A project lead submits a request. They select the project, attach the deliverable, describe the decision, name the approver, and enter the due date. The agent checks that required information is present. If the request says only “review this,” it asks the project lead to clarify what the client needs to decide.

The agent checks routing rules. It matches the request type to the approver and backup contact listed for that project. If the person isn’t listed, or the approver conflicts with the project’s decision rights, the request goes back to a human instead of being sent to an uncertain contact.

The agent prepares the message. It creates a concise email or task with the decision, the due date, a link to the material, and a response option. The project lead can approve the message before it goes out, particularly during rollout. After the team trusts the process, routine requests can follow pre-approved templates.

Reminders follow the clock and status. For instance, a firm might send the initial request with five business days to respond, a reminder two business days before the due date, and a same-day note if there’s still no answer. Those are starting points, not universal rules. A board decision or scope change may need a different timeline from a quick review of interview participants.

If the client acknowledges the request and asks for time, the agent updates the status and adjusts the next reminder according to your policy. If the client says the approver is wrong, the request is routed for correction rather than repeatedly sent to the same person.

Escalation follows a clear rule. Once the due date passes, the system can alert the internal project owner. That person may contact the sponsor, ask the client to nominate another approver, or discuss how the delay affects the schedule. The agent can draft the escalation with the request history attached, so the project lead doesn’t have to search through email first.

The decision becomes part of the project record. An approval, rejection, or request for changes is captured with its date and context. The agent links the record to the deliverable and updates the status. If the response changes the scope, it can flag the item for a human to assess through the firm’s change-control process.

The useful distinction is that the agent handles coordination and recordkeeping. The consultant remains responsible for the recommendation, the client relationship, and any judgment call about whether the project can proceed.

Set escalation rules before you automate

A reminder system can make matters worse if it sends the wrong message at the wrong time. Agree on the rules before turning on automated follow-up.

For each request type, decide:

How many business days the client normally gets
When a reminder goes out
Who is notified when the due date passes
When the client sponsor is contacted
Whether work can proceed using a documented assumption
Which requests always need human review

A minor formatting signoff and a decision that changes the project’s direction shouldn’t share the same escalation path. For a high-impact decision, the first step after a missed deadline might be a private alert to the engagement lead, not an automated message to the client’s executive sponsor.

Also make the “no response” policy explicit. Silence is not approval unless your contract and project governance say otherwise. If the team has authority to continue based on an assumption, record the assumption, its owner, and the point at which it needs to be revisited.

For more examples of how to make follow-ups feel organized rather than nagging, see how to automate approval reminders. The business context differs, but the principles of clear ownership, useful timing, and a documented response carry across project teams.

Make the decision log useful after the email is gone

A log is only useful if people can find and trust it. Don’t bury approval decisions in a long transcript or add fields no one maintains. Capture the information that helps the team act:

Project and deliverable
Decision requested
Named approver and their role
Date sent and due date
Final decision and date received
Conditions, comments, or assumptions
Link to the approved version
Internal owner and any follow-up action

Use a consistent naming convention and connect the log to the client and project. When a client changes their mind later, the team can see what was approved, by whom, and against which version. When a new team member joins, they don’t need to ask three colleagues to reconstruct the history.

There’s a knowledge-management benefit too. Tools can help the team find recorded decisions across its working documents and surface past context when similar decisions arise. Neither replaces an approval log, but both can make project knowledge easier to retrieve when they’re built around clear records.

The same foundation supports other operations. A proposal-generation agent can help prepare a tailored draft. That addresses a different source of delivery pressure: the time senior people spend on major proposals. These agents work best when a firm has a defined process and reliable source material, not when it expects automation to repair inconsistent records on its own.

Start with one project and measure the delay

Don’t roll the workflow out to every client at once. Choose a live engagement with several recurring approvals and a project lead willing to test the process.

For the first few weeks, track the number of requests, median time to decision, overdue requests, reminder count, and any work delayed by a missing signoff. Note where the agent needed a human correction. Those corrections show you which routing rules or request templates need attention.

Compare the results with the previous way of working, but be careful about claiming that every shorter delay came from automation. Client availability, project complexity, and the urgency of the decision all matter. The point is to learn whether requests are getting to the right person with enough context, and whether your team is spending less time chasing and reconstructing.

For a firm experiencing operational friction, approval delays are one place to investigate. That range is a reason to examine where time and delivery capacity are going, not a promise that an approval agent will recover the full amount. Measure the cost in your own projects: delayed billable work, extra project management, schedule changes, and senior time spent following up.

If you want to map the workflow against the rest of your operations, Book a 60-min Omni Audit. We use the session to identify the manual work, assess what can be automated, and agree on a practical first step.

Put the system into practice

The practical order is straightforward. Define the approval types, name the approvers and backups, set due dates and escalation rules, create a short request template, then test it on one project. Keep human review around high-impact decisions. Make the log part of the project record, not a separate spreadsheet that goes stale.

If you want a working aid for that first rollout, Deploy Your First Business Agent is a practical worksheet for mapping a task, its inputs, its rules, and the points where a person needs to stay involved. You can also download the worksheet directly. Use it to document the approval workflow before you choose tools or build automations.

An Omni Audit is a focused working session. You leave with outputs to help identify automation opportunities, a workflow to test, and practical next steps. There’s no deck to sit through. We work through the process with you and leave the next steps clear.

To see how the approach fits consulting and advisory firms, see Omni for consulting firms. When you’re ready to review the approval process and its place in your operations, Book your Omni Audit. The AI audit for consulting firms is built to find where better routing, reminders, and records can reduce avoidable delays.

Stop Chasing Clients for Consulting Approvals