Recognise the rights request buried in an ordinary support ticket, stamp the hour it arrived rather than the hour it was noticed, and route it to the named privacy owner who answers it.
A request arrives inside a thread about something else, and it is read as a request and not as a line.
02
A clock starts at the hour of receipt, and the days spent reaching the privacy team buy nothing.
Reason
03
A request uses a channel the controller published, and EDPB Guidelines 01/2022 count it as effective.
04
A request sent to a random or incorrect address carries no duty where a proper channel was provided.
05
A request comes in off a designated method, and 11 CCR 7020(e) leaves two answers and no silence.
Decide
06
A clock is extended, and Article 12(3) puts the notice and its reasons inside the first month.
07
A request is logged with the manner it was made in, and 11 CCR 7101 keeps that for twenty-four months.
Out
08
A request is recognised, and the ticket owner is told what was found, never what to do about it.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Recognition, the hour of receipt and the clock belong to the agent. Validity, identity, disclosure, refusal and the answer belong to a named privacy owner.
Example workflow
One ticket, arrival to routing
AgentHuman
1Support message receivedEmail, chat, web form, a social channel or a reply inside an open ticket
2Hour of receipt stampedThe channel it came in on, the hour it arrived and the thread it was sitting inside
3Rights request recognisedThe right invoked, the regime that applies, the clock and confidence
4Controls appliedChannel-duty checks, regime checks, extension-notice checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and none of them answers a request — the agent is recognising, and the privacy owner lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the named privacy owner.
Low confidence
Adds a second reader first.
Privacy owner review
The request is held with the hour it arrived, the regime read on it and the clock it started.
Take ownership · Reclassify · Send to counsel review
Taken — by the named privacy owner▼
6Request register updatedOnly where write access and records policy allow it
7Outcome evaluatedRecognition accuracy, clock accuracy, extension notices and what review found
Corrections
Each privacy-owner correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Deciding that a request is valid.
Verifying who the requester is.
Deciding what is disclosed or erased.
Refusing a request, on any ground.
Automation boundaryAgent acts unaided
✓Read each inbound support message against the recognition rules in use.
✓Stamp the hour of receipt and the channel that carried the request.
✓Tell the ticket owner what the agent thinks it found.
✓Track each clock against the regime that applies to it.
Nothing is answered, refused or verified here; a named privacy owner does all of it.
Answering a rights request, in any form.
Taking the extension and writing its reasons.
Ruling a channel outside the duty.
Changes to recognition rules or clock settings.
Example output
One rights request, annotated
This serves a support team who may have to show when a clock started — one month under the GDPR, forty-five days under 1798.130(a)(2)(A); below is one request as the agent leaves it.
Recognition output · single ticketIllustrative example
Ticket
Line recognised
Hour of receipt
Channel of record
Confidence
Right invoked
Refund thread
and while you are at it, delete my account and everything you hold on me
14:20, 3 August 2026
Published support inbox
Above threshold
Erasure, on the agent reading
As receivedTaken from the ticket as it arrived — nothing on this side is written by the agent.
Signals usedTicket textChannel of recordArrival timestamp
Why this flagThe clock ran from the hour it arrived, and a named person decides.
ActionTake ownershipReclassifySend to counsel review
What the score decidesBelow the configured threshold the flag picks up a second read before the owner sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every inbound messageFrom the ticket as it arrived
03Recognition
Recognise, then hand over
The vehicle data-privacy consent agent captures consent in a car and the ticket-deflection agent answers the ticket; this one recognises what the ticket actually is, and when it arrived.
01Approved path
The clock started at the ticket
One month, or forty-five days in California — each extendable once, with notice inside the first period.
02Human review
What was checked, and not found
Checked across the regimes surveyed: no action anywhere names arrival through a published support channel rather than a portal as the failure mode. The closest located is an Estonian reprimand of 12 May 2025, where requests to a general address were inadvertently rejected by the privacy team through human error. Under the GDPR there is no request-log duty at all, only the accountability articles; the one record duty found is Californian, at 11 CCR 7101, and it contemplates a ticket.
04Build an evidence trail
The request, the hour it arrived and the person who answered it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Ticketing and support desksZendesk · Freshdesk · Front Salesforce Service Cloud · Gladly
Shared inboxesMicrosoft 365 · Google Workspace Support and legal aliases
Privacy and rights toolingOneTrust · TrustArc · Transcend Rights-request case and log records
Agent
Rights-request recognition and intake
Reads the ticket Recognises the request Holds for the privacy owner
Chat, social and voiceLive chat · WhatsApp · Messenger Social inboxes and call summaries
A right-level recognition figure can read clean while erasure asked for mid-thread carries most of the misses. Nestack reports the miss rate by right invoked, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Erasure asked mid-thread
12.9%
3.7×
Review
Access worded as a complaint
9.2%
2.6×
Review
Requests arriving by voice
5.8%
1.7×
Watch
Requests on the privacy form
2.8%
0.8×
Normal
Bar: miss-rate lift vs. privacy-form baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What an unrecognised sentence costs
A cycle ends when the request that sat unrecognised is a standing case. That suite is what the next ticket routed is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Recognition misses rise on one inbound channel.
02Diagnose
The sentence in the middle of a support thread asking for everything you hold, answered about the refund and closed, is worked backwards until one cause is left standing.
03Improve
The change ships numbered, and the rights requests that forced it ride with it.
04Verify
One rights-request case still failing is enough to hold the release back.
05Learn
It is kept for good, and the recognition rules are amended in the same commit.
Learn → DetectThe return edge. The next ticket is read against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, channels, recognition workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Rights-request discovery and automation-boundary work.
02Ticketing, inbox and chat source assessment.
03Recognition-to-clock and multi-regime clock mapping.
04Support-message ingestion.
05Recognition logic and channel-duty binding.
06Confidence scoring and owner routing.
07Privacy owner review workflow.
08Ticketing-and-inbox integration.
09Recognition and clock cases.
10Guardrails and routing controls.
11Request-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne queue, one regimeProductionProduction support systemsAdvancedMultiple queues / regimes
Introduced at Pilot
Recognition to your channel rules✓✓✓
Privacy owner routing✓✓✓
Inbound-channel baseline✓✓✓
Introduced at Production
Reporting by right invoked—✓✓
Privacy review workflow in your systems—✓✓
Approved write-back—✓✓
Ticketing-and-inbox integration—✓✓
Introduced at Advanced
Multi-jurisdiction rule sets——✓
Multi-stage privacy approvals——✓
High ticket volume——✓
Multi-regime clock controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, ticket volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your inbound channels and the queues they land in→Channel mapping and hour-of-receipt captureWeek 1
02Representative tickets from each channel→Message ingestion, recognition logic and the intake baselineWeek 2
03The regimes you answer under and who owns each→Channel-duty mapping, regime binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Ticketing, inbox and chat assessment, then integration setupWeek 2
05Tickets you would not want re-read→Recognition cases and failure-mode testingWeek 4
06What no ticket may postpone→Confidence scoring, owner routing, guardrails and release controlsWeek 3
07A named privacy owner who takes the request→Privacy owner routing, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Every band below is measured; the fifth carries two phases because those two genuinely coincide.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Channel discovery, regime binding and the automation boundaryW2Ticketing and inbox integration and the intake baselineW3Recognition workflow, clock logic and routing controlsW4Evaluation suite, recognition cases and failure-mode testingW5Ticketing integration, pilot tickets and targeted correctionsW6One request cycle run under the privacy owner, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6When the request record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Customer Support AI agent
Build a rights-request intake agent around the queue those requests actually arrive in.
Show us one week of closed tickets and the channel each arrived on. The clock started at the hour a request was received, not at the hour somebody in privacy read it. A request that reached a channel you published is a request you were given.
