Development of an AI system for automating citizen request processing

Why automation of citizen appeals stalls on routine

More than half of the incoming flow consists of standard appeals: certificates, document copies, status clarification, extension, resubmission.

Formally, each goes through the same route of registration, classification, and response, but with manual processing of requests, an operator spends as much time on such an appeal as on a non-standard one — until they hit the regulatory deadline.

Then the arithmetic of the support bottleneck begins. The queue of appeals grows faster than the staff: distribution is done manually via a log or email, priority is determined by the date of receipt rather than by type and deadline.

As soon as an operator is distracted by an adjacent task, the appeal falls out of sight: the appeal status is lost, the reminder does not trigger, and the response deadline passes unnoticed.

The cost of such an error is not only in penalty deadlines. An applicant who has not received a response or notification about the progress of the case writes again — on the same issue, sometimes to several channels.

The share of repeat requests grows, the load on operators increases with the same volume of primary appeals, and support stops keeping up with processing non-standard cases where a human is truly needed.

The reason is not the discipline of the staff.

Routine processing of citizen appeals is not broken down into formalizable steps: there is no automatic classification by topic and legal basis, no deduplication and linked appeals, no status model that itself moves the request through stages and escalates as the deadline approaches. We explain how this is addressed.

What changes in the service's work after implementation

The deadlines for considering citizen appeals are set by regulation — law on the procedure for considering citizen appeals — so we evaluate the effect of implementation by measurable indicators, not by feelings. Below are five of them: we take them at the start, repeat after a month, and after a quarter.

• Response speed. Classification and routing of an appeal take seconds instead of hours of manual sorting. The applicant receives confirmation and the first substantive response on the same day.
• Share of automatic resolutions. Standard requests — certificates, statuses, repeat appeals — are closed without an operator using approved templates. The rest goes to a specialist with a ready summary and draft response.
• Load on operators. Routine leaves the queue, and people handle complex and conflict cases. Department throughput grows without expanding staff or overtime.
• Overdue appeals. The system calculates the deadline for each appeal, escalates several days before it expires, and does not allow closing a card without a response. Overdue cases turn from a systemic problem into a rare exception.
• Unified register of appeals. Email, website form, messengers, and paper are consolidated into a single repository with history and statuses. A repeat appeal is raised together with previous correspondence rather than created anew.

Formats of working with citizen appeals: comparison

The choice of approach is determined by the homogeneity of the flow and the cost of an error.

For predictable requests — a status certificate, extension, appointment booking — rules and keywords are enough: appeal routing works explainably, and the decision can always be shown to an inspector.

As soon as wording diverges, typos and attachments appear, the rules begin to miss the addressee, and a model that parses meaning is needed.

In practice, a hybrid approach almost always emerges: rules filter out the obvious and strictly defined regulations, a trained classifier refines topic classification and priority, a language model assembles a draft response from the knowledge base, and the operator's decision remains the final word.

The boundary lies in the share of appeals that go to manual review: if it stops decreasing after adding rules, it is time to connect labeling and the model.

How implementation proceeds: stages of engineering work

We start development not with choosing a model, but with analyzing how appeals actually live in the organization: which channels they come from, who decides and on what basis where to route them, and where the queue accumulates.

Without this picture, any automation accelerates the wrong process, so the first stage always takes more time than the client expects.

1. Appeal flow audit.

   We collect an export across all channels — portal, email, phone line, messengers — label by topics and types, calculate the share of standard ones, time to first response, and points where an appeal "gets stuck." The output is a flow map with bottlenecks in figures.

2. Routing scheme. We determine which categories are closed automatically, which go to an operator with a prepared draft, and which require approval. Separately, we specify escalation rules and prohibitions — topics that the system has no right to handle on its own.

3. Setting up the environment. We connect channels, set up reference books, response templates, and extraction of key fields from text: address, request number, category, deadline. Routing logic is fixed in configuration rather than code so it can be changed without rebuilding.

4. Validation on historical data. We run the environment on appeals from past periods and compare with operators' decisions. We look at the share of correctly identified categories, the accuracy of extracted fields, and the share of responses accepted without edits.

5. Response quality control. Regular sample labeling and review of disputed cases together with the support service. Anything where confidence is below the threshold is handed to a human by the system rather than guessed.

6. Acceptance and handover to operation. We fix regulations, the decision log, and rules for updating reference books, train the shift, and leave a support period with deviation review. Then we expand category coverage as statistics accumulate.

Set of documentation, diagrams, and regulations

We deliver development not as a demonstration but as a working environment: the client's team retains a set by which the system can be operated, expanded, and transferred to another contractor without reverse engineering. Below is a list of what is fixed based on the results of launching automation of citizen appeals.

• List of scenarios — all types of appeals with examples of wording, the expected response, and the boundary beyond which a human is involved.
• Route map — where the appeal goes at each step: which attribute triggers, which queue it enters, and what happens when data is missing or there is a duplicate.
• Access policies — which employees see which categories of appeals, what is logged, and how rights are granted and revoked upon dismissal or transfer.
• Escalation regulations — conditions for transferring the dialogue to an operator, notification procedure, and response time for each category.
• Operator instructions — work screens, quick actions, review of typical disputed situations, and the procedure for editing a response without developer involvement.
• Retraining regulations — how reviewed appeals accumulate, who approves examples, and how often the model is updated.
• Configurations and integration descriptions — connection parameters to record-keeping systems, exchange formats, and a list of external services and failure points.
• Acceptance log and deployment scheme — the set of checks by which the system was accepted and the procedure for recovery after a failure.

