Window and Door Installer Software Problems: The 5 That Cost You Jobs, and How to Avoid Them

Why does the quoting engine scope blow up so often?

Every window and door project starts with the same optimistic sentence: we just need the measure to turn into a quote automatically. Then the estimator sits down with the developer and the real rules come out. Full frame versus insert changes the labour line and sometimes the trim. Two of the nine openings are egress and have a minimum clear opening requirement, so the unit cannot simply be swapped like for like. The patio door has to clear a radiator. Grid patterns price differently by manufacturer. One colour is standard and another adds lead time as well as cost. Interior trim is sometimes included and sometimes a separate line depending on who sold it.

Each rule is fair. Together they are a configure-price-quote engine, which is the single largest piece of work in this category and is almost always underestimated because the person writing the requirement already knows the rules and does not think to say them.

The way through is to write the rules down before anyone quotes the software. Take your last twenty quotes, list every line that was not a straight unit price, and hand that list to the developer. Then scope the first release to the two or three product families that make up most of your volume, with an explicit manual override on anything unusual. An estimator who can price most jobs in the system and fall back to a manual line for the unusual ones is far better off than one waiting nine months for a perfect engine.

What goes wrong with migrating a decade of quotes, measures and win-loss history?

The years of quotes sitting in your spreadsheets and your current customer system are the most valuable thing you own, and they are also where these projects quietly fail. Three problems recur.

The first is that the outcome is missing. Most window companies record what they quoted and never record why they lost, so a decade of quotes tells you your prices and nothing about your conversion. Before migration, decide the small set of outcome codes you will use going forward and accept that history will be partly blank. Backfilling it from memory produces confident nonsense.

The second is customer identity. The same homeowner appears as a lead, a measure, a quote and a job, sometimes with a different spelling and a different phone number in each system. Merging those badly destroys the very history you are migrating for. Decide matching rules before import and keep an unmerge path.

The third is supplier orders, which usually live in their own spreadsheet maintained by one person. That file often holds the real lead time history for each manufacturer by season, which is genuinely useful data, and it needs mapping to product families that never existed as codes. Budget real time for this rather than treating it as a data dump. Anything older than five years is rarely worth the effort. Load it as archive and start clean.

Why do the supplier and manufacturer integrations break after launch?

Getting order and delivery status out of a manufacturer is where the value sits, because a delayed frame is a rescheduled crew, and it is also the most fragile part of the system. The breakages are predictable.

Manufacturer portals and dealer systems change without notice to you, because you are a dealer rather than a partner, and a screen scrape or a portal login that worked in April fails in August. Electronic data interchange connections behave better but carry their own version drift and mailbox failures that are silent by nature: nothing errors, the status simply stops updating, and nobody notices until a crew arrives at a house where the windows are not there.

Order identity is the other recurring break. Your job number, the manufacturer's order number and the purchase order number are three different keys, and a partial shipment or a re-order after a damaged unit creates a fourth. Systems that assume one order equals one job lose track the first time a single opening is remade.

What works: model the purchase order as its own object with lines that map to specific openings, so a partial delivery updates only the openings it covers. Alert on staleness rather than on errors, because silence is the failure mode here. And keep a manual status override with an audit note, so the person who phoned the branch can record what they were told without fighting the system.

What happens when permits, lead safety and the install record are not covered?

This is the gap that turns a good job into an expensive one. Window and door work touches real compliance surface. Homes built before 1978 fall under the Environmental Protection Agency Renovation, Repair and Painting rule, which requires certified firms, trained renovators, specific work practices and records kept for a defined period. Egress openings carry code minimums. Many replacements need a permit and a final inspection, and in coastal and high wind regions product approval numbers must match what was actually installed.

Systems scoped purely around selling and scheduling skip all of this, and the first time it matters is an inspection failure, a warranty claim or a complaint. The records that prove compliance then have to be reconstructed from photographs on a crew lead's phone.

Cover it as part of the job record rather than as a separate binder. Flag pre-1978 properties at the measure stage from the year built so the certified crew requirement is visible when the job is scheduled, not when the truck arrives. Capture the required documentation and photographs against the specific opening. Hold permit status as a gate on the install date, and store product approval and serial information per unit so a warranty claim three years out takes minutes. None of this is difficult engineering. It is simply absent from most quotes because nobody asked for it.

Should you build custom or configure what you already own?

If you run one or two crews, quote from a simple price book and do not have a manufacturer order problem, do not build. Jobber or Housecall Pro will serve you properly, and the money is better spent on a second estimator. We say this regularly and mean it.

If you are mid-sized and already on ServiceTitan or a similar platform, configure before you replace. Most companies get real value from tightening what they have: proper job types with real durations, price book items for the units you actually sell, automated review requests tied to job completion rather than invoice creation, and a disciplined follow up task on every open estimate. That covers a good share of the leak for the cost of a few weeks of internal work.

What no configuration will give you is per-opening configure-price-quote, manufacturer order status matched to the install calendar, or an after-hours answering path that books against real crew availability. Those three are the build case, and the sensible shape is usually a custom layer on top of the platform you keep rather than a replacement. Replacing the core system is a bigger project than most owners expect and it rarely addresses the actual leak.

How do hidden costs get into the quote?

Four items are routinely missing from proposals in this category. The first is the manufacturer integration, priced per manufacturer. Quotes often price one and describe the rest as similar. They are not, because each dealer system exposes different data in a different way, and one of yours will have no interface at all and require a manual process by design.

The second is the running cost of anything conversational. If the build includes a voice agent answering after hours, the model and telephony usage bills are yours every month and they scale with call volume. Ask for a figure at your actual volume. A developer who cannot give you one has not run this in production.

Third, the configure-price-quote rules themselves. Every product family, every manufacturer and every install type you add is more rules and more test cases. Cost scales with catalogue breadth, not company size.

Fourth, migration of the supplier order spreadsheet and the win-loss history, which is careful work rather than an import script. Ask for these four to be broken out as separate lines before you compare bids.

What separates a build that works from one that fails here?

The estimator decides it. This system is used standing in a garage or a customer's hallway with a measure sheet in one hand, and if it takes longer than the spreadsheet it loses. Watch a real estimator price a real nine opening job in the prototype before you sign off on anything. If they reach for their laptop halfway through, the design is wrong.

Second, the job has to span the whole lifecycle. A measure, a quote, a supplier order, a delivery, a permit, a multi day install and a punch list are one job, not five records. Systems that model them separately produce the classic failure where a crew is dispatched to a house whose frames are still on a truck.

Third, sequence the build so revenue-affecting pieces land first. After-hours answering and estimate follow up touch money directly and can ship while the quoting engine is still being specified. Dispatch and supplier tracking mostly return time, which is valuable and less urgent.

Fourth, ask a prospective developer to show field service or trades software they have shipped and kept running, not a portfolio of marketing sites. This niche has physical constraints, and a developer who has never modelled a job that spans a measure, a supplier order and a two day install will learn on your money.

Finally, confirm in writing that you own the source code and the infrastructure, with the repository in your company name. At Digital Heroes it is yours from the first commit. Ten years of quotes and win-loss data is the asset, and it should never sit in someone else's account.