How to set requirements for a quote tool that holds all the way to the order

You’ve sent a quote and the customer wants to change the scope. The salesperson opens the spreadsheet, adjusts the price and sends a new PDF. When the customer accepts, finance has to work out which version applies.

That’s what it can look like at an industrial supplier where requests arrive by email and orders are registered manually. Two weeks between sends is enough for the price list, stock level or delivery terms to change.

A quote tool therefore needs to hold together what you actually promise the customer. Price, product selection, permissions and terms need to be checkable even after the quote has been sent. The document’s appearance is a smaller part of that work.

Where the quote tool sits in the buying process

The customer’s request needs to start with the right context. Which company is buying, who represents the customer and which agreement applies? If the salesperson picks the wrong customer account, the whole calculation can rest on the wrong price list.

Products and the customer agreement are then selected. The tool calculates the price, checks any exceptions and sends the quote for internal approval. The customer then gets an offer with a defined scope and validity period.

When the customer accepts, the right quote version needs to follow through to the order. The business system must be able to receive the agreed item lines, prices and terms. Finance later needs to be able to follow the deal through to delivery and payment.

The order of steps matters. A wrong customer agreement at product selection gives the wrong price in the calculation. If the error gets past approval, the order department receives material that already contains a wrong promise.

According to Statistics Sweden, 30 percent of Swedish companies with at least ten employees received orders via their own website or app in 2024, compared with 21 percent in manufacturing.

For you, that means the quote flow needs to be assessed based on how your customers buy. Some requests need advice before the calculation. Others can start with product selection in a portal and continue with a salesperson.

A document tool can compile information into a PDF. A controlled quote flow also needs to preserve the link between the customer’s request, the approved calculation and the accepted order.

Seven functions and what each must handle

Use the functions as a checklist against your current process. Assess each function based on what information it receives and what the next responsible person can actually use.

Quote requests and customer login receive the request with customer context and product selection. Customer number, company registration number and contact person must be correct. Without this function, the salesperson re-enters the same information.

Pricing and customer agreements calculate the price per line using price lists and contract prices. Price list, discount rule, currency and VAT must be correct. Without this function, a wrong price can go out to the customer.

Configuration and product data fetch items, variants and terms. Item number, units and delivery time must be correct. Without this function, the quote can be based on an old product description.

Approval and attestation levels control who may send, change and approve the quote. Permissions and amount limits must be correct. Without this function, an unauthorised person can approve a quote.

Version control saves every sent quote as its own version. Version number and validity period must be correct. Without this function, it becomes unclear which price the customer accepted.

Sync to order sends the accepted quote to the business system as an order. Order reference, customer number and stock status must be correct. Without this function, you get double entry and discrepancies between quote and order.

Follow-up tracks status, dates and reasons for lost quotes. Quote status, dates and loss reasons must be correct. Without this function, no one knows why quotes are lost.

Customer login needs to link the user to the right buying company. One contact person can represent several companies with different agreements. A wrong customer number can therefore lead to both the wrong discount and the wrong invoice recipient.

Pricing also needs a defined order. The tool has to know how contract price, volume discount and manual price interact. Otherwise a discount can be applied on top of an already reduced contract price.

Imagine the item description sits in the business system, technical properties in a separate register and delivery information in a spreadsheet. The salesperson can then pick the right item number but send an old description. The customer accepts a property the current variant doesn’t have.

For each field, you need to state where the valid information lives. The need for shared source data for product information becomes especially clear when the same item is used on the website, in the portal and in quotes.

Approval then needs to follow the finished calculation. If someone changes a discount after approval, the tool should be able to require a new approval. Order transfer and follow-up must then use the approved version.

Mark which functions you have, which are handled manually and which are missing. Also write down the name of the person responsible for each manual step. That shows both system gaps and tasks without a clear owner.

When the price in the quote becomes binding

Fewer clicks in the quote flow can increase contract risk if the checks disappear at the same time. Under the Swedish Contracts Act, an offer is binding on the party making it once the recipient accepts in time, and the act also applies between companies. How your own agreements and terms affect the assessment needs to be decided by whoever is responsible for your contracts.

Technically, a send can work perfectly while the content is wrong. The tool can deliver the wrong currency, an expired validity period or attachments with conflicting delivery terms. An electronic acceptance doesn’t remove those problems.

