Selecting a model and ticking options is only part of preparing a quote. You still need to check component compatibility, establish the pricing basis and present the result clearly to the customer and fulfilment team. When designing this process, trace one configuration from the first requirement to the finished document. Each stage should have defined inputs, rules and a person responsible for exceptions.
Start with requirements and the data model
Configuration should begin with the information needed to select a product: intended use, required parameters and constraints. Establish which answers are mandatory and which can be completed later. A missing critical parameter should prompt clarification with the customer rather than an arbitrary default choice.
Next, describe the product model. Separate the base product, variants, equipment, services and sales data. Each element needs a unique identifier, name and defined units. Identify the information source and the person responsible for keeping it up to date. The same identifier should make the element recognisable in configuration, pricing and downstream documents.
Write rules that can be checked
Product selection knowledge often lives in technical descriptions and specialists' experience. Before automation, it needs to become unambiguous rules. Add a rationale and examples to each rule: a valid choice, a prohibited choice and one requiring an additional decision. This makes it easier for product experts and the team building the solution to communicate.
- Requirement: a selected option needs another component, so the configuration must include it.
- Exclusion: two options cannot be used together in a particular model.
- Range: a parameter value must fall within the limits for the selected variant.
- Availability: an option may be offered only for a specified model or market, according to current data.
- Exception: an unusual selection must be checked by a designated person before the final proposal is prepared.
Separate technical compatibility from commercial terms. A component may fit the product but still need individual pricing or confirmation of availability for delivery. These situations should not share a single error message. Users need to know what is invalid and what still needs to be agreed.
Hypothetical example: an option with a dependency
Imagine a device where an additional module requires a specific controller. When the salesperson selects the module, the process should identify the required controller and include both components in the scope and calculation. If that controller is unavailable for the selected base model, the model must change, the module must be removed, or the case must go to the person responsible for assessing the exception.
The reverse situation matters too. If the customer later removes the module, the controller's role needs to be checked again. It may no longer be needed, but it could support another remaining option. Simply undoing the last selection is not enough. Reassess the whole configuration and show the effects of the change before creating a new quote.
Validation before pricing and before sending
Validation means checking data against agreed rules. It starts with the completeness of requirements and configuration compatibility. Next comes the calculation: price list version, currency, service scope, surcharges and the commercial terms used. A technically valid configuration does not yet mean that every element has been priced.
Before generating the document, also check whether source data has changed since work began. Define how to handle a calculation in progress after a price list or catalogue update. A finished quote should retain a record of the data it was based on, so that later product updates do not change the content of a historical proposal.
Quote handover checklist
- The configuration has an identifier and version, and all mandatory parameters are complete.
- The scope includes the product, equipment and services, with items outside the quote clearly identified.
- The calculation has a defined basis, and required agreements and exceptions have been recorded.
- The document contains the same options, quantities and terms as the approved dataset.
- The next person knows which points are confirmed and what requires further action.
Test the entire flow with a typical configuration, a change requiring repricing and a case involving an exception. Both salespeople and those receiving their work should take part. The aim is a consistent set of information that passes through successive stages, with a clear place for human decisions wherever rules are not enough.