Why client requests get stuck between people

A client emails a partner with a question about a pricing model. The partner forwards it to a manager, who asks an analyst to find the latest numbers. The analyst sends a draft back two days later, but nobody replies to the client because each person assumes someone else owns the response.

That pattern can occur in consulting firms. Requests arrive through email, meetings, shared inboxes, project tools, and sometimes a direct message to the person who happens to know the client best. The firm may have the expertise to answer quickly, but no dependable way to decide who should take the next step.

For a consulting business, the cost isn’t just a delayed reply. It can mean partner time spent routing work, a consultant losing billable hours to coordination, or a client questioning whether the firm is paying attention. Some requests also point to new work, but they can be missed when nobody records them as an opportunity.

Automatically routing client requests to the right consultant means building a workflow that can do four things reliably:

Capture the request and enough context to understand it.
Classify the request by topic, urgency, client, and type of work.
Assign an owner using expertise and current workload.
Track acknowledgment, next action, and closure.

An agent can handle much of the sorting and follow-up. People still make judgment calls when the request is unclear, sensitive, or commercially important.

Start with the requests your team already handles

Don’t begin by trying to classify every possible message. Look at the requests consultants receive in a typical week and find the recurring categories.

A firm advising mid-market businesses might see requests about financial models, market research, operating processes, leadership workshops, proposal changes, project status, and introductions to specialists. Some are routine questions. Others are new scope, urgent delivery issues, or requests that need a partner’s judgment.

For two or three weeks, record a small sample of incoming requests. Capture:

The original channel and date.
The client and active engagement, if there is one.
The request in the client’s own words.
The topic and likely request type.
Who handled it and who should have handled it.
Time to acknowledgment and time to resolution.
Whether it created new work or changed the current scope.

That sample gives you a practical starting point. It also shows where the intake process breaks. A team that already has a structured intake form can use it. A team relying on email can begin by monitoring a shared inbox or forwarding selected messages to a controlled intake queue.

If intake is the bigger gap, see how to automate client intake for consulting firms. The goal here is not to force every client into a new portal. It’s to get requests into a consistent workflow, even when they arrive in different places.

Design a useful classification, not a complicated one

Classification is the decision about what a request is and what should happen next. Keep the first version small enough that a consultant can understand it without a guide.

A useful starting set of fields might include:

Topic: finance, operations, strategy, research, or another area the firm serves.
Request type: question, deliverable change, project risk, new opportunity, or administrative need.
Urgency: routine, time-sensitive, or urgent, based on clear service rules.
Client and engagement: the relevant account and active project.
Next action: answer, investigate, schedule a conversation, confirm scope, or escalate.

The agent reads the message and uses those fields to suggest a classification. It should retain the original request and provide a short reason for its recommendation. For example: “Classified as a time-sensitive finance question because the client mentions a board meeting on Friday and asks for an updated forecast.”

That explanation makes it easier for a person to correct the classification and helps the firm spot patterns in errors. If the client writes, “Can you send the scenario we discussed for the board pack?” the agent may identify a financial model request. If the reference is unclear, it should flag the missing context rather than inventing an answer.

Set straightforward rules for urgent requests. “Urgent” should mean something concrete, such as a delivery blocker, an imminent client deadline, or a material issue that needs a partner’s attention. If every message is marked urgent, the label stops helping.

Some requests are commercially sensitive. A question about adding a workstream should be tagged as a scope or opportunity discussion, not treated as a routine delivery task. That classification can notify the engagement lead or partner while keeping the current project team informed.

Assign an owner using expertise and capacity

Routing based only on topic can overload the person everyone already relies on. Routing based only on workload can send a request to someone who lacks the right client context. A useful assignment combines expertise, engagement knowledge, availability, and escalation rules.

Start with a routing table the team can maintain. For each consultant, record relevant practice areas, client relationships, active engagements, role, and any limits on what they can own. Keep it factual. “Has led pricing projects” is more useful than “good with strategy.”

Then define the order of decisions. A typical workflow might:

Assign the request to the current engagement lead when it concerns active project delivery.
Route specialist topics to a qualified consultant on the relevant practice team.
Check current workload or availability before confirming the assignment.
Notify a partner or practice lead if no qualified person is available, the request is urgent, or it could change scope.
Send the request to a human queue when the classification is uncertain.

The workload check doesn’t need to be a perfect utilization model on day one. It might use availability status, open request count, or a simple capacity indicator maintained by team leads. The important thing is to avoid treating a busy consultant and an available consultant as interchangeable.

Before sending a request to a client-facing owner, the workflow can draft an acknowledgment. The assigned person confirms or edits it, then sends it from the approved account or shared inbox. That keeps the client informed without letting an agent make a commitment on behalf of the firm.

For firms with a high volume of incoming email, automating client email triage can address the same classification and ownership problem at the inbox level. Keep the routing rules connected to the firm’s existing communication process rather than creating a second place people need to check.

What the end-to-end agent workflow looks like

Consider a client who emails, “We need to revisit the cost assumptions before next week’s steering committee. Can someone look at the new supplier figures?”

The workflow could run like this:

1. Capture the request. The agent monitors an approved shared inbox or receives messages passed in through an existing intake process. It records the sender, client, time received, message, attachments, and related engagement where available.

2. Identify context. It checks the client record and project information it is permitted to access. It looks for the engagement lead, project topic, key dates, and relevant documents. If it can’t confidently match the sender to a client or project, it flags the gap.