Documents are written for a specific environment rather than from a template: the names of queues, categories, and roles match those configured in the system. They can be updated by in-house specialists — rebuilding a scenario or editing escalation rules does not require us.

Project case study: response time cut threefold

Before implementation, each appeal was reviewed by an operator: they opened the card, manually determined the topic, and searched for the answer in regulatory documents.

The first response reached the applicant on average on the third day, and almost a third of requests came back again — already as new appeals, because the previous correspondence could not be found.

What was changed

The system classifies text by topics and determines intent: consultation, complaint, application, duplicate. Standard questions are closed automatically — the response is assembled from approved templates and checked against the regulatory base by semantic search.

Anything the model scored below the specified confidence threshold does not go to the applicant but to the manual revision queue: the operator sees a ready draft and edits it rather than writing from scratch.

Repeat appeals stopped multiplying: incoming text is compared with history by semantic similarity, and the request is linked to an open case rather than creating a new one.

Metrics before and after

The share of appeals closed without an operator — 12% → 61%. Time to first response — 3 days → 1 day. Repeat appeals — 29% → 14%.

The share of responses that the operator still edited remains within 8% and serves as the main signal for retraining: each edit is reviewed and a decision is made whether it is a new template or a labeling error.

"The shift handles disputed and emotional cases instead of identical consultations," this is how the result is described by head of the citizen appeals service.

How does an AI assistant differ from a regular auto-responder?

An auto-responder follows a decision tree: it catches keywords and pattern matches and outputs what was built into it.

An AI assistant first parses the meaning of the request — identifying the essence of the problem, application number, agency, deadline — and only then selects a response.

Hence the different classes of failures: a scenario breaks on paraphrasing, while meaning parsing breaks on missing data in the appeal itself.

Clarifying questions are asked not by script but based on gaps in the parsing: if the request does not contain an appeal number, the assistant will ask specifically about it rather than running through five formal items in a row.

When confidence is low or the topic falls outside the regulations, transfer to an operator is triggered — with a ready card: the essence, dialogue history, what has already been checked, and what is missing.

Trust in the response rests on verifiability. The wording is assembled according to a regulation clause or a norm in a legal database such as ConsultantPlus, and the reference remains in the response — it is seen by both the citizen and the operator. If the source is not found, the assistant does not guess but records a gap in the knowledge base.

A common misconception is that this is one tool with different settings. The scenario and meaning parsing live together: the scenario holds strict procedures such as accepting an application by form, while parsing covers everything expressed in free text.

Common technical doubts before starting

Before starting, clients ask the same set of questions: how the system will fit into the existing environment, what to do with dirty input, and who is responsible for an error.

We answer substantively — so that each point can be verified in a pilot area rather than taken on faith.

What to do with unstructured appeals?

We bring scans, emails without a subject, mixed language, and attachments to a unified form: recognize, extract entities, determine the topic. If confidence is below the threshold, the appeal goes to an operator with a note — the system will not silently guess.

Who is responsible for a system error?

The final decision remains with a human. Critical scenarios — refusal, accrual, status change — are not automated: the system prepares a variant, and the operator confirms. This eliminates the class of errors for which the agency is responsible.

Is it necessary to retrain the system after launch?

Yes, and this is a regular process. Operator edits become a training set, and quality is checked on a held-out set of appeals. We release a new model only with confirmed accuracy growth on it.

How is personal data protected?

We deploy the environment in your infrastructure, and personal data is anonymized before being passed to the model. Access is role-based, and all data accesses are written to a log.

Let's discuss the task: what is needed to start

To come back with an estimate and plan rather than general words, at the first meeting we break down the task to the data level. An hour with a tech lead and the specialist who currently handles appeal processing is enough. Below is what to bring and what to agree on.

• Problem statement. What exactly the system does with an appeal: determines the topic, extracts details, suggests a route to a department, prepares a draft response. We immediately mark the steps that remain with a human.
• Appeal sample. Several hundred real appeals from a comparable period, including rare topics, duplicates, and attachments. Without this, discussing the quality of the future model is pointless.
• Integration points. How the appeal enters the records today — web form, email, phone, departmental system. Whether reverse status writing, access to reference books, and personal data anonymization are needed.
• Acceptance criteria. We agree on numbers: the share of correctly identified topics, completeness of detail extraction, the share of appeals going to manual review, and response time. Separately — the confidence threshold below which the system does not answer on its own.
• Labeling and benchmark. Who labels the sample, according to which instructions, and how to handle disputed cases. We keep part of the labeling closed and test the result on it rather than fitting to it.
• Work plan. Stages, a shadow run on the live flow without affecting applicants, and metric checkpoints. And in advance — how we roll back if the indicators do not match.
• Access and restrictions. Where data is hosted, which specialists have access to it, and which channels are closed to automatic processing under regulations.

Send an example export and describe the current process — we will come back with an estimate and work plan.