Decide What a Client Request Becomes Before the Work Starts

The request usually enters through the wrong door

A client asks for a carrier comparison during a business review. Another sends an email asking your team to investigate a billing issue. A supplier mentions a migration that needs coordination. Somebody on your team says, "We can take care of that."

Now the work has started, but the firm has not decided what it is.

Is this normal account service? A simple follow-up? Paid analysis? A change to an active project? Does the client need it this week, or did they merely ask whether it was possible? Who can approve the work? What moves if the team says yes?

Small advisory firms lose margin and capacity in that gap. The problem is not that clients ask for help. Good clients should ask for help. The problem is treating the request itself as approval to begin.

Capture the request without pretending it is ready

Do not force every request through a giant form before you acknowledge it. That will teach clients and advisors to work around the process. Capture enough information to make the next decision.

Start with the client, requester, date, requested outcome, stated timing, source conversation, and the advisor who accepted the intake. Attach the email, meeting note, document, or recording that preserves the original context.

Notice what is missing from that list: a delivery owner and a promised completion date. Those belong after classification. The person who hears the request owns getting it into the process. That does not mean they have accepted the work.

Atlassian's current request-type documentation separates the form a customer completes from the work item view an agent uses to resolve the request. That is a useful operating distinction even if you never use Jira. The client can describe the need in familiar language while your team adds the internal fields required to evaluate and deliver it.

Clarify the outcome before estimating the work

"Research SD-WAN options" sounds like a task. It is not clear enough to estimate, prioritize, or complete.

Ask what decision the client needs to make, why it matters now, who will use the answer, and what a useful result looks like. Confirm any hard date and the event behind it. A board meeting, contract expiration, location opening, security finding, or budget deadline has more meaning than "as soon as possible."

Then identify what the firm would need from the client, supplier, or another party. A two-hour analysis can become a three-week chase when inventory, invoices, technical details, or stakeholder access are missing.

If you cannot describe the result and the decision it supports, move the request to needs clarification. Do not create five tasks that make an unclear request look organized.

Route every request into one of five treatments

The intake decision should change what happens next. Use a small number of treatments that your team can apply consistently.

• Answer or record: The request can be resolved with existing information and creates no new delivery commitment.
• Routine task: The work fits the current service, has a clear output, and can be assigned within the firm's normal capacity.
• Clarify: The outcome, urgency, information, authority, or commercial treatment is not clear enough to accept.
• Scope or project decision: The work changes an active commitment or deserves a separate deliverable, plan, fee, owner, and acceptance point.
• Decline or defer: The request sits outside the firm's model, authority, capability, or available capacity, or another party should own it.

A request can move between treatments as facts change. The important part is that it does not drift from email to delivery without a visible decision.

Make the tradeoff visible before saying yes

Client importance does not create infinite capacity. Before accepting meaningful work, check the estimated effort, required skill, deadline, dependencies, and current commitments. Name what will move if the request jumps the line.

Asana's March 2026 explanation of its own project intake process makes the resource constraint explicit. Its teams use structured intake to assess business impact, scope, staffing, budget, and the tradeoffs required to fit ad hoc work around existing priorities. You do not need a program management office to use that logic.

A small firm can ask four direct questions: Does this protect revenue, reduce a client risk, support a current decision, or fulfill a service commitment? What is the effort? What must happen first? What work loses time if this starts now?

Do not let the requester assign priority by writing "urgent." Your firm owns the capacity decision. The client owns the business context that helps you make it.

Separate intake authority from delivery ownership

The account owner should not become the default worker for every request. Their job is to protect the relationship and make sure the request reaches a decision. A project owner, analyst, operations person, or supplier may own the resulting work.

Define who can approve each treatment. An advisor may be allowed to create routine tasks inside agreed service boundaries. A practice leader may approve paid analysis or a temporary service exception. A client sponsor may need to approve a scope change. Legal, finance, or the firm owner may need to review work that creates unusual risk or commercial exposure.

This is where the intake process connects to your client exception rules and scope change process. Intake identifies the route. Those processes make the actual approval.

Respond with a decision, not a vague acknowledgment

"We are looking into it" feels responsive for a day. After that, it becomes an unmanaged promise.

Give the client a clear intake response. Confirm what you understood, the treatment, the next owner, and the next date. If you need more information, ask for it specifically. If the request needs a project or commercial decision, say when the client will receive that proposal. If you are deferring or declining it, explain the operating reason without hiding behind internal process language.

The next date is not always a completion date. It may be the date for clarification, an estimate, an approval decision, or a supplier response. Promise the next decision you can control.

Keep intake out of the active task backlog

A request awaiting classification is not the same as approved work. If both appear in one undifferentiated task list, the team will either start unapproved work or ignore real commitments.

Track intake states separately: new, needs clarification, under review, approved, deferred, declined, and converted. Once approved, create the task or project with its owner, due date, dependencies, scope, and completion evidence. Keep the original request linked to the resulting work.

Atlassian's current queue guidance describes requests becoming work items that can be filtered by priority and pending service levels for triage. The software details are specific to Jira, but the broader point is practical: capture, triage, assignment, and resolution are different stages. A queue full of captured requests is not proof that anybody accepted the work.

Review open intake during your weekly operating review when it has missed a response date, needs an authority decision, conflicts with capacity, or exposes a client commitment. Do not turn the meeting into a reading of every request.

Start with the last ten client requests

Pull the last ten requests that arrived through meetings, email, chat, or supplier conversations. For each one, identify the requested outcome, current treatment, decision owner, next date, commercial boundary, and resulting task or project.

If your team cannot tell whether the work was accepted, stop and make that decision now. Do not backfill a clean story that never happened.

Advisor OS CRM connects clients, contacts, activity history, tasks, projects, opportunities, suppliers, owners, and reporting. Use that connected record to preserve the request, its intake decision, and the work that follows without turning every client question into an automatic commitment.

Use the free Advisor OS agency scorecard if client requests still move from conversation to delivery through inboxes and memory.