Imagine a salesperson gives a discount above their approval limit. The tool allows the quote to be sent because permissions are only checked when the user logs in. The customer accepts before the sales manager notices the discount.

You then need to be able to show what mandate the salesperson had, which check was missing and what the customer received. The legal assessment needs that material. The tool needs to preserve the events so you can produce it.

A change after sending should create a new quote version with its own timestamp. The earlier content should remain.

Also decide how price renewal should work. A useful internal rule is that an authorised salesperson may recalculate an expired offer. Deviations from the price list then go to the person responsible for approval before the new version leaves the system.

That rule needs to be supplemented with handling for older offers. A new send doesn’t automatically mean an earlier offer has no effect. Let whoever is responsible for your contract terms decide how withdrawals and replacement quotes should be worded.

Finally, check that the customer’s acceptance points to a specific version number. Attachments, validity period and any reservations should belong to the same version. You can then investigate a disputed price without comparing email threads and locally saved documents.

Why the sync with the business system determines your result

The system creates the order, but the response never comes back. The connection tries again and places a second order, even though the price and the customer’s acceptance were correct.

The error is in the acknowledgement. Because the quote governs price and terms, the transfer needs to be idempotent: the same identifier gives the same result even if the request is sent again.

Customer, quote and order each need a persistent identifier. If a response doesn’t arrive, the connection should be able to check whether the record has already been created. The same principle applies when messages are redelivered after an outage.

A PDF can show item numbers and terms to a person. On its own, though, the document gives no reliable field mapping to an order. Structured quote lines make it possible to check every value before the business system receives it.

At transfer, the company registration number and customer number must refer to the same buying company, the order reference and quote version must point to the customer’s accepted offer, and the item number and unit must be usable on the right order line. VAT and currency should follow the approved calculation, while the delivery address and payment terms should match the offer.

You also need to decide which system owns price and stock. A current stock level at the time of calculation doesn’t mean the goods are reserved. The quote therefore needs to distinguish between stated availability and a confirmed delivery.

Appoint someone responsible for field mapping and test changes in the business system against the quote flow. Reconcile a sample of accepted quotes against orders every month and document the discrepancies. The article on integration with the business system helps you define which responsibilities need to come with the connection.

Five metrics that show whether your quotes are profitable

Fast quote production can go hand in hand with weak profitability. If the salesperson uses outdated purchase prices, more accepted quotes can mean lower margins. You therefore need to track both the effort and the financial outcome of the deal.

Your quote metrics need to be designed around your own process and be traceable to actual events.

Time from quote to accepted order shows how long the deal takes. The value comes from timestamps on quote versions and orders. A common mistake is starting the measurement at the wrong point.

The share of quotes that become orders shows conversion per channel and product group. The value comes from quote status and the order register. A common mistake is leaving out lost quotes.

Manual corrections per quote show where the quote needs manual work. The value comes from the log of changes after sending. A common mistake is that changes are made in spreadsheets outside the tool.

The share of order lines that match the business system’s data shows how well quote and order agree. The value comes from reconciliation against order lines in the business system. A common mistake is only reconciling at invoicing.

Gross margin against discount policy shows whether discounts follow your rules. The value comes from the quote line, purchase price and discount rule. A common mistake is only tracking margin at the end of the quarter.

Define when lead time starts and ends. If some salespeople register the request immediately and others only when sending, the comparison becomes misleading. Also decide how open quotes are handled when calculating the share that become orders.

Corrections need a reason. A customer extending the order is a different event from a salesperson fixing the wrong currency. If you mix them up, active selling can look like poor data quality.

Each quote line should carry product identity, price list, discount rule, currency, VAT treatment and calculation version. The margin calculation also needs a defined cost basis. Otherwise finance and sales can get different answers about the same deal.

Store the measurement points per channel and business system. That makes it possible to compare portal-based quotes with quotes entered by salespeople without mixing different ways of working.

There’s no shared industry standard to use as a benchmark for these metrics. Treat the first measurement as your baseline. Mark what you can measure directly and which events still lack logging.

Choose based on your situation, from standard to custom build

A quote is a binding promise on price and terms, so choosing a tool is in practice choosing a control system for your pricing rules. Which setup fits depends on quote volume, the complexity of your discount rules and your capacity to manage the solution over time.

A spreadsheet with CRM export fits when you have few quotes a year and few pricing rules. It requires discipline in version control and one responsible person. The biggest risk is the lack of traceability to the order.

