Support Is Arithmetic. You Shouldn't Be the Calculator.
Choosing a support level is a decision. Pricing it out is arithmetic.
The customer decides. Standard, Advanced, Premium, or an enterprise agreement if they qualify for one. That’s a real conversation with a real answer, and it takes a minute.
Then someone has to turn that minute into a quote.
How many support items do you have to add?
Quote twenty products that carry support and the quote holds forty items.
Twenty are the products themselves: the capex hardware, the opex subscriptions, the things the deal is actually made of. One-time payments sit in there too, and they carry no support at all. The other twenty are support items, one attached to each product, and they exist only to carry out a single choice made once.
The products get the scrutiny. They’re the big numbers, they’re what the customer asks about, they’re what the discount conversation is about. The support items underneath get a glance. They were computed, and computed things feel settled.
They stay settled right up until somebody touches the quote.
What happens if the customer changes one thing?
They ask for the bigger chassis. The model swaps, the price moves, the term goes from one year to three, and a discount lands on top.
The support item underneath does not move. It still reads fifteen percent of a number that no longer exists, carrying a part number built from a product that isn’t on the quote any more. Nothing flagged it, because nothing was watching it.
This isn’t a pricing problem. Every one of those numbers was right when it was worked out. It’s a derivation problem. A number worked out by hand goes stale the moment the thing it was worked out from moves, because nothing connects the two.
So you go looking for a rule that takes the guesswork out.
Why a global support rate doesn’t save you
The first thing everyone reaches for is a company-wide rate. Fifteen percent, applied to everything, done.
It survives about as long as it takes to quote a mixed deal. Capex hardware carries support on an annual cycle. Cloud and managed services follow whatever subscription they attach to. One-time payments carry none at all. A single quote ends up holding support on two different billing clocks at rates that should differ by category.
One flat rate is wrong for most of the catalog. So people stop trusting it, and quietly go back to working each one out by hand.
Which leaves the other obvious fix.
Why storing each support item in the pricelist doesn’t save you either
Make support a product. Every tier gets its own SKU, its own fixed price, and its own row in your pricelist, maintained like anything else you sell.
On a real catalog that more than doubles the row count. Support is a real thing you sell, but those rows aren’t describing it. They’re storing a number you could have computed. Then they age: reprice a chassis and the support SKUs beneath it are wrong until somebody remembers to update those too.
Worse, the rows have to exist before you can quote. Add a product to the catalog and nobody can sell support on it until somebody creates its three support SKUs and prices each one by hand.
Deriving support means those rows never exist at all. That’s a big enough subject on its own, and it’s the next post.
Two obvious fixes, and both are worse than the problem.
Why not use a rules engine?
That’s the third answer, and it’s what most systems land on. The behavior goes somewhere other than the catalog: conditions and actions in an admin screen, an expression language, a script. The catalog becomes input, and something else decides what happens to it.
It works. It’s also a lot of machinery for what is, in the end, three facts.
Does this product carry support? That belongs on the product, as a column on its own row in your pricelist, beside its price and its category. It’s an attribute of the thing, not a rule about it.
How does this kind of product attach? Fixed. Hardware one way, cloud another, managed services another, one-time payments not at all. That mapping is a property of the product type rather than of the deal, so it doesn’t need configuring per customer.
What does each tier cost, and how is the SKU built? A short table. Your tiers, your percentages, your affixes. A table of values, not a set of instructions. Nothing in it needs interpreting.
No conditions. No evaluation order. No expressions to debug at quarter end. An engine earns its keep when behavior genuinely varies case by case. This doesn’t. What varies is the product, and the product is already sitting right there.
How QuoteLogic solves this issue
QuoteLogic prices out support for every product that carries it. The part number is built from the root product’s part number, the price is a percentage of that product’s list price, and the billing cycle follows the terms for that category.
Then it keeps up. Add the bigger chassis and its support appears with it. Remove the chassis and the support goes with it, because a support item for a product that isn’t on the quote is a mistake waiting to be printed. Swap the model, change the quantity, change your mind four more times before it goes out, and every support item follows without being asked.
Support keeps its own discount, because discounting support is its own conversation. Set it once for a category and every support item in the quote moves together.
Twenty support items stay correct for the same reason one does. Nobody is maintaining them, and there is no engine to configure. A column on the product, and a short table of your tiers.
The takeaway
The customer decides what support they want. That should be the last human decision in the chain.
Everything after it is arithmetic: which products carry it, what each one costs, what the part number is, which clock it bills on, and what all of that becomes when the quote changes again tomorrow. That work is real and it has to happen. It just shouldn’t be happening in your head.
You should be selling. The pricelist should be the calculator.