Chatbot for citizen enquiries

The municipality currently handles around 11,000 citizen enquiries per year through a fully manual process. When a citizen contacts the department asking about fees, opening hours, or the correct form to use, a case officer picks up the enquiry, locates the relevant official document, drafts a response, and sends it. Complex or ambiguous cases are escalated to the department head. Everything is logged via email or spreadsheet. With six minutes of officer time per enquiry on average, the process consumes roughly 1,100 hours of staff effort annually on questions that are, in the majority of cases, straightforwardly answerable from published official documents.

The process runs continuously throughout the working day and involves three people: a department head and two case officers, supported by a shared regional IT function that moves slowly and is subject to formal public procurement rules. Some supporting information is available through open data registers published by municipal bodies, but there is no single system holding the full process. The fragmented landscape means institutional knowledge is concentrated in a small team, citizens wait longer than necessary for routine answers, and the two case officers spend a significant portion of their time on work that does not require their professional judgement.

The compliance context is demanding. Administrative procedure law, GDPR, and the requirement that decisions survive appeal mean every answer the municipality gives must be traceable to a current, authoritative source. Outdated information, invented content, or answers given without a proper audit trail are not just quality problems; they are legal liabilities. Any automation solution must account for this from the ground up, not as an afterthought.

The recommended path is Hybrid: a retrieval-augmented AI chatbot grounded strictly on official municipal documents, with clearly defined and mandatory human escalation gates. The core logic is straightforward. The vast majority of citizen enquiries ask factual questions whose answers already exist in published documents. A retrieval-augmented generation system, one that finds the relevant document passage and uses it as the direct basis for its answer rather than generating content from general training, eliminates the hallucination risk that makes fully autonomous AI unsuitable for a compliance-bound public sector context. The chatbot does not invent answers; it retrieves and presents them, with a traceable link back to the source document. That auditability is not a nice-to-have in this setting; it is the legal foundation on which the system must be built.

The escalation gates are the other half of the design, and they are equally non-negotiable. Roughly five percent of enquiries, around 550 per year, involve procedural interpretation, formal administrative decisions, or situations where the available documents do not give a clear answer. These cases must reach a human, and the system must be designed so that the boundary is explicit, tested, and reviewed regularly. The escalation gate routes flagged cases to a case officer queue with full context, so the officer picks up a case already understanding what the citizen asked and what the system could and could not find. This is a better working experience than the current manual triage, not just a compliance safeguard.

The client has no stated technology preference and is constrained by public procurement rules and central IT governance. This is acknowledged directly in the recommendation. The hybrid solution should be specified around open-standards components, for example an open-source retrieval-augmented generation framework backed by the municipality's own document store, so that it can be written into a formal tender and approved through the existing procurement process without creating a long-term dependency on a single proprietary vendor. The procurement timeline is the longest dependency in the project, and the team should treat it as such rather than trying to work around it.

Compared to the other paths considered, Hybrid is the clear fit. An AI Workflow scored 7 and is viable, but without explicit escalation logic hardcoded into the design it carries compliance risk; once you add those gates, it converges with the Hybrid approach anyway. An AI Agent scored 4 and is not recommended: autonomous multi-step reasoning is not what this process needs, and the accountability risks under administrative procedure law are unacceptable when the agent could take actions beyond retrieving and presenting document content. RPA and Traditional Code both scored 3; RPA cannot interpret natural-language enquiries, and a rules-based coded FAQ would require constant manual maintenance and would fail on any question phrased outside its predefined patterns, which is most of them. Staying Manual scored 1 and is indefensible at this volume: 1,100 hours a year on largely repetitive, answerable questions is a structural problem that better officer skills alone cannot solve, which is why Education alone also scored 3 and is recommended only as a complement to the technical implementation, not a substitute for it.

The honest tradeoffs are worth naming. The public procurement process will stretch the project timeline significantly compared to a private-sector equivalent, and central IT involvement adds coordination overhead. The ROI case is strong, with a projected 70 percent automation rate freeing over 750 officer-hours per year and a payback period of around 14 months at mid-range build cost, but that payback depends on the document governance model being established and maintained properly. If the document store is not kept current, the chatbot will give citizens wrong answers and the efficiency gain will be overwhelmed by the resulting rework and legal exposure. The document ownership and refresh process is not a phase-two concern; it is a prerequisite for go-live.

