Table of Contents
Guided selling leads a prospect, or your own sales team, to the right product variant through questions about their needs, instead of sending either of them through a catalogue. With variant-rich products that decides whether an enquiry turns into a quote or into a round of follow-up questions. This article separates guided selling from guided buying and from CPQ, walks through a concrete dialogue from mechanical engineering and names what the product data has to deliver.
Key points
- Guided selling is an interaction pattern, not a software category. It describes the route from needs to solution, not the system behind it.
- What separates it from guided buying is perspective: guided buying is the buyer’s view, guided selling the vendor’s. Ideally both draw on the same rule set.
- CPQ is the system category in which a guided selling dialogue often, but not necessarily, runs.
- Success depends on a piece of translation: needs-based questions in the customer’s language have to map onto technical attributes. Without that mapping the dialogue stays an attribute form with nicer wording.
What is guided selling?
Guided selling describes a guided selection process that starts from the need rather than from the product. The user answers a few questions about their application, the system excludes unsuitable options and proposes one or a few matching variants. Instead of finding the right one among four hundred versions, the user describes their case and gets three to choose from.
That is why a configurator can make sense even in a web shop that offers only standard variants, meaning versions that are already fully configured. It works differently from a faceted search and can be tuned to the specific product, which makes selection noticeably easier. In this case the required rule set can be generated automatically from the existing standard variants.
The mechanism behind it has three parts. A question tree collects information about the need. A mapping layer translates each answer into one or more attribute values. A rule set checks which combinations are technically valid and reduces the result set. The first and third parts are well understood. The second is the one most often missing in practice, and without it the whole thing does not work.
The three parts work best when they come together in an interactive configuration process. A faceted search can suddenly return an empty result set when filters are combined unfavourably. A rule set prevents exactly that, because it only allows selections for which a variant actually exists. The sales rep therefore never has to tell the customer at the very end that nothing fits. If no standard variant covers the need, the rule set can additionally allow individually configured variants.
What is the difference between guided selling and guided buying?
Perspective, not technology. Guided buying describes the guided purchase decision from the buyer’s point of view, typically self-service on a website or in a procurement system. Guided selling describes guided advice from the vendor’s point of view, meaning sales, internal sales or channel partners.
The difference becomes practically relevant in three places: which prices are visible, which exceptions are permitted, and what happens at the end of the dialogue. A buyer sees list prices and gets a basket. A sales rep sees terms and margins and gets a quote with an approval path. Same rule set, two roles, two exits.
Is guided selling the same as CPQ?
No. Guided selling is an interaction pattern, CPQ is a system category. CPQ stands for configure, price, quote and describes software that brings configuration, pricing and quoting together. A guided selling dialogue can sit inside it, but it does not have to: it runs equally well in a web shop with no commercial follow-through. What CPQ delivers in detail and where its limits are is covered in the article on CPQ.
Conversely, there are CPQ systems where configuration runs through a classic attribute form with no predefined path at all. That is not a flaw. For experts in internal sales, a form with 50 attributes and sometimes more than 100 values per attribute is often exactly the right input method, provided they can start anywhere and set attributes in any order they choose. Someone working from a list of customer requirements jumps straight to the relevant attributes. The system evaluates every entry dynamically and shows the resulting constraints. Many configuration systems, by contrast, make users run through all subsequent steps again after an earlier decision changes.
Guided buying, guided selling, product configurator and CPQ compared
| Guided buying | Guided selling | Product configurator | CPQ | |
|---|---|---|---|---|
| Type of term | Interaction pattern | Interaction pattern | System component | System category |
| Who operates it | Buyer, end customer | Sales, internal sales, dealer | Either, depending on where it sits | Sales |
| Starting point | The need | The need | An attribute | Need or attribute |
| What gets checked | Fit to the use case | Fit plus selling logic | Technical validity | Validity, price, approval |
| Result | Basket or enquiry | Quotable configuration | Valid specification | Approved quote |
| Price visibility | List price | Terms and margin | Price from feature prices, or none | Full pricing logic |
| Typical trigger | Customers abandon product search | Quotes take too long | Unbuildable orders | Discounts without control |
The table is not an academic exercise. In the market all four terms are used interchangeably, and that is exactly where bad investments come from: a company buys a CPQ suite because product search in the shop does not work, and finds out afterwards that the problem was in the product data. On the line between configurator and configuration logic, the article on what a product configurator does is worth reading alongside this one.
How a guided selling dialogue runs in mechanical engineering
An example makes this more concrete than any definition. A manufacturer of industrial gearboxes carries around eight hundred valid variants. The customer is a machine builder who knows what their plant has to do but not which gearbox fits. Four questions are enough to bring the set down to a manageable number.
| Question to the customer | Attributes behind it | What the answer excludes |
|---|---|---|
| What power has to be transmitted, and at what torque? | Rated power, rated torque, ratio range | Every frame size outside the power window, in this case roughly half the range |
| How is the drive mounted in space? | Design type, shaft position, mounting position | Design types not permitted in the stated mounting position |
| What environment does the plant run in? | Protection rating, temperature range, corrosion protection class, food-grade suitability | Versions without the required protection rating; with food contact, additionally all standard lubricants |
| Which control system is in place? | Compatible motors, encoders, fieldbus protocols | Combinations the existing bus system does not support |
Two observations. First, none of these questions is phrased technically, yet each one leads to clearly named attributes. That is the mapping layer described above. Second, every question excludes a substantial part of the range. Questions that do not do that belong in detailed configuration, not in the entry dialogue.
Strictly speaking, this entry is sizing or selection rather than configuration. Even the power and torque figures are usually mapped onto internal product attributes through calculations first, and the outcome is the set of gearbox types that are suitable in principle. Configuration comes afterwards: for the chosen type the user sets, for example, the housing material, aluminium or steel, or the flange. Only then does the individual variant of a specific product emerge. In practice the line blurs, because parts of sizing can also be modelled as configuration. What matters to the user is that the transition between the two steps does not feel like a break.
The most common mistake in such dialogues is asking for the attribute instead of the need. “Which protection rating do you require?” assumes the customer knows the IP system. “Is the plant hosed down with water?” assumes nothing and yields the same information. How technical a question may be depends on the audience, though. A planner with domain expertise may find the simplified wording too coarse and would rather state the protection rating directly. Phrasing questions for non-specialists requires attributes that describe the use case, not only the technology.
What guided selling requires of product data
Guided selling does not create information, it connects what exists. Five things have to be in place, and none of them is a software topic.
- Attributes with a data type, unit and closed value list. A free-text field cannot be filtered, even when the information is sitting in it.
- Documented rules and exclusions. They usually live in the heads of the engineering team and of experienced internal sales staff. Writing them down is regularly the longer part of such projects, not the software rollout.
- Use-case attributes. Statements such as suitable for wet areas, for a cleanroom class, for food contact. They are the bridge between customer language and technology, and they are missing from most data models.
- A maintained mapping from question to attribute. It is an artefact in its own right and needs an owner, otherwise it goes stale with every new product. What completeness and consistency mean in numbers is described in the article on data quality.
- Accompanying content for the recommended variant: dimensional drawing, datasheet, certificates, images. Without it the dialogue ends in a recommendation nobody can verify. That content is governed in a PIM system.
Where guided selling sits in the process
The same logic carries four rather different situations, and the requirements differ noticeably.
| Where it runs | Who uses it | Particular requirement |
|---|---|---|
| Web shop and self-service | End customer, new customer | Highest data completeness, because nobody can ask. Price transparency has to be settled. |
| Dealer and partner portal | Channel partners | Role-dependent terms, range permissions per partner, multiple languages |
| Internal sales and quoting | Your own staff | Fast handover into the quote, special approvals, traceability of changes |
| Field sales at the customer site | Sales in the meeting | Usable without a stable connection, few steps, a reliable statement on delivery date |
A recommendation that follows from the sequence: start internally. Internal sales notices immediately whether the questions make sense and whether the recommendations are right, and mistakes cost nothing there. A public dialogue is the harder case, because incomplete data becomes visible at once.
Native integration or a bolt-on tool?
In selection projects this decision is usually made too early and from the gut. The factual core: a guided selling tool needs attributes, value lists, rules and accompanying content. That data already exists somewhere, typically in the PIM and in the configuration logic. A bolt-on tool receives a copy of it, and from that moment there are two truths that have to be kept in sync.
This is not a theoretical problem. Every rule change has to land in two places, every new product has to be maintained twice, and when something goes wrong the first question is which side is right. Anyone choosing a separate tool should therefore establish beforehand how often the rule set changes and who owns the synchronisation.
At Viamedici, guided selling runs in Smart Product Configuration (SPC), our configuration platform. The dialogue runs against the same configuration engine that serves configuration in the quote and in the shop, and it draws on the attributes from the same PIM. That is the reason for the recommendation rather than a sales claim: there is exactly one rule set. Four properties of SPC are directly relevant to the failure patterns described below:
- Flexible order: users answer the questions in the order that suits them instead of following a fixed path.
- Intuitive guidance: at every point the dialogue shows only the options that are still valid.
- Explanations and solutions: if a selection is blocked, SPC explains why and shows a way out, instead of simply locking the option. The system does not allow contradictory selections in the first place. Anyone who has hit a dead end in a car configurator and had to start over from scratch knows why understandable ways out decide whether people accept the tool.
- Automatic decisions: whatever follows unambiguously from the rules, the system sets by itself, without asking the user. That saves noticeable time, above all in sales.
Implementation details are on the product page for our CPQ solution.
How to measure guided selling
Without numbers the assessment stays a matter of taste. Six measures can be collected without a large project, and the first three say more than any satisfaction survey.
| Measure | What it shows | What it points at when it is poor |
|---|---|---|
| Drop-off rate per question | Where the dialogue loses users | Questions phrased too technically or placed too early |
| Share of completed configurations | Whether the dialogue holds up | Too many questions, or recommendations without documentation |
| Correction rate by internal sales | Whether the recommendations are right | Gaps or errors in the rule set |
| Query rate after completion | Whether the recommendation was understandable | Missing datasheets, drawings or certificates |
| Quote lead time | The commercial benefit | A break between dialogue and quote creation |
| Share of enquiries without manual intervention | The degree of automation | Special cases not represented in the rule set |
The baseline matters. Measure quote lead time only after go-live and you can prove nothing later. A week of measurement before the start is enough for a defensible starting point.
Where guided selling fails
The cases where it does not work are predictable. Four patterns come up again and again.
- The questions are phrased from an engineer’s point of view, although non-specialists use the dialogue. It asks about protection rating, tolerance class and connection type, and thereby assumes exactly the knowledge the user does not have.
- The rule set is incomplete. The dialogue then produces recommendations that are not technically permitted, and after the first few incidents it loses the sales team’s trust. From there it is hard to recover.
- There are too many questions. Beyond roughly eight steps participation drops sharply. If you want to ask everything, build the dialogue in two stages: few questions to a shortlist, details afterwards.
- The handover is missing. A dialogue that ends in a recommendation and then leads to a contact form gives away its own benefit. The transition into a quote, a basket or an enquiry with the full configuration is part of the job.
One development sharpens these requirements. As selection and procurement are increasingly initiated by software rather than by people, fit has to be machine-verifiable and not merely explainable in a dialogue. What that means for product data is covered in the article on agentic commerce.
Conclusion
Guided selling is not a tool you buy but a piece of translation you perform. The questions have to be in the language of the respective audience, the attributes behind them have to exist, and the rule set has to be complete enough that sales trusts the recommendations. Get those three right and you can put any interface on top. Without them, what you get is a politely worded attribute filter.
Webinar: how guided selling shortens sales cycles and improves the buying experience is shown in our webinar Accelerate sales, boost CX and increase efficiency with guided selling.
Frequently asked questions about guided selling
A dialogue that leads to the right product variant through questions about the customer's needs, instead of offering a catalogue to search. The user describes their application, the rule set excludes unsuitable options in the background, and the result is a valid configuration that can be quoted.
The perspective. Guided buying describes the guided purchase decision from the buyer's point of view, usually in a self-service scenario. Guided selling describes guided advice from the vendor's point of view, meaning sales, internal sales or a dealer. Technically both draw on the same rule set, but they differ in permissions, price visibility and the follow-on process.
No. Guided selling is an interaction pattern, CPQ is a system category. A guided selling dialogue can be part of a CPQ solution, but it can equally run in a web shop or a dealer portal without any commercial follow-through. Conversely there are CPQ systems where configuration runs through an attribute form rather than a needs-based dialogue. For experts in internal sales that can even be the better choice.
Attributes with a data type, unit and closed value list, documented rules and exclusions, a mapping from needs-based questions to attributes, and use-case attributes that translate technical values into the customer's language. Without that mapping, every dialogue remains an attribute form with friendlier wording.
As few as possible, and only those that genuinely narrow the selection. A useful rule: every question has to exclude a measurable number of variants, otherwise it belongs in detailed configuration rather than in the entry dialogue. Often the dialogue begins with sizing, where the user enters basic process parameters that narrow the selection sharply. The matching product is configured afterwards.
Yes, and often there first. Internal and field sales benefit immediately because queries and misconfigurations drop. A public self-service dialogue places higher demands on data completeness and price transparency, which is why it is usually the second step.
From three signals: a high drop-off rate in the first questions, a high share of recommendations that internal sales subsequently changes, and queries that arise despite a completed dialogue. All three point at the rule set or at the wording of the questions, not at the software.
