Most guides to how an AI automation project works are written for a company with a data team, a project office, and an IT budget line. Yours has none of those. You are a managing broker or ops director doing this between showings, “our data” means a shared drive of PDF leases and an Outlook inbox, and the person who will own the project is you. This is the same journey told from your side of the table: what actually happens from the first discovery conversation to a system running unattended on a Monday morning, what it costs, how long it takes, and — the part every sales-driven version skips — what the work requires of you at each step. Read it and you will run the project as an informed client instead of a hopeful spectator, which is the single biggest predictor of whether the thing ships.
An AI automation project is the work of turning a repetitive, rules-loose task your firm does by hand — abstracting a lease into your underwriting model, normalizing a rent roll, drafting a first-pass LOI, triaging the deal inbox — into software that does it for you and runs without a person babysitting it. It moves through a predictable sequence of phases, and understanding that sequence is how you tell a serious partner from a slide deck. This piece maps the whole path. For the decision of whether to build at all or buy something off the shelf, the companion buy-vs-build playbook runs the cost math; here we assume you have decided a build is on the table and want to know how the build itself works.
Two Questions Before Any Project Starts
Before the phases, answer two questions that most vendors would rather you skipped.
Should this even be a project? A custom build earns its price only when the workflow is specific to how your firm makes money and no product on the market serves it well. If a $200-a-month subscription or a well-written prompt over a tool you already pay for would fix the problem, a project is the expensive wrong answer. The honest first move is often an inventory of your workflows and a fluency step for the team, not a procurement decision. The wider case for that sequencing lives in the small CRE firm AI playbook.
Is what you were shown a demo or a system? This is the trap that catches small firms most often. A vendor runs a flawless demonstration on a clean sample lease, and you assume that capability is a product you can switch on. It is not. A demo proves the idea can work once, on curated data; a production system works every day on your ugliest scanned documents, unattended, with a way to catch its own mistakes. The gap between the two is most of the project. The distinction between a proof of concept, a pilot, and production has its own guide — read it before you sign, because the word a vendor uses for what they showed you tells you how far the work actually is.
The Phases, Start to Finish
A well-run engagement moves through seven phases. Smaller single-workflow projects compress the middle ones; larger multi-system builds expand them. The names vary by shop, but the shape does not.
Phase 1: Discovery
Discovery is where a good partner learns your workflow before automating a line of it, and it is the phase small firms most underestimate. The builder sits with the person who does the task today and watches the real thing: which document types come in, where the messy exceptions live, what “correct” means, and what happens to the output afterward. For a lease-abstraction automation, that means handing over a stack of your actual leases — including the badly scanned 1990s amendment nobody can read — not the clean one you would show a client.
Discovery is mostly your time, not the vendor’s, and that surprises people. The calendar risk in almost every small-firm project is here, because a builder cannot automate a workflow they do not yet understand, and only your team holds that understanding. Discovery ends with a written scope: the exact task, the inputs, the definition of a correct result, and what is explicitly out of bounds.
Phase 2: Scoping and a Proof of Concept
With the workflow understood, the partner builds a proof of concept — a narrow, throwaway version that answers one question: can this actually be done reliably on your real data? A proof of concept for rent-roll normalization might take ten of your genuine rent rolls, including two you consider a mess, and show what the extraction gets right and where it breaks. The point is not a polished tool; the point is to kill or confirm the idea cheaply before anyone commits build money.
This phase is where the earlier demo-versus-system question gets answered honestly. A proof of concept run on your worst documents, with the errors shown openly, is worth more than any demo on a curated sample. If a partner resists testing on your real files, treat that as the most important signal in the entire engagement.
Phase 3: The Build
Now the workflow becomes durable software. The build turns the proof of concept into something that handles the full range of inputs, not just the ten test files — the odd formats, the missing fields, the documents that arrive as photos of documents. Most current automation of this kind is assembled from general AI models (the ones behind ChatGPT, Claude, and Gemini) wired into a pipeline that pulls the input, runs the model, checks the result, and writes it where you need it, such as your Excel model or your CRM.
The most important thing built in this phase is not the extraction itself but the way the system catches its own mistakes: a confidence flag on a number it is unsure about, a link back to the source page so a person can verify anything a decision rides on, a queue for the exceptions it cannot handle. A clean-looking wrong number is more dangerous than a visible failure, because it moves money before anyone notices. Insist that verification is part of the build, not an afterthought.
Phase 4: Integration
Integration is the work of making the automation talk to the tools you already run — Outlook, Excel, your accounting system, your CRM. For a firm with no IT department this is often the hardest and most underestimated part, because your five tools were never designed to talk to each other, and the automation has to bridge them. Plain-language ground on this is worth having before the conversation; the guide to software integration for non-technical owners covers what “it connects to your systems” actually involves and where it goes wrong.
The practical test is whether your least technical colleague can operate the finished thing from where they already work. If using the automation means learning a new dashboard and a new login, adoption will suffer regardless of how good the underlying model is. The best small-firm builds disappear into the tools the team already opens every morning.
Phase 5: The Pilot
A pilot is the system running on live work, in parallel with the old manual way, for a defined period. Where the proof of concept asked “can this be done?”, the pilot asks “does this hold up day after day?” You run the automation alongside the human process for a few weeks and find the failure modes that only show up at volume — the lease clause phrased in a way the proof of concept never saw, the rent roll from one property manager that breaks the parser.
The pilot is also where your team decides whether they trust it. Trust is earned by watching the system be right on hard cases and, just as importantly, watching it flag the ones it is unsure about instead of guessing. A pilot with a clear pass/fail bar protects both sides; a pilot with no acceptance criteria is just an open-ended beta that never ends.
Phase 6: Production and Acceptance
Production is the system doing the work for real, with the manual fallback retired. The gate between pilot and production is acceptance: a written test the system has to pass — an agreed accuracy level on a representative sample, verified together — before you sign off and before final payment is due. Acceptance is the buyer’s protection; it is the difference between paying for a promise and paying for a result. Do not let a project reach this phase without one having been defined back in scoping.
Reaching production is also where most AI initiatives quietly die across the wider market — the gap between a working pilot and a system trusted to run unattended is where the majority of projects stall. The firms that cross it are the ones that treated verification, integration, and acceptance as first-class parts of the build rather than things to sort out later.
Phase 7: Handoff and Support
The project is not finished when the software works; it is finished when someone is contractually responsible for keeping it working. A small firm cannot maintain custom software itself, so the handoff has to include three things: a plain-language runbook a non-technical person can follow, a named support arrangement with response times, and a defined procedure for when the underlying AI models are updated by their providers, because an update can quietly change behavior. A build handed over as a folder of code with no support model is an orphan waiting to happen. If a partner cannot describe their post-launch support in the first conversation, that absence tells you how the last month of the project will feel.
What It Costs and How Long It Takes
A scoped single-workflow automation commonly delivers in one to three months; larger multi-system builds run four to six months or more. Beware anyone promising a complex build in two weeks — that is a demo timeline, not a system timeline. The calendar risk, again, is rarely the build itself; it is discovery, because the partner has to learn your workflow first.
On price, the market ranges are wide and depend on scope. A hands-on fluency workshop for a small team runs roughly $2,000–$15,000. A scoped custom automation project generally lands between $25,000 and $150,000 as a one-time build, with a single-workflow automation in the lower half and multi-system builds toward the top, plus modest monthly running costs — typically low hundreds of dollars for small-firm volumes — and a support arrangement. Any quote worth taking seriously names the maintenance model and the acceptance test up front; a number without those two things attached is not a real quote.
Who Does What: Your Job vs. the Partner’s
The reason projects surprise buyers is that the phases most responsible for success are mostly the client’s work, not the vendor’s. Here is the honest split.
Your job: supply representative real documents (including the ugly ones), make the person who does the task available for discovery, define what “correct” means, decide what is in and out of scope, run the pilot in parallel, and hold the acceptance test. None of this is technical. All of it requires your time and your judgment about your own business.
The partner’s job: translate your workflow into software, build the verification and exception handling, do the integration, run the proof of concept and pilot honestly, and stand behind a support arrangement. If you are weighing whether to hire an outside firm for this at all, the guide to what an AI agency actually is when a small firm hires one covers how these relationships are structured and what to expect from a good one.
The firms that get the most out of a project are the ones whose team is already fluent with general AI tools before the project starts. Fluency means you recognize a real capability from a wrapper, you can define “correct” precisely because you have done the task with AI by hand, and you can operate and sanity-check the finished system. It upgrades every phase.
When a Project Is the Wrong Answer
Sometimes the most valuable outcome of thinking through the phases is deciding not to do a project yet. A build is the wrong answer when you have not proven the volume — automating a task you do twice a year is a hobby, not an investment. It is also wrong when an off-the-shelf tool already serves the workflow, when the real problem is a fluency gap a workshop could close, or when you cannot yet define what “correct” looks like, which means discovery would fail anyway.
The sequence that works for most small firms is fluency first, off-the-shelf tools for the commodity workflows, and a custom project only for the one or two workflows that prove themselves the bottleneck and that no product serves. Entered in that order, a project tends to ship; entered as the first move, it tends to become the unused login everyone forgets they are paying for.
Frequently Asked Questions
What are the phases of an AI automation project?
Seven, in sequence: discovery (learning your workflow), a proof of concept (proving it can be done on your real data), the build (durable software with verification), integration (connecting to your existing tools), the pilot (running live in parallel with the manual process), production and acceptance (a written test the system must pass before sign-off), and handoff with support (a runbook and a named maintenance arrangement). Smaller projects compress the middle phases; the shape stays the same.
How long does an AI automation project take?
A scoped single-workflow automation commonly delivers in one to three months. Larger builds that cross several systems run four to six months or more. Anyone promising a complex system in two weeks is describing a demo, not a production build. The longest phase is usually discovery, because the partner has to learn how your firm actually works before automating it, and a firm with documented workflows and a fluent team shortens that considerably.
How much does a custom AI automation project cost?
Market pricing for scoped custom automation runs roughly $25,000 to $150,000 as a one-time build, plus modest monthly running costs in the low hundreds for small-firm volumes, plus a support arrangement. A single-workflow automation sits in the lower half of that range; multi-system builds sit higher. A separate fluency workshop for a team runs about $2,000 to $15,000. Any quote should name both the maintenance model and the acceptance test.
What is discovery in an automation project?
Discovery is the phase where the partner learns your workflow in detail before building anything: watching the task done, collecting your real documents including the messy ones, and defining exactly what a correct result looks like. It is mostly your team’s time, not the vendor’s, and it is where the calendar risk in small-firm projects usually hides. It ends with a written scope naming the task, the inputs, the definition of correct, and what is out of bounds.
What is the difference between a proof of concept and a pilot?
A proof of concept is a narrow throwaway version that answers one question — can this be done reliably on your real data — and it is run early and cheaply to kill or confirm the idea. A pilot comes later: the finished system running on live work in parallel with the manual process for a defined period, to prove it holds up day after day and to let your team decide whether they trust it. A proof of concept tests feasibility; a pilot tests durability.
Why do AI automation projects fail?
The common failures are all avoidable: buying a demo instead of a system and discovering it never worked on real data; skipping a serious discovery phase so the build automates a misunderstood workflow; having no acceptance test, so there is no agreed bar for done; and no support arrangement, so the build is orphaned when it breaks. Across the wider market the biggest stall point is the gap between a working pilot and a system trusted to run unattended in production.
Who maintains the automation after it is built?
The partner should, under a written support arrangement, because a small firm cannot maintain custom software itself. A proper handoff includes a plain-language runbook for daily operation, named response times for when something breaks, and a defined procedure for when the underlying AI models are updated by their providers, since an update can change behavior. If a development partner cannot describe their post-launch support model in the first conversation, keep looking.
Should we build custom automation or buy an off-the-shelf tool?
Default to buying for standard, industry-wide workflows and build only for workflows specific to how your firm makes money that no product serves well. Most 4–20 person firms should earn the build case with real volume data first. The staged path — get fluent, buy off-the-shelf for the commodity layer, then build for the one workflow that proves itself the bottleneck — ships more reliably than starting with a custom project. The full cost comparison lives in the buy-vs-build playbook.
What should we do before starting a project?
Get the team fluent with general AI tools on your actual work product, and inventory the workflows where hours disappear. Fluency lets you tell a real tool from a wrapper, define “correct” precisely, and operate the finished system; the inventory tells you which workflow is worth automating first and whether a project is even the right answer versus a subscription. An outside AI-readiness assessment can compress that inventory into a ranked plan in about a week.
Where to Start
The phases only matter once you know which of your workflows is worth automating, in what order, and whether a build is the right path at all. That ranked inventory is the real starting point, and it is what we produce in a free AI-readiness assessment: a working session that maps your firm’s workflows, flags the ones a subscription or a prompt already solves, and returns an honest plan with build, buy, or wait calls for each. Book a free AI-readiness assessment if you want that map for your firm — and if a project is not the right answer yet, the assessment will tell you so, and you will still leave with the plan.
Dirk Jan van Veen, PhD
