Contractor AI HubField guidesGuides
Field guides

Scope of Work Field Note: Minimum Fields Before an AI Draft

Contractor AI Hub · 2026-10-25

A scope of work (SOW) is the document that tells a customer what your crew will and will not do, what counts as included, and what will trigger a change. An AI tool can turn a messy set of notes into a readable draft. It can also invent inclusions nobody promised, drop exclusions the estimator meant to keep, or invent a start date that the office never confirmed. The difference is almost always whether the office collected a minimum field note before the model wrote anything.

This guide is office-process education for small contractors and home-service teams. It describes the facts to capture, or explicitly mark UNKNOWN, before any model drafts an SOW. It is not legal advice, not a contract template, not a pricing schedule, and not a claim that any insurer, GC, or homeowner will accept the result. For the broader SOW drafting playbook on this site, see AI scope of work templates for contractors. When the job later changes, use the sister field note in Change Order Field Note Minimum Fields Before AI Draft. Privacy still matters when notes include customer identifiers; the FTC's protecting personal information guide and start with security guide are practical baselines for what not to paste into prompts.

Why an SOW draft needs a stricter field set than a job summary

A job summary can tolerate a fuzzy sentence about what the tech saw. An SOW is a commercial instrument: it defines scope, money, and often schedule. If the model invents a quantity to sound complete, the company may later argue from a document nobody on site meant to authorize. Minimum fields exist to keep the draft tethered to what the field actually recorded.

Treat the AI as a writer working from a case file, not as an estimator. It can organize inclusions and exclusions into clean sections, keep the tone even, and flag gaps. It cannot know whether the roof deck was soft, whether the customer agreed to a temporary toilet, or whether the owner is willing to include disposal. Those facts come from people and from documents already in the job file.

Classification comes first. Decide whether you are drafting a first SOW for a new estimate, a revised SOW after a walkthrough, or a narrow work-authorization that will later sit under a larger contract. Write that purpose down. A model that thinks it is writing a full residential remodel SOW when the office only meant a water-heater swap will pad the document with irrelevant sections and miss the one exclusion that matters.

The minimum fields to collect first

Before prompt time, fill each field or write UNKNOWN with the name of the person who can resolve it:

  • Parties — legal or trade names of the contractor entity and the customer, plus who may approve changes. If a property manager or GC sits between you and the homeowner, name that role.
  • Site pointer — street address or job ID, unit or building if relevant, and access notes that affect scope (locked gate hours, occupied home, pets).
  • Baseline scope pointer — the estimate number, proposal ID, walkthrough date, or prior SOW this draft revises. An SOW without a baseline is easy to rewrite against itself later.
  • Inclusions — the concrete work items that are in scope, with enough detail that a stranger on the crew could tell whether a task is done.
  • Exclusions — the concrete items that are out of scope. Write them as positive statements ("does not include drywall repair") rather than hoping silence means excluded.
  • Quantities and units — measurable amounts where the price depends on them (squares of roofing, linear feet of trench, count of fixtures). Mark measured, estimated, or allowance.
  • Allowances and unit-price hooks — any dollar or unit allowance that will be trued up later, with who owns the true-up.
  • Schedule constraints — start window, blackout dates, occupied-home limits, inspection dependencies. Do not invent a hard finish date if the office only has a target.
  • UNKNOWN gaps — every field that is blank, with the named owner who must fill it before the draft is customer-facing.
  • Named owner — the person who may approve the final SOW language and any price attached to it.
  • PII check — confirm the prompt excludes payment card data, bank details, and anything not needed to describe the work.

The exclusions and UNKNOWN fields are the ones most often skipped, and they cause the most expensive arguments. A polished SOW that never says "does not include permit fees" invites the customer to assume they are included. A polished SOW that silently fills an unknown roof-deck quantity invites the company to argue from a number nobody measured.

An illustrative example

