Every founder selling to Indian enterprises eventually gets the same email: “We love the product. Just a few small changes for our environment.” Six months later, half your roadmap belongs to one customer and the contract value has not moved.
The problem is rarely the customer. It is a pricing model that treats customisation as free.
What is the short answer on pricing software for Indian enterprises?
Price the product as a standard platform fee, price anything custom as separately scoped and separately paid work, and give every change request a clear route: configuration, paid services, or the product roadmap. If a request has no price and no route, it becomes free engineering.
The rest of this post breaks down how to set that up so it survives a procurement negotiation.
Why do custom requests destroy margins in Indian enterprise deals?
Three forces combine. Large buyers often run procurement as a competitive process, so every vendor is asked to fit the buyer’s existing workflow. Business teams negotiate scope informally while procurement negotiates price formally. And founders, eager to land a marquee logo, say yes in meetings that nobody records.
The result is scope that grows without a matching invoice. Your effective margin falls quietly, and it shows up months later as engineers stuck on one account.
How should you structure pricing for an enterprise buyer?
Separate the platform fee from services
Use two lines on every commercial proposal: a recurring platform fee and a one-time or time-boxed implementation fee. The platform fee covers what every customer gets. The implementation fee covers integration, data migration, configuration and training.
Anchor on value metrics, not only seats
Seat pricing invites arguments about how many users “really” need access. A metric tied to usage, such as transactions, entities, locations or modules, grows with the value the customer gets and is harder to discount arbitrarily.
Build in a standard discount ladder
Decide in advance what you give for multi-year terms, higher volume or prepayment. Indian buyers will ask for a discount; a ladder lets you trade discount for something concrete instead of conceding it for free.
How do you stop scope creep before it starts?
Treat every request as one of four types and respond accordingly:
| Request type | Example | Your response |
|---|---|---|
| Configuration | Different approval levels, custom fields, role setup | Included in implementation, within a stated limit |
| Integration | Connect to the customer’s ERP or internal systems | Priced as a scoped services line, with acceptance criteria |
| Custom development | A workflow that only this customer needs | Paid change request, with the IP position agreed in writing |
| Roadmap-worthy | A capability several customers have asked for | Product backlog, with no promised date unless funded |
Put this table, or something like it, into your statement of work. When a request arrives, you are not saying no. You are saying which row it sits in.
What should a change request process look like?
- All requests come in writing to a named owner on both sides.
- Your team responds within a fixed window with the request type, effort estimate and price.
- Nothing starts until the customer approves the change in writing.
- Approved changes are tracked against the original scope and reviewed in the monthly governance call.
The monthly review matters. It gives the customer’s sponsor visibility into how much extra they are asking for, which often reduces the volume of requests by itself.
How do you protect margins while still looking flexible?
Founders worry that a rigid structure will cost them deals. In practice, enterprise buyers respect a vendor who can say precisely what is included. Vague flexibility looks like risk to a procurement team that has been burned before.
- Offer packages, not blank cheques: a Standard and an Enterprise tier, with a defined list of what changes between them.
- Cap included services: for example, a fixed number of configuration hours before billing starts.
- Decide the IP position early: if the customer pays for custom development, state who owns it and whether you can reuse it. Ambiguity here becomes a dispute later.
- Track margin per account: measure engineering hours against revenue for each enterprise customer every quarter.
When is it right to say yes to a custom request?
Say yes when the request is paid, scoped, and either strategically useful or likely to be needed by other customers. A paid custom feature for a flagship account can fund a roadmap item you would have built anyway. Say yes without payment only as a deliberate investment, with a named owner who has agreed the cost.
Frequently Asked Questions
Should Indian enterprise software be priced per user or per usage?
Both can work, but usage or value-based metrics tend to hold up better in negotiation because they scale with the benefit the customer receives. Per-user pricing is simpler but invites debate over who counts as a user and pushes buyers to cap seats.
How do I charge for customisation without losing the deal?
Present it as a separate, scoped line item with a clear outcome and acceptance criteria. Buyers are generally more comfortable paying for defined work than for an open-ended promise, and a priced option shows you take their requirement seriously.
What discount is reasonable for a large Indian enterprise?
There is no universal figure. Decide your floor price in advance and give discounts only in exchange for something concrete, such as a longer term, larger volume, faster payment or a reference. Avoid unconditional discounts, because they reset the baseline for renewals.
Conclusion
Healthy enterprise margins come from structure, not from saying no more often. Separate the platform from services, give every request a type and a price, and run changes through a written process. Your customers get clarity, and your engineers stay on the roadmap.
If you are building a B2B company for Indian enterprise buyers, join The Builders Club community to compare notes with other founders and CXOs who are working through the same problems.
