A statement of work is the one document that decides whether a custom CRE automation project ships what you thought you bought — and most small-firm principals sign it after reading the price and the timeline and skipping the nine clauses that actually govern the outcome. A good automation SOW is not long, but every section does a specific job: it names the single workflow being built, defines the deliverable as an artifact you can point at, sets acceptance criteria a probabilistic system can actually pass, and pins down the run cost, the data handling, and the exit before any money moves. This is a section-by-section reading of that document, and of the vague phrasing in each section that should make you ask a question before you sign.
Most contracting advice online is written for a buyer with a legal team and a project manager. You have neither. You are a principal or an ops director at a firm of four to twenty people, the deal data is confidential, and whoever reads this contract is the same person who will live with what it produces. You are not looking for airtight legal language; you want a scope you can hold the builder to and clauses that protect a firm with no IT department. If you have not yet decided whether to build at all, the buy-versus-build playbook is the step before this one.
Why the SOW Is the Whole Deal
A pitch deck sells the outcome. A demo shows it on the vendor’s cleanest example. The statement of work is the only document that says, in writing, what you are paying for and how everyone knows it is done. When an automation project disappoints a small firm, the failure rarely traces to the code — it traces to a scope that was never pinned down, an acceptance test that was never written, or a run cost that was never disclosed, and all three live in the SOW. Read it the way you read a purchase agreement: you would want the address, the square footage, and the closing conditions, not “a good building in a strong market.” The nine sections below are that document’s address and closing conditions.
Section 1: The Scope Statement
This section names what is being built. The single most reliable predictor of a project that ships on budget is a scope statement that describes one workflow, completely, rather than several workflows, partially.
A good version reads like a job you could describe to a new analyst: “Build an automation that reads inbound lease PDFs, extracts twelve named terms into the firm’s existing Excel abstract template, and flags any document where a term is missing or ambiguous.” You can picture it. You know when it is working.
A weak version reads: “Implement an AI-powered lease intelligence solution to streamline the firm’s document operations.” That sentence has no edges. It cannot be finished because it was never bounded, and it is the phrasing that turns a $35,000 project into a $90,000 one through a discovery phase that never ends. If the scope statement does not name a specific workflow, a specific input, and a specific output, it is not a scope — it is a mood. Send it back for one that names all three.
Section 2: Deliverables
Deliverables are the artifacts you receive, and the test of this section is whether each line is a noun you can point at. “A working lease-abstraction automation,” “a one-page operating guide for the two people who will run it,” “a test report showing accuracy on the sample documents the firm supplied,” “access credentials and configuration in the firm’s own accounts” — those are artifacts.
“Ongoing optimization,” “AI enablement,” and “strategic guidance” are not deliverables; they are billable time wearing a deliverable’s clothing, and they belong in a support agreement with its own scope. Every deliverable should either exist or not on the day the project closes. If you cannot tell whether a line item was delivered, it becomes an argument later — and the party without a legal team usually loses it.
Section 3: Acceptance Criteria
This is the section small buyers skip and the one that matters most. Acceptance criteria define how everyone agrees the thing works. For ordinary software, “it does what the spec says” is enough. For an automation built on a language model it is not, because the system is probabilistic — right most of the time, wrong some of the time — and the SOW has to say what “good enough to accept” means.
| Unsignable | Signable |
|---|---|
| “The tool accurately extracts lease terms.” | “On a 20-lease test set the firm provides, the tool extracts all 12 named fields, achieves at least the agreed field-level accuracy on that set, and links every extracted figure to its source page for verification.” |
| “The system screens deals effectively.” | “The system ranks a supplied batch of 25 deals against the firm’s written buy-box, produces a first-pass summary per deal, and misses no deal the principal marks as a genuine fit.” |
Two things make an acceptance clause real: a test set you supply (not the vendor’s demo file) and a stated bar the output must clear on that set, including your ugliest documents. What keeps a probabilistic system honest is grounding — every number it reports should link back to a source page a human can check — so acceptance should require that link, not just a right answer. “To the client’s satisfaction” protects no one; satisfaction is not a testable standard, and it becomes a stalemate the moment there is a disagreement.
Section 4: Data Handling and Security
Your firm handles confidential deal data, often under NDA, and this section says what happens to it. A firm without an IT department has the contract as its main safeguard, so vagueness here is a real exposure, not a formality.
Three commitments belong in writing: where the data is stored and processed; whether your documents are used to train any shared model — the answer you want is no, and the major model providers state that API and enterprise data is not used for training by default, but the clause should say so rather than rely on it; and how you export and delete your history when the engagement ends. “Enterprise-grade security” is a marketing phrase; a data-processing addendum that binds the builder and its subprocessors to those three things is an enforceable one.
Section 5: Dependencies and Assumptions
This section lists what the project needs from you and from third parties, and it is where honest builders disclose risk. Two dependencies matter most for CRE work.
The first is your own data. If the automation reads leases or deal files, its accuracy depends on the state of those documents. A SOW that assumes “the client will provide organized, consistent source documents” is quietly shifting the cost of messy files onto discovery — fine if you know it, expensive if you do not. Getting your source documents into one place with a consistent structure before the project starts is the largest cost lever you control.
The second is licensed data. If the scope reads a CoStar, Argus, or Yardi export, the automation inherits that platform’s access terms and export formats, and a change on the vendor’s side can break the workflow. A good SOW names these dependencies and says who is responsible when one shifts. A SOW silent on dependencies is not simpler; it has moved the surprises past the signature.
Section 6: Timeline and Milestones
The timeline should tie payments to observable checkpoints, not calendar dates alone. A scoped single-workflow automation commonly runs one to three months; a multi-system build runs longer. The build is rarely the long pole — discovery is, because the builder has to learn your workflow and untangle your data before automating anything.
Watch for two failure modes. A timeline with no intermediate milestone — a single “delivery” date months out — gives you no early signal that the project is drifting. And a promise to ship a complex build in two weeks describes a demo, not a production system you can run unattended. You want a first checkpoint early enough that a wrong direction is cheap to correct, ideally a working version of the narrowest slice of the workflow within the first few weeks.
Section 7: Price and Payment Schedule
The price structure tells you as much as the number. Fixed-price ties a defined scope to a defined cost and puts overrun risk on the builder; time-and-materials bills for hours and puts that risk on you. For a small firm buying a well-scoped single workflow, a fixed price against a tight scope is usually the safer instrument, because it forces the scoping discipline that keeps a project from wandering.
Two clauses inside this section earn their attention. The payment schedule should release money against the milestones in Section 6, not front-load it — a large deposit with the balance “on completion” leaves you little recourse if completion slips. The change-order clause should say how new scope gets priced and approved, in writing, before work on it starts; its absence is how a fixed price quietly becomes time-and-materials mid-project. On the number itself, custom automation for a small CRE firm lands in market ranges rather than at a single list price, and a defensible quote is built from named scope drivers — the full cost model covers what actually moves a quote.
Section 8: Run Cost and Maintenance
This is the ambush section, because it is the one most often missing. A SOW that prices only the one-time build and goes silent on what it costs to keep running is incomplete, and the silence usually hides three recurring lines: model usage, hosting or infrastructure, and support. At small-firm volumes the model and hosting lines typically total tens to low hundreds of dollars a month — modest, and almost always less than the per-seat proptech subscription the automation replaces, which is the economic case for building. The three-year comparison against a subscription is the math that tells you whether the run cost is worth it.
Maintenance is the line a firm with no IT department cannot skip. Software needs occasional attention — a model provider changes something, a document format shifts, a dependency updates — and a firm that cannot do that work itself needs a named arrangement for who does. The absence of a maintenance clause is not a saving; it is a deferred bill and a single point of failure. Ask for the monthly run estimate against your real volume, and a written support arrangement, before you sign.
Section 9: Ownership, Handover, and Exit
The last section answers a question most buyers never ask until they need the answer: what do you own, and what happens if you and the builder part ways? The automation, its configuration, and its prompts should live in your firm’s own accounts, with credentials handed to you — not locked inside the builder’s environment where leaving means losing the tool you paid to build. The SOW should state that the intellectual property in the delivered work is yours, and that on exit you receive everything needed to run it or hand it to someone else.
This is also where the workshop and the build stay separate. If part of the goal is that your team can prompt these models themselves — for LOIs, lease summaries, market write-ups, and email — that is LLM fluency training, a distinct engagement that should be scoped and priced on its own rather than folded into the SOW as “training included.” A firm that can both run its automation and use the underlying tools directly is far less dependent on any single vendor.
The Fast Read: Six Lines That Should Stop You
If you read nothing else in a proposed SOW, read for these six phrases. Each one is a section doing its job badly.
| The phrase | The section it hides in | What to ask |
|---|---|---|
| “AI-powered solution to streamline operations” | Scope | Which one workflow, what input, what output? |
| “Ongoing optimization and enablement” | Deliverables | What artifact do I receive, and when is it done? |
| “To the client’s satisfaction” | Acceptance | What test set and what accuracy bar? |
| “Enterprise-grade security” | Data handling | Where stored, trained on my data or not, deletion how? |
| “Client provides all necessary data” | Dependencies | Who pays if my files are messy? |
| “Balance due on completion” | Payment | What are the milestones, and what is the run cost? |
None of these phrases is dishonest on its own. Each one is simply where a scope gets vague, and the job of reading a SOW is to trade every one of them for a sentence with edges before your signature makes them binding.
Frequently Asked Questions
What is a statement of work for a CRE automation project?
It is the contract section that defines exactly what a custom automation will deliver, how everyone knows it is done, and what it costs to build and to run. For a CRE firm it names the specific workflow being automated — lease abstraction, deal screening, rent-roll or CAM handling, investor reporting — the artifacts you receive, the acceptance test the output must pass, how your confidential data is handled, and the ownership and maintenance terms. It turns a sales promise into an enforceable definition.
What sections should a good automation SOW contain?
Nine: a scope statement naming one workflow, a deliverables list of concrete artifacts, acceptance criteria tied to a test set you supply, data-handling and security terms, dependencies and assumptions, a milestone-linked timeline, a price and payment schedule, run-cost and maintenance terms, and ownership and exit terms. A SOW missing any of these has not simplified the project — it has pushed that section’s risk past your signature.
What is the most important part of the SOW?
The acceptance criteria. Because a language-model automation is probabilistic — right most of the time, wrong some of the time — the contract has to define what “good enough to accept” means, or you have no testable standard. A real clause specifies a test set the firm supplies, including its ugliest documents, a stated accuracy bar the output must clear, and a requirement that every reported figure links to its source page. “To the client’s satisfaction” is not a standard; it is a future stalemate.
How do I know if a scope is padded?
Read the scope statement and the deliverables. If the scope names one workflow with a specific input and output, and every deliverable is an artifact you could point at on closing day, it is tight. If the scope reads “an AI-powered solution to streamline operations” and the deliverables include “ongoing optimization,” it is padded — those phrases have no edges and cannot be marked done.
Should the SOW price be fixed or time-and-materials?
For a small firm buying a well-defined single workflow, a fixed price against a tight scope is usually safer: it puts overrun risk on the builder and forces the scoping discipline that keeps a project from wandering. Time-and-materials fits exploratory work but puts that risk on you — hard to carry without a project manager watching hours. Either way, insist on a written change-order clause.
What data protections belong in a CRE automation SOW?
Three, in writing: where your documents are stored and processed, an explicit commitment that your data is not used to train any shared model, and a defined process to export and delete your history when the engagement ends. Major model providers state that API and enterprise data is not used for training by default, but the SOW should say so through a data-processing addendum that also binds subprocessors. For a firm with no IT department, these clauses are the primary safeguard for confidential deal data.
What run costs should the SOW disclose?
Three recurring lines: model usage, hosting or infrastructure, and maintenance or support. At small-firm volumes the first two usually total tens to low hundreds of dollars a month, typically less than the per-seat subscription the automation replaces. Maintenance is the line a firm without IT cannot skip. A SOW that prices the build and stays silent on run cost is incomplete — ask for the monthly estimate against your real volume before signing.
How much should a custom CRE automation cost?
Market ranges, not a single list price. A scoped single-workflow build generally starts in the tens of thousands; multi-system builds with business logic run higher. The number is set by named scope drivers — how many workflows, how many systems it touches, whether licensed data is involved, and the state of your own documents. A defensible proposal builds its price from those drivers rather than handing you one flat figure.
Who owns the automation after it is built?
You should. The SOW should state that the intellectual property in the delivered automation, its configuration, and its prompts belongs to your firm, and that everything lives in your own accounts with credentials handed to you. Parting with the builder should not mean losing the tool you paid for. A build locked inside the vendor’s environment is a dependency dressed as a deliverable.
How do I choose who writes the SOW in the first place?
The quality of the draft SOW is a direct read on the quality of the builder. A partner who scopes one workflow, writes real acceptance criteria, discloses run cost, and hands you ownership is showing you how the whole engagement will go. One who sends a vague scope, a flat price, and a silent maintenance line is showing you the same. That judgment is most of the partner-selection decision.
Where to Start
A SOW is only as good as the workflow it scopes, and most firms request one before they have decided which workflow is worth automating in the first place. That inventory — which of your workflows would actually pay for a custom build, in what order, and at what honest price — is the real first step, and it is what a free AI-readiness assessment produces: a working session that maps your firm’s workflows, flags the ones where custom software earns its cost, and returns a ranked plan with real ranges, including the workflows where the right answer is a cheaper subscription or a prompt library rather than a project. Book a free AI-readiness assessment if you want that map before any statement of work lands on your desk. If a build is not the right spend, the assessment will say so, and you will still leave with the plan you needed to read the next proposal well.
Arthur Wandzel
