Extract project requirements before preparing an estimate

Start with the operational bottleneck

An estimate can be delayed before any calculation begins. Specifications, floor plans, elevations, and emails contain overlapping requirements, and an estimator must determine what actually applies. The bottleneck is gathering a trustworthy view of the request, not simply producing a quote faster.

Define a requirement schedule for one trade or product family. For a synthetic facade enquiry, this might include opening references, dimensions, materials, finishes, performance requirements, and exclusions. Missing information should remain missing until someone confirms it.

Design the target workflow

Store each incoming document with a project identifier and revision. Extract candidate requirements into a structured schedule, including the source page and the original wording. Use conventional parsers where the format is predictable, then a model for unstructured descriptions or comparisons.

Compare the schedule across documents. Flag contradictory dimensions, unmatched drawing references, and requirements that appear in one source but not another. An estimator reviews those flags and records the accepted interpretation. Only accepted requirements flow to pricing. Keep product selection, engineering calculations, and bid decisions outside automatic generation in the initial pilot.

Connect to the existing systems

Connection	Information	Control
Project intake	Files, emails and revision identifiers	Associate documents with the correct enquiry
Requirement schedule	Candidate values with source references	Distinguish missing, extracted and accepted values
Estimating system	Accepted requirements and assumptions	Write only after estimator approval

Use stable identifiers and versioned inputs. A retry should resume the same piece of work, with the original permissions and evidence attached. Treat an upstream outage as a visible workflow state.

Fit the model to the task

A small local model can classify clauses and extract bounded fields. Drawing interpretation requires a separately evaluated vision or document-extraction component. Larger reasoning models may help organise conflicting evidence, but they do not establish which drawing is contractually authoritative.

Keep a clear human boundary

The estimator owns assumptions and exclusions. Review low-quality scans, conflicting values, and unit conversions. Keep an audit of the source set used for each estimate so a later revision does not silently alter an issued quotation.

Measure the complete operating cost

Track time to the first usable requirement schedule, correction effort, and missing-information follow-up. Include the cost of drawing extraction and manual review. An apparent gain in extraction speed has little value if incorrect quantities cause rework downstream.

Pilot checklist

• Choose one repeatable enquiry type.
• Define required fields, units, and the meaning of missing values.
• Attach a source reference to every extracted requirement.
• Test revised drawings and contradictory specifications.
• Require accepted assumptions before pricing or external communication.

Agree on acceptance thresholds before testing, then compare the proposed workflow with the same work handled through the current process. Expand only after the operation can explain both successful and failed cases.

Further implementation detail

• Choose the lowest-cost model that meets the task requirements
• Serve a local model to a team
• Ollama’s local API reference