IOSOR Gabay

Mga loop ng inbound auto-reply: paano binabakante ng echo ang prepaid na wallet

Paano pinananatiling tapat ng B2B ang dalawang-daang SMS — STOP/HELP bilang patakaran, kisame ng auto-reply, disiplina ng inbound webhook, at bakit sinusunog ng walang hangganang echo ang prepaid.

Ang inbound auto-reply na palaging sumasagot ay hindi «magandang CX». Sa inuupahang DID ito ay prepaid na tagas: dalawang bot o HELP na nagsipi ng orihinal ay maaaring tumalon hanggang mawalan ang wallet. Nakikita ng produkto ang engagement. Nakikita ng pananalapi ang butas. Minamana ng ops ang insidente nang 02:00 nang walang may-ari.

Pinananatili ng IOSOR ang inbound sa parehong white-label prepaid na ibabaw ng outbound.

Binabakante ng loop ng auto-reply ang prepaid

Pattern Hitsura Epekto sa wallet
Echo bot ↔ bot Dalawang auto-ack tumatalon Walang hangganang outbound debit
HELP nagsipi ng inbound Payload lumalabas bilang bagong send Dobleng segment
Ping-pong sa labas ng oras «Natanggap namin ang SMS» sa bawat retry Pagsunog sa gabi nang walang tao
Bagyo ng webhook retry Parehong MO dalawang beses Dobleng sagot, dobleng debit

Nangyayari ang inbound retry. Kung walang idempotence, bawat webhook retry ay nagiging isa pang auto-reply. Tingnan muling subok ng inbound webhook. Ipares ang pagtuklas ng loop sa hinto kapag mababa ang balanse para mapatigil ng wallet ang natitirang echo. Dapat tumakbo ang correlation ID mula inbound hanggang debit.

STOP/HELP laban sa walang hangganang echo

Ang STOP at HELP ay patakaran, hindi cute na bot. Dapat igalang ng STOP ang opt-out at itigil ang thread — kasama ang auto-reply. Ang HELP ay dapat maikling, brand-safe na landas na may tunay na oras, hindi echo ng huling pangungusap ng kliyente. Walang hangganang «natanggap namin ang SMS» sa bawat MO ay hindi HELP. Isulat ang pahina ng keyword bago ang unang conversational send; tingnan patakaran sa STOP at HELP. Kung «karaniwang gumagana» ang STOP, swerte kayo, hindi patakaran.

Mga kisame na kayang ipagtanggol ng produkto at pananalapi

  1. Outbound na kisame bawat thread — max auto-reply bawat DID + client id at window.
  2. Idempotent MO — isang inbound event, isang sagot, kahit mag-retry ang webhook.
  3. Katahimikan pagkatapos ng STOP — walang marketing, walang «sigurado ba kayo», walang pangalawang HELP.
  4. Hinto sa mababang balanse — ang natitirang auto-reply ay humihinto bago ang teatro ng overdraft.

I-export ang insidente: inbound → auto-reply → linya ng ledger. Kung walang kadena, walang dalawang-daang kontrol. Pangalanan ang may-ari ng kisame.

Katapatan ng dalawang-daang inbox

Ang dalawang-daan ay operating system, hindi switch. Sino ang unang nagbabasa, aling numero ang tumatanggap at nagpapadala, ano ang hindi kailanman nahuhulog sa shared channel, paano gumagana ang patay na oras. Tingnan gabay sa two-way na inbox at mga kaganapan sa inbox sa inuupahang numero. JIT ay hanapin → hawakan → bilhin → italaga. Hindi ibinebenta ang katalogo in setup bilang inbox na may tauhan.

Mga pulang bandila

  • Auto-reply nang walang kisame bawat thread
  • HELP na inuulit ang inbound payload
  • STOP na bumaril pa ng marketing ack
  • Webhook retry na doble ang sagot
  • Katalogo live nang walang may-ari ng loop
  • Error na nagtatapon ng dayuhang brand
  • Echo sa labas ng oras nang walang landas ng tao

Magsimula sa IOSOR

Sumulat ng STOP at HELP na mababasa nang malakas ng support. Maglagay ng takip sa auto-reply bawat thread sa staging, pilitin ang dobleng MO webhook, at kumpirmahin na isang sagot ang nakikita ng wallet, hindi dalawa. Gayahin ang eco ng bot hanggang tumigil ang gastos. I-export ang isang inbound-to-debit chain para makita ng pananalapi kung saan wawalisin ng loop ang prepaid na balanse.

Buod ng IOSOR

Ang inbound na eco ay sunog ng wallet.

Nakatulong ba ang gabay na ito?

Mga kaugnay na gabay