Chatbot for citizen enquiries

The municipality currently handles around 11,000 citizen enquiries per year covering fees, opening hours, and official forms. When a citizen submits a question, a case officer picks it up manually, locates the relevant official document, formulates an answer, and sends it back. If the question involves legal nuance or could constitute a formal administrative decision subject to appeal, it is escalated to the department head. The whole cycle takes about six minutes on average and is tracked informally through email and spreadsheets. At current volume, that adds up to roughly 1,100 staff hours per year spent answering questions that are, in the majority of cases, answerable directly from published municipal documents.

The process sits across two case officers and a department head, with shared regional IT that moves slowly and requires formal procurement for any new tooling. Some official registers publish open data, but there is no single authoritative system of record, and the knowledge needed to answer most enquiries lives in a collection of official documents rather than in a live database. The compliance environment is demanding: administrative procedure law, GDPR, and the requirement that any decision be justifiable on the file and survive an administrative appeal all shape what an automated solution is and is not allowed to do on its own.

The recommended path is Hybrid: a retrieval-augmented generation chatbot that answers routine enquiries directly from official municipal documents, with a clearly defined escalation gate that routes legally sensitive or judgement-heavy cases to a human case officer. The core insight is that the majority of the 11,000 annual enquiries are not difficult questions. They are repetitive lookups against a finite and relatively stable set of published documents. A well-built retrieval-augmented pipeline can handle those reliably, cite its sources, and free the case officers for the roughly five percent of cases that genuinely require human accountability. That split, roughly 10,450 automated and 550 escalated per year, is the realistic operating model.

The compliance dimension is what makes a fully automated AI Workflow the wrong choice, even though the volume and structure of the enquiries would otherwise support it. Administrative procedure law requires that any answer which could be interpreted as a formal decision be traceable to a person on the file. An AI-generated answer sent directly to a citizen without human review carries real appeal risk, and in a public sector context that risk is not theoretical. The Hybrid model preserves human accountability exactly where the law requires it, while still capturing most of the efficiency gain. The escalation gate is not a fallback for when the chatbot fails; it is a designed feature of the architecture.

The client has no stated technology preference and is bound by public procurement rules and centrally managed IT. That constraint actually points toward a sensible architectural choice: a retrieval-augmented generation pipeline built on open standards, using a document store and an embedding model that can be hosted on an approved cloud environment or on-premises if required. This approach avoids deep proprietary lock-in, makes the procurement justification easier to write, and means the knowledge base, the official municipal documents, remains under the municipality's direct control. Whether the team ends up using an off-the-shelf platform like Azure AI Search combined with Azure OpenAI, or a more custom stack built around an open-source embedding model and a vector database, the architecture is the same: documents in, citizen question in, grounded answer out, with a routing rule that decides whether the answer goes straight to the citizen or to an officer's queue.

The honest tradeoffs are worth naming. Retrieval-augmented generation substantially reduces hallucination compared to a general language model responding from memory, but it does not eliminate it. If the source documents are ambiguous or if a citizen asks a question that sits on the edge of the catalogued knowledge, the chatbot can still produce a plausible-sounding but incorrect answer. This is why source citations in every response and a quarterly document refresh cadence are not nice-to-haves; they are core to keeping the system trustworthy. The build cost range of 15,000 to 35,000 EUR reflects genuine uncertainty about whether an off-the-shelf platform or a custom build is the right fit once procurement constraints are known. The lower end assumes a well-supported SaaS platform; the upper end assumes a more bespoke implementation on approved infrastructure. Either way, at projected annual savings of around 20,000 EUR, the payback sits at roughly 14 months on a mid-range build cost, which is a reasonable return for a public sector investment of this type.

The alternatives considered were straightforward to rule out. An autonomous AI Agent introduces multi-step agentic behaviour and unpredictability that is incompatible with administrative procedure law and simply unnecessary for a process that requires accurate document retrieval, not autonomous action across systems. Traditional Code could cover a narrow FAQ set but would require constant manual maintenance as fees and hours change, and it cannot cope with the natural language variation in how citizens phrase questions. RPA has no role here because there is no repetitive UI-based workflow to automate. Staying Manual is the baseline being escaped: 1,100 staff hours per year on largely routine lookups is not a sustainable use of a small team's capacity, and the client has already identified it as a problem worth solving.

