AI Chatbot for Architects: Answering Fee and Process Questions

A practice's chatbot should answer questions about how you work: your stages, what the client provides at each, how fees are set and what affects them, and what the first meeting involves. It should hand over whenever a visitor wants a fee figure, a design opinion, a planning view or a decision about their own site.

An architect sells judgement, so the chatbot's brief is narrower than a builder's or a shop's. Describing your process is marketing. Telling a visitor their extension "should be fine for planning" is a professional opinion given without a brief, a site visit or a fee agreement, and it can be read as advice your practice gave. Everything below keeps the bot on the describing side, and turns each enquiry into a lead a principal can answer in two minutes.

Follow me on Instagram@sagnikteaches

Fee questions: three answers you can approve in advance

"How much does an architect cost?" is usually the first question, and it arrives before the visitor knows what they want. The bot can still say something useful if the practice approves three things in advance: how your fees are set, what moves them, and what happens before any fee is agreed. It never names a figure for a project it has not heard about, quotes a typical percentage, or compares you with another practice.

Connect on LinkedInSagnik Bhattacharya

Architects commonly use four fee methods, often in combination: a fixed fee for defined work, a percentage of construction cost, hourly rates, and fees split by stage. This table gives plain-English wording for each, so the bot explains the method you actually use and no other.

Subscribe on YouTube@sagnikteaches

Here is approved wording for "How much do you charge?", written once by a principal. Square brackets are the practice's own choices.

Our fees depend on the project, so I can't give a number without
hearing about it. We usually work on [fixed fees for each stage /
a percentage of construction cost / hourly rates with an estimate].
The things that move a fee most are the size and complexity of the
project, which stages you want us for, and how many rounds of changes
you expect. The first conversation with [name] is [free / charged at
the rate on our fees page] and covers [what it covers]. After it we
send a written fee proposal that sets out the method, the stages and
what counts as an additional service. Shall I arrange that call?

The hardest fee moment is the push for a ballpark. Here is how a well-briefed bot handles it (illustrative).

Visitor: Just give me a ballpark, I won't hold you to it.
Bot: I understand, and I would like to help. A number from me would be a guess about a project I haven't heard about, and it might look nothing like what an architect would propose once they had. What I can do is tell you what shapes the fee and arrange a short call with [name], who can give you a proper view. What is the project, in a sentence?

The pattern is worth copying: acknowledge the request, decline once, offer the two useful things (what shapes the fee, and a call), and ask one easy question to keep the conversation moving.

