Artificial Intelligence for Complaint Handling in Local Government

How can artificial intelligence improve complaint handling in a council?

Artificial intelligence can read and summarise complaints, identify the subject and the location, classify the responsible service, geolocate incidents, consult municipal knowledge, draft replies and turn the accumulated data into territorial management information — while keeping human supervision over the decisions and communications that matter.

A complaint can run to three pages. The problem can fit in three lines.

A complaint sent to a council can run to several pages: repeated information, references to earlier contacts, opinions, dates, street names, separate events, sometimes several problems mixed into one text.

For the officer who will handle it, what matters comes down to a few questions: who is complaining, what the problem is, where it happens, which service should deal with it, how serious it probably is and what should happen next.

In a long complaint about heavy vehicles using a residential street, the resident may describe when the trouble started, previous contacts, near misses, damage to the road surface, ambulances struggling to get through, noise and accumulated frustration. The officer needs to understand all of it. Operationally it condenses to: Signage and Traffic · street identified · recurring heavy traffic on an unsuitable residential road · road safety risk and emergency access · Mobility Management Division · strongly negative sentiment.

The officer stops hunting for the information inside the text and starts receiving it organised. The original stays available — the AI does not remove information, it adds a layer of synthesis over it.

The problem is not the channel, it is what happens on the other side

Councils and parish authorities receive complaints, information requests, suggestions and incident reports every day. Email is still one of the most used channels, and that has an advantage: it does not force residents to learn a new platform. They simply keep writing.

Every message then has to be read, interpreted, summarised, classified, tied to a location, routed to the responsible service, logged, answered and followed up. Multiplied by hundreds or thousands of messages, a significant share of administrative time goes not into solving problems but into organising the information about them.

An agent is a workflow: read, extract, classify, geolocate, route

Autark-IA is not a chatbot. It is an agentic AI architecture that runs the steps of an administrative workflow: it reads, understands, summarises, extracts, classifies, geolocates, consults knowledge, recommends, logs, follows up and measures.

It does not need the resident to fill a rigid form or write in a particular way. The message can be long, emotional, unstructured or repetitive — because the language people use rarely matches the structure of the systems inside public administration.

Classification goes further than the subject. Given the organisation's own taxonomy and its org chart, the agent can determine not only what the complaint is about but who should probably handle it: Signage and Traffic → Municipal Works Department → Mobility Management Division. And where the text says «at the junction of X Street and Y Avenue», that can become latitude and longitude — so the complaint stops being only an administrative case and becomes a point on the map.

A complaint is a sensor on the territory

Every resident is permanently observing a small part of the municipality. Reporting a problem generates, in effect, a data point about the territory. Traditionally that information stays buried in mailboxes, documents and unstructured text.

Accumulated over time it can be plotted on a map and aggregated by parish, neighbourhood, street, category, department, period, priority and sentiment. With enough volume it becomes possible to answer questions like «why have road-surface complaints risen in this parish over the last three months?» or «which streets have the highest concentration of parking complaints?».

Human-in-the-loop is three levels, not one

Not every decision should be automated, and not every organisation wants the same degree of autonomy. The level should match the risk and the digital maturity of each authority.

1. Assistance — the AI summarises, classifies and extracts. Everything else is human.
2. Recommendation — the AI analyses, classifies, consults knowledge and drafts the reply. A human approves before sending.
3. Supervised automation — cases matching rules defined in advance run on their own. Humans get the exceptions.

When an officer approves or edits a drafted reply, that interaction can become institutional knowledge, linking question, context, category, department, drafted reply, approved reply and outcome. The knowledge stops living only in people's heads or scattered across thousands of emails.

Silence costs more than delay

Satisfaction depends as much on what happens while a problem is being solved. Even when the council is genuinely working on it, the resident can read silence as inaction. An agent can track the case, support interim communications and ask internally for an update when a deadline passes. The aim is not only to reply faster — it is to shorten the period in which the resident does not know what is going on.

Sentiment analysis serves as an aggregate indicator of the service experience, not as a way to grade residents. A complaint can arrive strongly negative and end, once resolved, in positive territory — and that change is more interesting than the initial sentiment. The question stops being only «how many complaints did we receive?» and becomes «how did the resident's perception move during the process?».

An architecture built for the European public sector

AI for public administration has to be designed from the start around privacy, security and governance. The architecture can run on infrastructure and data processing located in the European Union, Germany included.

It covers data minimisation, access control, logging, traceability, separation between municipal data and models, retention policies, human supervision, control over the knowledge bases and auditing of what the agent did — to support the applicable requirements of the GDPR and the EU AI Act, according to the context and the concrete use.

From complaint handling to municipal intelligence

The same logic configures to each authority's org chart and responsibilities. In a large municipality the value is in the volume of interactions, the number of departments and the integration with internal systems. In a small or medium one it is in automating administrative work that consumes a significant part of a small team's capacity. In a parish authority it is in small teams handling enquiries and incidents for thousands of residents.

Complaint handling is the first use case. The same architecture can later absorb information requests, suggestions, incident reports, enforcement, general enquiries, internal communication, document management and case tracking. That is why Autark-IA is better understood as a platform for municipal service and intelligence than as a complaints tool.

More about the solution on the AutarkiA page (in Portuguese).