Stop Ledger
A log of every text-message opt-out a small business receives, with the deadline to honor each one.
Stop-Ledger
A log of every text-message opt-out a small business receives, with the deadline to honor each one.
Date: 2026-11-05 Form factor: web app Status: Prototype
What it is
Stop-Ledger reads the replies that come back from a business's text campaigns and flags the ones that read as opt-outs. That includes "STOP", but also "please stop texting me about sales" and "wrong number, leave me alone". Each opt-out gets a 10-business-day clock, a suggestion for which lists it covers, and a one-click suppress button.
Who it serves
The owner or office manager of a small clinic, salon, gym or home-services shop that texts appointment reminders and promotions through a basic SMS tool. They know "STOP" has to work. They are less sure what to do with a free-text "I'm done with these", or whether an opt-out on promos also has to stop reminders. Today that is handled by whoever happens to read the inbox.
Why it could be profitable
Model: flat monthly subscription for small businesses (something like $29–$79 depending on message volume), with a higher tier for agencies running several client accounts. It would sit alongside an existing SMS provider, not replace it.
The timing: the FCC's 2024 order says consumers can revoke consent to calls and texts by any reasonable means, and that revocations must be honored within 10 business days. Per a National Law Review report dated 2026-01-07, the "revoke-all" part (an opt-out on one message applies to all of that sender's automated messages) was pushed to 2027-01-31, while the other parts were already in effect. TCPA claims are a familiar litigation risk for small senders, which is the reason someone might pay for this.
The thin spots: I did not verify the penalty figures or the current litigation volume, so the size of the market is a guess. Many SMS platforms already handle the plain STOP keyword, so the product only matters for free-text opt-outs, cross-list scope and audit records. Whether owners will pay for that, instead of treating it as a settings page in their existing tool, is untested. This is not legal advice and a real product would need a lawyer reviewing the rules engine.
Form factor & scope
Web app. The prototype is a single page with a canned inbox and a keyword matcher. It has no SMS integration.
How to run it
- Open
index.htmlin any modern browser. - Opening from
file://uses a small embedded fallback dataset. To see the full 12-message set fromsample-data.json, serve the folder (for examplepython3 -m http.server). - Toggle "Simulate revoke-all" to see the scope text change, and type into "Test a reply" to try your own wording.
What's in this prototype
- Reply inbox with opt-out detection, filterable by all / opt-outs / not yet suppressed / overdue
- Deadline math: 10 business days from receipt, skipping weekends and listed holidays, measured against a fixed demo date of 2026-11-05
- Status tags (suppressed, days left, overdue) and a Suppress button that moves a number to the suppression list
- Scope hint per opt-out, which changes under the revoke-all toggle, and a "scoped request" flag for messages like "stop the reminders but I still want promos"
- Reply tester for checking phrasing
Roadmap
- Import from common SMS providers' exports or webhooks
- Better intent detection than a keyword list, with a human-review queue for ambiguous replies
- Exportable audit trail showing when each opt-out was received and honored
- Quiet-hours and consent-record checks before a campaign sends
- Multi-client view for agencies
Sources
- https://natlawreview.com/article/breaking-fcc-pushes-back-tcpa-consent-revocation-rule-new-effective-date-now — revoke-all delayed to 2027-01-31; other revocation parts already in effect (article dated 2026-01-07)
- https://www.lewissilkin.com/insights/2026/08/10/the-consumer-law-revolution-continues-spring-forward-spring-back-subscription-102ngsk — context on consumer-messaging and subscription rules tightening in the UK from January 2027 (adjacent, not the basis of this prototype)
Requirements
Stop-Ledger — Requirements
Goals
- A user can see at a glance which customer replies are opt-outs and which are overdue.
- No opt-out is left without a visible deadline.
- The scope of each opt-out (one list vs. all lists) is stated, not assumed.
Primary user
Owner or office manager of a small service business sending appointment and promotional texts. They check the reply inbox a few times a week and need to know what must be suppressed and by when.
Functional requirements
- FR1: Load replies (phone, received date, text, list, suppressed flag) from
sample-data.json, with an embedded fallback if fetch fails. - FR2: Classify each reply as opt-out or normal using a phrase list, and show the matched phrase.
- FR3: Compute a deadline of 10 business days after receipt, excluding weekends and listed holidays.
- FR4: Show days remaining or days overdue relative to a fixed demo "today".
- FR5: Show summary counts: replies, opt-outs, not suppressed, overdue.
- FR6: Filter the inbox by all / opt-outs / not suppressed / overdue.
- FR7: Sort by urgency (fewest days left first).
- FR8: A Suppress button moves a number to the suppression list and updates counts.
- FR9: Display a scope hint per opt-out; a toggle switches it between per-list and all-lists.
- FR10: Flag opt-outs containing qualifiers ("but", "still want", "only") as scoped requests needing review.
- FR11: A free-text tester reports whether typed text reads as an opt-out.
- FR12: Escape all message text when rendered.
User stories
- As an office manager, I want overdue opt-outs at the top, so that I handle the riskiest ones first.
- As an owner, I want "please stop texting me" recognized, so that I don't depend on customers typing STOP.
- As an office manager, I want one click to suppress a number, so that it takes seconds.
- As an owner, I want to see which lists an opt-out affects, so that I don't keep sending reminders to someone who left.
- As an owner, I want ambiguous replies flagged, so that I can ask rather than guess.
- As an owner, I want to test how a phrase is read, so that I understand the tool's limits.
Non-functional requirements
- Runs from
file://with no build step, no network calls beyond the local JSON. - Keyboard-usable controls and labelled inputs.
- Data stays in the page; nothing is transmitted.
Out of scope (for the prototype)
- Real SMS integration or sending
- Persisting state across reloads
- Legal determinations; the phrase list is illustrative
Open questions
- Which SMS providers expose reply data well enough to integrate with?
- How should "cancel" in an appointment context be told apart from an opt-out?
- Do small senders pay for this, or do they expect it from their SMS provider?