A standard function in an existing platform fits when the flow is common and pricing rules are few. It requires a named owner for price lists. The biggest risk is that a generic solution can’t handle the discount rules.

An adapted function based on your business logic fits when approval and pricing rules differ from the standard. It requires a decision on who owns the rules. The biggest risk is that the rules change more often than the function.

A customer-unique solution for one company or portal fits when the flow is unique and needs to be kept separate from other parts. It requires a budget for management after go-live. The biggest risk is that upgrades become expensive if the solution isn’t isolated.

A custom build from scratch fits when you have your own development organisation. It requires capacity for integrations and upgrades. The biggest risk is that knowledge sits with a few people.

A spreadsheet can be enough when quotes are few, the price list is simple and one person is responsible. It becomes unsuitable as soon as several people need to change the same offer or customer agreements require recurring special checks, because every change then needs to be traceable to the order.

A standard function suits a well-defined flow. Test it with your hardest discount cases before deciding. If salespeople have to finish calculations outside the system, you still have a manual calculation step to manage.

An adapted function may be needed when approval rules differ between product groups or when approval limits should apply differently to different customer segments. Customer-unique parts can be justified for a particular company or portal. They need to be kept isolated so that changes and upgrades can be tested without disrupting the rest.

A custom build requires you to staff development, documentation and troubleshooting over time. It’s a weak choice if you lack capacity to maintain the connections after launch. Whatever the setup, someone in your organisation has to decide what the pricing rules mean; the tool can enforce the rules but not define them.

Glanser delivers standard, adapted and customer-unique functions from the Function Library at a fixed price, and Glanser Care covers version tracking, compatibility through upgrades and bug fixing at a fixed monthly cost.

The cost after go-live needs to be part of the comparison from the start, so review three items missing from your TCO calculation before you cost the alternatives. A simple flow with few quotes can still be handled reasonably in a spreadsheet, but it needs the same clear ownership as a custom build.

Three questions to ask the supplier

A demo shows how the intended flow works. Your questions also need to show what happens when someone changes a price, a transfer is interrupted or the responsible person leaves.

How do you version a quote after it’s sent, and what happens to the price the customer has already accepted? A vague answer reveals that the supplier may lack a persistent link between the acceptance and the approved calculation. Ask the supplier to show both the history and the order that was created.

Which fields carry over to the order, and how do you handle an interruption when the business system has already created the order? An answer without idempotency or equivalent protection signals a risk of duplicate orders. The demo should also show how the administrator spots a failed attempt and can continue safely.

Who owns the price lists and rules after go-live, and what does a changed pricing rule cost in money and time? The answer shows how the work functions when business terms and system versions change. Distinguish between updating a price list, configuring an existing rule and developing a new calculation.

Compare the answers against a saved quote version and its order for the accepted price, an event log and demonstrated recovery for an interrupted transfer, and the responsible role, agreed scope and change handling for a changed pricing rule.

With us, the line between existing functions and new functionality needs to be clear before work starts. A fixed price can only be assessed once the scope is described.

Written answers give you something to compare between suppliers. They should state both what the solution can do and which tasks you are responsible for yourselves.

Two hours and 72 hours are enough to see where you stand

A supplier presentation makes it easy to choose before the current quote flow has been mapped. You then risk buying functions you already have and leaving the difficult handovers untouched. First map how an accepted quote becomes a correct order in your business.

The material needs to show which functions you use, where the price is calculated and how the connections work. Also bring an example where something went wrong, such as a corrected invoice or a quote with several revisions. Cases like that show what an ordinary demo misses.

Bring your current website, e-commerce or portal to show which parts can be kept, a quote with revisions to show where price and terms change, the corresponding order to show how the handover works, and your documented pricing rules to show which functions and exceptions are needed.

In a 72-hour analysis of your existing solution, you show your current website, e-commerce or portal and set aside two hours of your time. Within 72 hours, you get a clear picture of where the solution stands and exactly what a change would involve. The analysis is free of charge, and the material is yours to use whoever you choose.

For the assessment to be useful, you need to be able to explain your most important pricing rules. The person responsible for sales terms should therefore take part together with someone who knows the systems, since the trade-offs often sit at the boundary between business rules and technology.

The outcome may be that the solution stays as it is. It may also be fundamentally sound and need limited adjustments, or it may need to be rebuilt. In that case, it should be clear which needs justify the rebuild and how the costs are distributed.