When do we need one instead of Word templates or a CRM's built-in quoting?

The usual trigger is volume and shared work: more than a handful of quotes a week, or more than one person preparing them. Warning signs are copy-paste errors in totals, no record of which version a customer saw, and no visibility of opens. Below that, a careful template or your CRM's quoting module is cheaper.

How do you handle negotiated pricing when there is no fixed list price?

Separate cost basis from sell price. Store unit costs, labour rates and margin rules, then let the salesperson adjust discount within limits you define. The system recalculates totals, tax and validity each time, so negotiated pricing stays consistent and auditable rather than living in one person's spreadsheet. Every override is logged with who did it.

How do you build a quote approval workflow when discounts need a manager's sign-off?

Define thresholds as data, not code. A discount above one percentage routes to a named approver; above a higher one it routes to a second. The quote locks while pending, approvers get in-app or email notification, and each decision is stored with user, timestamp and reason. That log is what makes the workflow auditable.

How do you verify a quote was actually sent and seen by the customer?

Log three events: generated, sent and viewed. Send through your own SMTP or transactional provider so delivery and bounces are recorded; give the customer link a unique token and write a row on every open. If a quote shows as never viewed, check spam scoring, token expiry and whether the customer's mail client blocks remote images.

How do you handle revisions after the customer negotiates?

Never edit a sent quote in place. Create a new version that inherits the previous one, change only what was negotiated, and re-issue it with a fresh validity date. The customer link shows the current version while older ones stay readable for audit. That record is what settles "we agreed a different figure" disputes.

What breaks most often in an online quotation system?

The common ones: totals that differ between screen and PDF because tax and rounding are applied in a different order; expired quotes still accepting; and mixed currencies without a stored exchange rate. Reproduce with a fixed line-item set, compare screen, PDF and database row, and check the server timezone, since date boundaries cause quiet off-by-one errors.

How should access to quote data be secured?

Quotes expose your margins and customer list, so treat them as confidential. Use per-user accounts with role-based permissions rather than a shared login, serve customer links over HTTPS with unguessable expiring tokens, and keep an audit log of reads and edits. If you accept electronic signatures, confirm which legal standard your jurisdiction recognises.

Can a quotation system be integrated with CRM, invoicing or accounting?

Yes, and it pays off once re-typing is the bottleneck. The usual shape: CRM holds customer and opportunity, the quoting tool holds line items and versions, and an accepted quote posts to invoicing as a draft. Build on the vendors' documented APIs with retries and idempotency keys, otherwise a failed sync can create duplicate invoices.

What are the build, buy and plugin options, and what drives running cost?

Options: a quoting SaaS, your CRM's built-in module, or a custom build; a WordPress plugin only suits simple catalogue quotes. Cost is driven by seat count, quote volume, PDF and attachment storage, and whether you need e-signature, multi-currency or approval chains. Ongoing overhead is real: someone owns pricing tables, tax rules and user access. Vendor prices change, so check current pricing pages; our team can scope a build through /contact.

Online Quotation System: Pricing That's Negotiated

Quotations online when every price is negotiated

An online quotation system collects a buyer's requirements, assembles a price from rate cards or cost inputs, routes it for approval, and issues a versioned, trackable quote the customer can accept. It is not an online shop: the price is calculated per deal rather than read from a catalogue, so the system tracks the negotiation, not a checkout.

Key Takeaways

A quotation system earns its keep when pricing is negotiated, approvals are real, and somebody will ask months later what was sent and why. If none of those three are true, a structured form and a locked document template beat a custom build on cost, risk and time to first quote.

A quotation system is a record-keeping system with a document renderer attached. The database is the source of truth, and the PDF is only a view of it.
Never edit an issued quote in place. Change something and issue a new version, so the trail survives the argument that follows.
Store money as integers in minor units or as a decimal type, never as a float. Rounding drift on a 200-line quote is the complaint you will hear first.
Freeze the price book, tax rule and currency rate at the moment of issue. Recomputing with today's numbers quietly rewrites history.
Route approvals on measurable thresholds — discount percentage, margin floor, deal size — not on who asked most persuasively.
Customer-facing quote links need to be unguessable and expiring. A sequential ID in a URL leaks your pipeline to anyone who counts.

The four stages a negotiated quotation passes through, from the incoming request and price assembly to approval, issue, and the accept-or-expire decision.

What is an online quotation system, in plain terms?

