IOSOR

IOSOR База знань

WhatsApp чи RCS для OTP і алертів, доки другий канал ще in setup

Як тримати OTP і алерти чесними, коли WhatsApp або RCS ще in setup: позначка Live, політика fallback і prepaid-чеки без обіцянки каналу, який не вміє надсилати.

OTP і критичні алерти ламаються публічно. Другий канал часто продають як «додамо WhatsApp або RCS у наступному спринті», хоча каталог досі каже in setup. Користувач не бачить ваш roadmap — він бачить код, якого немає. Фінанси бачать debit на шляху, який не завершився. Чесний крок — не яскравіший слайд, а fallback, який уже live, і позначка каталогу, що збігається з тим, що ви справді можете надіслати сьогодні.

IOSOR тримає WhatsApp, RCS, SMS і Verify на одному white-label prepaid ledger. Каталог live — production-обіцянка; in setup — заявка, не м’який Live. Біля USD 1 000+ місячного platform usage готовність каналу й докази fallback стають матеріалом комерційного review. Не обіцяйте Live на коридорі, який досі валить smoke.

Live і in setup — це обіцянка продукту

Позначка Live — мова, звернена до користувача. Якщо шаблони WhatsApp, готовність RCS-відправника або quality window не закриті, канал лишається in setup. Продажна фраза «OTP у WhatsApp» при каталозі setup — інцидент довіри, не «затримка маркетингу». У позначки мають бути іменні власники: хто вмикає Live, хто володіє шаблонами, хто відповідає за SMS-шлях, який уже працює. Див. чесний запуск WhatsApp і RCS і vault і шаблонні гейти для rich-каналів.

Стан Що можна сказати користувачу Що мають бачити фінанси
live Канал може завершити OTP або алерт Debit прив’язаний до delivered або terminal status
in setup Для production OTP недоступний Немає тихого стрибка в неготовий шлях

WhatsApp OTP лише коли профіль справді готовий

WhatsApp виграє OTP там, де business-профіль і utility-шаблони чесно production-ready. Він не виграє тому, що так написано на чужому слайді. Порівняйте OTP у WhatsApp чи SMS-fallback. Невірний клас шаблону — користувач не бачить код, а гаманець уже зрушив. Тримайте SMS як default завершення, доки smoke WhatsApp не датований і не закріплений за owner. Session-повідомлення — не обхід review шаблонів.

RCS не є штатною запаскою для OTP

На roadmap RCS виглядає сусідом SMS; у production це програмований канал. Алерти й branded receipts мають сенс, коли відправник схвалений і каталог live. Автоматична запаска OTP через RCS, поки канал in setup, перетворює відсутній код на інцидент підтримки. Краще live SMS або voice, який ви захистите о 02:00, ніж стрибок у RCS, який ops не може replay.

Чесний fallback, доки другий канал ще in setup

Fallback — продуктова політика: timeout, definitive fail або resend на запит користувача — ніколи «спробуємо багатший канал заради скріншота». Обмежте автоматичні hops. Логуйте, який канал пробували, який пропустили бо він in setup, і який debit сів. Prepaid-гаманець, який не пояснює пропущену спробу RCS, — не контроль.

Червоні прапорці

  • Live на WhatsApp або RCS при чернеткових шаблонах
  • Автоматичний hop у канал in setup
  • OTP тарифікується як marketing blast
  • Client-facing помилки з чужими брендами
  • Немає SMS або voice шляху, який уже live
  • Порядок fallback вирішується в інцидентному чаті

Почніть з IOSOR

В консолі IOSOR відкрийте правила маршрутизації та перевірте бейджі статусів для кожного каналу перед запуском сесій авторизації. Якщо WhatsApp або RCS перебуває в статусі «в налаштуванні», заблокуйте автоматичний перехід на цей канал через гейт верифікації. Налаштуйте вебхуки для моніторингу DLR основного каналу та утримуйте прямий SMS-шлях як єдиний активний резерв до завершення модерації шаблонів.

Підсумок IOSOR

Ця стаття доводить, що канал зі статусом «в налаштуванні» не можна використовувати як резервний маршрут для одноразових паролів чи термінових сповіщень.

Чи був матеріал корисним?

Пов’язані гіди