3. Classify the request. It suggests “financial model update,” marks the steering committee date as a deadline, and identifies that supplier figures are attached. It notes that the request could be in scope or could require a change, based on the engagement’s recorded scope.

4. Select an owner. The engagement lead is the first choice because the request relates to active project assumptions. If that person is unavailable, the workflow checks the agreed backup and alerts the lead. It doesn’t route the request to an unrelated consultant simply because they have a lighter workload.

5. Prepare the next action. The agent creates a task with the message, attachment links, suggested category, and a proposed due date. It drafts an acknowledgment for review, such as confirming receipt and saying the team will check the figures against the current model.

6. Get human confirmation. The engagement lead confirms the owner and message. If the work is outside scope, they can mark it for a scope discussion rather than letting the agent promise extra work.

7. Track the request. The workflow records the acknowledgment, owner, due date, status, and resolution. If the request hasn’t been acknowledged within the firm’s service target, it reminds the owner or escalates to the agreed backup.

8. Learn from corrections. If a partner changes the category or owner, that correction becomes a review point. A team lead can see whether the routing rule needs updating, rather than quietly relying on the same partner to fix it next time.

This is a controlled workflow, not an agent making client commitments on its own. The system can classify, suggest, create tasks, and remind people. Your team decides what to send, what to accept as scope, and when a partner needs to step in.

Book a 60-min Omni Audit to map where requests enter your firm, which decisions can be automated, and where human approval should remain.

Connect routing to the firm’s reusable knowledge

A routed request often needs more than a name and a due date. The consultant may need the latest client assumptions, a prior analysis, or a similar answer from another engagement. If that knowledge sits in old decks and email threads, routing alone won’t speed up the work.

A knowledge agent can help consultants find relevant material across the firm’s knowledge base. It should identify the source and distinguish a past project finding from current client-specific advice. A previous answer is a reference, not a substitute for checking whether the facts still apply.

A research agent can support company and industry research when a request turns into a new engagement or a substantial follow-on project.

When a routed request becomes a proposal opportunity, an agent can help prepare a draft for review. The draft still needs commercial and partner review, but the team has a better starting point.

These agents connect request handling to the wider operating system of the firm. They don’t replace the consultant’s relationship with the client. They reduce time spent searching, copying, and coordinating so the right person can focus on the decision.

Set follow-up rules and measure whether routing works

A request isn’t handled just because it has an owner. The workflow needs to make the next step visible and bring stalled work back to someone’s attention.

Agree on response targets by request type. A routine question may have a different acknowledgment target from a delivery blocker or a potential scope change. Don’t promise a universal response time unless the firm can meet it. A target that’s realistic for your team is more useful than a polished service standard nobody follows.

Track a short list of measures:

Time from receipt to acknowledgment.
Time from receipt to assignment.
Requests with no owner or no next action.
Requests reassigned after the first routing decision.
Requests that miss their due date.
Requests that become scope changes or new opportunities.
Consultant and partner time spent on coordination.

Review these measures monthly with the people who own the process. If requests are often reassigned from a general queue to the same specialist, update the expertise rules. If owners accept requests but don’t close them, the missing piece may be a clear next-action field or a reminder. If requests are frequently marked urgent, revisit the definition.

Routing can also expose the cost of surrounding manual work. A request that requires an onboarding task may point to gaps in client setup. Understanding what client onboarding really costs your consulting firm can help you separate routing delays from broader process costs.

Data access needs the same care as the workflow. Give the agent access only to the inboxes, client records, and documents needed for its job. Define who can view sensitive requests, how attachments are handled, and what gets logged. For a closer look at those controls, read how consulting firms keep client data confidential with AI.

Put the dollars in context

For consulting firms, the annual leakage associated with this vertical can vary widely. That’s a broad band, not a promised saving or a forecast for any single firm. The actual exposure depends on request volume, partner involvement, consultant rates, follow-up discipline, and how often a request leads to work that the firm fails to scope.

A practical way to estimate your own exposure is to count the hours spent sorting and chasing requests over a representative month. Add the time partners and senior consultants spend forwarding messages, resolving ownership confusion, and recreating context. Then consider whether delayed follow-up has affected retention, delivery, or opportunities to extend an engagement.

Even a few hours of avoidable coordination each week can matter when senior time is expensive and project capacity is tight. But the point isn’t to put a speculative dollar figure on every email. It’s to identify where requests stall, who spends time unsticking them, and what the firm could do with that capacity instead.

Start with a focused Omni Audit

An Omni Audit can help your team explore its request-routing process. Bring a sample of real requests, your current client and engagement structure, and the routing decisions people make today.

Use the session to explore how requests enter the firm, possible routing rules, and implementation considerations.

The aim is to leave with a clear view of what to automate first and what should stay with a person. Start with the AI audit for consulting firms if you want to see how the session fits your business.

For a practical worksheet before that conversation, download Deploy Your First Business Agent or get the worksheet directly. Use it to list the request types, likely owners, information needed, and follow-up rules for one workflow. You don’t need to map the whole firm before testing a first version.

If the team can name its common request types and agree on who should own them, you have enough to start designing the workflow. The next step is to test it on a small set of requests, review the classifications and assignments with consultants, and adjust the rules before expanding access.

Book your 60-min Omni Audit and map a first workflow for your firm. You can also see Omni for consulting firms and identify where request routing fits alongside the rest of your operations.

How to Route Client Requests to the Right Consultant