Citizen Appeals Management: How Requests Are Processed Online
Basics4 minInnovialabs editorial team
In short
A citizen appeals system collects requests from every channel into one registry, routes them to the right department, tracks the required deadlines, notifies the applicant at each status change and shows which problems recur most.
How it works in brief
A citizen submits a request through any convenient channel. The system registers it with a number, identifies the topic, routes it to the responsible department, tracks the deadline, notifies the applicant as it moves and stores the response. Management sees where requests get stuck and which problems keep coming back.
The real value is not a website with a form but a single registry: every request has a number, a history and an owner, and nothing gets lost between email, phone and paper.
Intake channels
| Channel | Specifics |
|---|---|
| Website or portal form | Structured data, attachments, topic selection |
| Mobile app | Photos and geolocation — handy for roads, lighting, waste |
| Telegram bot | Familiar channel, quick answers to common questions |
| Call center | The operator enters the request into the same system |
| In-person visits and paper letters | Scanned and registered manually |
| Messages are parsed into cards automatically |
All channels must feed one queue. Applicants are often identified through the national identity system, but anonymous or simplified requests should also be possible where the law allows.
Routing to departments
- Classification: the applicant picks a topic, or an operator or machine learning model suggests one from the text.
- Routing rules: topic + address or district → a specific department or subordinate organization.
- Assignment of an executor by the department head.
- Redirection with a mandatory reason if the request landed in the wrong place. Every redirection is visible in the history.
Automatic classification saves time, but a person makes the final call on ambiguous cases.
Deadlines and SLAs
Response deadlines for appeals are usually set by law, and an organization may have its own shorter internal SLAs per stage. The system should:
- calculate deadlines accounting for weekends and holidays;
- support deadline extensions with a justification;
- show executors and managers a traffic light: on track, due soon, overdue;
- escalate to a manager when a deadline is at risk;
- distinguish "formally closed" from "problem solved".
Measure not just speed but also repeat requests on the same issue: if the applicant came back, the first closure was a formality.
Status notifications
Applicants should not have to call to find out what is happening. A minimum set of notifications:
- registered, with the request number;
- forwarded to a department;
- more information needed;
- deadline extended, and why;
- answered, with text or a document.
Channels: SMS, email, push or Telegram. Status is also available by request number in a personal account. After the answer, ask for a rating: was the problem solved?
Analytics of recurring issues
Appeals data is a map of problems in a territory or service. A dashboard shows:
- topics and their trend by week and month;
- a heat map by district and address;
- departments with the most overdue requests;
- the share of repeat requests and average ratings.
If one address reports the same thing every week, that is a signal to fix the root cause rather than answer each letter.
Transparency for citizens
- Public statistics: how many requests were received and resolved, and how fast.
- A map of solved problems without personal data.
- Open answers to common questions to reduce the flow of identical requests.
Applicants' personal data stays protected: role-based access, an audit log, storage in line with the law.
Common mistakes
- Several separate channels with no shared registry.
- Closing requests with boilerplate replies to hit targets.
- No notifications, so people submit duplicates.
- Analytics exist, but nobody makes decisions based on them.