How to Build a B2B RFQ and Quoting System: From Product Configuration and Tiered Pricing to PDF Quotes (Real Costs and a 90-Day Roadmap)

Three Hours a Day, Spent Copy-Pasting Quotes

An industrial-parts trading company: five sales reps, roughly 220 RFQs a month. The workflow is email in, open the Excel price list (version 7, though someone is still on version 5), paste into the quote template, export to PDF, send, and three days later the customer asks for a better price, so it gets revised again. Around 45 minutes per quote, about three hours a day of pure clerical work. Worse, one or two quotes a month go out wrong: freight omitted, an expired discount applied, the wrong quantity break selected. The gap is typically NT$8,000 to NT$30,000, and the rep usually absorbs it. That is not a discipline problem. It is a missing system.

When It Fits vs. When It Does Not

Good fit for an online RFQ and quoting system

• Products vary by specification (size, material, finish, quantity break); there is no single list price
• Clear customer tiers: dealer, project and direct pricing must be kept separate
• 80+ RFQs per month, or revising a quote more than twice is the norm
• Discounts beyond a threshold require manager approval
• When a rep leaves, the quoting history sits in their personal inbox and the company cannot recover it

Not a fit — do not start yet

• 10 to 20 SKUs, single list price, fewer than 20 RFQs a month — a shared Google Sheet is enough
• Pricing is pure ad-hoc negotiation with no rule-based logic — the system becomes another place to paste data
• The product data itself is a mess (one part number with three names, inconsistent units) — spend 4 to 6 weeks cleaning the master data first
• You just switched ERP and are still migrating master data — wait until it stabilises, or you will integrate twice

Alternatives Matrix: Five Paths

The most common real-world answer is a hybrid: ERP owns master data and inventory, while a custom system owns the RFQ entry point, the pricing rules and the customer-facing experience, synced over an API.

Technology Selection

The Full Process, Stage by Stage

• Weeks 1–2 | Extracting the pricing logic: interview three reps and one manager, transcribe how each price is actually calculated, and convert it into a rules table. Deliverables: pricing rules list (Notion), customer tier table, discount approval thresholds. Skimp here and everything downstream is wasted.
• Week 3 | Master data audit: part numbers, units, spec attributes, quantity breaks, currencies. Deliverables: product master CSV template and a gap list.
• Weeks 4–5 | Process and interface design: Figma wireframes for the RFQ entry point, configurator, quoting back office and approval flow. Deliverable: a clickable prototype two reps walk through end to end.
• Weeks 6–10 | Build: rules engine, quote editor, PDF generation, email delivery and open tracking, approval flow, ERP import/export.
• Week 11 | UAT: replay 30 historical RFQs and reconcile system-calculated prices against manual ones, explaining every difference.
• Week 12 | Launch and parallel run: two weeks of old-and-new in parallel, Cloudflare CDN and WAF, UptimeRobot monitoring the RFQ entry point.

Roughly 12 weeks total; add 4 to 6 weeks if the product master data is disorganised.

Real Cost Breakdown (Three Budget Tiers)

The figures below are reasonable estimated ranges for the Taiwan market in 2026, not quotes from any specific vendor.

Hidden costs people forget

• PDF generation needs a dedicated headless Chrome runtime: est. NT$1,000–3,000 per month
• Transactional email (quote delivery and open tracking): est. NT$0–1,500 per month
• ECPay contracted-merchant setup fee NT$5,000 plus NT$13,000 per year; domestic credit card 2.75% (minimum NT$5 per transaction) plus NT$1 per-order processing fee, with 5% business tax added at settlement
• Master data cleanup labour: est. 40–120 hours
• Post-launch maintenance: roughly 15–20% of build cost per year

Expectation vs. Reality

• Expectation: just import the Excel file. Reality: about 30% of the rules exist only in a rep's head and have never been written down; it takes three rounds of interviews to surface them.
• Expectation: customers will submit RFQs themselves. Reality: 60–70% of RFQs still arrive by email and phone for the first three months. The first win is speed on the sales side, not customer self-service.
• Expectation: keep the quote looking exactly as it does today. Reality: current Excel quotes rely on merged cells and manual layout; pagination, long product-name wrapping and the notes block all need redesign for programmatic PDFs.
• Expectation: ERP integration is trivial. Reality: ERP vendors usually charge separately for API access, and permissions plus a sandbox take 2 to 4 weeks.
• Expectation: win rate is visible on day one. Reality: you need at least a quarter of quotes and outcome data before the number means anything.

