Find the problem under the request
Enterprise requests arrive as specifications because the customer has already designed a solution internally. That design encodes their constraints, their existing tooling, and often the preferences of one person in the room — none of which you have seen.
So the first work is to get behind it. Who experiences the problem, how often, what do they do today, and what does the workaround cost them? A request for "a custom approval workflow with four configurable stages" frequently turns out to be one team needing a second approver on transactions above a threshold. The first is a subsystem; the second is a field and a rule, and might ship in a week.
This is not a delaying tactic and should not be presented as one. It is the difference between building what was asked for and solving what is wrong, and it changes the cost estimate by an order of magnitude often enough to be worth the two days it takes.
Test whether it generalises
The question that decides most of these: is this account early to a need others will have, or genuinely idiosyncratic?
Evidence rather than intuition. Check whether other customers have raised anything adjacent in support tickets or churn interviews. Ask account managers whether it comes up in deals you lost. Look at whether the workflow is common in the industry or specific to this company's internal structure. If three other enterprise accounts have a version of the same problem, this stops being a custom request and becomes a roadmap item that happens to have a funded, motivated design partner — which is a very good position.
If it does not generalise, you are being asked to carry a single-tenant feature in a multi-tenant product, and that has to be priced honestly rather than hidden.
Price the whole thing
The build estimate is the smallest part of the cost and the only part usually discussed.
Ongoing maintenance. Every feature is tested, supported, documented and migrated forever. A feature used by one customer has the same claim on every future refactor as one used by all of them, and there is never a moment when removing it is easy.
Architectural constraint. Single-tenant behaviour in shared code means every subsequent change must consider a special case. This compounds, and it is the cost that engineers feel and product people underestimate.
Precedent. Say yes to this and your other enterprise accounts learn what leverage produces. The second and third custom request arrive with the first one cited. That is a structural change to how your roadmap gets set, and it is worth naming explicitly because it is invisible in any single decision.
Opportunity cost, made concrete. Not "we would have less capacity" but "this displaces the onboarding work that three deals in the pipeline are asking for". A named trade-off is arguable; a vague one always loses to a specific revenue number.
Generate options between yes and no
Presenting this as build-or-refuse is the weakest version of the answer. The middle ground is usually where it lands:
Configuration rather than a feature. Can the need be met by extending something that already exists — a rules engine, a webhook, an API surface they build against themselves? This is often the fastest path and it generalises by construction.
Services rather than product. Build it as an integration or a script owned by professional services, priced accordingly, and kept out of the core product. This gives the customer their outcome without a permanent tax on the roadmap.
A partial or staged commitment. Deliver the 20% that solves the sharp edge before renewal, with the rest conditional on evidence other customers want it.
Yes, with terms. If you are going to build it, the cost should be reflected somewhere — a longer contract, a higher price, a reference commitment, or their engineering time as a design partner. A customer unwilling to pay in any currency for something they described as essential is telling you something about how essential it is.
Test the churn claim before you price it
"They will leave without this" deserves polite scrutiny, because it is asserted far more often than it is true and it is the input doing all the work in the decision.
Useful questions: has the customer said that, or is it sales' inference? What else would they lose by switching, and how long would migration take? Are they using the product deeply — usage data is better evidence than sentiment? Is the champion asking for this the person who controls the renewal?
Sometimes the answer is that the risk is real, and then it is real. But a 15% revenue concentration is itself the finding worth escalating, because a business where one customer can set the roadmap has a strategy problem that this decision will not fix and should not be quietly absorbed into.
Decide, and write down why
Whichever way it goes, record the reasoning, the evidence, and what would change the answer. If you say no and they churn, you need to be able to show the decision was sound given what was known — a decision is not proved wrong by a bad outcome. And if two more customers ask for the same thing next quarter, the written record is what lets you notice that the answer has changed rather than defending the original position out of consistency.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).