IOSOR База знань
Вимоги TCPA та CASL перед запуском SMS у продакшн
Впровадження доказів згоди TCPA і CASL та автоматизована обробка STOP як обов'язковий шлюз перед бойовим відправленням SMS через платформу IOSOR.
Вимоги TCPA та CASL перед запуском SMS у продакшн.
Валідація згоди як непорушний шлюз для бойового трафіку
Сприйняття збору згоди клієнтів та обробки відписок як звичайних показників доставлення є неприпустимою помилкою проєктування зв'язку. У регуляторному полі Північної Америки наявність дозволу — це безапеляційний бінарний критерій перед стартом будь-якого надсилання. Вихід у бойовий режим без збережених доказів опт-іну наражає платформу на багатотисячні штрафи згідно з TCPA у США та CASL у Канаді.
Юридичні відмінності TCPA та CASL для SMS-розсилок
Норми TCPA вимагають отримання чіткої письмової згоди (Prior Express Written Consent) для будь-яких маркетингових розсилок, створених автоматизованими сервісами. Канадський закон CASL розділяє згоду на явну (Express, яка діє до моменту відкликання) та неявну (Implied, що базується на ділових відносинах і діє протягом 6 або 24 місяців). Архітектура IOSOR підтримує автоматичну диференціацію трафіку за географічними кодами (+1 для США та локальні коди Канади).
Апаратний перехоплювач STOP та надсилання Webhook подій
Обробка запитів на відписку реалізована безпосередньо в ядрі маршрутизації, унеможливлюючи помилки клієнтського коду. Коли на виділений E.164 номер надходить вхідне MO SMS із ключовими словами STOP, CANCEL, UNSUBSCRIBE, QUIT або ARRET, IOSOR негайно заносить контакт до локального реєстру блокування. Платформа формує службове підтвердження зі статусом 'Verify OK' та транслює подію через webhook у вашу систему.
Мультитенантне блокування та захист балансу платформи
Платформа гарантує повну ізоляцію списків відписки між різними клієнтськими акаунтами, запобігаючи ситуаціям, коли відписка в одній системі блокує OTP авторизацію в іншій. Телефонні номери призначаються через JIT-пайплайн із резервуванням коштів через механізм prepaid hold та списанням щомісячного MRC.
Верифікація контуру відповідності та регламентні ресурси
Перед переведенням трафіку в робочий контур проведіть тестування обробки запитів: надішліть команду STOP на тестовий номер та перевірте фіксацію статусу у CRM-системі через вебхук менш ніж за 500 мс. Ознайомтеся з архітектурними інструкціями платформи:
Пов’язані матеріали: Зупинка після постановки в чергу: пропускати без фальшивої доставки · Політика STOP та HELP не є інфраструктурою вхідного інбоксу · prepaid-резерв до першого списання.
Почніть з IOSOR
Зайдіть у консоль IOSOR та перевірте налаштування автоматичного блокування трафіку для E.164 маршрутів перед запуском продакшн-кампаній у Північній Америці. Переконайтеся, що обробник inbound webhooks реагує на ключові слова STOP, CANCEL та ARRET протягом 500 мілісекунд і миттєво оновлює реєстр відкликань згоди. Переведіть перевірку журналів згоди у статус обов'язкового шлюзу (gate), без якого відправка SMS блокується на рівні платформи.
Підсумок IOSOR
Ця стаття доводить, що докази згоди та обробка STOP-запитів згідно з вимогами TCPA та CASL є жорстким юридичним шлюзом, а не абстрактною метрикою доставляємості. Нехтування вимогами до письмової згоди чи затримка в оновленні реєстру відкликань призводить до миттєвих регуляторних штрафів та блокування маршрутів.
Робіть автоматичну перевірку наявності фіксованого логу згоди для кожного E.164 номера перед передачею трафіку та ізолюйте таблиці відписань на рівні тенанта. Не намагайтеся відкладати обробку вхідних MO-повідомлень STOP на рівень зовнішньої CRM або сприймати відклик згоди як звичайну метрику відтоку.
Чи був матеріал корисним?
Пов’язані гіди
- Зупинка після постановки в чергу: пропускати без фальшивої доставки
Правильна обробка запитів STOP для відкладених SMS із придушенням надсилання без запису неправдивих звітів про доставку.
- Політика STOP та HELP не є інфраструктурою вхідного інбоксу
Чому ключові слова STOP і HELP відносяться до обов'язкових політик захисту прав абонента, а не до маршрутизації вхідних чатів у платформі IOSOR.