The two most viable paths here are the Hybrid approach and a fully automated AI Workflow. Both use a retrieval-augmented generation pipeline to answer citizen questions from official municipal documents, and both would dramatically reduce the manual burden on the two case officers. The difference is the mandatory human escalation gate, and in this context that difference is decisive. A fully automated AI Workflow scores reasonably well on volume and rule clarity, but it cannot satisfy the requirement that any answer potentially constituting a formal administrative decision be traceable to a named human accountable under administrative procedure law. Without a hard routing rule, there is a genuine risk that a chatbot answer gets treated as a binding municipal response, and that risk is not theoretical in a public sector environment where citizens have formal appeal rights. The Hybrid model preserves automation for the roughly 95 percent of enquiries that are genuinely routine while keeping the escalation gate as a structural feature of the architecture, not an afterthought.

The AI Agent path scores significantly lower and is not recommended. An autonomous agent capable of reasoning across systems and taking multi-step actions goes well beyond what the process actually requires. The core task here is accurate retrieval and a clean handoff decision, not agentic planning. Introducing that level of autonomy would add unpredictability that is fundamentally incompatible with administrative procedure law, and it would be very difficult to justify in a procurement process or a compliance audit. Traditional Code and RPA both fail for different reasons: a rule-based decision tree cannot cope with the natural language variation in citizen enquiries and would become a maintenance liability for a small team, while RPA has no meaningful role in a process that is about understanding and answering questions rather than automating clicks across a UI. The Hybrid path wins not because it is the most sophisticated option, but because it is precisely calibrated to what this specific process actually needs.

The build starts before any technology is procured. The most important first step is a document inventory conducted by the case officers themselves, cataloguing every official municipal document that is the authoritative source for fees, opening hours, and forms. This produces the knowledge base that the chatbot will be grounded in, and it also forces an early conversation about versioning: who is responsible for updating the knowledge base when fees change, and how quickly must a new document be ingested before the old answer becomes misleading? That refresh cadence should be formalised as a quarterly cycle with a named owner, because a retrieval-augmented system is only as accurate as its most recent source documents. In parallel, the department head should work with the case officers to produce a written escalation policy that defines which question types must always reach a person, including anything that could constitute a formal administrative decision subject to appeal. This document becomes both a governance artefact and the specification for the chatbot's routing logic.

The technical core of the solution is a retrieval-augmented generation pipeline. Documents are chunked, embedded, and stored in a vector database such as Weaviate, Qdrant, or pgvector depending on what the approved cloud environment supports. When a citizen submits a question through whatever channel the municipality exposes, whether that is a web form, an email intake, or a chat widget, the query is embedded and matched against the document store. A language model, preferably a hosted model available through an approved procurement framework such as Azure OpenAI Service or a self-hosted open-weight model if data residency requirements demand it, generates a response grounded in the retrieved chunks and returns it with source citations so the citizen and any reviewing officer can see exactly which document the answer came from. The escalation gate sits downstream of the generation step: a classifier or a rules layer checks the query and the retrieved context against the escalation policy, and any case flagged as complex, legally sensitive, or outside the document scope is routed to the case officer queue rather than returned to the citizen directly.

The case officer interface does not need to be sophisticated. A simple queue view showing the original citizen question, the documents the system attempted to retrieve, and any draft answer the model produced is enough for an officer to review, amend, and send. This keeps the human genuinely in the loop rather than rubber-stamping outputs they cannot evaluate. For citizen-facing delivery, the simplest compliant option is often a web chat widget embedded on the municipality's existing site, with email as a fallback channel for citizens who do not use the chat interface. Neither channel requires deep integration with central IT systems in the short term, which matters given the slow procurement environment. The solution should be designed so that live API integration with open data registers can be added later as a layer on top of the document-grounded baseline, rather than being a dependency that blocks the initial rollout.

Once the pilot has been tested against a sample of historical enquiries and the escalation gate has been validated, the phased rollout should involve the case officers closely in monitoring the queue and feeding errors back into document quality improvements and routing rule refinements. KPIs worth tracking from day one include containment rate, meaning the share of enquiries resolved without human involvement, escalation rate, time to resolution for escalated cases, and a periodic citizen satisfaction sample. The department head should review these monthly for the first six months. This is not just good practice; it is the mechanism by which the team builds justified confidence in the system and catches the edge cases that no discovery process fully anticipates.