IOSOR

IOSOR Wiedza

STOP i HELP na wynajętym DID: polityka, którą support potrafi obronić

Jak zespoły B2B piszą politykę słów STOP/HELP na wynajętych numerach — ownership, brzmienie, logi audytu i uczciwość prepaid bez nawyku third-party portal.

Słowa kluczowe to nie urocze autorespondery. Na wynajętym DID, który może przyjmować odpowiedzi, STOP i HELP to polityka zgodności i marki — skrypty, które support musi umieć obronić o 02:00 bez wymyślania wiedzy plemiennej. Dwukierunkowa wiadomość bez tej polityki staje się cichą kolejką incydentów.

IOSOR trzyma inbound na tej samej powierzchni white-label prepaid co outbound: Wasza relacja marki, ścieżka inbox, portfel — bez codziennych ops uwięzionych w third-party portal.

Keywords to polityka, nie side-quest bota

Produkt, legal i support powinny podpisać jedną stronę przed pierwszym conversational send:

Keyword Wymagany wynik Owner
STOP / wypisz Opt-out szybko honorowany; zalogowany Compliance + messaging ops
HELP / info Ścieżka brand-safe: godziny, kanał, eskalacja Lead supportu
START / wznów (jeśli używane) Re-opt tylko z jasnym językiem zgody Produkt + legal
Komendy kampanii Opcjonalne; nigdy nie nadpisują STOP Owner kampanii

Jeśli STOP «zwykle działa», nie macie polityki — macie szczęście.

Napiszcie język STOP, który support przeczyta na głos

Odpowiedzi STOP powinny być krótkie, skierowane na markę i jednoznaczne:

  • Potwierdźcie, że opt-out dotyczy tego programu / tożsamości
  • Powiedzcie, co się zatrzymuje (alerty, klasa marketingu, ten wątek DID)
  • Wskażcie ścieżkę ludzką, jeśli klient nadal potrzebuje pomocy
  • Unikajcie zrzucania technicznych ID lub marek osób trzecich

Log: kto wysłał STOP, który DID, kiedy honorowano, które klasy outbound są zablokowane. Eskalacje supportu muszą wyciągnąć ten log z Waszej platformy — nie z polowania na screenshoty.

HELP zgodny z realnymi godzinami

HELP to miejsce, w którym marki obiecują za dużo.

  1. Rzeczywistych godzin supportu i strefy czasowej
  2. Kanałów, które naprawdę obsadzicie (e-mail, chat, callback) — nie fantazji
  3. Tego, co klient ma podać (ostatnie 4 cyfry numeru, id zamówienia)
  4. Następnego kroku, jeśli nikt nie jest online

Wynajęty DID odpowiadający HELP martwym e-mailem uczy użytkowników głośniej narzekać w social — i pali zaufanie szybciej niż spóźnione OTP.

Ownership i ślad audytu

Nazwijcie primary owner i backup. Gdy STOP pada w produkcji, to incident compliance, nie ticket «podkręć bota».

Wymagajcie:

  • Webhook MO lub zdarzenie inbox, które Wasz stack potrafi zweryfikować
  • Idempotentną obsługę (retry się zdarzają)
  • Korelację: inbound keyword → id klienta → stan suppressions
  • Reguły retencji dla treści keyword, które mogą zawierać PII

White-label oznacza, że agenci zostają na jednej powierzchni komercyjnej. «Sprawdź inny portal» to nie model operacyjny.

Czerwone flagi

  • Odpowiedź STOP nazywająca portal innej firmy
  • Godziny HELP niepasujące do obsady
  • Brak logu momentu honorowania opt-out
  • Keywords edytowane live przez marketing bez review compliance
  • Live claimy conversational, gdy inbound jest jeszcze in setup
  • Błędy klienta zrzucające marki upstream

Start z IOSOR

Napiszcie jedną stronę STOP i HELP, którą support przeczyta na głos na wynajętym DID. Podłączcie oba słowa, udowodnijcie po jednym wierszu audytu i nazwijcie HELP poza godzinami. To mówiona polityka na jednym numerze, nie izolacja list rezygnacji najemców, nie ocena spamu na wlocie i nie architektura dwukierunkowego inbox.

Powiązane: pętle auto-odpowiedzi inbound Buforowanie webhooków przychodzących w celu radzenia sobie ze szczytami opóźn… rezerwacja środków prepaid przed pierwszym obciążeniem.

Podsumowanie IOSOR

STOP i HELP to mówiona polityka na wynajętym DID, nie synchronizacja rezygnacji między najemcami.

Róbcie: napiszcie brzmienie, które support przeczyta, i udowodnijcie wiersz audytu.

Czy ten przewodnik był pomocny?

Powiązane przewodniki