Most businesses that text customers store consent as a checkbox. Somewhere in the CRM there is a field called `sms_opt_in`, set to true. That field is a conclusion, not evidence. It tells you what somebody decided at some unspecified point, and nothing about who decided it, when, on what page, after reading what, or from which device.
That gap is an operations problem before it is anything else: what to capture at the moment of opt in, single or double opt-in, why the timestamp outweighs everything around it, how a stop request should propagate through your stack, and how to treat retention as a system design question. None of it replaces counsel on SMS compliance or on what counts as express written consent; it is the record-keeping underneath that advice.
One thing up front, and it is not boilerplate. This is product and operations guidance, not legal advice. What consent your program needs, what your disclosures should say, and how long you are obligated to keep anything are questions for qualified counsel who knows your business. What follows is about building a record good enough to hand to the lawyer you hire.
What a consent record actually is
Three things get collapsed into one word. The permission itself is a legal question and belongs to your attorney. The record of it is a data question and belongs to whoever owns your forms and your database. The enforcement of it is a systems question and belongs to whoever owns your sending infrastructure. Teams that treat all three as "compliance" tend to solve none of them, because the person who could actually fix the record is never in the room.
A consent record, in the operations sense, is the set of artifacts that lets someone reconstruct a specific moment later. This number, on this date at this time, on this page, after this text was on screen, submitted through this mechanism. Keep the boolean. It is a cheap index for your send logic. It just needs to point at something.
The fields worth capturing
Vendors who publish on this converge on a similar list. ActiveProspect, which sells consent documentation tooling, describes its TrustedForm Certify product as a JavaScript snippet that captures a page's DOM and the visitor's interactions during a form submission and returns a certificate URL, usually written into a hidden field named `xxTrustedFormCertUrl`. Buy tooling or build your own capture; the fields underneath are the same.
- —The number as entered, plus the normalized version you actually send to. Store both.
- —A timestamp to the second, in UTC, with the local offset recorded separately.
- —The source. Page URL including query string, form identifier, or for an inbound opt in, the keyword and the number it was sent to.
- —The exact wording that was on screen. Store the text, not a link to a page marketing will edit next quarter. This is the field teams most often skip and most often wish they had.
- —IP address and user agent for web submissions.
- —Mechanism and channel. Web form, inbound text, checkout, tablet at the counter, call logged by a rep, imported from a partner.
- —Which consent was given. One contact can carry several distinct permissions, and a bare "opted in" gets less useful the more programs you run.
- —The confirmation event, if your flow has one, with its own timestamp.
- —Provenance for anything not collected first party. Partner name, the contract it came under, any certificate or reference ID they supplied.
- —Every later event. Opt out, opt back in, number change, manual edit and who made it.
The structural rule underneath that list matters more than any single field: append, do not overwrite. Consent is a timeline, not a state. If your database updates a row in place when someone opts out, you have destroyed the record of the opt in you were trying to keep.
Why the timestamp is the whole ballgame
Nearly every other field can be approximated later. You can usually work out which form a lead came through, and old disclosure text sometimes survives in a git history or an archived page. What you cannot reconstruct is exactly when, and the timestamp is what turns a pile of fields into a sequence.
Sequence answers the questions that actually get asked. Did the opt in land before or after the page version with the shorter disclosure? Did Tuesday morning's message go out before or after the stop request that came in Monday night?
Three habits make timestamps trustworthy. Store UTC and keep clocks synced with NTP across every service that writes to the record, because a CRM and a messaging platform disagreeing by ninety seconds will eventually put a send before a stop in your own logs. Record both the event time and the time your system wrote the record, since the gap exposes queueing and backfills. And keep the timestamp on the immutable event row, not on a summary row something else can update.
Why reconstruction after the fact almost never works
Consent archaeology fails in boring, predictable ways. Pages change and form builders rarely version them, so the disclosure a visitor saw in March is gone by August. Web server access logs, where the IP would have been, are commonly rotated on a thirty day cycle. Lead partners get acquired or change their retention, and the file they sent was a three column CSV. The person who built the funnel has left. A tool gets swapped and the export drops fields nobody mapped.
What people call backfilling is usually inference presented as data, which is worse than an honest gap. If you cannot capture a field at the moment of opt in, record that you did not capture it.
Suppression that crosses channels
Stopping is where operations either works or quietly does not, and it helps to know what your infrastructure already does.
Twilio's documentation describes the platform layer: when it receives an opt out keyword, the number goes onto a blocked list checked before any outgoing message, and later sends fail asynchronously with error 21610. STOP, START, and HELP cannot be removed from a Messaging Service's keyword handling. Toll free US numbers carry an additional carrier level opt out layer that sits outside the platform entirely. Other providers implement broadly similar mechanics.
Good news for the message, bad news for your data, because a send failing at the carrier does not tell your CRM anything. The contact stays active in your dashboards, sits in your nurture segments, gets counted in your reporting, and gets exported into next quarter's list while every message to them dies in flight. The classic version is a number that stopped six months ago reappearing through a list import.
- —One authoritative store, not one per tool. Every sending system reads from it instead of keeping its own copy.
- —Propagation, not just blocking. A stop over SMS should mark the contact, pause the sequences, and flag segment membership, so what people see matches what the wire is doing.
- —Identity matching, not string matching. Normalize before you compare, or `973-555-0142` slips past an entry stored as `+19735550142`.
- —A defined scope. Does a stop cover this campaign, this brand, or every entity you operate? Decide that deliberately with counsel, then encode it once.
- —Every channel a stop can arrive on. People reply "take me off your list" to an email, say it on a call, or tell a receptionist. If the only path in is an SMS keyword, the rest vanish.
- —A standing test. Opt a test number out, then attempt a send from every system that can send, including your agency's. On a schedule, not once at launch.
- —Named reintroduction paths. List imports, partner files, CRM restores, and reactivation campaigns are how suppressed numbers come back. Each needs a check on the way in.
The same artifacts surface again while your numbers are being registered, since campaign reviewers commonly ask to see the opt in flow. Our guide to 10DLC registration covers that process.
Retention as an operations decision
How long to keep consent records is, at the boundary, a legal question. Vendors build products around multi-year windows: ActiveProspect markets a TrustedForm Retain tier described as storing certificates through the statute of limitations for marketing related laws. Your own window is something your counsel sets based on your jurisdictions, your industry, and your risk posture.
What operations owns is making that window real. Storage cheap enough that nobody quietly prunes it. Write-once behavior for consent events, with corrections recorded as new events rather than mutations. A short list of people holding delete permissions. And an answer for how a deletion request interacts with the retention window, which is a real tension worth raising with your lawyer before it is urgent.
Then the retrieval test, the one that matters in practice: can someone produce a chronological history for a single phone number, in a format a non technical person can read, on the day it is asked for, without an engineering ticket? A record you cannot pull is functionally a record you never kept.
What to ask your counsel
Bring questions, not guesses. A useful starting set:
- —What form of consent do our message types require, and does it differ by program or by state?
- —Does our current disclosure wording do what we believe it does?
- —How long should we retain consent records, and does that vary by data type or jurisdiction?
- —What scope does a revocation have across our brands, entities, and sending numbers?
- —How quickly must we act on a stop that arrives outside the messaging channel?
- —What are our obligations for numbers we acquire from partners rather than collect ourselves?
- —What is our process the day a demand letter arrives, and who owns it?
Regulators and industry bodies publish material directly, and it is worth reading for orientation. The FCC maintains a consumer guide titled "Stop Unwanted Robocalls and Texts" on fcc.gov, and adopted a Report and Order, FCC 24-24, on February 15, 2024 addressing consumer revocation of consent, with a limited waiver issued April 7, 2025 moving the effective date of certain revocation provisions to April 11, 2026.
CTIA publishes "Messaging Principles and Best Practices," the current published edition dated May 2023, which is an industry document rather than law. Read them. Let your counsel tell you what they mean for you.
How Kai handles stop requests
Kai is an AI texting agent. It responds, follows up, qualifies, answers questions, schedules appointments, and hands off to a person when a conversation calls for one. When somebody asks it to stop, it stops.
Two honest limits. Standard keyword handling lives at the messaging platform layer underneath Kai, which is where it should live, and no vendor removes it. What Kai adds is that a stop phrased as a sentence rather than a keyword, the "please don't text me again" that never trips a keyword matcher, is treated as what it is, and the conversation ends there.
The second limit is broader. FromKai does not decide what consent your program needed, does not collect that consent for you, and does not tell you how long to keep your records. Those stay with you and your counsel. What a platform can do is make sure that when someone says stop, the stopping is not the part that fails.
Frequently asked questions
What is an SMS consent record?
Operationally, it is the set of stored artifacts that let you reconstruct a specific opt in later: the number as entered, a precise timestamp, the source page or keyword, the exact wording shown on screen, the capture mechanism, and every later opt out or opt in event. That is different from the true or false consent flag in your CRM, which is a conclusion rather than evidence.
What fields should you log when someone opts in to texts?
Common practice is to capture the number in both entered and normalized form, a UTC timestamp to the second, the source URL or inbound keyword, the disclosure text as it appeared, IP address and user agent for web submissions, which program the person opted into, any confirmation event with its own timestamp, and provenance for numbers received from a partner. Write these as append only events rather than updating a row in place.
How long should you keep SMS consent records?
That is a question for your counsel, and it depends on your jurisdictions and industry. Vendors build for multi-year windows; ActiveProspect markets a retention tier described as storing consent certificates through the statute of limitations for marketing related laws. What operations should own is making the chosen window enforceable: durable storage, write-once event history, controlled delete permissions, and fast retrieval of a single number's full history.
What is an SMS suppression list and how should it work across channels?
A suppression list is the authoritative record of contacts that should not receive outbound messages. It works when one store is read by every sending system, numbers are normalized before matching, stops arriving on any channel including email or a phone call reach that same store, and list imports and reactivation campaigns are checked against it. Platform level blocking alone is not enough, because a send that fails at the carrier does not update your CRM.
Does an AI texting agent handle STOP requests?
Standard opt out keyword handling sits at the messaging platform layer beneath the agent. Twilio's documentation describes STOP, START, and HELP as keywords that cannot be removed from a Messaging Service, with blocked numbers producing error 21610 on later sends. An AI agent like Kai adds handling for stop requests worded as ordinary sentences rather than keywords, and ends the conversation there. Neither layer determines what consent your program required.
---
Sources: "Stop Unwanted Robocalls and Texts," Federal Communications Commission consumer guide, fcc.gov, accessed August 2026. Report and Order and Further Notice of Proposed Rulemaking, FCC 24-24, adopted February 15, 2024, and limited waiver order DA 25-312, April 7, 2025, Federal Communications Commission. "Messaging Principles and Best Practices," CTIA, May 2023 edition. "Customize users' opt-in and opt-out experience with Advanced Opt-Out," Twilio Docs, accessed August 2026, and "Twilio Support for Opt-out Keywords (SMS STOP Filtering)," Twilio Support, accessed August 2026. "TrustedForm Certify: Document leads' consent," ActiveProspect, accessed August 2026. This article is product and operations guidance and is not legal advice; consent requirements and retention obligations should be reviewed with qualified counsel.