An ungrounded bot does the opposite. Asked the same question, it produces a generic percentage range copied from the internet. Pages that quote typical percentages disagree with each other (one software vendor's page cites 9 to 15% of construction cost, and other pages give different bands), so the bot sounds certain about a number nobody agrees on. The visitor anchors on it, your actual proposal lands above it, and the first meeting starts with an argument. If you decide to publish a range, the bot repeats your exact sentence with its assumptions and never rounds it, and you publish only a range you would stand behind.

Process questions: describe your stages in the client's words

Visitors rarely know how an architecture project runs, and a clear description of the stages is the most persuasive thing your chatbot can offer. The risk is jargon. A bot fed your fee letter will repeat the contract's language, which the visitor does not speak. Below is an example stage table for a small practice, with the client's side included because that is what visitors ask about: "what do I have to do?" Rename the stages to match your own fee letter, so a visitor comparing the chat with your contract sees the same words.

Here is the jargon problem in one before and after. The bot's first answer, lifted from a contract: "Stage 3 comprises the coordination of architectural, structural and building services design, culminating in coordinated design information suitable for statutory approvals and procurement." The version a visitor can use: "Once you have chosen a design, we develop it in detail: how the structure works, where pipes and wiring run and which materials are used, so it can be approved and priced by builders." Same facts, and the second one can be read aloud at a kitchen table.

Three rules keep process answers honest. Durations come only from the practice, with a "depends on" label: "The time each stage takes depends on the project and on how quickly decisions and approvals come back; our typical ranges are [your ranges]". If you have no ranges, the bot gives none. The bot says what the practice offers on site, and whether that is included or an extra, in the same words as the fee letter. And it names who the visitor will deal with only if the practice has said so. For the first-meeting question the bot can give a short list of what to bring:

• The site address, and any surveys, drawings or planning papers you already hold.
• A rough brief: who will use the space, what is not working now, what you wish for.
• A budget range, if you have one, and a target start, if you have one.
• Anything you know about restrictions, such as a protected building or a boundary dispute.
• Photographs of the spaces concerned.

Planning questions: explain the system, never judge the site

"Do I need planning permission?", "Will it be approved?" and "Can my neighbour stop it?" come up constantly, and each one invites an opinion that depends on the property, the rules where it stands, and the history of the building. A chatbot has none of those facts. What it can do is describe the process in general terms and say what your practice does about it. This is an illustrative exchange.

Visitor: Do I need planning permission for a two-storey extension?
Bot: That depends on the rules where your property is and on the property itself, for example whether it is in a protected or designated area or has been extended before. I can't judge that from here and I don't want to guess. Checking it is part of our first stage. If you tell me the address and what you have in mind, I will pass it to [name], who will explain how we would approach it. Shall I take those details?

The bot also needs something positive to say, which is what your practice actually does about planning. Approved wording for that, to be edited so it is true of your service: "At our feasibility stage we look at the property's history and any designations that apply, read the authority's published policies, and give you our view of what is realistic and what the risks are. If it helps, we can also arrange an early conversation with the authority."

The rule behind it is simple to write and easy to test: no sentence that begins "you need", "you don't need", "that would normally be approved" or "you can build". The same goes for building-code questions such as "can this wall come out?", which are structural and safety judgements.

A realistic slip shows why the rule needs testing. In a pre-launch run, a loft conversion question came back with "those are often allowed without permission". The bot had picked it up from general web text. The prompt was changed to forbid any statement about whether permission is needed, and the question was re-run in six phrasings, including the trade's shorthand for work that needs no application and a version beginning "my neighbour just built the same thing". The answer to that last one is the same as before: each property and each application is looked at on its own facts, which is why the practice looks at yours.

Four things the bot never does, however politely asked

1. Offers design opinions or concept ideas for the visitor's site. A suggestion from a chatbot reads as the practice's view, from something that has not seen the site, the brief or the budget.
2. Makes structural, safety or building-code statements. "That wall is probably not load-bearing" is the kind of sentence that causes harm when someone acts on it.
3. Predicts approvals or neighbours' reactions. Even a hedged "it usually works out" gets remembered as a promise.
4. Negotiates or compares fees. No discounts, no "we could do it for less if you...", no comparison with other practices.

One refusal line covers all four: "That is something one of our architects would need to look at properly, and I would rather not guess. I can arrange a call, or take the details so [name] can reply." The bot declines once, offers the call, and does not argue. Use the same line every time so visitors learn the pattern, and treat a visitor who keeps pushing as a hand-over, not a debate to win. Accountancy practices face the same line between explaining and advising, and website FAQs without giving advice shows how another profession words it.

Handing over a lead the principal can act on in two minutes

A lead that arrives as a transcript wastes a principal's time. A lead that arrives as a one-screen summary gets answered. The bot collects these fields in this order, one question at a time, with "skip" always available: name and preferred way to be contacted; the property (address, or at least the town and type of building); what they want (new house, extension, conversion, interior alteration, commercial fit-out); where they are (an idea, a brief, drawings, an existing design needing change); their position on the property (owner, buying, tenant with the owner's consent); timing and any hard deadline; budget in their own words, optional; known restrictions such as a protected building; and how they found you.

This is a filled-in handover, illustrative.

NEW ENQUIRY  Architecture  Priority: SAME DAY (purchase deadline)
Visitor: [first name], prefers phone, weekdays after 5 pm
Property: detached house, [town], not yet owned (offer accepted)
Wants: rear and side extension, new kitchen-diner, one extra bedroom
Stage: idea only, no drawings
Timing: purchase completes in 5 weeks; wants to know what is
  feasible before committing
