Client message
“Can we also…?”
Treat a new request as information before treating it as a commitment.
The request is rarely the problem. The uncomfortable part is turning a casual message into a clear commercial choice without sounding defensive. That is a workflow problem, not a personality flaw.
Client message
“Can we also…?”
Treat a new request as information before treating it as a commitment.
Your reply
clarify + price
Confirm the result, then make the time, cost, and timing visible.
Next step
written approval
Start only after the client has chosen the option.
A fast yes feels generous, but it quietly rewrites the project. Pause long enough to compare the request with the agreed deliverables, revision allowance, deadline, and budget.
Name the request, state the consequence, and invite a choice. Avoid arguing about whether the work is ‘small’; clients can decide better when the trade-off is concrete.
A vague email thread is weak evidence and creates a second round of admin. Put the new work, price, timing, and approval in one place. The client should not need a project-management account just to say yes.
Acknowledge the idea first, then name the commercial decision: ‘I can add that. It is outside the current scope, so I will send the cost and timing for approval before I begin.’
No. You can make a deliberate goodwill exception. The important habit is to classify the request first, rather than letting repeated exceptions silently become the contract.
Discuss the outcome and impact, not the label. A task can be quick to describe yet affect testing, deadlines, or responsibility.
EasyScope