Two fields in this example block a customer-ready draft: permit responsibility is unresolved, and the finish date is only a weather-dependent window. The correct output at this stage is not an SOW that quietly assigns permits to the customer or invents a completion date. It is either a holding draft marked "pending UNKNOWN: permit responsibility," or a short office note that names who must resolve the gap. Once the office manager confirms permits and Maya approves, the model can draft the customer-facing SOW from the completed case file.

If the field later finds soft decking beyond two sheets, that is a change-order problem, not a silent rewrite of the original SOW. Capture it with the change-order field note so the baseline SOW stays stable and the overage has its own quantities, pricing basis, and owner.

Prompt rules that keep the SOW honest

Paste the filled fields into the prompt as a short structured block, then add explicit constraints:

  • Use only facts present in the case file. If a field is UNKNOWN, do not invent a value; leave a visible gap or a "pending confirmation" line.
  • List inclusions and exclusions as separate sections. Do not bury an exclusion inside a marketing paragraph.
  • Do not invent quantities, unit prices, allowances, or dates. Refer to the estimate or write UNKNOWN.
  • Do not describe warranty, lien, or legal terms unless the exact office-approved wording is pasted into the case file.
  • Do not calculate a new total. If a price appears, it must come from the estimate or from the named owner as a pasted figure.
  • Keep customer PII to the minimum needed to identify the job. Follow the FTC baselines linked above for data you do not need in the prompt.
  • End the draft with a short checklist of every sentence that depends on a field the reviewer should verify.

A useful final instruction is to ask the model to list, after the draft, every inclusion, exclusion, quantity, and date it used, mapped back to the case-file field. That list turns review from rereading polished prose into checking a handful of factual claims against EST-1182 and the walkthrough notes.

Who reviews what before the SOW goes out

Split the review by field, the same way an office would split responsibility on a change order:

  • Estimator or project manager — inclusions, exclusions, quantities, and baseline pointer match the estimate and walkthrough.
  • Field lead — access notes and schedule constraints are realistic for the crew and the site.
  • Office / admin — parties, job ID, and any permit or inspection language match office policy.
  • Named owner — price, allowances, and final customer-facing wording.
  • Sender — tone, length, and that no UNKNOWN remains in a version labeled ready to send.

If two reviewers disagree—for example the field lead believes decking will exceed two sheets and the estimate still says "up to two included"—the SOW should not paper over the disagreement with vague language. Either update the quantity status to estimated with a unit-price hook, or escalate to the named owner before sending. A model is very good at sounding certain; certainty is exactly what an unresolved field does not have yet.

Common failure patterns

The first failure is the invented inclusion. The model is asked to "make the SOW complete" and adds cleanup, protection, or disposal language that nobody priced. The second is the silent exclusion drop: an estimator had "no gutter work" in the notes, and the draft never says so, so the customer assumes gutters are included.

The third is quantity theater, where the model invents precise measurements because the field note said "about 24 squares." If the note says estimated, the SOW must say estimated. The fourth is schedule fiction: a hard completion date appears because the prompt said "next week," even though the office only approved a start window.

The fifth is the template mismatch, where a narrow service authorization receives a full-project SOW shell with payment schedules and lien notices the company does not use. Keep SOW templates matched to job type, and pause any automation that fills legal sections from generic training data. Finally, keep a record: save the field note, the draft, the reviewer's changes, and the sent SOW with the job. If scope is disputed later, that record shows what the business knew and when.

Assumptions and limits

All examples are hypothetical. Trade rules, contract clauses, lien rights, permit requirements, and consumer-protection rules vary by jurisdiction and by your signed agreements; this page does not interpret them and is not legal advice. If a job involves a written master contract, a public bid form, or attorney-reviewed terms, follow those documents and your advisor's guidance rather than an AI draft. AI tools differ in data retention; review vendor terms before pasting customer data. This guide does not claim measured time savings, win rates, or AdSense outcomes. Check the stated assumptions before adopting the field list.

Sources and method

AI-assisted writing with automated source, calculation and editorial checks. No hands-on testing or professional certification is claimed. Check the stated assumptions before applying this guide.