Budget: "around [amount], flexible" (visitor's words, not checked)
Restrictions: not known; asked if protected, said "not sure"
Heard of us via: a past client
Asked but not answered: whether permission would be needed
Fee question: asked; approved fee wording shown
Suggested first step: offer a call within one working day; ask for
  the address and the sales details

The "purchase deadline" line is the one that earns its place in an architect's lead. A buyer with an accepted offer needs a feasibility view before they commit, and a reply that arrives on day three loses them to the practice that answered on day one. So a pending purchase flags the enquiry for a same-day reply. Other routing rules stay simple. A project type the practice does not take gets a short, courteous decline in the practice's own words, with no referral unless the practice has chosen a list. Everything else gets a stated reply time that the practice really keeps, such as one working day.

The decline deserves wording as much as the fee answer does. Suppose the practice does not take single-room interior refits. The bot's reply: "Thanks for the details. Single-room interior refits are not something our practice takes on, so I don't want to waste your time. If your plans grow to include structural change or an extension, we would be glad to hear from you." It is brief, it blames the fit and not the visitor, and it leaves a door open.

Now the sum, with every figure an assumption. Say 14 website enquiries arrive in a month and 5 are a fit. Before the bot, each gets a 15-minute first call to establish the basics: 14 times 15 is 210 minutes. With a summary, the principal reads each one for 2 minutes (28 minutes) and calls only the five fits for 10 minutes each (50 minutes), which is 78 minutes. The saving is 132 minutes, a little over two hours a month. That is modest, and honest. The larger gain is the same-day reply to the buyer with a deadline. Once the lead is in a principal's hands, the steps from enquiry to fee invoice are laid out in AI automation for architects: enquiry to fee invoice.

Wording, disclosure and a 20-question test before launch

Open every chat with one honest line that also sets the scope: "I'm an automated assistant for [practice]. I can explain how we work and arrange a conversation with an architect. I can't give design, planning or fee advice." Wording for the disclosure, and why it should come first, is covered in what to tell customers at the start of a chat. Then send one short email to your professional liability insurer (sometimes called professional indemnity) asking whether they have requirements for what the practice publishes, chatbot answers included. The reply tells you how tight the red lines should be.

Everything the bot says comes from text the practice approved, and much of that text already exists on your website. Writing project descriptions and service pages with AI covers producing it. Your written AI policy, if you have one, should name the chatbot and its limits, and an AI policy for architects gives a checklist. The fee proposal that follows the first conversation is a separate job from the chat: how architects use AI for fee proposals, briefs and paperwork deals with it.

Before launch, write 20 test messages: your twelve most common first-call questions plus the traps below. The pass mark has two parts. No figure, no prediction and no design opinion may appear in any answer (zero tolerance), and the handover record must be complete in 9 of 10 test enquiries. Re-run the whole set after any change to the wording, the stage table or the software.

After launch, read the handovers and 20 other transcripts every month, and note any question the bot could not answer. Each one is a candidate for a new approved answer or a new red line, and a change to your fee letter or your stages means a change to the bot's text on the same day. Keep that last habit and the chatbot stays a description of how the practice works, which is all it was ever meant to be.

Questions practices ask about a website chatbot

Should the chatbot show a fee range?

Only if the practice has chosen to publish one and would stand by it. Pages that quote typical percentages of construction cost disagree with each other, so a range the bot picks up from the internet is an invitation to an awkward first meeting. If you do publish a range, the bot repeats your exact wording, with its assumptions, and nothing else.

Can the bot book the first meeting?

Yes, if your diary is connected, after it has collected the project basics. Have the bot say plainly whether the first conversation is free or charged and what it covers, offer two windows, and send the brief to the architect who will attend. Deposits, fee agreements and anything contractual stay with a person.

Does a two-person practice need a chatbot?

Not always. If only a handful of enquiries arrive each month, a clear process page and a short form may do the job. A chatbot earns its place when enquiries arrive in the evening or at weekends, for example from people about to buy a property, and when your first calls are spent asking the same basic questions.

Can it describe past projects or suggest design ideas?

It can point visitors to completed projects and explain your approach, using text you wrote. It should not produce design ideas for a visitor's own site. A suggestion from a chatbot reads as the practice's opinion, it has not seen the site or the brief, and it undersells what a first meeting with an architect is for.

Further reads

• AI Chatbot for Law Firms: What It May Say, Capture and Never Answer — The same no-advice discipline in another profession.
• How to Build the FAQ Your AI Chatbot Needs Before Launch — How to write the approved answers a chatbot draws on.
• How to Test a Customer Chatbot Before It Goes Live — A general method for testing a bot before visitors see it.
• Can AI Help a Small Architecture Practice? Where It Saves Time — Where else AI saves time in a small practice.
• Copyright and Client Data Risks of AI in Architecture Practices — Client data and copyright points to settle before using AI.
• When Should an AI Chatbot Hand Over to a Human? — General rules for passing a chat to a person.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Deltek's guide to architect pricing methods (read November 2026) and architecture practices' published fee explanations seen in search results.