A spoken consent record must name the agent who took it
The requirementstatement
Every consent record must carry the identifier of the agent who read the consent script.
- Severityseverity
- MediumMEDIUMUsually survives review, but lowers your trust score or invites a manual look you would rather avoid.
- When it bitesphase
- Gates approvalapprovalGet this wrong and the brand or campaign is refused at registration.
- What is checkedobject
- campaign.message_flow + privacy policy
- Where it liveslayer
- OperationalOPERATIONAL
- How Ekas settles itdetectability
- AI · formAI_FORM
- A semantic question about what you wrote: whether a description matches a use case, whether a name looks like a filed entity. Judged by a model against written criteria.
- What the fix involvesfailureClass
- Fix the fieldRETRY_FIELD
- A better value in the form fixes it. Ekas can rewrite it and re-check.
- Who requires itauthorities
- FTCpractice
- When it appliesapplicabilityText
- Applies when consent was collected by live verbal.
Why this rule existsrationale
A verbal opt-in has no artifact the consumer touched, so the whole evidentiary weight sits on the call. Naming the agent is what makes the record investigable: it is how a brand finds out that one agent has been paraphrasing the script, and how it shows a regulator that it looked. Contact centres omit it because the CRM records the account owner rather than whoever was on the call.
How to fix itremediation
Store the agent identifier — the login, extension or badge number of the person who read the script — on each verbal consent record. Done when any consent record names a specific person, not a team or a queue.
A compliant exampleexample
Verbal opt-ins store agent_id: acme-cs-0142 with the call UCID and the script version read.
Notesnotes
Registration-side twin: we judge whether the programme describes storing the field, never whether the stored record exists.
Rules you will hit next
6 other rules read campaign.message_flow + privacy policy. Fixing one field to satisfy a single rule is how a resubmission trades one rejection for another, so read these before you change anything.
OPS-056Opt-out records must keep the words the consumer actually sentBlockingBLOCKINGOPS-085The programme must scrub deactivated numbers before sendingBlockingBLOCKINGOPS-210Telemarketing consent must retain the request, its purpose and the answerBlockingBLOCKINGOPS-236An IVR opt-in must log the prompt, the keypress, the time and the callBlockingBLOCKINGOPS-261Only the charity may use the numbers a charity collectsBlockingBLOCKINGOPS-199Consent records must capture all seven required fieldsHighHIGH
OPS-233 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.