A quotation system captures a request, prices it against rules you control, records who approved what, and issues a numbered document the customer can accept or reject. The record is the product: line items, discounts, terms, revisions and timestamps live in a database, and the PDF is a rendering of that record.

That distinction matters more than it sounds. Teams that treat the PDF as the artefact end up rebuilding the same quote three times — once in a spreadsheet, once in the template, once in the accounting package. Teams that treat the database row as the artefact can answer "what did we send them in March, and who approved the discount?" in seconds. The document becomes disposable; the record does not.

Why is a negotiated price harder to put online than a fixed one?

A catalogue price is a lookup; a negotiated price is a calculation whose inputs change per deal — quantity breaks, freight, warranty, payment terms, currency, and a discount somebody has to justify. The system must hold those inputs, recompute totals deterministically, and still show the customer only what you want them to see.

It also has to survive negotiation. A retail checkout ends when payment succeeds. A quotation usually gets revised two or three times before anyone signs, and each revision has to stay readable on its own. If your data model only stores "the current quote", the first revision destroys the evidence. If you are still deciding how work like this gets priced in the first place, our notes on fixed price versus hourly development cover the commercial side of that decision.

When do you actually need a quotation system — and when is a form enough?

You need a quotation system when more than one person touches a quote, when approvals have thresholds, or when you cannot answer "what did we send them in March?" in under a minute. Below a few quotes a week, a structured intake form, a shared mailbox and a locked document template do the job for far less money.

How quoting volume and pricing complexity map to the setup that actually fits, from a simple form-and-template process up to a full quote engine.

Be honest about volume. A business sending fifteen quotes a month does not have a software problem; it has a consistency problem, and a template plus a checklist solves it. The build only pays for itself once manual copying starts producing real errors — a wrong freight rate on a large order costs more than a year of tooling. Our team can help you work out which side of that line you are on before anyone writes code.

How does a quotation system work end to end?

A quote moves through states — draft, pending approval, issued, revised, accepted, expired, rejected — and every transition should be a row in an audit table. Price assembly reads from a price book, approval routing reads from thresholds, and issuing freezes a version that never changes again.

The mechanism is a state machine with two important properties. First, transitions are guarded: you cannot issue a quote that failed approval, and you cannot accept one that expired. Second, transitions are logged with the actor, the timestamp and the reason. That log is what you show a customer who claims they were quoted something else. It also tells you where deals stall, which is genuinely useful commercial information you get for free.

How do you build one, step by step?

Build the record first, the form second, and the PDF last. Most failed projects do it the other way around — they spend weeks on a beautiful document template and then discover the pricing logic has nowhere to live.

Model the quote before you build the form: customer, quote header, quote version, line item, price book entry, approval decision, attachment.
Decide who prices what. Cost and margin columns are internal only; the customer view is a filtered projection of the same row, not a second table.
Make the intake structured. Quantity, delivery location, payment terms and required-by date are fields, because they drive the calculation.
Write price assembly as a pure function. Same inputs, same output — no reads from the clock, the session or "the latest rate card".
Add approval routing on thresholds: discount percentage, margin floor, deal size. Record each decision with user, time and reason.
Issue by freezing a version: line items, tax rule, currency, exchange rate, terms and validity date all snapshot into an immutable record.
Render the PDF from the frozen record only, using a versioned template, so a design change never alters an old quote.
Send a tokenised link rather than the document as the source of truth. The link points at the record and always shows the current version.
Wire the transitions to the systems that care: CRM for pipeline, accounting for the invoice on acceptance, a scheduler for reminders and expiry.

Which settings decide whether the numbers stay correct?

Money storage, rounding rules, tax treatment, currency snapshots, validity windows, numbering sequences and field-level permissions decide whether your quotes reconcile. Get any of them wrong and the errors are subtle, appear weeks later, and usually surface in a customer argument rather than a test.

Use a decimal type or integer minor units — PostgreSQL's numeric types exist precisely because floating point cannot represent money exactly. Round once, at line level, and write the rule down. Store the tax rate and the rule version alongside the amount, not just the computed total. Keep one numbering sequence per legal entity and allocate it inside the same transaction as the quote; a gap in the sequence is a minor audit question, a duplicate is a real problem.

How do you verify it before go-live?

Test the arithmetic and the transitions, not the screens. A quotation system fails in ways a click-through demo never reveals: two sessions editing the same draft, an expiry job firing in the wrong timezone, a PDF that no longer matches the record it claims to represent.

