How to Build a Pricing Assistant for Sales and Finance

Pricing questions bottleneck deals. A seller needs to know what a configuration costs in a region under a term commitment with a partner discount, and the answer exists across a rate card, a policy document, and a spreadsheet that one person maintains. An assistant can answer in seconds — provided it computes nothing itself. This guide covers building one, drawing on FISTA Solutions' AI agents work in revenue operations. It complements how to build a proposal generation system and ai cpq automation. This article is general guidance, not legal advice.

Why can the model never compute the price?

Because models produce plausible arithmetic. A price is not a stylistic choice; it is either right or wrong, and a wrong one quoted to a customer is a commercial problem whether or not it is legally binding. Discount stacking, proration, regional adjustment, and tiered volume logic all compound, and a model applying them in prose will produce something that reads correctly and is off by a margin point.

The architecture that works separates roles: the model interprets the question and identifies which rules apply, deterministic code applies them, and the model explains the result. See deterministic ai outcomes.

Component	Owner	Why
Question interpretation	Model	Natural language varies
Rule selection	Model, validated	Retrieval problem
Rate application	Code	Must be exact
Discount stacking	Code	Compounding logic
Approval threshold check	Code	Authority, not opinion
Explanation	Model	Clarity matters

What does the assistant genuinely add?

Finding the right rules. Pricing complexity in most organisations is not in any single rate; it is in knowing which of eleven rate cards applies, whether the regional multiplier stacks with the volume tier, whether the partner discount is off list or off net, and what the term commitment does to all of it.

Sellers ask that question of the deal desk constantly. An assistant that answers it correctly, with the reasoning shown, removes a queue and a delay. The explanation matters as much as the number, because an unexplained price generates a follow-up question to the person the assistant was supposed to relieve.

How is approval enforced?

In workflow, not in advice. When a requested discount exceeds the seller's authority, the assistant states the approval required, assembles the deal context, and routes it. What it must never do is display the requested price as though it were available pending approval, because a seller who has seen a number will use it in conversation and the approval becomes a formality nobody feels able to refuse.

Approval routing should carry the reason for the request and the margin effect, so the approver decides on evidence rather than on relationship.

Why does margin visibility change behaviour?

Because abstraction protects discounting. A seller asking for another five points is weighing a deal they can see against a margin effect they cannot. Showing the effect at the moment of the request — in currency, on this deal, against target — is a more effective control than policy documents.

The presentation matters. Margin shown as a percentage invites argument; margin shown as the amount of gross profit given away invites reconsideration.

How should quotes be traceable?

Every quoted number carries the rules that produced it: which rate card, which version, which discounts, which approvals. That record serves three purposes — the seller can explain it to the customer, the deal desk can audit it, and when a rate card changes, every open quote built on the old version is identifiable.

Without version-stamped quotes, a mid-cycle price change turns into a manual hunt through open opportunities.

What do exception patterns reveal?

That the policy is wrong. When a particular discount level is approved as an exception in most deals of a segment, it is not an exception; it is the market price, and the organisation is spending approval cycles ratifying it. Exception analytics — by segment, product, region, and approver — is one of the highest-value outputs, and it exists only because the assistant structured the requests.

What does the build sequence look like?

Two to three weeks consolidating the pricing rules into a machine-readable, versioned form, which is the real work and usually reveals contradictions nobody had noticed. Two weeks on the deterministic calculation engine with tests against known deals. Two weeks on the model layer for question interpretation and explanation. One week on approval routing and margin display. Exception analytics after a quarter of data.

The consolidation step is where most of the value is created, because ambiguous pricing rules are ambiguous for humans too.

What goes wrong?

Letting the model compute. Skipping rule consolidation and retrieving from documents directly, which produces confident answers from a superseded rate card. Showing unapproved prices. Hiding margin. Unversioned quotes. And treating exceptions as a queue to be processed rather than a signal to be read.

How does it connect to CPQ?

As a layer above it where CPQ exists, and as a bridge where it does not. Configure-price-quote systems hold the deterministic logic well but are hard to query conversationally, which is exactly the gap sellers feel. The assistant should call the CPQ engine for calculation rather than reimplementing it, and confine itself to interpretation, explanation, and routing.

Where pricing lives in spreadsheets instead, the consolidation step effectively builds the missing engine. That is more work, but it produces an asset the organisation needed anyway, and it removes the single-maintainer risk that spreadsheet pricing always carries.

What about customer-facing use?

Treat it as a separate decision with a higher bar. An internal assistant that is occasionally unhelpful costs a seller a minute. A customer-facing pricing answer is a quote, with everything that implies. If the organisation wants self-service pricing, it should be driven by the same deterministic engine with a much narrower conversational surface and explicit limits on what can be quoted without a human.

How is it evaluated?

On answer correctness against known deals, time from question to answer, deal desk queue volume, and the proportion of quotes requiring correction after issue. That last metric is the one that matters commercially, because a corrected quote costs credibility with the customer as well as time.

How FISTA Solutions helps

FISTA Solutions builds pricing assistants with consolidated versioned rule sets, deterministic calculation, model-driven interpretation and explanation, enforced approval routing, margin visibility at the point of request, and exception analytics, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To unblock pricing questions without risking a wrong number, message FISTA on WhatsApp, or read how to build a proposal generation system.