One Quote, Two Pricing Models: Building CAPEX and OPEX Quoting Into Zoho CRM
Most sales teams can quote a product one way: the customer buys it, and here is the price. But more and more B2B buyers do not want to buy outright. They want to spread the cost over a contract term and pay monthly. Suddenly, your sales team needs to quote the same product two completely different ways, and the spreadsheet that used to work starts to crack.
This is the story of how I solved exactly that problem for a media technology reseller, and what it taught me about building pricing logic that reps can actually trust.
The problem: two ways to sell the same thing
The client sells media asset management systems, connectors, and professional services to broadcasters and production companies. Their customers buy in two very different ways.
Some pay CAPEX: a one-time capital purchase. A licence costs €3,500; you pay €3,500, done.
Others prefer OPEX: the same licence spread across an operating expense budget over a contract term. That €3,500 licence on a 48-month agreement becomes roughly €73 per month.
Here is the catch. Not everything on a quote should be spread over the term. A one-off professional services engagement or a piece of hardware might still be billed as a single charge, even on an OPEX deal. So the system could not simply divide every line by the term. It had to know, product by product, what was eligible for monthly pricing and what was not.
Before this project, the team handled all of that in a spreadsheet. It was not crude, either. There were formulas and macros doing the heavy lifting behind the scenes. The problem was fragility: the whole thing was one wrong keystroke away from trouble. Overtype a formula, paste into the wrong cell, or break a reference, and the sheet would keep calculating and produce a confident, wrong number. That is the dangerous kind of error, the sort that does not announce itself until a mispriced deal is already out the door.
The goal: let the rep choose, and let the system do the maths
The brief was simple to say and harder to build. A rep should be able to:
Mark a deal as CAPEX or OPEX and choose the contract term.
Add products to the quote as normal.
Have every eligible line automatically reprice to the correct monthly figure, while ineligible lines stay at full price.
See clean, whole-number amounts that finance would accept, not awkward long decimals.
Get accurate margins that reflect whichever pricing model was in play.
Crucially, none of this could require the rep to think about the calculation. The whole point of a good quoting system is that the salesperson focuses on the customer, not the arithmetic.
The design decisions that mattered
A single "Include in OPEX" flag on each product
Rather than maintaining separate product records or price lists, we added one field to each product: an Include in OPEX flag. If it says yes, that product reprices monthly on OPEX deals. If it says no, it always shows full price. This keeps the rule where it belongs, on the product itself, and means the sales team never has to remember which items behave which way.
Preserving the original price so it never drifts
One of the biggest risks in any repricing logic is compounding. If the system divides a price by the term every time a quote is saved, the number keeps shrinking on each save until it is nonsense. We solved this by always anchoring the calculation to the product's true catalogue price, so the monthly figure is recomputed cleanly every time and never divides a already-divided number. Switch a deal from OPEX back to CAPEX, and the full price returns exactly as it should.
Whole numbers, because finance asked for whole numbers
An early version produced monthly figures like €73.11111, which Zoho rejected and which, frankly, looked wrong on a customer-facing quote. The client was clear: they did not want a "funny-looking number." So every monetary value the engine writes is rounded to a clean whole figure, matching the rest of the business's numbering conventions.
Margins that understand the pricing model
A quote is only useful to the business if the margin is right. So the margin engine was made OPEX-aware too. When a line is priced monthly, its cost is calculated on the same monthly basis, so licence cost, total cost, and margin percentages all stay consistent. A 50% margin reads as 50% whether the deal is CAPEX or OPEX, which is exactly what a sales manager needs to see at a glance.
What building it actually taught me
This is the part worth sharing honestly, because it is where the real lessons live.
Platforms have opinions, and you have to work with them. Zoho automatically syncs certain quote line fields from the product record. That is helpful most of the time, but it fought hard against writing a custom monthly price back onto those same fields. A lot of the engineering work was not about the pricing formula at all. It was about finding the right mechanism, in the right place, that the platform would actually respect.
The right answer was to reprice in the interface, as the rep works. Instead of forcing the calculation through the back end where the platform kept overriding it, the repricing runs in the quote screen itself, the moment a rep adds or edits a product. The rep sees the monthly figure appear immediately, and the server-side margin logic then confirms everything on save. Two pieces, one shared rule, working together.
Real systems have edge cases, and you find them by testing on real data. One that caught us out: when a rep uses Zoho's bulk "Add Products" picker to drop several items in at once, it bypasses the events that fire when you add products one at a time. That is not in any documentation. You find it by building, testing, and watching what actually happens, then adding a catch-all so no line slips through unpriced.
Guardrails matter more than clever code. The most important features are not the ones that do something impressive. They are the ones that stop something bad: preserving the original price so it cannot drift, only writing when a value genuinely changes, and rounding so nothing gets rejected. Boring, defensive engineering is what makes a quoting system trustworthy.
The outcome
The team can now build a quote once, flip a single field to switch between one-time and subscription pricing, and let the system handle the rest. The right products reprice, the wrong ones do not, the numbers are clean, and the margins are accurate. The spreadsheet gymnastics are gone, and with them the risk of quietly mispricing a deal.
More importantly, the logic now lives in one place as the single source of truth, which means the same rules can be reused as the business grows, including into a partner portal where resellers build their own quotes.
If quoting is your bottleneck
If your team is wrestling with complex pricing, multiple sales models, or a quoting spreadsheet that has quietly become business-critical and terrifyingly fragile, this is exactly the kind of problem worth solving properly inside your CRM.
I help service businesses replace manual, error-prone processes with Zoho systems that do the thinking for them. If your quoting process is slowing you down, let's have a short callto talk through what is not working and whether Zoho is the right fit.