Building a Quoting Engine for the Auto Glass Industry

Why Auto Glass Quoting Is Harder Than It Looks

From the outside, quoting an auto glass job seems straightforward: look up the part, add labor, give the customer a number. In practice, it involves dozens of variables that interact in non-obvious ways.

The glass itself varies by vehicle year, make, model, and trim. A 2022 Toyota Camry LE has a different windshield than a 2022 Toyota Camry XSE because the XSE has a heads-up display that requires a specific glass type with a coating layer. That is one vehicle model with two completely different parts, different costs, and different installation procedures.

Then there is the insurance dimension. Insurance-paid jobs and cash-pay jobs have different pricing structures. Insurance companies negotiate rates with glass providers, and those rates vary by insurer, by region, and by the specific glass type. A shop needs to quote accurately for both channels, and the margins are different enough that getting it wrong on a few jobs per week can meaningfully impact profitability.

BastionGlass's quoting engine needed to handle this complexity while being fast enough for Chris to quote a customer on the phone without putting them on hold.

Vehicle and Parts Resolution

The quoting process starts with vehicle identification. The customer provides year, make, model, and sometimes trim. The system resolves this to a specific vehicle configuration, which determines which glass parts are compatible.

We built the vehicle resolution as a cascading lookup. The database contains a normalized vehicle catalog — makes, models, years, and trims as separate related tables. When a user selects a make, the model dropdown filters to models available for that make. Year and trim further narrow the options. This is the same pattern used in the customer intake form, ensuring consistency between the website-facing form and the internal quoting tool.

Once the vehicle is identified, the system queries the parts catalog for compatible glass options. Each vehicle configuration maps to one or more part numbers, each with different characteristics — OEM, OEM-equivalent, and aftermarket options with different price points, quality ratings, and availability.

The parts catalog is a shared resource across all BastionGlass tenants, but pricing overlays are tenant-specific. Each shop can set their own markup percentages, preferred suppliers, and default glass types. The quoting engine merges the shared catalog data with the tenant-specific configuration to produce prices that reflect the individual shop's business model.

The Pricing Calculation

The quote calculation combines several cost components. Glass cost is the base — the wholesale price of the part from the shop's supplier, plus the shop's markup. Labor cost is calculated based on the job type and complexity. A standard windshield replacement has a base labor rate, but certain vehicles require additional labor for recalibration of advanced driver-assistance systems (ADAS), removal of rain sensors, or special adhesive requirements.

Material costs cover adhesives, primers, and other consumables. These are relatively small per job but add up and should be accounted for in the quote rather than absorbed as overhead.

For insurance-paid jobs, the calculation changes. Insurance companies pay based on their own rate schedules, which may differ from the shop's retail pricing. The quoting engine maintains rate tables for major insurers and can generate both a customer-facing quote and an insurance claim amount from the same job record. When the insurance reimbursement differs from the shop's standard rate, the system calculates the customer's out-of-pocket amount automatically.

The entire calculation runs in TypeScript with the business rules encoded as pure functions. Given a vehicle configuration, a part selection, a job type, and a payment method, the pricing function returns a deterministic quote with a full breakdown of each cost component. No side effects, no database calls in the calculation itself — all the data is loaded before the calculation runs, and the function operates on plain objects.

This design made the quoting logic straightforward to test. Unit tests cover the matrix of vehicle types, part selections, and payment methods with known expected results. When insurance rate tables change, we update the test expectations alongside the data and verify that existing quotes are not affected.

Speed and User Experience

A quoting engine is only useful if it is fast. Chris needs to quote a customer while they are on the phone, which means the entire flow — vehicle selection, parts lookup, price calculation — needs to complete in seconds, not minutes.

The primary optimization was preloading. When a user starts a new quote, the most common vehicle configurations and their associated parts are loaded in a single query and cached in memory. The cascading dropdowns filter this preloaded data on the client side rather than making round trips to the server for each selection. The price calculation runs entirely on the server but returns in under 200 milliseconds because all the input data is already resolved.

For less common vehicles that are not in the preloaded set, the system falls back to a server query that typically returns in under 500 milliseconds. The user experience is slightly slower but still well within the tolerance of a phone conversation.

The quoting engine also supports saved quotes that can be sent to customers via email or text with a link to approve and schedule. This turned the quote from a verbal number on a phone call into a documented, trackable artifact that feeds into the scheduling and dispatch system when the customer approves.