Skip to content

An estimating assistant where the model names the parts and code sets the prices

Past proposals become a searchable library, and a plain-English brief becomes a priced draft estimate in which every line says where its number came from, built as a working demo on the integrator's own past proposals.

An Australian AV integratorClient engagement2026Working demo
A draft estimate in which every priced line carries its basis: price book, matched job, rate card or ratio estimate, with one line marked 'needs price'
The product itself, running with demonstration data.
of prices set by code, none by the model
100%
line shows the source of its number
Every
past jobs matched to each brief, with reasons
Top 3

The problem

Estimating an audio-visual installation for a school hall or lecture theatre is skilled and slow, and most of it is recall: which equipment last time, how many hours it really took, how much cabling and freight to allow. That knowledge lives in past proposals, as PDFs and Word documents.

Asking a language model to produce a quote is the obvious answer and the wrong one. A model will cheerfully invent a part number and a price, and an estimate that looks authoritative and is wrong is worse than a blank page.

The history is also messy. Proposals come as nested bills of materials with totals that have to reconcile, and labour is often given only as a dollar figure, not as hours.

What we built

01

Ingest by reading, then prove the arithmetic

A proposal goes in as a PDF or Word document; payment terms and conditions are cut out before the model sees it. The model extracts into a strict schema and is told to copy numbers exactly and never compute them. Code then rebuilds the bill-of-materials tree, reconciling every line to its parent, every parent to its section and every section to the subtotal and the ten per cent tax. A document that does not reconcile is flagged for review rather than quietly saved, and a person confirms before anything is stored.

02

Rebuilding the tree from the sums

The model reports indentation, and code trusts the resulting tree only if every parent equals the sum of its children. If it does not (a bundle shown both whole and in parts, a per-unit assembly), the tree is rebuilt by recursive descent from the sums alone. Hours are derived from labour dollars only when the result lands on a sensible step and reproduces the printed figure within one per cent.

03

Matching a new brief to the right old jobs

Each job is embedded and a new brief is matched on a hybrid score: weighted cost-driver parameters, semantic similarity of the scope (falling back to keyword overlap when no embedding key is set) and overlap of equipment categories. The closest three are returned with a breakdown and plain-English reasons, so the estimator can see why a past job was chosen.

04

The model decides what; code decides how much

The model turns the brief into sections and components, each marked new, retained or removed, and then chooses parts, but only from a list of candidates drawn from the price book. Anything it returns that is not on that list is dropped. A deterministic function does all the pricing: price-book lookup times quantity, hours times the rate card. No price the model wrote ever reaches an estimate.

05

Every line shows where its number came from

Each priced line carries its basis (price book, matched job, rate card, ratio estimate or 'needs price'), with a confidence level and the source job, shown as a badge. Low-confidence rows are tinted, and a part nothing can price goes in at zero with a warning rather than at a guess. Cabling, consumables and freight are ratio estimates from the best-matching section, and the demo says so on screen.

06

Checking the prose against the lines

The scope, assumptions and exclusions text is drafted last, with an instruction to mention only equipment that is in the estimate and to list what it mentions. Those mentions are checked against the lines, and any that do not match raise a warning; the model's description is audited by the same data it describes.

07

A blind test, built in

One real job is held out of the library, the price book and the knowledge layer entirely. A comparison view sets the draft against that quote section by section, shows what is missing from the draft and what the draft has that the real quote did not, and compares labour hours.

The library of past proposals with room, structure and subtotal
The library of past proposals with room, structure and subtotal

The outcome

  • A working demo: upload past proposals, review the extraction, enter a short brief, edit the parsed specification, generate a draft and export it as a bill of materials CSV.

  • A real job is held out of the library and the draft is compared with it section by section, so every change to the matching or pricing can be checked against a quote that was actually sent.

  • Honest limits: the rate card is a hypothesis drawn from a single job, ratio estimates are labelled as ratio estimates, and it sits behind a shared demo password rather than real accounts. Feedback loops, proposal-document output, bulk upload and production hardening are planned phases, not built.

Built with

  • Next.js
  • TypeScript
  • Supabase
  • PostgreSQL
  • Claude
  • Voyage AI
  • Zod
  • Vercel

Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy

Start here

Have something shaped like this?

If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.

Book a 15-minute callsaveez@skofi.tech

What happens on the call

  • 15 minutes, no deck
  • We map the process on the call
  • A written scope, or an honest no
Book a call