Complaints · Root cause analysis
DashboardRetail bankingA complaints root cause dashboard that shows where to fix, not just what broke
Counting complaints tells you volume. Grouping them by root cause, product and journey step tells you what to change. Here is a dashboard built for the second question.
Valnora & Elric team5 min read
Root causes ranked
| Root cause | Product | Journey step | Complaints | Upheld | Status |
|---|---|---|---|---|---|
| Payment delays | Current account | Outbound payment | 188 | 58% | Rising |
| Unclear fees | Overdraft | Statement | 96 | 44% | Stable |
| Card replacement wait | Debit card | Card dispatch | 71 | 39% | Falling |
| App login failures | Mobile banking | Sign-in | 64 | 22% | Rising |
| Branch wait times | All | Branch visit | 38 | 18% | Stable |
6 weeks
Time from spike to fix
Down from a quarter when causes surface monthly by hand.
92%
Complaints with a confirmed root cause
Handlers confirm the suggested tag before closing.
1 pack
Monthly forum report
Scheduled from the dashboard, not rebuilt in slides.
Illustrative example. Figures show how the workflow is measured; they are not customer results.
Most complaints reports answer one question well: how many? They are weaker on the question a regulator and a product owner both care about: why, and what are you changing? In the UK, DISP 1.3.3R expects firms to analyse complaint causes, identify root causes common to types of complaint and act on recurring or systemic problems. Other regimes ask for something similar.
This post walks through a dashboard built in Agent Serve Dashboards for that second question. Every number on it is an illustrative example.
Where the data comes from
The dashboard sits on a complaints table. Records arrive from your complaints system by API, database connection or a scheduled CSV import. A tagging workflow then adds three fields your complaints system usually lacks: a root cause from your taxonomy, the product and the journey step where things went wrong.
The tagging is a suggestion. An Agent block reads the complaint summary and proposes a cause with a short reason; the handler confirms or corrects it when they close the case. A Guardrails PII detection step masks account numbers and names before the text reaches the model. Over time the corrections show where your taxonomy is unclear, which is useful in itself.
The headline tiles
Four KPI tiles answer the Monday questions, each bound to a governed metric so the number means the same thing everywhere it appears:
- Complaints received. A count over the selected period, compared with the previous period.
- Top cause share. The share of complaints from the single largest root cause. A high share is good news in one sense: it means one fix moves the total.
- Upheld rate. A ratio metric, upheld outcomes over decided complaints. Comparing it by cause shows where the firm is most often wrong, not only most often complained at.
- Repeat complainants. The share of customers with more than one complaint in the period, a sign that the first resolution did not hold.
Defining these once in the semantic model matters. When the forum asks why the upheld rate in the pack differs from the one in a spreadsheet, the answer is a definition you can show.
The trend and the ranking
The line chart compares the top cause with everything else, month by month. It answers whether a cause is growing on its own or rising with overall volume. Annotations mark known events, such as a payments platform change, so the next reader knows what the spike lined up with.
Below it, a ranked table lists root causes with product, journey step, volume, upheld rate and a status. Click through any row to drill into the complaints behind it. A pivot panel alongside shows the same data as causes against journey steps, which is where patterns jump out: a fees cause concentrated at the statement step points at the statement, not the fee.
Rules that flag what totals hide
Some complaints matter more than their count suggests. Three Rules run over every row:
- Repeat complainant. Flags complaints where the tagging workflow found an earlier complaint from the same customer in the last 90 days.
- High redress. Flags complaints where redress paid is above a level you set.
- Systemic candidate. Labels complaints the handler marked as likely to affect other customers, or whose cause is on the forum’s watch list.
Rule results appear as columns in the drill-through table and can drive highlighting, so a reviewer scanning the list sees the flagged rows first.
Monitors that reach the owner
A dashboard only helps if someone looks at it. Monitors make sure the right person does:
- Cause volume. A metric monitor fires when complaints for any one cause cross a monthly threshold.
- Systemic candidates. A rule monitor fires when the systemic candidate rule matches at least one row.
- Upheld rate. A KPI alert fires when the upheld rate moves by more than a set percentage against the previous period.
Each has a severity and goes to the product owner in the app and by email, or to a Slack or Teams channel through a webhook. Alerts resolve on their own when the condition clears.
What the solution produces
Monitor alert to the payments owner (illustrative)
MessageWarning: Payment delays complaints crossed 150 this month (current 188).
Upheld rate for this cause: 58%, against 41% across all causes.
Most affected journey step: outbound payments over a weekend.
Open the dashboard filtered to this cause to see the complaints behind it.
Reporting and access
A scheduled report sends the dashboard to the complaints forum monthly as a PDF. A text panel at the top holds a short narrative of what moved, generated by AI from the panels and edited by the complaints lead before the send date.
Row-level access policies limit each product owner to their own products, and complaint-level detail can be restricted to the complaints team while others see totals.
What the change could be worth
A complaints team where one root cause starts generating 150 extra complaints a month.
| Assumption | Value |
|---|---|
| Extra complaints a month from the growing cause | 150 complaints / month |
| Weeks from spike to fix with monthly manual analysis | 13 weeks |
| Weeks from spike to fix with the dashboard | 6 weeks |
| Handling cost per complaint, before redress | 120 GBP |
- sooner from complaint spike to fix: Weeks from spike to fix with monthly manual analysis − Weeks from spike to fix with the dashboard
- complaints avoided per spike: Extra complaints a month from the growing cause × (Weeks from spike to fix with monthly manual analysis − Weeks from spike to fix with the dashboard) × 12 ÷ 52
- handling cost avoided per spike: Extra complaints a month from the growing cause × (Weeks from spike to fix with monthly manual analysis − Weeks from spike to fix with the dashboard) × 12 ÷ 52 × Handling cost per complaint, before redress
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
How to measure it
6 weeks
Time from spike to fix
Down from a quarter when causes surface monthly by hand.
92%
Complaints with a confirmed root cause
Handlers confirm the suggested tag before closing.
1 pack
Monthly forum report
Scheduled from the dashboard, not rebuilt in slides.
Illustrative example. Figures show how the workflow is measured; they are not customer results.
Controls and governance
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
GDPR ready
Retention from one day to five years, deletion and access controls support GDPR obligations. Ready means the controls are in place, not a certification.
More on how Agent Serve handles access, data and audit on the security page.
Where to start
Start with the taxonomy, not the dashboard. If your team cannot agree on 20 to 30 root causes, no chart will help. Then tag the last six months with the workflow, have handlers review a sample, and build the four tiles and the ranked table first. Add rules and monitors once the forum has used the view for a cycle. If many of your complaints start on the phone, the complaint detection on calls setup feeds the same table.
From complaint records to root cause view
Data · Complaints and tagging
- 01Complaints systemComplaint records arrive by API, database connection or a scheduled CSV import.
- 02Root cause taggingAn Agent block suggests a root cause from your taxonomy; handlers confirm or correct it.
- 03Complaints tableOne row per complaint with product, journey step, root cause, outcome and dates.
- 04Repeat-issue rulesRules flag repeat complainants, redress above a level and causes tagged as systemic.
Dashboard · Root cause view
- 05Root cause dashboardKPI tiles, a cause trend, a pivot by product and journey step, and a drill-through table.
- 06Cause monitorsAlert owners when a cause crosses a threshold or a rule matches too many rows.
- 07Monthly packA scheduled PDF to the complaints forum, with a written summary on top.
What you need
- Complaint records with product, channel, dates, outcome and redress amount
- A root cause taxonomy your complaints team already agrees on, ideally under 30 causes
- A journey map for your main products, so each complaint can be placed at a step
- Named owners for each product or journey who will receive alerts
- Thresholds for each monitor, agreed with the complaints forum
- Decisions on who sees complaint-level detail and who sees totals only