How to Say No to a Client and Keep the Request Moving

Check the Agreement Before Refusing the Work

Read the actual agreement before creating the exclusion list. A request isn't extra merely because it is unfamiliar to the person answering. If the contract is unclear, send the question to someone who can interpret it before telling the client they're asking for something they didn't buy.

Separate a request for help from permission to make a change. You may need to understand the issue before you can tell which work is included. Give the technician enough room to gather the facts without treating that initial conversation as approval to start a new project.

If the report could involve a security incident or a serious service failure, follow the agreed triage and escalation process. Keep the service question moving while the appropriate person checks any further work. An argument about a later project quote shouldn't replace the response you already owe.

Use plain words in the desk guide. Service boundary alignment won't tell a technician whether to continue. State which work they may perform and who answers when the request doesn't fit the written offer.

Turn Exclusions Into Useful Replies

Choose request types your desk actually receives and compare them with your agreements. The examples below are possible exclusions to check, not a standard list that overrides what you've sold. Replace each handoff with the person your team can reach.

Erick Simpson distinguishes unrelated requests during a project from changes to that project's scope. He recommends routing the former through ordinary support and documenting the latter as a change even if you choose not to charge. That's his project-control advice, and it gives the desk a useful routing distinction.

'While you're here' isn't a purchase order. Keep the request, but don't let its timing authorize it. The person approving project scope still needs to decide what happens next.

Make the Handoff Finish Somewhere

Assign the request to the person who can decide and keep its current status visible. A technician saying someone will call isn't a completed handoff. The receiving person needs to acknowledge the request and own the next contact.

Have the account team explain the available option and any price before the extra work starts. If you can't offer the service, say so and identify whether a suitable referral is possible. Don't promise a quote simply to get the request off the phone.

Tim Golden cautions MSPs against accepting specialized compliance work without the people or time to deliver it. He suggests weighing the change it would require against appropriate expertise and the customer economics. That's a vendor's scope warning, rather than proof that every request can be solved by finding a partner.

Give the client an update they can rely on. Record the agreed next contact and the person responsible. Keep the technician's original work scheduled unless someone with authority deliberately changes its priority.

Fix an Ambiguous Offer With the Client

If the same request repeatedly creates disagreement, review what your offer says. Your team may have been selling a broader service than the written summary suggests. Find that mismatch before treating each new request as another difficult conversation.

Eric Anthony describes repeated Excel training requests leading to a client review and a revised agreement distinguishing training from support. He offered paid training or another provider as options and says the discussion ended amicably. That is his account of clarifying the offer, not a guarantee that every client will agree to a new exclusion.

Don't tell the desk to enforce a proposed exclusion before the client has agreed to the applicable change. Have the account lead work through the current contract and approval process. Then update the desk guide to reflect the arrangement you can actually support.

Let management approve any goodwill exception explicitly. Record the actual effort even when you waive the charge. The decision shouldn't quietly add the same work to every future month of the agreement.

Count the Requests and the Work Behind Them

Record requests referred for scope review in the PSA with the eventual decision. Count them by request type and client, using the same definitions each period. That shows which parts of the offer need attention without turning every enquiry into a refusal score.

Read the work record alongside the count. A reduction might mean clearer wording, fewer requests, or missing entries. Ask the receiving team what happened before claiming that the new script improved the service.

Have finance inspect the actual effort spent on approved extra work and waived charges. Keep recorded cost separate from a fee you might have quoted. An unbilled task doesn't prove the client would have bought it at your project price.

Use the results to improve the offer and the routing. The aim isn't to maximize the number of times a technician says no. It is to make sure agreed work gets done and new work reaches someone who can make a proper decision.

Give the Desk a Working Checklist

My test for the guide is this: what does this do to the board on Monday morning? A referred request needs a next owner and an honest status. The desk shouldn't have to choose between doing unapproved work and leaving the client with no answer.

• The service lead checks each example against the current client agreement.
• The technician records the requested work and uses the approved handoff wording.
• The account lead accepts the commercial question and confirms the next client contact.
• The project manager handles a proposed change to an active project.
• The process owner updates the desk guide after an agreed scope change.

Take a recent disputed request and run it through the guide. Confirm who would receive it and what the client would hear. Repair the handoff before asking every technician to use the sentence.