AI is good at the words around the number. It should never be allowed near the number.
TL;DR AI drafts the scope narrative from your site notes. Pricing comes from your own calculator, always. Inject the case study that matches their situation. Assemble the contract from approved clauses, not generated text.
The hard boundary
| AI drafts | Never AI |
|---|---|
| Scope of work narrative | The price |
| Explanation of the approach | Contract terms |
| Why option A over option B | Compliance statements |
| Case study framing | Warranty wording |
| Covering note | Any statistic or claim |
| Summary of findings | Timescales you have not confirmed |
Everything in the right column is a legal or commercial commitment. Generated text there is a liability, not a time saving.
Scope narrative from site notes
The workflow
- Structured intake on site. Job type, findings, measurements, condition flags, access notes, customer priority.
- AI drafts the narrative using your template and your previous approved proposals as the style reference.
- You insert the price from your own calculator.
- You read every line and correct it.
- Send.
The time saving is real: twenty to forty minutes per proposal on the descriptive sections, which are the parts you currently rewrite from scratch and resent writing.
Feed it your own past proposals. The output quality difference between a generic prompt and a prompt containing three of your own approved proposals is enormous.
Prompt structure that works
Give it constraints, not creative licence.
Draft the scope section of a proposal using the notes below and matching the tone of the three attached examples.
Rules:
– No prices. Leave[PRICE]placeholders.
– No timescales other than those in the notes.
– No statistics, percentages or research claims of any kind.
– No superlatives about our company.
– British spelling.
– Under 400 words.
– If information is missing, write[NEED: ...]rather than assuming.Notes: [paste intake]
The [NEED: ...] instruction is the most useful line in that prompt. It converts the model’s tendency to fill gaps with plausible invention into a visible flag you can act on.
Dynamic pricing, from your own logic
Build the calculator separately and deterministically.
- Rate tables per job type.
- Quantity and measurement inputs.
- Condition multipliers.
- Materials at current cost plus your margin.
- Travel and access adjustments.
- Rounding rules.
Then merge the calculated figure into the document. The AI never sees the pricing logic and never generates a number.
Review the rate tables quarterly. Material costs move and a calculator with last year’s numbers produces confident, precise, wrong quotes.
Case study injection
Match the case study to their situation, automatically.
Build a small library, tagged by job type, property type, and problem.
Selection rule: closest match on job type first, then property type.
Similar job: A 1930s semi on the other side of town, same boxed-in pipework problem. Two days, no disruption to the rest of the house. Photos below, and the owner is happy to be contacted if you want a reference.
Offering the reference contact is the strongest element and it costs nothing if you have permission on file.
Never let AI write the case study. Fabricated project examples are a serious problem. These come from your real completed jobs, with permission, and get injected as fixed blocks.
Contract assembly
Modular, from approved clauses. Never generated.
How it works
- A library of clauses, each reviewed by a solicitor once.
- Rules selecting which apply. Job type, value band, customer type, jurisdiction.
- Assembly into the document.
- No generation, no paraphrasing, no summarising of legal text.
Version and date every clause. Know which version each customer signed.
Review the library annually with the same solicitor. Cheaper than reviewing every contract and far safer than generating them.
The proposal document
Structure
- The outcome, in one line. What they get.
- What we found, from the site visit. Photographs.
- What we propose, the AI-drafted scope, corrected.
- Options, if relevant. Two or three, never five.
- Price, broken into components.
- What is not included, explicitly.
- Timeline and availability.
- Similar job, with photos.
- Accept button.
- Terms, assembled.
Accept button at the top and the bottom. Not only after the terms.
Guardrails to build in
- A verification checklist before send. Price checked, no invented claims, dates correct, name correct.
- Search for
[NEED:and[PRICE]before sending. Never send a document containing a placeholder. - A second reader for anything above a value threshold.
- A log of what was sent, so a dispute can be resolved from record.
The most common failure is sending a draft. Build the placeholder check into the send step mechanically.
Measure it
- Time from site visit to proposal sent.
- Proposal acceptance rate, before and after. If it drops, the generated text is reading as generic.
- Time spent per proposal, including editing.
- Errors caught at review. Rising means the prompt needs tightening.
- Questions from customers about proposal content, which indicate unclear sections.
Build the structured site intake form first. AI-assisted drafting is only as good as the notes it works from, and better notes improve your proposals whether or not you ever automate the writing.
Need a pro to build it? [BOOK A CALL]