Request for quote in B2B
Your shop shows a price. The buyer asks for a quote anyway. Understanding why they do that (it is rarely because they missed the price) decides whether your quoting wins deals or only documents them.
Four reasons buyers ask
Their process requires a document. Above a threshold, most purchasing departments require a written offer, often two or three from different suppliers, attached to the internal requisition. The buyer is not negotiating. They need a number, a validity date and your terms, because without them their own approval will not move. Answer fast and yours is often the offer the requisition is built around.
The thing has no catalogue price. A made-to-order assembly, a cut-to-length item, a project quantity that needs a supplier enquiry. These have no list price and should not fake one. A position without a list price is what "price on request" means in a quote.
The freight, not the goods. Two pallets to a construction site, a crane delivery, an island. The article prices are fine; the parcel tariff cannot answer the delivery. Carriage is quoted as its own figure for exactly this case.
They want a better number. A volume that justifies a different price, a competitor's offer in hand, a negotiation coming up. That is a sales conversation, and it is why quoting is a sales tool rather than a form.
Two doors in
A quote in the Revenue Cloud starts in one of two ways, and they are different events.
| From a cart | Opened by sales | |
|---|---|---|
| Who starts it | The buyer, in the shop | Your sales team, with New quote under Order Management › Quotes |
| Positions | A copy of the buyer's cart at that moment | Typed in: article, quantity, unit, list price (empty for price on request), tax rate |
| First state | requested, waiting in the list | in_review, already on the desk |
| Typical case | A basket the shop cannot price | The customer who phoned, emailed a parts list, or never visits the shop |
The cart is copied, never referenced. The buyer keeps shopping while you price, and a quote that changed because somebody added a bolt to their basket would be useless; nobody could say what was quoted. A fresh request totals at list prices, with no discount shown, because nobody has given one yet.
Asking commits the buyer to nothing. That is the point of asking. Asking needs
the permission quotes.request; accepting needs quotes.accept. Keep them
apart if your customers' buyers may collect offers but should not commit to
them.
A buyer whose company buys through a procurement system (SAP Ariba, Coupa) arrives through punchout. Punchout brings a cart back to their system; it is not a way to request a quote. A cXML request that asks for a sourcing event (an RFQ) is refused. See Punchout explained.
Response time is what wins
In a three-supplier enquiry, the offer that arrives first is read first, sets the frame for the others, and disproportionately wins. It does not have to be the cheapest. By the time offers two and three arrive, the buyer has built their requisition around the first one's structure, and a differently structured offer costs them work.
The figure to manage is the time from the request to the quote being sent, and it has to be managed against the tail, not the average. An Innendienst that answers most requests in four hours and a tenth of them in six days has a six-day reputation, because buyers remember the wait.
Three things make the tail long:
| Cause | Fix |
|---|---|
| Requests arrive by email into a personal inbox | Requests land in one list everybody can see. Filter Status = requested |
| Nobody owns a request | Take it on puts a name on it and moves it to in_review |
| The buyer is never told | Every request and every pricing round is announced as an event; a workflow turns it into a mail |
The buyer asks, your team does the work
Buyers do not want to use a quoting system. They want to ask a question and receive an answer. Every additional field on the request is a reason to send an email instead, and an email is a request that never enters your list.
So the buyer's side stays small: the basket, the addresses, and a note on why they ask (it appears on the quote as From the buyer). Everything else is your side: the price per position, the freight, the validity and the message the buyer reads.
What a good B2B quote contains
Vendor-neutral, and longer than a B2C order confirmation:
- Your quote number, and the buyer's own enquiry reference if they gave one. Their reference is how the offer gets found again in their system.
- A validity date. Without one, the offer is either indefinite or worthless, depending on which lawyer you ask.
- Positions with quantity, unit and unit price, the unit stated explicitly.
PCE,MandKGare not interchangeable. - The price basis. Net, in the buyer's currency, VAT stated separately. See Currencies and tax.
- Freight, priced or explicitly excluded.
- Delivery terms and lead time.
- A named person with a direct number. German B2B buyers still phone, and the quote with a name on it gets the call.
How this works in the Revenue Cloud
On a quote, the number, the validity, the positions with list and quoted price, the carriage and the total are fields on the record. The buyer reads them in their account in the shop. The message you write when sending appears as To the buyer. Notes you keep for yourself stay internal: a note is internal unless it is explicitly marked for the customer, so "under 950 we do not go" never reaches the buyer by accident.
Delivery terms, lead time and a contact name go into the message to the buyer.
The app does not produce a PDF document, and it sends no mail itself. A
workflow on the quote.quoted event mails the buyer with everything it needs
already on the event: name, email address, total, carriage, validity and your
message. See Events and webhooks.
Next
- Handle a quote request: the task, step by step.
- Quote settings: validity, grace period and who may accept.