A statutory clock nobody can see

The situation

Complaints arrive by several routes, and the response deadline is set by rule rather than by preference. Each one needs acknowledgement, investigation, a decision, a final response letter and, in aggregate, a periodic return to the regulator. Today they live in a mailbox and a spreadsheet, and the deadline is a column somebody sorts by.

These are illustrative scenarios showing how the products are used, not customer case studies.

What gets modeled

The structure as it would actually be defined — sections that repeat are marked.

How it gets built

In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.

1. 1

   Model the complaint as it is actually decided

   One complaint can raise several issues, each upheld or not on its own and each carrying its own redress, so issues repeat. A single outcome field on the complaint would have made the regulatory return impossible to produce without re-reading every case.

   What it uses: Repeating sections

2. 2

   Use the regulator’s categories, not your own

   Category reads live from the taxonomy record type, so when the regulator revises it the change is made in one place and every form, validation and report sees it on the next read.

   What it uses: Live option sources

3. 3

   Accept complaints from every route

   The portal writes through the record type’s own REST URL space, and other systems raise one with a signed HTTPS call using per-source secrets you rotate. Repeat deliveries of the same event are recognized and ignored, so a resent message does not open a second case.

   What it uses: Its own API on publish, signed external triggers, and repeat-event recognition

4. 4

   Start the clock as data, not as a column

   A trigger starts the run when the complaint is created. Deadline warnings fire against the statutory limit while the case is open, and escalation moves it on when it is at risk — before the breach rather than in the report about it.

   What it uses: Record triggers, deadline warnings and escalation

5. 5

   Investigate with the record in front of you

   A step reads the related account or policy record mid-run so the investigator sees what is true now, and results are written back onto the complaint. Where the case touches records in your own systems, the same step reads those instead.

   What it uses: A step that reads and writes the record mid-run, including your own systems

6. 6

   Decide each issue on its own

   The decision step uses your own outcome vocabulary and reason codes, and the decision chooses the outgoing path — upheld, partly upheld and rejected are genuinely different routes rather than one route with a flag. The record can be locked while it is under review.

   What it uses: Your own decision vocabulary, with the decision choosing the path

7. 7

   Send the final response and keep what was sent

   The letter goes out as a mapped step, the reference and sent date are written back, and the document is attached to the complaint through a short-lived signed upload link. What the complainant was told is part of the case rather than a copy in a mailbox.

   What it uses: Mapped step inputs, and direct-to-storage upload with signed links

8. 8

   Produce the return without a reconstruction

   Because outcomes and redress are typed fields on repeating issues, the periodic return is a filtered export of the record type rather than a rebuild. Every published version can be exported as CSV or JSON.

   What it uses: Typed fields with filtering, and export per published version

Numbers used above, and where they come from

Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.