Transform sales

Automate quote-to-order

Requests, negotiation, framework agreements, call-offs: the sales-led half of B2B revenue, out of Outlook and into one place.

A large part of B2B revenue never sees a shopping basket first. It starts as a request (an email, a phone call, a PDF of a parts list, sometimes a formal RFQ with a deadline) and becomes an order only after somebody quotes, somebody negotiates, and somebody signs. In most companies that whole process lives in Excel and Outlook: last year's quote copied, dates changed, a PDF attached, and the negotiation preserved in one person's mailbox. It works until that person is on holiday, or leaves, or quotes the same customer a different price than a colleague did last month.

Why this is harder than it sounds

A quote is a binding promise with an expiry date on it, made against assumptions: this quantity, this delivery period, this cost basis. The whole discipline of quote-to-order is keeping those assumptions attached to the promise. Email-based quoting loses them immediately. The PDF says €14.20 per piece; it does not say that the price assumed 2,000 pieces called off within six months and a material price that has since moved.

The second problem is authority. When quoting is a document task, everyone quotes what they can defend in the moment, and nobody can see what anyone else quoted. The same customer gets three different prices from three colleagues; the discount that was a one-off concession in March becomes the expected price in September. Margin leaks two points at a time, invisibly, and no report exists that would show it.

A won quote that does not become a price is worth nothing. The customer accepts, and three weeks later their buyer opens your shop and sees the list price, because the agreement lives in a PDF. They phone, annoyed, and your Innendienst manually applies the price you already agreed to, for every order, for the whole term. Acceptance has to produce a condition the platform uses. This is the single most common structural defect in B2B quoting, and it converts a sales win into permanent manual work.

Then there is vocabulary, which matters more than it sounds. A quote is a priced offer with a validity period. A contract price is a condition that applies to a customer for a period. A framework agreement is a commitment to a volume over a term, against which individual call-offs are placed. Customers use all three words to mean "the price we agreed", and the difference decides what happens when the customer orders half the committed volume, or orders after the quote expired, or orders an article the agreement does not cover. Settle the definitions before you configure anything.

