Most teams bolting AI onto Salesforce or Vlocity CPQ start the same way: pick one large
language model, wire it into the quote flow, and call it done. It works in the demo. It gets
expensive and slow once real quote volume hits it.
Quote-to-cash is already a chain of small steps. A single quote can pass through product configuration, pricing and discount logic, approval routing, contract clause checks, and document generation before it reaches a customer. If you’re adding AI to any of those steps, agentic assistance for configuration exceptions, clause extraction from a redlined contract, discount justification text, you’re not adding one model call. You’re adding one per step, sometimes several per step if the agent loops. Multiply that by quote volume and the model choice stops being a technical footnote and becomes a real line item.
I ran into this directly building AI-assisted contract and clause extraction work at enterprise scale, and the same design question showed up again inside CPQ: does this specific step need a large general-purpose model, or does it need something smaller and cheaper that’s accurate enough for the job.
Sort CPQ AI tasks by what they require
Before picking a model, sort the AI-assisted steps in your quote flow into two buckets. Classification, extraction, and routing tasks. These have a narrow, well-defined answer
space. Examples from a typical CPQ implementation:
- Pulling a discount reason code or approval tier from a sales rep’s free-text note
- Matching a product attribute from an unstructured request to a catalog entry
- Flagging a contract clause as standard, non-standard, or missing
- Detecting a likely duplicate quote before it hits approval
A smaller, task-specific model handles these reliably. The answer space is narrow enough that you don’t need frontier-model reasoning to get it right, and these are usually the highest-volume steps in the flow, which is exactly where model cost and latency compound the fastest.
Multi-step reasoning tasks. These need the model to hold several constraints at once
and produce a judgment call, not a lookup. Examples:
- Resolving a bundle configuration conflict across multiple interdependent product rules
- Drafting quote justification language that reconciles pricing exceptions, customer history, and deal-desk notes
- Walking a rep through a non-standard approval path with several possible branches
These are lower volume and higher stakes per instance. That’s where paying for a larger model’s reasoning is worth it.
Where this fits in an OmniStudio build
If you’re building this on Vlocity/OmniStudio, the natural place to make the call is in the
Integration Procedure that orchestrates the AI step. Branch on task type before the model call, not after: route classification and extraction calls to a smaller model endpoint and reserve the larger model for the branches that require multi-constraint reasoning. A DataRaptor feeding a classification task doesn’t need the same context payload as one feeding a reasoning task either. Trim the context to what the task needs, since a bigger payload into a bigger model is where cost stacks up unnoticed.
This is the same discipline Salesforce architects already apply when deciding Flow versus Apex, or DataRaptor versus Integration Procedure: match the tool to the complexity of the job instead of defaulting to the heaviest option because it’s available. Model selection for agentic CPQ features is that same decision, applied one level up.
The governance conversation to have before you build
Before the first AI-assisted step goes into a CPQ build, get agreement with your
architecture team on three questions:
- Which quote-flow steps are classification/extraction, and which are multi-step
reasoning? - What’s the acceptable latency and cost ceiling per quote, given expected volume?
- Who owns the decision to move a task from one model tier to another as volume or accuracy requirements change?
Skip this and the default becomes “use the biggest model for everything,” which is the version that looks fine in a proof of concept and turns into an unplanned cost and latency problem once it’s running against production quote volume.
The takeaway
Treat model selection in CPQ the way you’d treat any other architecture decision on the
platform: task by task, not platform wide. Route the narrow, high-volume steps to smaller models. Reserve the larger models for the steps that genuinely need multi-constraint reasoning. Your quote-to-cash flow will be faster and cheaper for it, and you won’t have redesigned the whole pipeline around a single model choice.
