Glivera
← Back to Case Studies

AI-Powered Estimation System: From 20-Minute Spreadsheets to 2-Minute Quotes

Construction / Concrete Cutting | Concrete Cutting Company (Confidential)
ReactOpenAIMCP ServerServiceFusionClickUp

Key Results

  • Estimation time reduced from 15-20 minutes to 2-3 minutes
  • 325+ hours saved per year across 1,300+ estimates
  • Error rate dropped from 3-4% to 0% with automated testing
  • Dual interface: web calculator and AI chat agent

The Challenge

This concrete cutting company does over 1,300 estimates a year across six service types: Core Drilling, Flat Sawing, Pour Back, Bollards, Wall Sawing, and Concrete Scanning. All of it ran through a Google Sheets calculator that somebody spent two months building.

Every estimate took 15 to 20 minutes. The estimator would navigate a sprawling spreadsheet with dozens of conditional formulas spread across multiple tabs, pick the right service type, punch in dimensions and quantities, adjust for site-specific stuff like mobilization distance and concrete thickness, then eyeball the result to make sure it looked reasonable. Nobody had ever documented how the formulas worked. They’d just grown over the years, formula referencing formula, tab referencing tab.

About 3-4% of estimates went out wrong. That’s roughly 40 bad quotes per year. Some got caught before reaching the client. Some didn’t — and those either lost money on underquoted jobs or lost bids on overquoted ones. Multiply 1,300 estimates by 15-20 minutes each, and you get 325+ hours a year. That’s eight full work weeks spent wrestling with a spreadsheet.

The Solution

I replaced the spreadsheet with a four-phase system. The goal was to keep every original calculation intact while making the whole process faster and impossible to screw up:

Phase 1: AI Data Extraction. I pointed an LLM at the original Google Sheets file and had it extract every formula, conditional rule, and pricing variable. It traced dependencies across tabs and produced a structured spec document that captured the complete logic — including edge cases the original builder never wrote down. This would’ve taken me weeks to do manually, and I still might’ve missed things.

Phase 2: React Web App. I built a web application where the estimator picks a service type, enters the variables, and sees the price update in real time. No more navigating between tabs. No more hunting for the right cell.

Phase 3: Automated Tests. I wrote a test suite covering all six service types with different dimensions, quantities, and site conditions. Every calculation path gets checked against the original spreadsheet’s outputs. If anything doesn’t match, the tests catch it.

Phase 4: AI Chat Agent. Using an MCP (Model Context Protocol) Server, I built a chat interface that connects to the estimation engine. Someone can type “core drill four 6-inch holes through 12-inch concrete at a site 30 miles away” and get a formatted estimate back in seconds.

The Implementation

Getting the data out of the spreadsheet was the make-or-break step. The original file had hundreds of formulas with cross-tab references, deeply nested IF statements, and lookup tables that had been tweaked dozens of times. I could’ve sat there tracing formulas by hand for weeks and still missed something. The LLM approach worked much better — it analyzed the structure systematically and caught things I wouldn’t have found until a client complained about a bad quote.

The React app gives each service type its own calculation module. Pricing variables — labor rates, material costs, mobilization fees — live in a config file that the office manager can edit directly. When concrete prices go up or equipment rates change, she updates a simple table. No formula debugging required.

The MCP Server lets the AI chat agent call the estimation engine’s functions directly. It parses natural language job descriptions, pulls out the relevant numbers (service type, dimensions, quantities, site conditions), runs the calculations, and formats the result. When the input is ambiguous, it asks a follow-up question instead of guessing. The team started using it for quick estimates during phone calls with potential clients.

Here’s what really killed the error rate: the test suite runs every time someone changes a pricing variable. So if updating the core drilling labor rate accidentally breaks the flat sawing calculation, the tests catch it before anyone sees a wrong number. That’s how we got from 3-4% errors to zero. Not by being more careful, but by making it structurally impossible for a bad estimate to pass.

The Results

The system rolled out over six weeks. From the first day:

  • 2-3 minutes per estimate instead of 15-20. That’s an 85% time reduction
  • 325+ hours freed up annually — the estimation team spends that time on site visits and building client relationships now
  • Zero calculation errors since launch. The test suite catches everything
  • Two ways to get an estimate: the web app for structured input, or the chat agent when you’re on the phone and need a number fast
  • Price updates are easy — the office manager edits a config table in minutes. No more debugging nested spreadsheet formulas
  • The calculation logic is documented — it’s in code with clear variable names, not buried in an undocumented spreadsheet that one person understood

The Google Sheets calculator took two months to build originally and nobody fully understood it anymore. The replacement is faster, has zero errors, and the office staff can maintain it without calling a developer.

Want Results Like These?

Book a free discovery call and let's find the automation opportunities in your business.