IOSOR

IOSOR Learn

STOP and HELP on a rented DID: a policy support can defend

How B2B teams write STOP/HELP keyword policy on rented numbers — ownership, wording, audit logs, and prepaid honesty without a third-party portal habit.

Keywords are not cute autoresponders. On a rented DID that can receive replies, STOP and HELP are compliance and brand policy — the scripts support must be able to defend at 02:00 without inventing tribal knowledge. Two-way messaging without that policy becomes a quiet incident queue.

IOSOR keeps inbound on the same white-label prepaid surface as outbound: your brand relationship, your inbox path, your wallet — not day-to-day ops trapped in a third-party portal.

Keywords are policy, not a bot side-quest

Product, legal, and support should sign one page before the first conversational send:

Keyword Required outcome Owner
STOP / unsubscribe Opt-out honored promptly; logged Compliance + messaging ops
HELP / info Brand-safe path: hours, channel, escalation Support lead
START / resume (if used) Re-opt only with clear consent language Product + legal
Campaign commands Optional; never override STOP Campaign owner

If STOP “usually works,” you do not have a policy — you have luck.

Write STOP language support can read aloud

STOP replies should be short, brand-facing, and unambiguous:

  • Confirm the opt-out applied to this program / identity
  • Say what stops (alerts, marketing class, this DID thread)
  • Point to a human path if the customer still needs help
  • Avoid dumping technical IDs or third-party brand names

Log: who sent STOP, which DID, when it was honored, which outbound classes are blocked. Support escalations must pull that log from your platform — not a screenshot chase.

HELP that matches your real hours

HELP is where brands over-promise.

  1. Actual support hours and timezone
  2. Channels you staff (email, chat, callback) — not fantasy
  3. What the customer should include (last 4 of the number, order id)
  4. A next step if nobody is online

A rented DID that answers HELP with a dead email address trains users to complain louder on social — and burns trust faster than a late OTP.

Ownership and the audit trail

Name a primary owner and a backup. When STOP fails in production, it is a compliance incident, not a “tweak the bot” ticket.

Require:

  • MO webhook or inbox event your stack can verify
  • Idempotent handling (retries happen)
  • Correlation: inbound keyword → customer id → suppression state
  • Retention rules for keyword bodies that may contain PII

White-label means agents stay in one commercial surface. “Check the other portal” is not an operating model.

STOP/HELP collapse when receive and send are treated as unrelated SKUs.

Red flags

  • STOP reply that names another company’s portal
  • HELP hours that do not match staffing
  • No log of when opt-out was honored
  • Keywords edited live by marketing without compliance review
  • Live conversational claims while inbound is still in setup
  • Client errors that dump upstream brands

Start with IOSOR

Draft one page of STOP and HELP that support can read aloud on the rented DID. Wire both keywords, prove one audit row each, and name after-hours HELP. This is spoken policy on one number, not tenant opt-out list isolation, not ingest spam scoring, and not a two-way inbox architecture.

Related: inbound auto-reply loops Buffer Inbound Webhook Processing Against Carrier Latency Spikes Prepaid hold before first debit.

IOSOR takeaway

STOP and HELP are a spoken policy on a rented DID, not a multi-tenant opt-out sync job.

Do: write wording support can read and prove the audit row. Don't: treat keywords as a bot side-quest or sync another tenant's opt-out list here.

Was this guide helpful?

Related guides