A manufacturing company was producing cost estimates using spreadsheets, historical reference files, and the knowledge of two senior estimators who had been with the company for 20+ years. Every estimate took 2–3 days. When those estimators were unavailable, estimates took longer and were less accurate. The company knew the process was fragile, but replacing it meant codifying decades of institutional knowledge into a system that could actually produce reliable numbers.
We built a custom cost estimation system that reduced estimation time to 4 hours and improved accuracy by 30% compared to the manual process. The system is in production and handles the company's full estimation workload. See the full manufacturing cost estimator case study for the technical architecture overview.
What was the actual problem?
The problem was not "we need software." The problem was that the company's ability to quote accurately and quickly was dependent on two people. When both were available, the process worked. When one was on leave or both were occupied with large quotes, smaller jobs waited. Lost quotes meant lost revenue. Slow quotes meant competitors won on speed.
The estimation process involved:
- Reviewing the job specification and identifying material requirements
- Looking up current material prices across multiple suppliers
- Estimating labour hours based on similar past jobs (from memory or reference files)
- Calculating machine time and production scheduling impact
- Adding overhead, margin, and contingency
- Cross-checking against historical quotes for similar jobs
- Formatting and delivering the quote to the sales team
Steps 1–4 required deep knowledge of the company's specific materials, processes, and equipment. That knowledge lived in two people's heads. The spreadsheets were tools, not systems — they required expertise to operate.
Why couldn't off-the-shelf software solve this?
The company evaluated three off-the-shelf estimating tools before engaging us. None could handle the specific combination of requirements: custom material databases with supplier-specific pricing, labour estimation models based on the company's own production data (not industry averages), and integration with the existing ERP for production scheduling. This is a pattern we see across manufacturing ERP decisions — generic tools use industry averages where company-specific data is what matters.
The fundamental issue: generic cost estimation tools use industry-average data. This company's competitive advantage was that their estimation process was more accurate than competitors because it was based on their own historical data. Replacing that with industry averages would have made them less competitive, not more efficient.
What did the system architecture look like?
The system has four layers:
Data layer. A structured database of the company's materials, suppliers, historical job data, and production parameters. We migrated 8 years of estimation history from spreadsheets and reference files into a normalised database. This was the most time-intensive part of the project — cleaning and structuring decades of data took 6 weeks alone.
AI estimation engine. Machine learning models trained on the company's historical data. The models predict material quantities, labour hours, and production time based on job specifications. The training data was the company's own completed jobs — actual costs vs estimated costs, with the variance used to calibrate accuracy. This is the part that generic tools cannot replicate: the model learns from this company's specific patterns, not industry averages.
Estimation workflow. The user interface where estimators work. They input job specifications, and the system generates a draft estimate with material costs, labour projections, machine time, and overhead. The estimator reviews, adjusts, and approves. The system learns from every adjustment — when an estimator overrides the AI's suggestion, that correction feeds back into the model.
Integration layer. Connections to the company's existing ERP for production scheduling, supplier systems for current material pricing, and the sales system for quote delivery. The estimate flows from creation to approved quote to production order without manual re-entry.
What made the AI component work in production?
Three decisions made the difference between a proof-of-concept and a production system:
The AI assists, it does not replace. The system generates draft estimates. Humans review and approve them. This was a deliberate choice. The estimators' expertise is still in the loop. The AI handles the 80% of the work that is data lookup and calculation. The estimators focus on the 20% that requires judgment — unusual specifications, non-standard materials, customer-specific requirements.
The model trains on the company's own data only. No industry averages, no third-party benchmarks. Every prediction comes from the company's historical jobs. This means the model knows that a specific material from a specific supplier takes a specific amount of time to process on the company's specific equipment. That level of specificity is impossible with generic tools. This approach to AI in manufacturing is what separates production systems from vendor demos.
Continuous learning from corrections. When an estimator adjusts the AI's output, the correction is logged and used to retrain. After 6 months in production, the model's accuracy improved an additional 12% beyond the initial 30% improvement — because the system learned from every job that went through it. This is the compounding advantage: the longer the system runs, the more accurate it becomes.
What were the measurable results?
Estimation time: Down from 2–3 days to 4 hours for a standard job. Complex jobs that previously took a week now take 1–2 days.
Estimation accuracy: 30% improvement in estimate-to-actual variance at launch. 42% improvement after 6 months of continuous learning. The model gets better every month.
Quote volume: The company now processes 3x more quotes per week than before. Faster estimation means more bids, which means more won work.
Knowledge dependency: The estimation process no longer depends on two specific people. Three additional team members now produce estimates using the system. When the senior estimators are unavailable, the process continues without interruption.
What would we do differently?
Data migration should have started earlier. We spent 6 weeks cleaning historical data, and that pushed the overall timeline. If we were doing it again, we would start data extraction and cleaning in Week 1, in parallel with discovery and architecture — not sequentially after it.
We also underestimated the importance of the feedback loop. The continuous learning mechanism — where estimator corrections retrain the model — ended up being the most valuable part of the system. We designed it as a secondary feature. If we were starting from scratch, it would be the primary design consideration from Day 1.
This project is still in active development. The system now handles the company's full estimation workload and is being extended to include automated supplier quote comparison and predictive material cost forecasting. For companies evaluating whether a custom ERP with AI fits their manufacturing operations, this project demonstrates what production AI in enterprise software actually looks like — not a demo, but a system that gets more accurate every month. See the full ERP development company guide for evaluation criteria.
Need a team to build this for your business?