CPQ UX design: quoting software sales reps choose over spreadsheets

CPQ software design: where quoting gets hard

CPQ UX design shapes how configure, price, quote (CPQ) software builds a quote, and it gets hard when several people each own part of that quote. Published guides to CPQ UX tend to treat it as an interface problem for the sales rep. They recommend a clear, simple layout, onboarding, consistent visual design and integration with the CRM (UXmatters). That advice is sound as far as it goes. It says little about where quoting gets hard, which is when several people each own part of a quote.

Gartner describes CPQ suites as software supporting the configuration, pricing and quote generation that accompany solution and negotiated selling. They are typically built from rules or constraint engines, pricing engines and proposal generators, with approval workflows around them (Gartner glossary). Each of those parts produces a decision someone has to trust:

• this configuration is valid;
• this price is right;
• this discount is allowed, or who has to allow it;
• this version is the one the customer saw.

The design job is to show each of those decisions to the person who has to act on it, at the moment they act.

Rep-assembled or expert-assembled: which quote are you designing for?

Before any screen, agree what a typical quote in your product looks like. The split below is our own working judgement, and it changes almost every later decision.

A product can sit anywhere between the two. The expensive mistake is designing for one while your customers live in the other. You see it in a fast single-user form for quotes that really need three specialists, or in a heavy collaborative workflow for a seat-count renewal.

What the Auxentios CPQ research showed: the quote is the shared object

When Tcules designed the MVP for Auxentios, an industrial CPQ product, the research included eight qualitative interviews with people in six roles. The roles were sales representative, sales manager, product expert, pricing expert, solution expert and maintenance expert. The existing work moved between CRM records, internal communication, product knowledge, pricing, service contracts and customer revisions.

Each role carried different knowledge and authority into the same quotation. The sales representative needed progress and customer context. The pricing expert needed commercial rules. Product and solution experts needed configuration detail. Maintenance work could change the offer after the initial product decision. Designing for one generic "enterprise user" would have hidden the coordination the product actually had to do.

So the research became a responsibility map. It showed who contributes what to a quote, where information changes, and where a person needs a hand-off or a way out of a fixed sequence. The product was expected to need more than 200 screens, so the interface system came after that model. Use cases were mapped to screens, and repeated needs were extracted into components. A component library built before the role model would have standardised visual fragments while leaving the product logic unresolved.

The case study sets out five questions for any workflow that crosses roles with different authority. They apply to any quoting product where more than one role touches the quote:

1. What shared object are these roles changing?
2. What evidence can each role see and contribute?
3. Who decides, approves or returns the work?
4. Which states and exceptions must survive a hand-off?
5. Which interface rules can become reusable without erasing role-specific work?

That work was MVP design that Auxentios could take into development. The Auxentios CPQ case study shows how Tcules modelled a multi-role quote and what the MVP could express.

Configure price quote UX: rules that explain themselves

The configurator is where a CPQ earns or loses trust. The user research here studied web and sales configurators, which sit close to rep-facing B2B tools, so treat it as indirect evidence.

Leclercq, Abbasi, Dumas, Remiche and Heymans surveyed web configurator users in 2022. They found that the validity of the configured product, and how well it matched the user's needs, were the most desired perceived values. Missing usability, missing product visualisation and a missing progress or state indicator were the worst defects (Proceedings of the ACM on Human-Computer Interaction, 2022). For a rep, validity is the whole point: a quote the factory or the billing system later rejects is worse than a slow one.

Four design moves follow.

Say why an option is unavailable. "Unavailable" teaches reps nothing. "Not available with a 12-month term" tells them what to change. This is the plain-language error rule in Nielsen's heuristics: name the problem precisely and suggest a fix. Configuration research treats detecting and diagnosing conflicting constraints and requirements as a subject in its own right (Felfernig et al., 2014). The interface is where that diagnosis has to reach a person.

Let people change an earlier choice without starting over. Trentin, Perin and Forza call this flexible navigation (Trentin, Perin and Forza, 2012; journal version in Computers in Industry, 2013). A person can change a choice made at any earlier step. They revise only the later choices that the change made invalid, and they keep a saved configuration to return to. In a CPQ, a change of region or term should flag the specific lines it broke and leave the rest of the quote intact.

Show where the quote stands. Which sections are complete, which are waiting on someone, which are invalid. The same survey ranked a missing progress and state indicator among the worst defects.

