Complaints · Time limits
MixedRetail banking serviceStop SLA breaches in the complaints queue before they happen
Most complaint breaches are visible weeks before they happen, in a queue nobody has time to read. Here is a setup that computes every deadline, flags risk early and puts the at-risk list in front of the right person.
Valnora & Elric team12 min read
- Team
- Retail banking complaints operations
- Manual steps today
- 5
- Build steps
- 10
- Review points
- 5
The problem
Complaint time limits are clear on paper. In the UK, for example, DISP 1.6.2R gives a firm eight weeks to send a final or interim response, and DISP 1.6.2AR sets shorter limits for payment services complaints. Other regimes set their own. The hard part is operational: thousands of open cases, handlers moving between teams, third parties who reply late, and an ageing report that is out of date by mid-morning.
Breaches are rarely surprises. A case that breaches on Friday usually stopped moving weeks earlier, when it lost its owner or waited on a merchant. The signal was in the queue; nobody had time to read it. Each breach then costs twice: the extra handling and remediation on the case itself, and the time leads spend explaining the number to the complaints committee instead of preventing the next one.
How retail banking complaints operations works today
Today, done by hand · Retail banking complaints operations
- 01Team leads export an ageing report from the case system each morning.
- 02They sort it in a spreadsheet and work out which cases are close to their time limit.
- 03Payment services complaints, with shorter limits, are picked out by hand.
- 04Leads message handlers about stuck cases and reallocate when someone is off.
- 05A weekly report counts breaches after the fact for the complaints committee.
Where it breaks
- The report is a snapshot, so a case that stalls after 09:00 is invisible until tomorrow.
- Cases left without an owner after a team move fall out of everyone’s view.
- Different leads calculate days left differently, especially around bank holidays.
- Holding letters are written from scratch under time pressure.
- Breaches are counted weekly, too late to prevent them.
In this illustrative scenario, a bank receiving 2,500 complaints a month closes 4% of them past the limit today, and most cases get about two days of notice before a deadline.
What the change could be worth
A retail bank complaints operation receiving 2,500 complaints a month, run by 12 team leads.
| Assumption | Value |
|---|---|
| Complaints received a month | 2,500 complaints |
| Share closed past the time limit today | 4% |
| Share closed past the limit with early warning | 1.5% |
| Extra handling and remediation cost per breach | 250 GBP |
| Team leads checking ageing reports | 12 people |
| Minutes a day each lead spends on ageing checks | 45 min |
| Minutes a day with the at-risk list | 10 min |
| Days of notice before a deadline today | 2 days |
| Days of notice with the breach-risk rule | 10 days |
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
The outcome you want
Every open complaint carries a computed deadline, risk is flagged days ahead, the right lead hears about it within the hour, and handlers get a reviewed holding letter where one is needed. Breaches drop because they are seen in time.
Acceptance criteria
- Every open complaint has a computed deadline and days left, refreshed every hour.
- Cases with five or fewer working days left and no final response in progress are flagged.
- The complaints lead gets a briefing within the hour of a case being flagged.
- Every holding letter is reviewed by a handler before it is saved to the case.
- Breach rate and at-risk count are on one dashboard, by team and product.
The solution end to end
The setup uses two workflows, a queue table, rules, metrics, monitors, a Relay and a dashboard.
The queue table and sync workflow. A workflow starts from a Schedule block every hour. A ServiceNow, Salesforce or API block reads complaints opened or changed since the last run. A Function block maps each complaint type to its time limit, applies your working-day calendar and computes the deadline and days left. A Table block upserts one row per complaint into the "Complaints queue" table. The case system stays the record; the table is a read copy built for deadlines.
Rules, metrics and the semantic model. A Classification (labels) rule sorts cases into Overdue, Due in 5 days, Due in 10 days and On track. A Flag (true / false) rule called "Breach risk" marks cases with five or fewer days left and no final response in progress. Governed metrics count open complaints and compute breach rate as the average of a closed-late marker the sync writes, and a Complaint entity in the semantic model ties them to team, product and complaint type.
Monitors. One monitor fires when the Breach risk rule matches any row, at Critical severity; a second fires at Warning when it matches more rows than your limit, a sign the whole queue is slipping rather than one case. Monitors have no built-in SLA check, which is why the deadline logic lives in the sync. Alerts show in the app and start the Relay. For a channel alert, a dashboard KPI alert on breach rate can notify Slack.
The Relay. The Breach reviewer is a Relay built from the Compliance Reviewer template, which starts when a monitor alerts and runs in Observe. It reads the queue and procedures, then writes a briefing for the complaints lead: which cases, why they are stuck, and a suggested owner or next step. It cannot write to the table, send email or contact customers.
The holding-letter workflow. Each weekday morning a second workflow picks up flagged cases, searches approved templates in the Knowledge Base, and drafts an interim letter with an Agent block. A Human block pauses the run; the handler opens the paused execution, edits the text, picks a Decision in the Resume Form and clicks Resume execution. The approved letter is attached to the case for the handler to send.
Dashboard and Chat. The dashboard shows open, at-risk and breached complaints with a previous-period comparison, and goes out each morning as a PDF. Team leads can ask Chat ad-hoc questions of the queue table, such as which cards complaints are due this week without an owner.
From complaint case to an early warning
Workflow 1 · Queue sync
- 01Every hourA Schedule block runs the sync during working hours.
- 02Read the case systemA ServiceNow, Salesforce or API block reads open complaints changed since the last run.
- 03Compute the deadlineA Function block applies the right time limit for the complaint type and counts days left.
- 04Complaints queueUpsert Row keeps one row per complaint with owner, stage, deadline and days left.
Rules, metrics and monitors
- 05Deadline band and breach riskA classification sorts cases by days left; a flag marks cases at risk of breaching.
- 06Breach-risk monitorsOne fires on any flagged case; one fires when the at-risk count passes your limit.
Workflow 2 · Holding letters
- 07Weekdays at 08:00A Schedule block picks up flagged cases with no final response in progress.
- 08Draft from templatesAn Agent block drafts an interim letter from approved templates in the Knowledge Base.
- 09Handler reviewsA Human block pauses until the handler edits and approves the draft.
- 10Save to the caseThe approved letter is attached to the case for the handler to send.
Relay · Breach reviewer
- 11Starts on a monitor alertBuilt from the Compliance Reviewer template, set to Observe.
- 12Brief the complaints leadLists each at-risk case, why it is stuck and a suggested owner or next step.
Dashboard · Queue health
- 13Complaints time limitsOpen cases, at-risk cases, breaches and breach rate by team and product.
- 14Team leads actLeads reallocate cases and chase evidence. Nothing reaches a customer unreviewed.
Build it
Start with the table and sync, and check computed deadlines against the case system before adding rules or alerts. The deadline mapping is the part compliance will want to see, so keep it in one Function block with a comment per complaint type.
Configure it step by step
- 01
Create the queue table
Tables → New table
- Table "Complaints queue": Case (Text), Team (Select), Product (Select), Complaint type (Select), Received (Date), Owner (Text), Stage (Select).
- Add Deadline (Date), Days left (Number), Final response in progress (Boolean) and Closed late (Number: 1 if closed after the deadline, else 0).
- 02
Build the sync workflow
Workflow builder → Schedule block
- Run frequency: Hourly. Timezone: your operations time zone.
- ServiceNow, Salesforce or API block: read complaints opened or changed since the last run.
- Function block: map complaint type to its time limit, apply your working-day calendar and compute Deadline and Days left.
- Table block, Upsert Row keyed on Case. Deploy.
- 03
Add the deadline rules
Rules → New rule
- Rule type: Classification (labels). Buckets on Days left: Overdue, Due in 5 days, Due in 10 days, On track. Fallback label: On track.
- Rule type: Flag (true / false), named "Breach risk". Condition: Days left is 5 or less and Final response in progress is false. Create rule.
- 04
Define the metrics
Metrics → New metric
- Metric type: Aggregate, Count (rows): "Open complaints". Display: Number.
- Metric type: Aggregate, Average of Closed late: "Breach rate". Display: Percent.
- 05
Map the complaint entity
Semantic model → New entity
- Name: Complaint. Table: Complaints queue. Synonyms: case, grievance.
- Attributes & dimensions: Team, Product, Complaint type. Measures: the two metrics above.
- 06
Add the monitors
Monitors → New monitor
- Rule match on "Breach risk", Threshold: 1 row. Check: Hourly. Severity: Critical.
- A second Rule match on "Breach risk", Threshold: 25 rows. Check: Hourly. Severity: Warning. Create monitor.
- 07
Create the breach reviewer Relay
Relays → New Relay
- Specialization: Compliance Reviewer. Name: "Breach reviewer". Create draft.
- How it works → Instructions: for each flagged case, explain why it is stuck and suggest an owner or next step. Do not contact customers.
- What it can use → Other resources: Complaints queue (Table), both rules, and the complaints procedures Knowledge base.
- Responsibilities → New responsibility → Trigger: When a monitor alerts. Monitor: the breach-risk monitor.
- Permissions → Autonomy: Observe. Result goes to: The task. Publish.
- 08
Build the holding-letter workflow
Workflow builder → Schedule block
- Run frequency: Daily. Time: 08:00. Table block, Query Rows where Breach risk is true.
- Knowledge block, Search: the matching letter template. Agent block drafts the interim letter.
- Guardrails block, PII Detection on the draft summary before it is posted to Microsoft Teams.
- Human block: Display Data shows the case and draft; Resume Form has a Decision field (Use draft / Edit / Not needed) and the final text.
- After Resume execution, the case system block attaches the approved letter to the case. Deploy.
- 09
Build the dashboard
Dashboards → New dashboard
- KPI cards: open complaints, at-risk complaints, breached this month, breach rate with Compare with: Previous period.
- Line chart: flagged at risk vs breached per week. Table: cases at risk with team, days left and stage.
- Filters → Add filter: Choice list for Team and Product, Date range for Received.
- 10
Limit each lead to their team and share
Dashboard Settings → Row security → Add policy
- Applies to: Complaints queue. Who: each team lead group. Rows they see: Team equals their team. Status: Enforced.
- Share → Subscribe…: Frequency Daily, Time 08:30, Format PDF, to the complaints lead and team leads.
- Share → New KPI alert…: breach rate, Goes above 2%, Notify: Slack.
What it produces
One case moving through the setup: the record in the case system, the queue row after sync and rules, and the briefing the complaints lead receives.
What the solution produces
Case as it sits in the case system (illustrative)
Record- Case
- C-48590 · Mortgages · received 12 Aug
- Category
- Payment applied late, arrears fee charged
- Owner
- Unassigned since handler moved team on 2 Sep
- Last activity
- 19 days ago
Queue row after sync and rules (illustrative)
Record- Time limit
- Eight weeks from receipt · deadline 7 Oct
- Days left
- 3
- Deadline band
- Due in 5 days
- Breach risk
- Yes · no owner, no final response in progress
Relay briefing to the complaints lead (illustrative)
Message4 cases flagged since 07:00. The most urgent: C-48590 (Mortgages, 3 days left) has had no owner since 2 Sep.
Suggested: assign to the mortgages team lead today and send a holding letter if a final response cannot be ready by 7 Oct. A draft is waiting in the holding-letter review.
C-48211 (Cards, 2 days left) is waiting on a merchant reply. Consider an interim response explaining the delay.
Where people stay in charge
Where people stay in charge
- Gate 1Compliance signs off the mapping from complaint type to time limit before the sync goes live.
- Gate 2The complaints lead decides on reallocation; the Relay only suggests.
- Gate 3A handler reviews every holding letter in the Human step before it is saved to the case.
- Gate 4Handlers send letters through the usual channel; no part of the setup contacts customers.
- Gate 5Team leads review the at-risk list daily and record actions in the case system.
The dashboard
Complaints time limits (illustrative)
Cases at risk
| Case | Team | Days left | Stuck at |
|---|---|---|---|
| C-48211 | Cards | 2 | Waiting on merchant |
| C-48590 | Mortgages | 3 | No owner |
| C-48704 | Current accounts | 4 | Awaiting evidence |
| C-48812 | Loans | 5 | Draft response |
Controls and audit
Every sync and holding-letter run records each block’s inputs, outputs and errors in Logs. Relay briefings and any proposed actions are written to the audit log, which admins can export. The Human step records who approved each letter. Row-level policies limit each lead to their team’s cases in tables, dashboards and scheduled reports, and the Guardrails block masks personal data before summaries reach Microsoft Teams. Sign-in runs through SSO with SCIM provisioning, and you can self-host. Zero data retention is available with supported model providers using your own keys or self-hosted models. Some provider features keep data on the provider’s side by design, such as Gemini Deep Research, so they are outside zero data retention.
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
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.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
More on how Agent Serve handles access, data and audit on the security page.
Roll it out
Shadow the morning ageing report for two weeks before anyone relies on the alerts. Put breach rate, at-risk count and days of notice on the dashboard from day one, so the complaints committee sees the trend.
Pilot, measure, expand
- Weeks 1–2
Shadow the ageing report
- Run the sync and rules alongside the morning export.
- Check computed deadlines against a sample of cases each day.
Done when: Computed deadlines match the case system for every sampled case.
- Weeks 3–4
Alerts and briefings
- Switch on the monitors and the Relay for one team.
- Tune the at-risk threshold so leads get warning without noise.
Done when: The pilot team lead works from the briefing instead of the export.
- Weeks 5–8
Holding letters and scale
- Add the holding-letter workflow with handler review.
- Extend to all teams with row-level access per lead.
Done when: Breach rate and at-risk count are reviewed from the dashboard at the complaints committee.
| Risk | How to handle it |
|---|---|
| A complaint type is mapped to the wrong time limit. | Compliance owns the mapping, the Function block keeps it in one place, and weekly samples are checked against the case system. |
| The hourly sync misses a change in the case system. | Run logs show every sync; a failed run is visible in Logs, and the case system stays the record. |
| Too many cases are flagged and leads ignore the alerts. | Start with a tight threshold for one team, review flagged-vs-breached on the dashboard and adjust. |
| A holding letter goes out with wrong details. | Every draft passes handler review in the Human step and uses approved templates only. |
Timings are an illustrative plan, not a commitment; your pilot sets the pace.
Before you start
What you need
- Read access to your complaints case system through its integration or an API
- The time limits that apply to each complaint type, agreed with compliance
- Your working-day calendar, including bank holidays
- Approved holding and interim letter templates
- A named complaints lead and team leads who own reallocation
- An agreed at-risk threshold in days, and a limit for the at-risk count
- Row-level access rules: which leads see which teams
Questions teams ask
Questions teams ask
Which time limits does the setup use?
The ones you configure. The Function block in the sync workflow maps each complaint type to its limit. In the UK, for example, DISP 1.6.2R sets eight weeks for a final or interim response, and DISP 1.6.2AR sets shorter limits for payment services complaints. Agree the mapping with compliance before you rely on it.
Do monitors have a built-in SLA check?
No. Monitors watch metrics and rules. The deadline logic lives in the sync workflow, which writes days left to each row, and a rule flags rows at risk. A monitor then fires when the rule matches.
Does anything contact the customer automatically?
No. The Relay runs in Observe, cannot send email and is told not to contact customers. Holding letters are drafted for a handler, who reviews them in a Human step and sends them through your usual channel.
Can team leads ask their own questions of the queue?
Yes. Chat can query tables, so a lead can ask which mortgage complaints are due in the next seven days without an owner. Row-level access still applies.
Does this replace our complaints system?
No. The case system stays the record. The queue table is a read copy refreshed every hour, used for deadlines, rules and the dashboard.
Related reading: a complaints root cause dashboard and detecting complaints on calls. Request access to try it on your own queue.