Two practical realities. Requests arrive unstructured (a scanned parts list, a bill of quantities, a competitor's article numbers), and translating that into your article numbers is the work in a large share of quotes. And the person who requests is often not the person who decides: quotes get forwarded, discussed, and come back with questions weeks later. A quote that cannot be reopened, revised and version-tracked turns every follow-up into archaeology.

Finally, the number nobody has: why quotes are lost. Sales teams record wins in detail and losses not at all. Without a loss reason, the pipeline tells you the volume of your quoting and nothing about its quality.

Where the platform stands today. Quotes, framework agreements and call-offs are planned apps. What exists now is the storefront form that captures a request, the customer model that a request attaches to, the price lists and time-limited contract prices that an accepted quote becomes, and the order it turns into. This page describes the target process; the guides for the quote screens describe them at their planned state.

The levers

Get the request into one place, with what you need to answer it

What good looks like: requests arrive through a defined route (a storefront form, an email address that creates a record) and land as a quote request with the customer, the contact, the articles and the required-by date already attached. Nothing lives only in an individual mailbox.

What it depends on: knowing which organisation and contact a request belongs to, which means customer data that is maintained rather than typed into the quote each time.

  1. The quote lifecycle
  2. Request for quote in B2B
  3. Handle a quote request
  4. Forms and email
  5. Contacts and roles
  6. Organizations

Decide who may promise what, before you make quoting faster

What good looks like: validity periods, numbering and the document itself are standard; discount authority is explicit per role, with a threshold above which a quote needs a second pair of eyes. A colleague quoting an unfamiliar customer produces the same number as the account owner would.

What it depends on: a stated position on discounting rather than an inherited habit. Speeding up an undisciplined quoting process only distributes the discipline problem faster.

  1. Quote settings
  2. Quote templates and documents
  3. Price models in B2B
  4. Pricing rules
  5. Negotiate and revise

Make acceptance produce the price the buyer will see

What good looks like: the moment a quote is accepted, it becomes an order at exactly those prices. Where the agreement covers a period rather than a single order, it becomes a contract condition that the shop, the punchout and the Innendienst all read from the same place.

What it depends on: the quote and the price engine sharing one model, so that "agreed" is a state in the system rather than a sentence in a PDF.

  1. Convert a quote to an order
  2. Quotes, contracts and framework agreements
  3. Contract prices for a customer
  4. Time-limited prices
  5. Check which price a buyer sees
  6. Common quote problems

Run framework agreements as agreements, not as folklore

What good looks like: a committed volume over a term, with the call-off rules written down, the remaining volume visible to both sides, and each call-off priced from the agreement rather than re-negotiated.

What it depends on: deciding in advance what happens at the edges: the customer who calls off 40% of the commitment, the article that was not in the original scope, the agreement that expires with volume outstanding.

  1. Set up a framework agreement
  2. Call-offs against a framework agreement
  3. Quotes and negotiation
  4. Scale prices
  5. Reading the quote pipeline

A sensible order

Phase 1: one team, standard quotes, one place. Move the quoting of a single product group or a single sales team off email: request in, quote out, versions kept, status visible. Do not change the prices or the authority rules yet. Change only where the process lives. The deliverable is that any colleague can answer "what did we quote this customer, and when does it expire" without asking anyone. Depends on customer data being clean enough that a quote can be attached to an organisation.

Phase 2: authority, templates, and won-quote-to-price. Now set discount thresholds and the approval step, standardise the document, and close the loop that makes acceptance produce a usable condition. This phase is where the margin argument is won or lost, and it depends on Phase 1 having produced enough quotes in the system to see what your discounting looks like rather than what people believe it is.

Phase 3: frameworks, call-offs and configured quotes. Framework agreements with visible remaining volume, call-offs the customer can place themselves, quotes for configured products carrying the full specification, and a pipeline review with loss reasons that is held every month. This is the phase that turns quoting from an administrative function into a steering instrument. It belongs last because it needs a year of clean quote data underneath it.

Common mistakes

  • Digitising the document instead of the process. A nicer PDF changes nothing. The value is in versions, status, expiry and the link to a condition.
  • Speeding up quoting before settling discount authority. You will produce inconsistent prices faster.
  • Leaving the won quote in the quote. If it does not become a price the buyer sees, your Innendienst applies it by hand for the whole term.
  • No expiry discipline. An expired quote accepted six months later at a cost basis that has moved is a loss you agreed to in writing.
  • Not recording why quotes are lost. The pipeline then measures activity and nothing else.
  • Framework agreements nobody tracks. If neither side knows how much volume remains, the commitment is decoration.

How you know it is working

  • Hit rate (quotes accepted against quotes sent), segmented by product group and by who quoted. The aggregate number hides everything interesting.
  • Time from request to quote sent. The metric customers experience. Track the median and the tail; the tail is where deals are lost to a faster supplier.
  • Share of accepted quotes that produced an automatic condition rather than a manual price correction. This should reach effectively all of them, and every exception is recurring manual work.
  • Average discount granted, by role and by customer segment, compared with the authority thresholds. Persistent quoting at exactly the threshold is a sign the threshold is wrong.
  • Open quote value and expiring-this-month value. The second number is the one that drives a follow-up call worth making.
  • Loss reasons, categorised. Price, delivery time, specification, no decision. Without this the pipeline report is a volume count.

What you're building

A request arrives through the storefront or a form and attaches itself to the right organisation and contact. Somebody in sales turns it into a versioned quote with an expiry date, within their discount authority. When the customer accepts, the platform creates the order at those prices and, for agreements with a term, a time-limited contract price that the shop reads from then on. The quote app itself is planned; the customer model, the forms, the contract prices and the orders it connects exist today.

flowchart LR
  BUYER["Buyer"]
  ERP["Your ERP"]
  subgraph XS["Experience Studio"]
    SF["Storefront"]
    FM["Forms"]
  end
  subgraph CS["Commerce Studio"]
    C["Customers"]
    PR["Prices"]
    O["Orders"]
  end
  subgraph IS["Integration Studio"]
    WF["Workflows"]
  end
  Q["Quotes (planned)"]:::planned
  FA["Framework agreements (planned)"]:::planned
  BUYER -- "request, parts list" --> FM
  FM -- "request" --> C
  FM -.-> Q
  C -- "organisation, contact" --> Q
  Q -. "accepted: contract price, validity" .-> PR
  Q -. "accepted: order" .-> O
  FA -. "call-off" .-> O
  PR -- "agreed price" --> SF
  BUYER -- "reorder at agreed price" --> SF
  SF -- "order" --> O
  O -- "order" --> WF
  WF -- "order" --> ERP
  classDef planned stroke-dasharray: 5 5

What you need

Build it

  1. Write the one-page definitions of quote, contract price, framework agreement and call-off — Quotes, contracts and framework agreements
  2. Clean the customer data for the pilot team so every request can attach to an organisation — Customer data hygiene
  3. Build the request form on the storefront and route it to the pilot team — Forms and email
  4. Move one team's quoting into the platform: request in, versioned quote out, status visible — Handle a quote request
  5. Set validity periods, numbering and the quote document — Quote settings
  6. Read three months of quotes to see the discounting as it is — Reading the quote pipeline
  7. Set discount authority per role and the threshold for a second signature — Pricing rules
  8. Make acceptance create the order and, for a term, a time-limited contract price — Convert a quote to an order
  9. Check that the shop shows the agreed price to that customer the next day — Check which price a buyer sees
  10. Set up the first framework agreement with call-off rules and visible remaining volume — Set up a framework agreement
  11. Let the customer place call-offs themselves from the storefront — Call-offs against a framework agreement
  12. Hold the monthly pipeline review with loss reasons on the table — Common quote problems

Decisions you'll need to make

DecisionThe trade-offWhere most customers land
What does acceptance produce? An order only, a time-limited contract price only, or both.Order-only is simple and leaves the second order at list price. Condition-only fits framework deals and leaves the first order to be placed by hand. Both closes the loop and needs the definitions from step 1 to be agreed.Both, with the condition's validity equal to the quote's term. This is the mechanism that stops the Innendienst applying the agreed price by hand for a year.
Who may grant what discount? Per-role thresholds with a second signature above them, or trust the account owner.Thresholds make quotes consistent across colleagues and add a step for the large deals. Trust is fast and produces three prices for one customer.Thresholds, set from the actual distribution after Phase 1 rather than from a policy document. Sales accepts a threshold they can see themselves already meeting most of the time.
Where does the quote process live until the quote app ships? Start with forms, contract prices and orders now, or wait for the app.Starting now settles the definitions, the customer data and the price loop, which is most of the work. Waiting keeps everything in Outlook for another cycle.Start now with the request form and time-limited contract prices, and treat the quote app as the screen that replaces the spreadsheet in the middle. The definitions and the data are the same either way.
Framework agreement: fixed price or price at call-off? The agreed price holds for the term, or each call-off takes the price valid that day.Fixed is what the customer expects and turns into leakage when input costs move. Price at call-off is fair to you and produces a raised invoice nobody warned the customer about.Fixed for the term, with a written adjustment clause tied to a material index for terms over a year. The rule goes in the agreement, and the customer is told before an adjustment takes effect.
Who owns the loss reason? Mandatory field for sales when a quote is closed, or a monthly review that assigns reasons afterwards.Mandatory fields get filled with "price" by default. Monthly reviews are accurate and depend on someone running them.Four reasons, mandatory at close, plus a monthly review that challenges the "price" entries. Both, because neither works alone.