Give experienced reps a direct path. Guided selling questionnaires can help new reps and slow down experienced ones. Nielsen's flexibility heuristic applies: shortcuts, hidden from novice users, that let experts move faster (NN/g). Offer the guided path and a straight route to the catalogue, and let both produce the same valid quote.

The people who maintain the rules are users too. In the Auxentios research the pricing expert needed commercial rules. In any CPQ product someone, in product, pricing or sales operations, has to keep the rules current. If they can't see which rule blocked a quote, reps will route around the rule and it stays broken.

CPQ UI design for prices and approvals reps see before submitting

A total with no build-up invites a spreadsheet check. Show how the price was reached: list price, rule-driven adjustments, the rep's discount, and which of those the rep controls.

Trentin, Perin and Forza's "benefit-cost communication" makes the same point for configurators (Trentin, Perin and Forza). Show what each option gives and what it costs, including non-monetary costs such as a longer delivery lead time. Their paper also cautions that this can add choice complexity, for example when each option is priced individually. Pair it with navigation that narrows the options first.

Approvals need the same treatment. If a discount above a threshold needs a manager, show the threshold while the rep is still editing, early enough to change the discount before submitting. When a rejected quote comes back, re-ask only what changed.

Salesforce's Advanced Approvals implements this as Smart Approvals: on resubmission, approvers aren't asked again for a condition whose tested value hasn't changed (Salesforce Trailhead). The principle holds whatever platform you build on. Every unnecessary re-approval teaches reps that the tool costs time.

Quote revisions: make the customer's version clear

The quote that closes is often a later version than the first. Oracle's Siebel CRM documentation describes the negotiation phase plainly. Users add or remove products and compare features and price. A revision creates a new record under the same quote number, and the original becomes read-only. The documentation also notes that editing a quote does not by itself create a version (Oracle documentation). That last detail is a design decision with consequences. If versions are opt-in, someone will overwrite the version the customer is holding.

In the Auxentios work, customer and internal communication continued while the quotation was revised. Design for that:

• Make "which version did the customer see?" answerable at a glance.
• Compare versions side by side and highlight what changed, and which change moved the price. Trentin, Perin and Forza describe this as easy comparison: showing which choices caused the price difference between two configurations (Trentin, Perin and Forza).
• Keep the specialists' contributions attached to the version they applied to, so a late maintenance change doesn't silently invalidate an earlier pricing decision.

CPQ usability: signs reps are working around the tool

The workarounds tell you more than login counts do. A quote that keeps leaving the product marks the part of the job the product has stopped supporting. It might go to a spreadsheet, a chat thread to the pricing team or an emailed PDF edited by hand.

Signals worth watching (from our own judgement):

• quotes built elsewhere and entered into the CPQ at the end;
• questions to product or pricing specialists asked in chat, away from the quote;
• quotes rejected at approval for reasons the rep could have seen while editing;
• resubmissions that re-trigger approvals nobody needed;
• disputes about which version the customer accepted.

The most reliable method is still the plainest: watch a few reps build real quotes, including one awkward deal. If the team disputes the cause of the trouble, a structured UX & Product Audit can separate interface problems from model and rule problems. It does so before anything is redesigned.

Re-platforming a CPQ: move the quote model before the screens

Move the quote model first.

Salesforce no longer sells new Salesforce CPQ licences to new customers. The product is in a maintenance phase with no announced end-of-life date, and Salesforce points new investment to Revenue Cloud Advanced (Salesforce). Existing customers can keep using it, and there is no forced migration.

Some teams do move, to Revenue Cloud, another CPQ or a product of their own. Our advice to them is to re-model the quote before any screen is carried across. Treat the move as the chance to do it. Porting screens carries the old workarounds across with them. Re-mapping roles, rules, approvals and revisions first is slower at the start and gives the new build something coherent to express.

Where the quoting tool sits inside an ageing product, that is Product Modernisation work as much as a CPQ project.

CPQ UX checklist: what good looks like, and the warning signs

Where Tcules designs quoting software UX

Tcules designs software with many roles and rules, and models roles, records and hand-offs before drawing screens. We apply that approach across B2B SaaS and workflow software. To see it applied to a quoting product, read the Auxentios CPQ case study. It covers six specialist roles, eight interviews and one quotation workflow, modelled before the interface system was built.

Quoting is also where AI is arriving next: suggested configurations, drafted proposals and recommended discounts. Each is one more decision someone has to trust, and the model that serves six human roles is the model an AI assistant has to fit into. We design that seat at the table too, deciding what the assistant may propose, who approves it and which version the customer finally sees.