Recompute a 200-line quote twice and diff the totals — they must be identical to the cent.
Open the same draft in two sessions and confirm one gets a conflict rather than silently overwriting the other.
Move the server clock past the validity date and check the expiry job fires once, not every minute.
Re-render an old version's PDF and compare it with the copy the customer received.
Log in as a sales user and confirm margin fields are absent from the API response, not merely hidden in the interface.
Submit the intake form twice in a row and confirm you get one quote, not two — an idempotency key on the submit endpoint.

We went through that list building internal systems for the Research and Development Analytics Institute, and the concurrency test caught more than the arithmetic ones did.

What breaks in production, and what do you check first?

Most production incidents in a quoting system come from stale data or a missing lock, not from a crash. The quote renders fine and is simply wrong, which is worse: nobody notices until the customer does.

Symptom	Likely cause	First thing to check
Customer sees a different total from the PDF	Document rendered before the final recalculation	Compare stored line totals with the PDF's own arithmetic; render only from the frozen record
Two salespeople sent different prices to one buyer	No lock on the quote header while both edited it	Look for row-level locking on the header row inside the update transaction
An expired freight rate appeared on a new quote	Price book lookup ignored validity dates	Query the price book as of the quote date, not as of today
Reminders went out for an accepted quote	Status transition never written back	Read the audit table for the accept event, then the scheduler's filter
Totals drift by a cent on large quotes	Money stored as a float	Check the column type and where rounding is applied

A typical quote lifecycle across thirty days, showing where a revision replaces an issued version and where expiry should close the record.

What does it cost to run, and who operates it?

Running a quotation system costs engineering time and a handful of small services, not a large licence. Expect to pay in build effort, application and database hosting, background workers for PDF rendering and scheduled jobs, storage for documents, and the ongoing work of maintaining price books and templates.

The recurring cost people underestimate is the price book. Someone has to keep rates, freight tables and validity dates current, and that person is usually not an engineer. If updating a rate needs a deployment, you have designed the wrong system. Give a commercial user a screen for it, with a preview and an audit entry for every change. Also budget for the day you change PDF templates: old quotes must keep rendering as they did.

What are the security risks in a quoting flow?

Quoting systems leak commercially sensitive data by design if you are careless: margin, cost, supplier names and pipeline size. The risks are guessable identifiers, over-permissive APIs, and customer links that stay live long after a deal is lost.

Sequential quote IDs in URLs let anyone estimate your pipeline. Use a random, revocable token for the customer-facing link.
Expire customer links and revoke them when a deal closes, so an old PDF cannot be forwarded indefinitely.
Strip internal fields server-side. Hiding a margin column in the template is presentation, not access control.
Treat attachments as an upload path into your infrastructure: scan them, limit types and store them outside the web root.
An e-signature needs an audit trail — signer, timestamp, IP and a hash of the exact document that was signed.
Public quote forms attract spam. Add a challenge such as Cloudflare Turnstile and rate-limit submissions per IP.

What mistakes do teams make most often?

The expensive mistakes are structural, and they show up as rework rather than outages. A quote modelled as a shopping cart, or an issued quote that can still be edited, will cost you months before anyone complains out loud.

Treating the quote as a cart, then fighting checkout assumptions for years.
Editing an issued quote because the customer asked for "a small change".
Storing money as a float and discovering the drift during an audit.
Emailing PDFs until the shared mailbox quietly becomes the system of record.
Over-building approvals — seven levels for deals nobody ever discounts.
No expiry, so a two-year-old price is still being accepted today.
Forgetting the accounting handoff, so accepted quotes get re-keyed by hand.

What does this look like in practice?

A mid-sized equipment supplier in Kathmandu quoted institutional buyers from spreadsheets. Each quote varied by quantity, warranty period, freight and payment terms, and two salespeople regularly sent different prices to the same buyer because each had their own copy of the rate file.

The rebuild was not dramatic. A structured intake form replaced the email thread, price assembly moved into a single function fed by a rate table with validity dates, and anything above a set discount went to the sales head for approval. The PDF became a rendering of the stored quote, and each customer received a link instead of an attachment. The first month surfaced two quotes that had been issued with an expired freight rate — errors the spreadsheet had been making quietly for a year. If your quoting still lives in files, the breakdown of what a web development quote actually contains is a useful sanity check on what to capture as fields.

Build, buy or configure: which option fits?

