An IVR opt-in must log the prompt, the keypress, the time and the call
The requirementstatement
Every consent record must carry the prompt version played, the digit or spoken answer captured, the timestamp and the call identifier.
- Severityseverity
- BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
- 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
- FTCCTIApractice
- When it appliesapplicabilityText
- Applies when consent was collected by IVR.
Why this rule existsrationale
An IVR consent leaves no human witness on either side, so the log is the entire record — and unlike a live agent, an IVR can be misconfigured to accept any keypress as agreement and will do it identically to everyone who calls. All four fields are needed together: the prompt says what was asked, the captured input says what was answered, and the call identifier is what ties the pair to a person.
How to fix itremediation
Log all four values on every IVR consent: the prompt version played, the DTMF digit or recognised phrase captured, the timestamp, and the call identifier. Done when one log line lets you replay what was asked and what was pressed.
A compliant exampleexample
IVR opt-ins log: prompt_version=ivr-optin-v4, captured_input=DTMF 1, captured_at=2026-03-04T14:22:11Z, call_id=UCID-88213004.
Notesnotes
Registration-side twin of a runtime log. We judge the description of the log, never the log. The four elements are one record judged in one pass rather than four rules, because they fail together: a log missing any one of them cannot reconstruct a single consent.
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-261Only the charity may use the numbers a charity collectsBlockingBLOCKINGOPS-199Consent records must capture all seven required fieldsHighHIGHOPS-207The consent record must name the page the opt-in came fromHighHIGH
OPS-236 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.