Run three pilots over 90 days: meeting minutes, fee proposals and site reports. Give each a named lead, a baseline measured beforehand, two KPIs (time taken and corrections needed) and a go or stop rule written in advance. Owner time peaks at about 90 minutes a week. Judge the tools on time saved and errors caught, not on design quality.
The usual failure is starting without a baseline, so nobody can say afterwards whether the tool saved anything. The second is using client-identifiable material before the data rules exist. This plan spends the first two weeks on both, then staggers the three pilots so one person can supervise them without it becoming a second job.
The 13-week calendar and who gives how much time
Each pilot runs six weeks and starts two weeks after the one before it. That overlap is deliberate: the lead of the first pilot can tell the second what went wrong, and it means the owner meets one new problem at a time. Week 13 is the decision meeting.
| Weeks | What happens | Suggested lead |
|---|---|---|
| 1 to 2 | Data rules, one tool set up, three baselines logged | Practice manager |
| 3 to 8 | Pilot A: meeting minutes | Project architect or practice manager |
| 5 to 10 | Pilot B: fee proposals | A principal |
| 7 to 12 | Pilot C: site visit reports | A project architect |
| 13 | Decision meeting: go, change or stop for each pilot | The owner |
The owner's time is a 30-minute weekly pilot review plus 20 minutes of quality sampling for each pilot that is running. With all three running in weeks 7 and 8, that peaks at 30 + (3 x 20) = 90 minutes. In weeks 3, 4, 11 and 12 only one pilot is running, so it is 50 minutes; in weeks 5, 6, 9 and 10 it is 70. Weeks 3 to 12 therefore add up to 660 minutes, or 11 hours. Add about two hours across the two setup weeks and two more for the week 13 decision meeting, and the quarter costs the owner roughly 15 hours, which you can multiply by your own hourly cost. If that is more than you can give, run Pilot A alone first and start the others next quarter.
Weeks 1 and 2: data rules, one tool and three baselines
Do not touch a pilot until three things are settled: what may go into the tool, which tool it is, and what you are comparing against.
What may go in
For the pilot, allow only your own non-confidential documents and client material that has been redacted: client names, addresses and contact details replaced with placeholders, fee figures left out unless the pilot needs them. Read your appointment terms for confidentiality clauses first. The pilot is not the place to discover that a client's terms forbid third-party processing. If you have no written rules yet, a ready-to-use AI policy checklist for architects gives you clauses to start from. Ask your professional indemnity or liability insurer, too, whether AI use needs disclosing.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowOne tool, on a business plan
Choose one general assistant and use it for all three pilots, so the results compare like with like. Pick a business plan rather than personal accounts, because business plans are where content is not used for model training by default. Claude's Team plan, for example, is for teams of 2 to 150, with a Standard seat at $25 a month or $20 a month on annual billing (read on its pricing page in November 2026), and ChatGPT Business lists a similar $25 monthly, $20 annual seat. Three seats on monthly billing is 3 x $25 = $75 a month, or $225 over the quarter. Which assistant suits an architect is a separate question; for the pilot it matters more that you pick one and stick to it.
Three baselines, logged for two weeks
While the tool is being set up, log how the work is done today. Time spent means honest elapsed working time, not billable time, and it includes the review. Use a plain spreadsheet with one row per document.
| Task | Log this | Illustrative baseline |
|---|---|---|
| Meeting minutes | Hours from meeting end to issue; corrections found at review | Median 3.2 hours; 2.4 corrections a set |
| Fee proposal | Total drafting and review hours; edits the principal makes before sign-off | 5.5 hours; 3.1 edits a proposal |
| Site visit report | Hours from visit end to issue; errors found at review | 2.8 hours; 1.2 errors a report |
You need at least five examples of each, which may mean looking back over recent files and asking colleagues to estimate. An estimate is better than nothing, but a logged figure is better than an estimate, so start logging now. Corrections on human-written documents are worth counting too: a senior colleague's markup on a trainee's minutes is a correction, and the pilot should not be held to a standard the current process does not meet.
Pilot A: meeting minutes (weeks 3 to 8)
Minutes make the best first pilot. Every output is checked by someone who was in the room, and the finished document is short. The set-up has four parts: agree recording with the attendees, produce a transcript, paste the transcript into the assistant with your house layout, and have the project architect review it against the transcript before issue. Tell everyone at the start that the meeting is being recorded and transcribed. Some clients will say no, so keep a fallback where the lead types rough notes and pastes those instead. Which meeting tools can transcribe depends on your plan, so check before you promise anyone a transcript. The detail of recording and issuing minutes the same day is in architect meeting minutes with AI.
The two KPIs are median hours from meeting end to issue, and corrections per set, counted by severity (the scale is below). Add one weekly spot check: play five minutes of one recording and confirm the minutes caught every decision and action in that stretch.
Write meeting minutes from this transcript using this layout: attendees and apologies; decisions made (numbered); actions (table: action, owner, due date, transcript line); matters for information; date of next meeting.
Rules: record an action only if someone accepted it. Where an owner or date was not stated, write "TBC". Keep names as they appear in the attendee list. Mark anything tentative as "for discussion", not as a decision. Add nothing that is not in the transcript.
Attendee list: [list]
Transcript: [paste]A realistic first-week output has two faults. It records "contractor to confirm window delivery date by Friday" as an action, when in the transcript the project architect said she would ring the supplier herself. And it lists the stair balustrade as "agreed", when the client said "let's look at it next week". Tentative talk turned into a decision is the most common minutes error, and the "mark anything tentative as for discussion" rule in the prompt exists because of it. Each of these is a major correction: a wrong owner or a false decision.
After six weeks and 12 meetings, the illustrative log reads like this. Median time to issue fell from 3.2 hours to 1.1, which is (3.2 - 1.1) / 3.2, about 66% shorter. Corrections fell from 2.4 a set to 1.3, with no critical errors. Against the rule written in week one (time down at least 40%, corrections no higher than baseline, no critical errors), Pilot A is a go.
Pilot B: fee proposals (weeks 5 to 10)
Fee proposals carry the most commercial risk of the three, so the rule is strict: the assistant drafts words, never numbers. The principal sets the fee the way they always have, in a spreadsheet, and the assistant writes the scope, stage deliverables, assumptions and exclusions around it. Collect two or three past proposals for similar jobs, remove client names and fees, and use them as the house examples. Feed in the enquiry in redacted form, the final fee table and your standard exclusions list. For the wider workflow around briefs and paperwork, see how architects use AI for fee proposals, briefs and paperwork.
Draft the scope, stage deliverables, assumptions and exclusions sections of a fee proposal for the project described below. Follow the structure and tone of the two example proposals.
Rules: use only the facts I give you; where something is not given, write [to confirm]. Reproduce the fee table exactly as I give it; do not calculate, round or restate any figure. List every exclusion from my standard exclusions list and add none of your own.
Project: [redacted description]
Fee table (final, from my spreadsheet): [paste]
Standard exclusions list: [paste]
Example proposals: [paste two, redacted]The KPIs are drafting hours per proposal, edits made at the principal's sign-off (by type: scope omission, wrong exclusion, tone, figure), and exclusions found missing after issue, which should be zero. A typical slip is a figure in the narrative that no longer matches the table. Suppose the fee table gives stage fees of $5,700, $9,500, $15,200 and $7,600, which sum to $38,000. The draft's narrative says "Stage 2 fee of $9,200". Taken at face value the stages would now sum to $37,700. The check is mechanical: search the draft for every dollar sign and tick each figure against the table.
The illustrative result after six proposals is mixed. Drafting time fell from 5.5 hours to 3.9, about 29% less, but principal edits rose from 3.1 to 4.8 a proposal, mostly duplicated assumptions and one missing exclusion. The rule for this pilot was time down at least 30% with edits no higher than baseline, so it fails on both counts. That is a change result: shorten the prompt, cap the assumptions list at eight, and retest next quarter on fresh proposals.
Pilot C: site visit reports (weeks 7 to 12)
After the visit, the architect dictates a three to five minute voice note while walking the site, saying the photo number and the drawing reference for each point. Upload the numbered photos and the transcript, and ask for a report in your house layout. Two limits shape the set-up. Anthropic's upload page (updated 23 July 2026) gives Claude chats up to 20 files each, in JPEG, PNG, GIF or WebP, and its vision guide adds a limit of 10 MB per image on claude.ai, so a 35-photo visit needs two chats or a choice of the 20 that matter. And neither assistant sees where a photo was taken: Anthropic's vision guide says Claude does not receive image metadata, and OpenAI's developer guide says its models do not process original file names or metadata. Never rely on a file name or location data to place a photo. Say it in the voice note: "photo 7, north gable, first-floor brickwork".
The KPIs are hours from visit end to issue, errors per report (an observation attached to the wrong location, drawing or photo), and caption mismatches. A fuller routine is in architect site visit report: notes and photos to a clear report.
Write a site visit report from my voice-note transcript and the numbered photos. Layout: visit details; observations grouped by location, using the drawing references I give; actions for the contractor (table: action, drawing reference, photo number); items for the client; photo log (number, caption).
Rules: caption each photo only with what I said about it; if I did not mention a photo, write "no comment recorded". Do not state that work complies with the drawings or the specification: record what I observed and nothing more. Use [to confirm] for anything unclear.The risky sentence in an unprompted draft is "the brickwork complies with the specification". The architect never said it, and in a report on professional letterhead it reads as an assurance. That is why the second rule in the prompt exists, and why the reviewer searches every draft for "complies", "satisfactory" and "in accordance with". A second realistic fault: the photo log captions photo 12 as "north gable" where the architect said "south gable". The weekly photo check catches this by opening five photos and reading their captions aloud.
After six weeks and nine reports, the illustrative log shows time from visit to issue falling from 2.8 hours to 1.6, about 43% shorter, and errors per report moving from 1.2 to 1.1. One draft contained a "complies" statement, caught at review and never issued, which was logged as a major correction and answered with a new rule. Against the pilot's rule (time down at least 30%, errors no higher than baseline, no critical errors) it is a go.
Measuring quality without creating a second job
A pilot dies when measuring takes longer than doing. Keep the log to one spreadsheet with one row per document: date, pilot, document, minutes spent, corrections by severity, and a note. The severity scale does most of the work, so write it on the first page of the sheet.
| Severity | Meaning | What happens |
|---|---|---|
| Minor | Wording, layout or tone; no change to meaning | Fixed at review and counted |
| Major | A wrong fact, figure, name, owner, location or drawing reference, corrected before issue | Counted; two in one document means the whole document is rechecked |
| Critical | Anything that left the practice wrong, a contractual or professional assurance nobody gave, or confidential material in the wrong tool | Pilot paused until the cause is fixed and the owner agrees to restart |
Each week, the lead of each running pilot picks three outputs at random and re-checks them against the source: 20 minutes, which is the quality sampling already counted in the owner's time. Three is deliberately small. It will not prove accuracy, but it catches a drift in behaviour, and a worrying result triggers a larger sample. An example row: "Week 6, Pilot A, progress meeting 14, 48 minutes, 0 minor, 2 major (owner, tentative decision), 0 critical, balustrade recorded as agreed."
The KPIs here are about the tool: time taken and errors made. They say nothing about whether the practice wins better work or designs better buildings, and in 13 weeks they cannot. Keep claims to what the log shows, and keep revenue and design quality out of the decision.
The go or stop rule, written before you start
Write the thresholds in week one, before anyone knows the results, and keep them in the same spreadsheet. A rule written after the fact bends to fit the data. The sheet below is the illustration carried through the three pilots.
| Pilot | Rule for a go | Result | Decision |
|---|---|---|---|
| A: minutes | Time down 40% or more; corrections at or below baseline; no critical | Time down 66%; 1.3 a set against 2.4; no critical | Go |
| B: fee proposals | Time down 30% or more; edits at or below baseline; no critical | Time down 29%; 4.8 edits against 3.1 | Change, retest next quarter |
| C: site reports | Time down 30% or more; errors at or below baseline; no critical | Time down 43%; 1.1 errors against 1.2; one "complies" caught at review | Go, with the "complies" search kept |
Three outcomes are enough. A go means the pilot becomes normal practice with sampling cut to once a month. A change means time may be saved but quality has not held, so adjust the prompt or the review step and retest on fresh documents. A stop means a critical error that no rule can prevent, or savings under 15%, or a review step that costs as much as the work it checks. A stop is a perfectly good result for a pilot: it cost 13 weeks and a few seat fees, and it saved you from rolling out something that did not work.
What the 13 weeks cost
The money is small; the time is the real cost. Three business-plan seats on monthly billing come to $75 a month, so $225 for the quarter, or $180 if you take annual billing at $20 a seat and can commit. Add the owner's roughly 15 hours and the leads' time on the pilots themselves, which is meant to be time they would have spent on the same documents anyway. At an illustrative internal cost of $100 an hour, the owner's 15 hours is $1,500, so the whole experiment sits at under $2,000 even before counting the saved hours. The comparison that matters is the one at the end: hours saved a month on the pilots that pass, times your internal hourly cost, against the monthly seat bill.
Two practical points keep the cost down. Use one tool, because a second subscription doubles the setup, and the data rules, and the confusion. And do not buy annual plans until the decision meeting; the saving from annual billing is not worth being locked in to a tool that failed the pilot.
What changes after day 90
A pilot that passes becomes ordinary practice, not a permanent experiment. Cut the quality sample to once a month, keep the severity scale, and re-run a short baseline whenever you change tool or version, because a new model can behave differently from the one you tested. For a pilot that needs changes, put the retest on the calendar with a date, or it will quietly lapse. For a pilot that stops, record why in two lines, so the next person to suggest it can read the reason.
Keep the hours and the errors separate when you report to partners. "Minutes now take a median 1.1 hours to issue, against 3.2 before" is a claim the log supports. "AI improved our service" is not. If the pilots pass and you want the next candidates, setting success criteria that hold up shows how to set thresholds for other jobs. If you would like a second pair of eyes on the pilot design before you start, that is what my AI implementation consultation is for. A general first pilot for any small business is described in how to run your first AI pilot project.
Questions about running the pilot
How many people does a pilot like this need?
One lead per pilot, one owner who reads the weekly 30-minute review, and the staff who already do the task. In a firm of five, the practice manager can lead minutes, a project architect can lead site reports and a principal can lead fee proposals. The same person can lead two pilots if the weeks do not clash.
Should the pilot use live client project data?
Not until your data rules are written. Start with redacted material and your own non-confidential documents, replace client names and addresses with placeholders, and read your appointment terms for confidentiality clauses. Then widen to live projects one pilot at a time, with the lead sampling outputs every week.
What if the pilot saves time but adds corrections?
That is a change result, not a go. Look at what kind of corrections they are: wording fixes are cheap, wrong figures or missing exclusions are not. Change the prompt or the review step, retest for four weeks on fresh examples, and stop if corrections stay above your baseline.
Do we need to tell our insurer about the pilot?
Check your appointment terms and your professional indemnity or liability policy before using any client information, and ask your broker whether AI use needs disclosing. Some practices add a line to the appointment letter. That is a question for your insurer and adviser; the pilot cannot settle it for you.
Further reads
- How to Review an AI Tool After 90 Days: Keep, Fix or Cancel — Keep, fix or cancel a tool once the 90 days are up.
- How Much Does AI Cost a Small Architecture Practice per Month? — What AI costs a small practice each month.
- Architecture Firms Adopting AI Design: What to Tell Your PI Insurer — What to tell your professional indemnity insurer.
- What AI Is Good for Architects? Six Jobs for a Small Practice — Six jobs worth piloting after these three.
- Claude vs ChatGPT vs Gemini for Architects: Which to Pay For — Which assistant to pay for during the pilot.
- How to Pilot AI in Shadow Mode Before Customers See It — Run a tool alongside the old process first.
- How to Use Claude AI in Architecture: Specs and Planning Reports — A fourth pilot: specification and planning summaries.
- AI Consultant for Architects: What a First Engagement Costs — Seven consultant days priced deliverable by deliverable for a ten-person practice: audit, policy, one workflow, team session and a 30-day check.
- AI Training for Architects: What a Practice Workshop Covers and Costs — A half-day AI workshop agenda for an architecture practice, modules by role, and the cost per person once staff time is counted, set against self-taught routes.
- AI Tools for Architects 2026: A Toolkit From Brief to Handover — Which AI tool to use at concept, design, tender, site and handover, what each costs on its own pricing page, and three stacks for a five-person practice.
- How to Use AI in Architecture Design: Concept Options for Small Practices — A concept workflow for small architecture practices: a numbered brief register, planning limits with page references and a brief check after every AI step.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Claude's pricing page, file-upload help page and vision guide, and OpenAI's developer image guide, read in November 2026; ChatGPT Business seat prices as checked in late October 2026. The figures in the worked pilot are illustrations, not results from a real practice.