A help request containing a stop-word is not an opt-out

The requirementstatement

An inbound message whose intent is a question must not be treated as a revocation merely because it contains a stop-word.

Severityseverity: MediumMEDIUMUsually survives review, but lowers your trust score or invites a manual look you would rather avoid.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: inbound message intent classification
Where it liveslayer: OperationalOPERATIONAL
How Ekas settles itdetectability: Post-submissionUNDETECTABLE_PRE_SUBMISSION; The subject does not exist yet at submission time: a reply window, an expiring PIN, a queue position. Reported with its deadline.
What the fix involvesfailureClass: Wait on someone elseTERMINAL_EXTERNAL; Needs an external system or a waiting period, such as IRS propagation, a vetting result, or a carrier queue.
Who requires itauthorities: T-Mobile
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

This is the false-positive edge of the previous rule, and it is worth its own line because over-correcting is its own harm: "I cannot get my device to stop buzzing, can you help?" is a customer asking for support, and silently unsubscribing them loses the notifications they wanted and answers nothing. Teams tune aggressively for recall after a complaint and create this second failure a month later.

How to fix itremediation

Where the intent check is uncertain, prefer the interpretation the consumer can correct: answer the question and ask whether they also want to stop, rather than suppressing silently. Done when a support question containing the word "stop" produces a reply rather than a silent unsubscribe.

A compliant exampleexample

Inbound "how do I stop the duplicate texts, is something broken?" → question, not revocation → HELP response plus an explicit offer to unsubscribe.

Check this yourselfattestation

No tool can settle this one for you. Here is the check, and what wrong looks like.

Does a support question containing the word "stop" produce a reply rather than a silent unsubscribe?

1Send "I can't get my device to stop buzzing, can you help?" to your own programme.
2Confirm it is answered. Where the intent check is uncertain, the safe design is to act and say so — answer the question and ask whether they also want to stop.

What wrong looks like: A team tunes aggressively for recall after a complaint and creates the opposite failure a month later: customers silently unsubscribed from notifications they wanted, and their question unanswered.

Notesnotes

The judgement lives in a classifier we cannot see. What the user has to decide is which way their handler errs and whether the consumer is told — a silent suppression is invisible to everyone, so the safe design is to act and say so.

Rules you will hit next

One other rule reads inbound message intent classification. 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-031A plainly-worded opt-out counts even with no keyword in itBlockingBLOCKING OPS-042Somebody has to own revocations that arrive in conversationMediumMEDIUM OPS-050The opt-out confirmation is worth sending inside five minutesMediumMEDIUM OPS-051Only ask which messages to stop when there is more than one kindMediumMEDIUM OPS-057Log the sends you did not makeMediumMEDIUM OPS-062An opted-out consumer must be able to come backMediumMEDIUM

All operational rules

OPS-032 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.