Guide
How to Manage Client Requests in an Agency
“Can you also add a version in French?” arrives by email on a Tuesday, gets a thumbs-up reply, and then nobody adds it to the project plan. Two weeks later the client asks why it is not done. The request was never the problem—the lack of a place for it to live was.
Requests are not intake, onboarding or feedback
These four get blurred together, but they happen at different moments and need different handling. Intake collects what you need before a project starts. Onboarding is the sequence from signed contract to a running project. Feedback is a reaction to specific delivered work. A request, as covered here, is a new ask that arrives once delivery is already underway—it may or may not be in scope, and someone has to decide.
Why an informal system fails specifically here
A request answered informally in an email thread has three problems at once: there is no record the team can see, no clear owner, and no explicit decision about whether it fits the agreed scope. Any one of these alone causes friction; together, they are how small, reasonable-sounding asks quietly erode margin over a project’s life.
A workable request workflow
One entry point
A form, a portal, or at minimum a single agreed channel, so a request does not depend on which app the client happened to open that day. See client request management software for tools built around this.
Immediate acknowledgment
A quick confirmation that the request was received, separate from a commitment to do it, keeps the client from chasing a response.
A triage decision
Someone checks the request against the agreed scope before work starts, not after. If it fits, it becomes a task. If it does not, it becomes a conversation about a change order.
A visible owner and status
Once accepted, the request needs an owner and a status the client can eventually check, rather than living only in the memory of whoever first replied.
Not every request needs the same weight
A genuinely small, in-scope tweak does not need a formal change order to move forward—treating every request as a negotiation slows the relationship down for no reason. What matters is that even small requests are recorded somewhere, so the pattern is visible if many “small” requests start adding up.
Common mistakes
Saying yes before checking scope
A quick, friendly “sure, no problem” reply is hard to walk back later if the request turns out to be more work than it looked.
Letting requests bypass the entry point
If a client learns that messaging a specific person directly gets faster action than the official channel, the channel stops being used.
Never reviewing the pattern of requests
A client who sends frequent small requests may need a different retainer structure. That is only visible if the requests are actually logged somewhere.
Frequently asked questions
Is a shared inbox enough to manage requests?
It can hold the request, but it does not by itself turn a request into a task with an owner and status. See shared inbox software for the messaging layer specifically.
Who should triage incoming requests?
Usually whoever owns the client relationship and understands the agreed scope well enough to judge fit—often a project or account manager.
How does this relate to scope creep?
Unmanaged requests are one of the main sources of scope creep. See how to prevent scope creep for the wider picture.
Conclusion
Client requests need one entry point, a triage step against scope, and a visible owner—not a policy against saying yes. Most of the friction disappears once requests stop depending on memory.
Find My Software Stack