AI for Architecture Practices: Where the Admin Time Actually Goes

Most architecture practices do not have an admin problem. They have a coordination problem that shows up as admin. The drawing work is the part everyone trained for; the hours quietly disappear into the correspondence around it.

If you run a small or mid-sized practice, you already know the shape of it. Somebody has to build the fee proposal. Somebody has to notice the council has come back with a request for information. Somebody has to work out whether the structural engineer or the building surveyor is holding up the set this week. None of that is design, but all of it has to happen before design can be issued.

This is a look at where those hours actually go in a practice, and which parts of it a custom system can take over without putting your professional judgment at risk.

Fee proposals take longer than the work they describe

A fee proposal for a residential alteration is not a complicated document. It is a scope, a set of stages, a rate card, an exclusions list, and a number. The reason it takes half a day is that every one of those parts lives somewhere different.

The scope comes from a conversation you had on site and half-remember. The stage breakdown comes from a template that was last updated two projects ago. The number comes from comparing this job to a similar one you did eighteen months back, which means opening old files to remember what you charged and whether it turned out to be enough.

The automatable part is the assembly, not the pricing. A system can pull your rate card, your standard stage descriptions, your current exclusions, and a shortlist of genuinely comparable past projects with what they were quoted and what they actually cost to deliver. What comes back is a first draft with the numbers already populated and the comparables sitting next to them.

You still set the fee. You are just no longer rebuilding the document each time to get to the point where you can set it.

Planning submissions run on chasing, not lodging

The lodgement itself is a defined process. The work is everything that leads up to it and everything that follows.

Every planning submission carries a document checklist, and the items on it arrive from different people at different times. A survey from the surveyor. A report from an arborist or a traffic consultant. Owner details and title documents from the client, who is not thinking about your deadline. Then the council comes back with a request for further information and a date, and the clock restarts on a smaller version of the same process.

What a system handles well here is state. It knows which items on the checklist have arrived, which are outstanding, who owes each one, how long they have been outstanding, and what the statutory date is. It sends the reminder before you have thought to send it, in your wording, and it escalates to you only when a date is genuinely at risk.

The value is not that it writes the email. It is that nobody has to hold the checklist in their head.

Consultant coordination is a communication job

On a typical project you are coordinating a structural engineer, a civil engineer, a building surveyor, sometimes a landscape architect, a hydraulic consultant, and an energy rater. Each one needs something from someone else before they can issue, and you are the switchboard.

Most practices run this on memory and a spreadsheet that goes stale within a fortnight. When it fails, it fails in a specific way: the set goes out with a clash nobody caught, or an issue is delayed a week because one consultant was waiting on a file another consultant had already sent to a different address.

A coordination system holds the dependency map. Who owes what to whom, by when, at which stage. It notices when a consultant has gone quiet past the point where that is normal, and it can assemble the issue register for a coordination meeting without anyone spending the evening before compiling it.

This is the area where practices are most sceptical, and reasonably so. The relationships are personal and the judgment calls are yours. The system should be doing the record-keeping and the prompting, not making the calls.

Contract administration buries the project record

During construction the volume changes character. Requests for information, variations, progress claims, site instructions, photographs, and a great deal of email. All of it is contractually significant and most of it is stored as correspondence rather than as a record.

Six months later somebody asks when a variation was approved and on what basis. Answering that means searching an inbox.

The useful automation here is capture. Each RFI, variation and claim gets logged against the project as it happens, with its date, its author, its status, and the decision. Progress claims get checked against the schedule of values before they are certified. The project record assembles itself as a by-product of the work rather than as a separate task nobody has time for.

What we would not automate

It is worth being direct about the limits, because the industry conversation tends to skip them.

Do not automate the design judgment. Generative massing tools have their place in early exploration, but nothing in this category should be making decisions that carry your registration.

Do not automate code compliance as though it were settled. Automated checking is useful for finding candidates for review. It is not a substitute for the review, and treating it as one transfers risk to you.

Do not automate client communication that needs a human. A system should draft and prompt. When a client is unhappy or a project is in trouble, the response should come from a person who understands the relationship.

The pattern that works is narrow and boring: automate the assembly, the tracking, and the chasing. Keep the judgment.

What this looked like in a real practice

SQM Architects, a Melbourne practice, came to us running three separate subscriptions that between them handled parts of enquiry management, project tracking and reporting. None of the three talked to the others, so the joins were done manually, and the manual joins were where the time went.

We replaced the three with one system built around how the practice actually worked. The measurable outcome was more than $18,000 a year in subscriptions no longer being paid and over 40 hours a month of administrative time returned to the practice. The build paid for itself inside twelve months.

The part worth noting is that none of it was clever. It was three tools becoming one system, and a set of handoffs that used to require a person no longer requiring one.

Where to start

Start with the task your team complains about most, and check whether it meets three conditions. It happens often enough to matter. It follows rules you could write down. And getting it wrong is recoverable.

Fee proposal assembly usually qualifies. Document chasing on submissions usually qualifies. Contract administration logging usually qualifies. Design decisions never do.

If you want a second opinion on which of your workflows are worth the effort, that is what our assessment is for. You get a written Automation Map naming the three highest-value automations in your practice, and it is yours to keep whether or not you build anything with us.