The two strongest contenders here are Hybrid and AI Workflow. Both can handle high volumes of natural-language enquiries and both can be grounded on official documents. The difference comes down to accountability. An AI Workflow solution can absolutely be built with escalation rules baked in, but those rules tend to be treated as configuration rather than as a structural feature of the system, which means they are easier to accidentally bypass or quietly erode as the workflow is updated over time. The Hybrid path makes the human escalation gate a first-class architectural component, not an afterthought, and that distinction matters enormously when administrative procedure law requires that certain decisions survive appeal and be justifiable on the file. For a private business answering questions about delivery times, the two approaches are nearly equivalent. For a municipality, the difference is material.

The AI Agent path scored significantly lower and is not a close competitor. An autonomous agent capable of taking multi-step actions beyond answering from documents introduces exactly the kind of unpredictable behaviour that public sector compliance cannot tolerate. This process does not need an agent that reasons across systems and initiates actions; it needs a system that retrieves accurate answers and knows when to stop and hand off to a person. Constraining an AI Agent tightly enough to be safe here would, in practice, produce something that behaves like the Hybrid design anyway, but with more complexity and fewer audit-friendly guarantees. Traditional Code and RPA were considered and set aside quickly: RPA cannot interpret natural-language enquiries at all, and a rules-based coded FAQ bot would require constant manual maintenance every time fees or opening hours change, which is precisely the maintenance burden the team is trying to escape.

The foundation of this system is a retrieval-augmented generation, or RAG, architecture in which the chatbot is permitted to answer only from a controlled, version-managed document store populated with official municipal documents. No general internet knowledge, no model fine-tuning on citizen data, and no answers generated from memory alone. Before any software is selected, the department head and case officers need to complete a document inventory: every fee schedule, opening hours notice, and form that the chatbot may reference must be catalogued, assigned an owner, and given a refresh cadence. This is unglamorous work but it is the single most important step in the project, because a RAG system is only as reliable as the documents behind it.

Once the document governance model is in place, the procurement specification can be written and published. Given the public procurement constraints, the specification should be written around open standards rather than a named product, requiring document-grounded answers with source citations, a full per-interaction audit log, GDPR-compliant data handling with defined retention periods, and an open API for integration with the municipal document store. Open-source RAG frameworks such as LangChain or Haystack, backed by a self-hosted vector database such as Weaviate or Qdrant, are representative of what a compliant vendor could offer, and naming these in the market engagement phase helps bidders understand the technical direction without locking the municipality into a proprietary stack. The channel interface, whether a widget on the municipal website, an email parser, or both, should be treated as a separate integration layer so it can be adapted without rebuilding the retrieval core.

The pilot phase deploys the selected solution against the highest-volume document subset, fees and opening hours, and runs it in shadow mode alongside the existing manual process. Shadow mode means the bot produces answers that case officers review before anything is sent to a citizen. This phase is specifically designed to surface answer-quality failures before they reach the public and to calibrate the escalation gate. The escalation logic should be rule-based and explicit: enquiries that contain keywords associated with formal administrative decisions, appeals, or procedural interpretation are flagged immediately; enquiries where the retrieval confidence score falls below a defined threshold are flagged automatically; everything else proceeds to a drafted response that is either sent automatically or reviewed on a sample basis, depending on the confidence level. The case officer queue that receives escalated cases should include the original citizen message, the documents the system attempted to retrieve, and the reason for escalation, so officers are never starting from scratch.

Full rollout extends the document library to cover forms and any remaining in-scope topics, retires the email-and-spreadsheet logging flow for standard cases, and replaces it with a structured interaction log that satisfies both GDPR audit requirements and the administrative law requirement for a justifiable file. A monthly review meeting, involving the department head and at least one case officer, should examine escalation rates, answer accuracy on sampled interactions, and any documents flagged as potentially stale. The escalation rate itself is the most useful quality signal: if it rises unexpectedly, something in the document store or the confidence thresholds needs attention.