Buy when your pricing rules are simple and your sales team already lives in a CRM. Build when approvals, price books, currencies or accounting integration make every off-the-shelf exception into custom work. The deciding factor is usually not features but who maintains the price logic after launch.

Option	Fits when	Watch out for
Spreadsheet plus document template	A handful of quotes a week, one person pricing	No audit trail, version confusion, rates locked in one person's head
CRM quoting module	Sales already runs in a CRM, pricing rules are simple	Per-seat licensing, limited document control, awkward export if you leave
Shop with hidden prices	Catalogue is stable, buyers self-serve after approval	Wrong shape for negotiated terms; every exception becomes custom code
Custom quotation system	Multiple approvers, price books, currencies, ERP integration	You own the maintenance, and approval rules invite scope creep

Whichever you choose, keep the accounts and repositories in your own name. That single decision is what makes the next change cheap. For a build, our team can help you scope and deliver custom software development in Nepal in your environment, and hand over something your own team can operate.

In short

An online quotation system is a record of a negotiation, wrapped in a document. Model the quote, not the cart. Freeze every issued version. Store money exactly, snapshot rates at issue, and gate approvals on thresholds you can measure. Then keep the price book editable by the people who actually own it. Do those things and the system will quietly outlast three sales hires and two rebrands. Skip them and you will be reconciling spreadsheets again within a year — see our frequently asked questions for how these projects usually start.

People also search for

If your quotes are still assembled by hand and nobody can say which version the customer is holding, that is worth a short review before you commission anything. Our team can help you map the current process, model the quote properly and build it in your own accounts — start by telling us how a quote gets priced today, and see how we have handled similar internal systems in our portfolio. Reach us through the contact page.

Frequently asked questions

It is a web application that lets your team build, send, track and revise price quotes from one place, with pricing drawn from a database instead of retyped into a document. The customer receives a link to a live quote they can accept or question, and every revision stays attached to the deal record.
The usual trigger is volume and shared work: more than a handful of quotes a week, or more than one person preparing them. Warning signs are copy-paste errors in totals, no record of which version a customer saw, and no visibility of opens. Below that, a careful template or your CRM's quoting module is cheaper.
Separate cost basis from sell price. Store unit costs, labour rates and margin rules, then let the salesperson adjust discount within limits you define. The system recalculates totals, tax and validity each time, so negotiated pricing stays consistent and auditable rather than living in one person's spreadsheet. Every override is logged with who did it.
Define thresholds as data, not code. A discount above one percentage routes to a named approver; above a higher one it routes to a second. The quote locks while pending, approvers get in-app or email notification, and each decision is stored with user, timestamp and reason. That log is what makes the workflow auditable.
Log three events: generated, sent and viewed. Send through your own SMTP or transactional provider so delivery and bounces are recorded; give the customer link a unique token and write a row on every open. If a quote shows as never viewed, check spam scoring, token expiry and whether the customer's mail client blocks remote images.
Never edit a sent quote in place. Create a new version that inherits the previous one, change only what was negotiated, and re-issue it with a fresh validity date. The customer link shows the current version while older ones stay readable for audit. That record is what settles "we agreed a different figure" disputes.
The common ones: totals that differ between screen and PDF because tax and rounding are applied in a different order; expired quotes still accepting; and mixed currencies without a stored exchange rate. Reproduce with a fixed line-item set, compare screen, PDF and database row, and check the server timezone, since date boundaries cause quiet off-by-one errors.
Quotes expose your margins and customer list, so treat them as confidential. Use per-user accounts with role-based permissions rather than a shared login, serve customer links over HTTPS with unguessable expiring tokens, and keep an audit log of reads and edits. If you accept electronic signatures, confirm which legal standard your jurisdiction recognises.
Yes, and it pays off once re-typing is the bottleneck. The usual shape: CRM holds customer and opportunity, the quoting tool holds line items and versions, and an accepted quote posts to invoicing as a draft. Build on the vendors' documented APIs with retries and idempotency keys, otherwise a failed sync can create duplicate invoices.
Options: a quoting SaaS, your CRM's built-in module, or a custom build; a WordPress plugin only suits simple catalogue quotes. Cost is driven by seat count, quote volume, PDF and attachment storage, and whether you need e-signature, multi-currency or approval chains. Ongoing overhead is real: someone owns pricing tables, tax rules and user access. Vendor prices change, so check current pricing pages; our team can scope a build through /contact.