On this page
Most of the questions a city or park district receives are not hard. What time does the pool open. Where do I pay a water bill. Is the lot at the trailhead open in winter. Can I still register for the autumn session. The answers exist, usually on a page somebody wrote carefully, and residents phone anyway — because finding the page is harder than dialling the number.
That gap is what an AI assistant is meant to close. It is also why so many of them disappoint. An assistant does not create answers, it retrieves them. Put one in front of a website whose content is thin, out of date or contradictory, and it will relay thin, out-of-date and contradictory answers faster than the website did.
What is an AI chatbot in a local government context?
Software that answers a resident’s question in their own words, drawing on a defined set of approved sources — your website pages, your documents, your published policies — rather than on general knowledge of the world. The defining feature is not the conversation. It is the boundary around what it is allowed to answer from.
That distinction matters more than the technology does. A general-purpose assistant trained on the open internet can write a convincing paragraph about your refuse collection schedule without ever having seen it. A grounded assistant can only tell a resident what your own published content says, and should say plainly when that content does not cover the question.
The words that get used interchangeably
- Chatbot
- Historically a scripted system: fixed buttons and decision trees. Reliable, and limited to the paths somebody built in advance.
- AI assistant
- Answers questions phrased freely, by finding and summarising relevant content. Handles the wording it was never shown.
- Grounding
- Restricting an assistant to a defined set of sources, so its answers come from your content rather than from general knowledge.
- Hallucination
- A fluent, confident answer that no source supports. The failure mode that matters most in public service, because it is not obviously wrong.
- Handoff
- What happens when the assistant cannot answer: a phone number, a form or a named team, rather than an apology.
- Smart search
- Search that understands intent rather than matching keywords. It returns pages; an assistant returns an answer. Both can be useful, and they are not the same thing.
Why a general-purpose chatbot is the wrong starting point
Procurement conversations usually open with capability and should open with constraint. The question is not what the assistant can discuss. It is what it may discuss.
- Fees, hours, deadlines and eligibility change. An assistant answering from anything other than your current published content will be wrong at exactly the moments accuracy matters.
- A resident has no way to tell a sourced answer from an invented one. Both read equally well.
- Public agencies are held to what they publish. An answer given by your website is, to the person who received it, something your agency said.
- The content most worth answering from — fee schedules, registration windows, permit requirements — is often locked inside documents the assistant has to be able to read in the first place.
What city staff should ask before buying one
Most of these are answerable inside a demonstration, and most vendors are never asked them.
- Ask it a question your website does not answer.A good assistant says so and hands off. A poor one produces something plausible.
- Ask it something whose answer is inside a PDF.This tells you whether your document library is in scope or invisible to it.
- Ask the same question three ways, including one with a typo.Residents do not use your vocabulary. "Bin day", "refuse schedule" and "garbage pickup" are one question.
- Ask about something seasonal that changed recently.It shows how quickly an edit to the underlying page reaches the answer.
- Operate the whole thing with the keyboard, then with a screen reader.It is part of your website and carries the same obligations as the rest of it.
- Ask where the answer came from.An assistant that can name the page it used is one your staff can check and correct.
Which questions should an assistant handle?
Anything factual, published and frequently asked. Not anything that requires identity, judgement or a system of record. Scope is a policy decision rather than a technical one, and it is worth writing down before launch rather than discovering it afterwards.
| Kind of question | Assistant | Why |
|---|---|---|
| Hours, locations, closures | Answer directly | Factual, published, and changeable enough that people check. |
| Fees and registration windows | Answer, with the source page | The resident will act on it, so they should be able to verify it. |
| How to apply for something | Answer and link the form | Collapses three levels of navigation into one reply. |
| Status of a case or payment | Hand off | Requires identity and a system of record. An assistant guessing here is worse than useless. |
| Anything with legal consequence | Hand off | Permits, code enforcement, appeals. Name the team and let a person answer. |
| Emergencies | Hand off immediately and prominently | Never let a conversational interface sit between somebody and emergency services. |
| Complaints | Capture and route | A complaint is not a question. Take it, and get it to someone. |
What an assistant will not fix
An assistant is a retrieval layer over your content. It inherits every property of that content, including the unflattering ones.
- Where two pages disagree about a fee, the assistant will pick one, and nobody will know which.
- Where a page was last reviewed three years ago, the assistant will answer from three years ago with complete confidence.
- Where the answer exists only in a scanned document, there is nothing to retrieve. An image of a page has no text in it.
- Where the answer was never written down at all — the thing everyone at the front desk simply knows — no assistant can retrieve it.
Who owns the answers?
An assistant publishes on behalf of the agency, continuously, without anyone reviewing each answer first. That needs the same governance as anything else you publish.
- Name an owner — usually communications, the team that already owns website content.
- Define the sources it may use, in writing, and revisit that list whenever the website changes shape.
- Read the transcripts weekly at first. Not for volume, but for the questions you did not expect.
- Set a correction route, so a staff member who sees a wrong answer can get the underlying page fixed the same day.
- Tell residents what they are using and how to reach a person. Disclosure is not a formality; it is what makes the handoff believable.
- Review the scope quarterly. The boundary that was right at launch will not stay right.
Where SmartBot fits
SmartBot is SmartRoots’ assistant for resident questions. It responds using your approved website content, documents and knowledge sources — which is the grounding boundary this article argues for, rather than an optional extra on top of it.
Two things follow from that, and both are worth stating plainly. It is available beyond office hours, which is when a great many resident questions are actually asked. And it reports back on what people ask, which is where your content gaps become visible — often the more valuable of the two.
Frequently asked questions
Will an AI assistant replace our front desk?
No, and a vendor who says otherwise is selling something. It removes a share of the repetitive questions so the desk can spend longer on the ones that need a person. The volume it takes is real; the judgement it cannot take is equally real.
What if it gives a resident the wrong answer?
Treat it as you would a wrong answer on a web page: correct the source rather than the symptom. This is precisely why grounding matters — if the assistant answers from your pages, a wrong answer points straight at a page you can fix.
Do we have to tell people it is not a person?
Yes, and you should want to. Residents behave differently when they know, and the handoff to a human is only credible if the distinction was clear from the start.
Does it need to be accessible?
It is part of your website, so it carries the same obligations: keyboard operable, announced properly to a screen reader, readable at high zoom, and never relying on colour alone to convey anything. Ask to see this in the demonstration rather than writing it into the contract and hoping.
What about residents who do not speak English?
Assistants generally handle other languages better than site navigation does, because the resident can simply ask in their own language. Confirm which languages are supported and how the answer is sourced — machine-translating an English page is not the same as having content in that language.
How long before it is useful?
Quickly for hours, locations and common processes, because that content already exists. Much longer for anything that was never written down. The distance between those two is the actual project.
What should we measure?
What residents asked, how often the assistant handed off, and which questions it could not answer at all. Conversation volume on its own tells you nothing about whether anybody got what they came for.
Where to go next
Before evaluating any product, spend an hour with the questions your front desk answered last week and write down the ten that came up most. That list is both the specification for an assistant and, more immediately, a list of pages worth rewriting — and the second is useful whether or not you ever buy the first.