Common Traps and How to Avoid Them

• Pricing rules hard-coded → move everything into an admin rules table so a sales manager can adjust prices without a release.
• Submission without follow-up → every quote needs a unique link with open tracking, so reps know when to chase.
• No expiry date or version number → print both on every PDF, so nobody returns with a six-month-old price and demands you honour it.
• Discount approvals done over email → approvals must leave an audit trail in the system (who, when, to what discount); it is the only way to investigate margin anomalies later.
• Ignoring RFQ page speed → the public catalogue is an SEO entry point; keep LCP under 2.5 seconds, convert images to WebP, serve via CDN.
• Hard cutover at launch → run old and new in parallel for two weeks and reconcile prices against replayed historical RFQs.

Success Metrics and the 90-Day Roadmap

• Day 30 | Adoption: 80% of RFQs handled in the system, quote preparation down from 45 minutes to under 15, and rule exceptions missed in UAT cleared out.
• Day 60 | Quality: quoting error rate at zero; identify which spec combinations are frequently requested but out of stock and feed that to purchasing; require reps to log won/lost reasons.
• Day 90 | Commercial: compare quote-to-order rate and average response time against the pre-launch baseline; analyse discount distribution to find habitual over-discounting by item and by person; decide whether phase two is two-way ERP sync or a customer self-service portal.

Decision Checklist

• [ ] We handle more than 80 RFQs per month
• [ ] The same product carries different prices for different customers
• [ ] Quantity breaks or spec configuration change the price
• [ ] We have mispriced a quote and absorbed the difference in the past six months
• [ ] Revising a quote more than twice is normal
• [ ] Personal inboxes are the only quoting history we have
• [ ] Discounts above a threshold need manager approval
• [ ] Product master data (part numbers, units, specs) is already standardised
• [ ] Someone can commit four hours a week as project owner
• [ ] Our ERP vendor can and will open an API
• [ ] We accept a two-week parallel run after launch
• [ ] We have budget for 15–20% annual maintenance
• [ ] Management will judge success by win rate, not by "it went live"

Eight or more ticked: worth doing. Fewer than five: clean up the price list first.

My Take

Most companies treat this as "building a quoting website", so they grade it on how the screens look. I see it the opposite way: this is a project that moves pricing knowledge out of individual heads and into company assets, and the UI is a by-product. The hard part is not the technology — rules engines, PDF generation and approval flows are all mature — it is whether anyone is willing to articulate and write down how they price. Companies that will do that save half their admin time even on the basic tier. Companies that will not can spend a million and buy a harder-to-use Excel. That is why our discovery phase is always paid and always requires the reps in the room: it is the single variable that decides the outcome.

FAQ

Our specs are extremely complex — can we do configure-to-order quoting?

Yes, provided the spec combinations are finite and enumerable. Up to a few thousand combinations, attributes plus a rules table will do it. If the variation is continuous (arbitrary cut-to-size, for example), you need formula-based pricing, which adds roughly 20–30% to the build.

Do we have to integrate with ERP?

Not necessarily. In phase one we recommend one-way export: orders created in the system are pushed to ERP by CSV or API, while inventory and cost stay ERP-owned. Two-way sync can wait for phase two, saving 15–25% of the phase-one budget and a lot of testing.

What if customers refuse to log in?

Do not force them. Replace account login with a unique quote link: the customer clicks through to view the quote, download the PDF, accept it or counter, with no registration. Reserve accounts for dealers who order regularly.

How long until we see returns?

Time savings on the sales side show up in the first month. Win rate and margin improvements usually take three to six months, because you need enough quote samples to run discount analysis.

Next Step

ScriptWalker offers a B2B RFQ and Quoting System build, starting at NT$300,000 for the standard tier, covering discovery interviews, pricing-rule extraction, a Figma prototype and a 12-week build to launch. You can also buy the discovery piece alone as a two-day Pricing Rules Audit Workshop (NT$45,000) and decide afterwards. Bring your current Excel quote template and thirty minutes will tell you whether your pricing logic can be systematised.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p