When a buyer's custom request could derail the deal

A buyer asks for a new feature, bespoke report, special workflow or expanded service. Saying yes may appear responsive. Saying no may appear inflexible. Neither response is useful until the seller understands why the request matters.

Customisation can reflect a genuine requirement. It can also be a preference, a proxy for implementation anxiety or an attempt to keep evaluating without deciding.

Trace the request to its source

Ask:

• Who requires this?
• What problem does it solve?
• Which decision criterion does it satisfy?
• What happens if the standard approach is used?
• Is it required before purchase or before deployment?
• Has the relevant stakeholder validated the requirement?

A request relayed through several people may become distorted. Where appropriate, speak with the person who owns the underlying workflow or risk.

Classify the requirement honestly

The request may be:

1. Essential: without it, the buyer cannot achieve the outcome or meet a real policy.
2. Risk-reducing: it makes adoption or approval safer but alternatives may exist.
3. Preferential: useful, but not necessary for a decision.
4. Misaligned: it pulls the offer away from what you can deliver successfully.

This classification should shape scope, price, timing and whether the opportunity remains a fit.

Explore the standard path first

Show how other customers achieve the intended outcome. A configuration, process change, partner solution or phased roadmap may meet the need without bespoke development.

Do not force a workaround merely to protect your product. If the standard path creates unacceptable operational cost for the buyer, say so.

Price and govern real custom work

When customisation is justified, define requirements, acceptance, ownership, maintenance, dependencies and commercial impact. Confirm who can approve the resulting change in scope and timeline.

Avoid promising work based on a salesperson's optimistic interpretation. Delivery and product owners need to validate feasibility before the commitment becomes part of the deal.

Customer responsiveness is not saying yes to every request. It is helping the buyer obtain the required outcome without hiding the cost and risk of how it will be delivered.