Pricing and quoting engines
Price books, contract terms, discounts and quote generation held as data rather than as special cases in code — so pricing becomes a business decision again instead of a release.
What a pricing engine has to support
Plans, tiers and price books
Multiple price books by market, segment and currency, with effective dates so a future price change can be entered before it applies.
Contract and negotiated rates
Customer-specific rates that override the list price for the term of the agreement, with clear precedence when several rules could apply.
Discount and approval rules
Discount limits by role and margin thresholds that trigger approval, so the guardrails are in the system rather than in a policy document.
Quote generation, online or offline
Quotes produced in the portal or by sales, with expiry, versioning and one-click conversion into an order or subscription.
Proration and mid-term changes
Upgrades, downgrades and mid-period changes calculated consistently, because this is where billing disputes actually originate.
Pricing changes without a release
New plans, tiers and promotions configured by the business, with a test mode that shows the effect before it goes live.
Don’t see your challenge here? Talk to us about your project
When every new plan is another special case in code
Pricing logic written as conditionals accumulates. After a few years nobody is willing to change it the week before month end, and the commercial team starts designing offers around what the system can do rather than what the market wants.
Modelling price as data — rules, effective dates, precedence, overrides — moves the decision back to the business. The engineering effort goes into precedence and proration, which are the parts that actually have to be right.
- Effective dating
- Future prices entered before they take effect.
- Clear precedence
- Deterministic order when several rules match.
- Proration rules
- Mid-term changes calculated one agreed way.
- Margin guardrails
- Discount limits and approvals enforced by the system.
- Quote versioning
- Every revision retained and comparable.
- Safe to change
- Test mode shows the effect before it is live.
A budgeting system where the rules had to be the business's, not the code's
Loral's budgeting system is the same shape of problem seen from the planning side: figures and rules that finance needs to change themselves, held as data with history, rather than assumptions buried in a spreadsheet or in code that only one person is willing to edit.
Common questions
Can this sit on top of our existing billing system?
Often yes — pricing resolution can run as a service that the billing system calls, which avoids a replatform. Whether that works depends on how much of the pricing logic is currently embedded in the billing product itself.
How do you avoid breaking existing customer prices?
Existing agreements are modelled as overrides with their own effective dates, and every pricing change is run against live contracts in test mode first, showing exactly which customers would see a different figure.
Who ends up maintaining the rules?
The commercial team, which is the point. Our part is making the model expressive enough that they do not need us for a new plan, and constrained enough that they cannot accidentally price below cost.
Let's talk about your billing platform
Tell us what your commercial model looks like today and where billing is holding it back. We will come back with an honest read on the pricing model, the reconciliation work involved, and what a realistic first phase looks like.
