French
GVISION Studio · 2026-09-15
A decision guide for choosing the right quote-request journey based on the complexity of the offering, commercial rules and internal tools.
Which tool should you choose in one sentence?
Choose according to the variability of the offering and the decision the visitor can make without sales intervention.
If the price depends on an interview, inspection or specifications that are still unclear, a short form that prepares a conversation is often sufficient. When three or four variables explain a range, a calculator can provide an initial answer. If choices depend on one another, affect feasibility or need to be passed to production, a guided configurator becomes more coherent. It is therefore not a matter of opposing a modern solution to an older one, but of aligning the interface with the actual sales logic.
The GVISION Studio page dedicated to e-commerce and configurator services presents a guided journey, dynamic pricing, rules and integrations. Here, the objective is to decide how far to go. Start by structuring the useful data, then add calculations or dependencies based on observed usage.
What are the four possible levels?
The right continuum runs from a simple form to a connected configurator; a smart form is often a useful intermediate step.
The simple form collects identity, requirements and a few attachments. The smart form reveals questions based on answers and standardises units or categories. The calculator turns a small number of inputs into an estimate, timeframe or order of magnitude according to a transparent formula. The configurator manages options, incompatibilities, dependencies and customer profiles, sometimes with a visualisation and an actionable summary. These levels can share the same visual interface, but they do not carry the same responsibility or maintenance cost.
Avoid calling every sequence of fields a “configurator”. The difference lies in the business knowledge encoded into it. If an answer changes the permitted choices, price, lead time or bill of materials, the tool is executing a rule. That rule must have a source, an owner, a version and tests. Conversely, a conditional form can already eliminate many incomplete requests without calculating a price. The terminology matters because it sets expectations for management, marketing, sales and development.
How can you compare the options without choosing an absolute winner?
Compare the value provided to the prospect, data quality, maintenance workload and risk of an incorrect response.
The table summarises a decision framework. Costs are not quantified because they vary with the number of rules, languages, integrations, administration, 3D, authentication and availability requirements. Instead, request a verifiable scope: scenarios covered, source of prices, update frequency, number of integrations, roles and acceptance criteria. A small connected calculator can be more demanding than a standalone visual configurator if the upstream data is unstable.
The best choice can also vary by segment. A new visitor may accept an estimate with assumptions; a contracted customer expects their negotiated rate; a distributor wants to record several variants; production requires a valid configuration. It is reasonable to offer two paths: a simple request for atypical cases and a guided journey for a standardisable offering. Then measure where users drop out and which requests actually become actionable.
| Criterion | Simple form | Smart form | Calculator | Configurator |
|---|---|---|---|---|
| Visitor response | Acknowledgement | Tailored questions | Estimate or range | Valid configuration and summary |
| Business logic | Very low | Simple conditions | Limited formula | Rules and dependencies |
| Prices | No | Rarely | Indicative or calculated | Calculated, negotiated or subject to validation |
| Data received | Text and fields | Structured fields | Inputs and result | Options, rules, version and result |
| Maintenance | Low | Low to medium | Formulas and assumptions | Catalogue, rules, tests and integrations |
| Ideal use case | Requirement still open | Repetitive qualification | Parametrisable service | Complex or configurable offering |
| Limitation | Manual exchanges | Poorly suited to dependencies | Difficult exceptions | Risk of over-engineering |
| Best choice according to the need | Human conversation essential | Qualify more effectively without calculations | Provide an order of magnitude | Guide and secure related choices |
Simple form
- Visitor response
- Acknowledgement
- Business logic
- Very low
- Prices
- No
- Data received
- Text and fields
- Maintenance
- Low
- Ideal use case
- Requirement still open
- Limitation
- Manual exchanges
- Best choice according to the need
- Human conversation essential
Smart form
- Visitor response
- Tailored questions
- Business logic
- Simple conditions
- Prices
- Rarely
- Data received
- Structured fields
- Maintenance
- Low to medium
- Ideal use case
- Repetitive qualification
- Limitation
- Poorly suited to dependencies
- Best choice according to the need
- Qualify more effectively without calculations
Calculator
- Visitor response
- Estimate or range
- Business logic
- Limited formula
- Prices
- Indicative or calculated
- Data received
- Inputs and result
- Maintenance
- Formulas and assumptions
- Ideal use case
- Parametrisable service
- Limitation
- Difficult exceptions
- Best choice according to the need
- Provide an order of magnitude
Configurator
- Visitor response
- Valid configuration and summary
- Business logic
- Rules and dependencies
- Prices
- Calculated, negotiated or subject to validation
- Data received
- Options, rules, version and result
- Maintenance
- Catalogue, rules, tests and integrations
- Ideal use case
- Complex or configurable offering
- Limitation
- Risk of over-engineering
- Best choice according to the need
- Guide and secure related choices
How do you measure the complexity of the offering?
Count the variables, but above all their dependencies, exceptions and the number of people needed to validate an offer.
List the decisions currently made by a salesperson: dimensions, volumes, frequency, finish, location, urgency, associated service, contractual profile and minimum margin. For each one, indicate whether it influences another choice. A list of fifty independent options can remain simple; eight options with cross-dependencies may justify a rules engine. Add exceptions by sector, country, channel or customer. If the answer depends on an expert’s memory, capture that knowledge before designing the screens.
Also analyse uncertainty. A form works if an expert reviews every case, but becomes frustrating when the same data is always missing. A formula is risky if exceptions are frequent. Classify cases as standard, parametrisable and bespoke; automate the standard cases first and route exceptions to human review.
Where should prices and business rules live?
There should be a single source of truth; the interface must not become a forgotten second pricing grid.
Designate the system of record: ERP, CRM, product catalogue, administrable table or pricing service. Document who can modify a rule, when it takes effect and how to revert to the previous version. Separate the visible calculation, contractual discounts, additional charges and conditions requiring validation. A public estimate can use a range or explicit assumptions; a firm price requires more controls, customer context and commercial governance.
Test every rule with examples accepted by the teams. Include minimum and maximum limits, units, rounding, taxes, currencies, cumulative discounts and prohibited combinations. The result must be explainable: a salesperson should be able to trace the inputs and rule version. If the price cannot be displayed, the configurator can still produce a precise summary and qualify the request. The value then comes from eliminating emails and re-keying, not from an artificial promise of instant results.
How do you design a journey that genuinely helps the prospect?
Start with the customer’s decision, group questions into stages and explain why information is being requested.
Ask first for what is needed to choose a path, not contact details. A visitor who understands the options and receives a summary is further along than a visitor immediately confronted with ten personal-data fields. Use business terminology, familiar units and examples. Show progress, retain answers when going back and offer “I don’t know” when uncertainty is legitimate. A good journey guides without forcing a level of precision the customer does not yet have.
Qualification is not about multiplying mandatory fields. It is about collecting the signals that change the answer: volume, constraint, timing, compatibility, site or contract type. Every question should lead to a decision, rule or sales preparation. Remove “just in case” fields. Provide a readable summary before submission, a clear confirmation and a request ID. For long offers, allow saving or sending a secure link rather than requiring a single session.
How do you connect the journey to the CRM, ERP and invoicing?
Send a structured configuration, an identifier and the rule version; do not reduce the result to a free-form email.
Define the mapping before integration: which field feeds the contact, opportunity, product, quote line or validation task? Keep both the label displayed to the customer and the technical value. Handle duplicates, failures, retries and missing data. A reliable integration should indicate what has been transmitted and what is awaiting intervention. The quote calculator demonstration from Studio illustrates a front-end interface; production adds real data, history, roles and connections.
In Belgium, the transition from quote to invoice requires a clear boundary. The federal portal states that structured B2B electronic invoicing has been mandatory since 1 January 2026 for the transactions concerned. An estimate or quote does not automatically become a compliant invoice: plan for acceptance, legal data, numbering and the invoicing system. Consult the official e-invoicing FAQ for the exact scope. The integration must preserve the commercial and accounting stages rather than confusing them.
How should you handle personal data, security and accessibility?
Collect the minimum, validate on the server side, control access and make every step usable with a keyboard and screen reader.
The’Article 5 of the GDPR sets out, among other things, purpose limitation, data minimisation, accuracy, storage limitation and security. Explain why contact details and project data are required, avoid sensitive information unless necessary, set a retention period and limit access. Do not place confidential data in the URL. For attachments, check type, size, storage and scanning. A saved configuration should be associated with an unpredictable token and expire when it is no longer needed.
Browser-side validation improves the user experience, but theOWASP Input Validation Cheat Sheet also requires server-side validation. Apply allow-lists, limits and safe error handling. For accessibility, the W3C forms tutorials recommend understandable labels, instructions, groupings and error feedback; the WCAG 2.2 also cover keyboard access, focus, errors and contrast. Test the journey without a mouse and at 200% zoom.
How do you build the business case without inventing an ROI?
Measure the current workload and define indicators before the pilot rather than borrowing generic percentages.
Time a sample of requests: qualification, information retrieval, calculation, validation, drafting, follow-up and re-keying. Count returns for missing data, impossible configurations detected late, version errors and abandoned requests. Distinguish sales time from engineering or production time. This provides a basis for estimating a range of value and choosing which part of the process to automate first, without promising a universal figure.
Track completion, requests that are actionable on the first pass, response time, exceptions, integration errors and human handling. Conversion rate alone can be misleading if poorly qualified requests overload sales. Also include operation, hosting, support, rule maintenance and evolution.
How do you manage the project in six steps?
Build a prototype around a profitable subset, test it with real scenarios and integrate systems only after validating the journey.
First, select a stable product family. Second, map rules, exceptions and the data owner. Third, create a clickable prototype with a summary, without trying to include every feature. Fourth, have customers or colleagues who do not know the model use it. Fifth, implement the calculation and automated tests. Sixth, connect the CRM or ERP with logging and recovery. At each stage, define a stop criterion and the expected decision.
The workshop visual below represents the least visible but most important work: aligning sales, operations, product and IT. Prepare at least twenty scenarios, including limits and common errors. Compare the result with an approved quote. Test three languages if the market requires them, number and address formats, mobile, keyboard access, loading time and API failure. Deploy gradually, keep a manual path and observe requests before expanding the scope.
Which Belgian scenarios illustrate the choices?
Recurring services favour a calculator; technical products favour a configurator; highly variable projects retain a human step.
A cleaning company can estimate a service based on areas, frequencies and options, while reserving atypical sites for a visit. An accounting firm can guide users based on document volumes, employees and obligations, then pass on a summary. A manufacturer of joinery or equipment combines dimensions, materials and compatibility: the configurator protects feasibility before the request. A multi-site group can add addresses, schedules and service levels without immediately asking for every technical detail.
An ASBL can offer packages; an administration will integrate roles and approvals; an engineering consultancy will retain human qualification. The journey must always make clear whether it provides an estimate, an offer to be confirmed or a configuration ready to order.
What mistakes should be avoided?
Failures mainly stem from unmanaged rules, an overly long journey, fragile integration and an ambiguous pricing promise.
Do not copy the internal questionnaire directly onto the website. Do not request data before explaining its purpose. Do not hide all calculation assumptions. Avoid duplicated prices in code, ownerless exceptions, endless dropdown lists and impossible configurations detected only after submission. Do not require an account before the user understands the offering. Do not send only a PDF to the CRM: also retain the structured data that will enable search, reporting and recovery.
Do not launch 3D before validating the selection logic. Plan for ERP unavailability, pricing, separate marketing consent, access and support. Beyond clicks, measure accepted requests, errors avoided and repetitive work eliminated.
Frequently asked questions
What is the difference between a calculator and a configurator?
A calculator turns inputs into a result according to a limited formula. A configurator guides dependent choices, applies compatibility rules and produces a structured configuration.
Should you display an exact price?
No. An estimate or range may be more honest when exceptions require validation. The status of the result and its assumptions must be explicit.
Can you start without a CRM or ERP?
Yes, with a prototype or structured submission. Nevertheless, you should plan the identifiers and data model to avoid a complete rebuild during integration.
Is a configurator suitable for services?
Yes. Packages, frequencies, volumes, lead times and options can form a service offering, provided that the rules are stable and understandable.
How should bespoke cases be handled?
Provide an option for human review while retaining the answers already provided. The journey must neither block nor invent a price.
Is 3D essential?
No. It is useful if it helps users understand dimensions, finishes or layout. A clear summary is sufficient when the decision does not depend on visualisation.
How long does it take to launch?
No universal timeframe is reliable. It depends on the rules, data, languages, integrations, testing and level of administration required.