> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/complaints-management/access/cms-dashboard.md).

# CMS Dashboard

The Dashboard is the analytics piece of the Complaints Management System. Instead of going through individual complaint data to analyse trends, you will be able to see the aggregated and summarised version of the complaints that flow through the system. It answers questions like "how many complaints came in this week", “what share of complaints are resolved”, “what is the SLA compliance rate for the week”, "which wards are falling behind", "how satisfied are citizens with resolutions" and much more.\
\
CMS has two forms of dashboards:

* The Employee dashboard - This is a role-gated view,  showing the full KPI catalogue to authorised employees (GROs, Supervisors, Admins).
* The public dashboard - An anonymous-access, credential-free dashboard meant for the citizens.

## Why Analytics Matter

Individual complaint records tell you about one citizen's problem. The dashboard tells you about the system - whether complaints are being resolved as fast as they come in, whether any ward or department is quietly becoming a bottleneck, whether SLA commitments are actually being met, and whether citizens are satisfied with outcomes.\
\
Currently, the dashboards have a set of the following Key Performance Indicators (KPI’s) to assess the complaints health of your account.

## KPIs For Configurable Dashboard

<table><thead><tr><th>Name</th><th>Type</th><th>Question answered</th><th>slice</th><th>basis</th><th width="138.74609375">Visualization</th><th>Submetric (formula-bearing)</th><th>Formula</th></tr></thead><tbody><tr><td>New Complaints Created</td><td>demand</td><td>how many complaints were filed</td><td></td><td>complaints filed between start–end date</td><td>Number tile with delta + sparkline</td><td>NA</td><td>Complaints whose created date falls in the selected range.</td></tr><tr><td>Open Complaints</td><td>demand</td><td>how many complaints are open</td><td></td><td>complaints filed between start–end date</td><td>Number tile with delta + sparkline</td><td>NA</td><td>Complaints not yet in a closing stage (resolved / closed / rejected).</td></tr><tr><td>Resolved Complaints</td><td>throughput</td><td>how many were resolved</td><td></td><td>complaints filed between start–end date</td><td>Number tile with delta + sparkline</td><td>NA</td><td>Complaints marked resolved during the range (counted by resolve date, not filing date).</td></tr><tr><td>Complaints Created Today</td><td>demand</td><td>how many complaints were filed today</td><td></td><td>complaints filed today (current day)</td><td>Number tile with delta + sparkline</td><td>NA</td><td>New complaints, but just today. Delta compares to yesterday.</td></tr><tr><td>Resolution Rate</td><td>throughput</td><td>what share of complaints get resolved at all</td><td></td><td>complaints filed between start–end date</td><td>Number tile with delta + sparkline</td><td>NA</td><td>Resolved ÷ all complaints created, as a %. "Did we close it at all."</td></tr><tr><td>Oldest Complaint</td><td>throughput</td><td>age of oldest complaint in the system</td><td>age</td><td>complaints filed between start–end date</td><td>Number tile + delta</td><td>NA</td><td>The open complaint with the earliest created date; report its age in days.</td></tr><tr><td>Average Resolution Time</td><td>throughput</td><td>how much time to resolve complaints</td><td></td><td>complaints filed between start–end date</td><td>Number tile + delta</td><td>NA</td><td>Average time from created to resolved, across resolved complaints.</td></tr><tr><td>Reopen Rate</td><td>quality</td><td>how many complaints reopened</td><td></td><td>complaints filed between start–end date</td><td>Number tile + delta</td><td>NA</td><td>Reopened ÷ complaints resolved, as a %. "Did the fix stick."</td></tr><tr><td>CSAT</td><td>outcome</td><td>how satisfied is the citizen</td><td></td><td>(period = resolution date)</td><td>Number tile + delta</td><td>NA</td><td>Average citizen rating on resolved complaints (out of 5).</td></tr><tr><td>First-Assignment Rate</td><td>quality</td><td>how many assigned correctly the first time</td><td></td><td>complaints filed between start–end date</td><td>Number tile + delta</td><td>NA</td><td>Complaints never reassigned ÷ all assigned, as a %. A reassignment = wrong first routing.</td></tr><tr><td>SLA Compliance Rate</td><td>throughput</td><td>what share of complaints met their SLA</td><td></td><td>complaints filed between start–end date</td><td>Number tile + delta</td><td>NA</td><td>Resolved within SLA ÷ all complaints, as a %.</td></tr><tr><td>SLA Non-Compliance Rate</td><td>throughput</td><td>what share of complaints breached SLA</td><td></td><td>complaints filed between start–end date</td><td>Number tile + delta</td><td>NA</td><td>Breached SLA ÷ all complaints, as a %.</td></tr><tr><td>Resolved on Time Rate</td><td>throughput</td><td>how many resolved within SLA</td><td></td><td>complaints filed between start–end date</td><td>Number tile with delta + sparkline</td><td>NA</td><td>Resolved within SLA ÷ resolved complaints, as a %. (Same top, different bottom than SLA Compliance — that's the confusing part.)</td></tr><tr><td rowspan="4">Complaints Over Time</td><td rowspan="4">demand</td><td rowspan="4">trend of complaint volume</td><td rowspan="4">time</td><td rowspan="4"></td><td>Line Chart (compound, up to 4 series; Daily/Weekly/Monthly toggle)</td><td>Created</td><td>Count by created date, per bucket.</td></tr><tr><td></td><td>Resolved</td><td>Count by resolve date, per bucket.</td></tr><tr><td></td><td>Resolution Rate</td><td>Per bucket: resolved ÷ created.</td></tr><tr><td></td><td>SLA Compliance Rate</td><td>Per bucket: on-time-resolved ÷ total.</td></tr><tr><td>Complaints by Type</td><td>demand</td><td>which complaint types are most filed</td><td>type</td><td>complaints filed between start–end date</td><td>Horizontal Stacked Bar</td><td>Complaint types, descending by complaints filed</td><td>Count grouped by complaint type, biggest first.</td></tr><tr><td>Complaints by Departments</td><td>demand</td><td>which departments receive most complaints</td><td>dept</td><td>complaints filed between start–end date</td><td>Vertical Bar</td><td>Departments, descending by complaints filed</td><td>Count grouped by department, biggest first. (Department comes from a type→dept mapping in config, not the complaint itself.)</td></tr><tr><td>Employees with Most Open Complaints</td><td>throughput</td><td>which employee has most open complaints</td><td>employee</td><td></td><td>Horizontal Stacked Bar</td><td>per employee: Resolved / On track / Nearing breach / Breached; SORT by most-breached</td><td>Per officer: open complaints assigned to them, split into on-track / nearing breach / breached. Sort by most breached.</td></tr><tr><td>Open Complaints by Workflow Stage</td><td>throughput</td><td>at which stage are most complaints stuck</td><td>workflow</td><td></td><td>Vertical Stacked Bar</td><td>subtypes with most open complaints; each stack = workflow stage with its count</td><td>Subtypes with the most open complaints, each broken down by which workflow stage they're stuck in.</td></tr><tr><td rowspan="3">Open Complaints by Geography</td><td>throughput</td><td>which geography has most open complaints</td><td>geography</td><td rowspan="3"></td><td rowspan="3">Map (choropleth, 3 toggleable layers)</td><td>Created</td><td>Color each ward/locality by complaints created.</td></tr><tr><td></td><td></td><td></td><td>Open</td><td>Color each ward/locality by complaints currently open.</td></tr><tr><td></td><td></td><td></td><td>Resolved</td><td>Color each ward/locality by complaints resolved.</td></tr><tr><td>Department-wise resolution rate</td><td>throughput</td><td>what % each dept has resolved</td><td>dept</td><td>complaints filed between start–end date</td><td>Vertical Bar</td><td>Department names; bar = resolution rate %</td><td>Per department: resolved ÷ all, as a %.</td></tr><tr><td>Open Complaints by Channel</td><td>throughput</td><td>which channels have most open complaints</td><td>channel</td><td></td><td>Pie Chart</td><td>Channel names</td><td>Open complaints grouped by source channel (web / mobile / IVR / walk-in).</td></tr><tr><td>Complaint type Details</td><td>throughput</td><td>which types exceed their SLA</td><td>type x workflow</td><td></td><td>Table (threshold-colored cells)</td><td>cols: subtype | type | avg resolution time | ideal (SLA) | reopen rate | oldest complaint | resolved-on-time rate | CSAT</td><td>One row per subtype: avg resolution time, SLA, reopen rate, oldest open complaint, on-time rate, CSAT. Flag rows where avg time > SLA.</td></tr><tr><td>Complaints by Age</td><td>throughput</td><td>age distribution of complaints</td><td></td><td></td><td>Histogram</td><td>buckets: 0–3d, 3–7d, 7–14d, 14d+</td><td>Open complaints bucketed by age: 0–3d, 3–7d, 7–14d, 14d+.</td></tr><tr><td>Employee Performance</td><td>throughput</td><td>performance of employees</td><td>employee</td><td></td><td>Table (per-metric threshold coloring; status as tags)</td><td>cols: name | role | dept | assigned | open | resolved | reopen rate | CSAT | escalation rate</td><td>One row per officer: assigned, open, resolved, reopen rate, CSAT, escalation rate (escalated ÷ assigned).</td></tr><tr><td>Complaints at Risk</td><td>quality</td><td>which complaints breached / will breach</td><td></td><td></td><td>Table (SLA-status tags; sort by breach duration desc)</td><td>cols: ID | type | subtype | locality | owner | owner role | status | SLA status | breach duration</td><td>Open complaints that breached or are nearing breach, sorted by how far past SLA. Breach duration = how far past the deadline it now is.</td></tr><tr><td>Flow Ratio by Dept</td><td>throughput</td><td>is each dept keeping up with incoming complaints</td><td>dept</td><td>complaints filed between start–end date</td><td>Horizontal Bar with break-even line at 1.00</td><td>one bar per dept; ratio labelled at bar end; reference line at 1.0; red &#x3C;1.0, green ≥1.0</td><td>Per department: resolved ÷ created. Above 1.0 = catching up (green), below 1.0 = falling behind (red). Break-even line at 1.0.</td></tr><tr><td>Breached SLA (Open)</td><td>throughput</td><td>How many currently-open complaints have already breached their SLA deadline</td><td></td><td>Live snapshot</td><td>Number tile with delta + sparkline</td><td>NA</td><td>Count of complaints where status = open AND SLA already breached, as of right now.</td></tr><tr><td>Flow Ratio</td><td>throughput</td><td>Is the ULB resolving complaints as fast as they're coming in, right now</td><td></td><td>complaints filed/resolved between start–end date</td><td>Number tile (scalar, rating-style delta)</td><td>NA</td><td>Resolved-in-period (counted by resolve date) ÷ Created-in-period (counted by created date). >1.0 = clearing the backlog faster than it's growing; &#x3C;1.0 = falling behind.</td></tr><tr><td>Service Quality by channel</td><td>mixed</td><td>How does each intake channel (web / mobile / IVR / walk-in) perform on volume, resolution and satisfaction</td><td>channel</td><td>complaints filed between start–end date</td><td>Table</td><td>cols: Channel | Volume | Resolution rate | CSAT</td><td>One row per intake channel (source): Volume = count filed; Resolution rate = resolved ÷ filed, as %; CSAT = avg citizen rating on resolved complaints from that channel (out of 5).</td></tr><tr><td>Ward Performance</td><td>mixed</td><td>How is each ward performing across volume, backlog, reopen rate, SLA and satisfaction</td><td>ward</td><td>complaints filed between start–end date</td><td>Table</td><td>cols: Ward | Created | Open | Reopen % | On-time % | CSAT</td><td>One row per ward: Created = count filed; Open = count currently open; Reopen % = reopened ÷ resolved; On-time % = resolved-within-SLA ÷ resolved; CSAT = avg rating on resolved complaints — all scoped to that ward.</td></tr><tr><td>Complaints Over time</td><td>demand</td><td>On a day-to-day basis, what does progress look like against the volume influx of new complaints</td><td>time</td><td></td><td>Line Chart</td><td>Created</td><td>Created: count by created date, per bucket. (Resolved / Open / On-time % are declared in the chart config but see Review Notes — they are not actually computed.)</td></tr><tr><td>Breach rate vs caseload by department</td><td>throughput</td><td>Which departments have both a large open caseload and a high breach rate at once</td><td>dept</td><td>Live snapshot (today's open backlog per department)</td><td>Scatter chart:</td><td>Open (caseload) | Breach rate %</td><td>Per department: Open = count of currently open complaints (caseload, x-axis). Breach rate = breached ÷ (within + approaching + breached) — i.e. among complaints whose SLA clock is meaningfully in play, excluding brand-new complaints nowhere near their deadline yet.</td></tr><tr><td>Complaints by Wards</td><td>throughput</td><td>Which wards have the most complaints, broken down by SLA state</td><td>ward</td><td>Live snapshot (today's open backlog per ward)</td><td>Horizontal Stacked Bar (by SLA state: Resolved / On track / Nearing breach / Breached), sorted by most-breached</td><td>per ward: Resolved / On track / Nearing breach / Breached; sort by most-breached</td><td>Count of complaints per ward, stacked by SLA status bucket (resolved / within / approaching / breached).</td></tr><tr><td>Complaint sub-type performance</td><td>throughput</td><td>How does each complaint sub-type perform on volume, resolution time and SLA</td><td>type</td><td>complaints filed between start–end date</td><td>Table</td><td>cols: Subtype | Complaints | Avg resolution | SLA</td><td>One row per complaint subtype (service_code): Complaints = count filed; Avg resolution = average resolve time among resolved complaints of that subtype; SLA = that subtype's configured SLA target. Can also roll subtypes up to a coarser category level, or filter to one category's subtree, via the same table.</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.digit.org/complaints-management/access/cms-dashboard.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.