IOSOR

IOSOR База знань

Вибір Sender ID перед першою кампанією

Оберіть alphanumeric чи local DID до брифу першої кампанії — щоб coverage, hold і failover збіглися з identity, з якої ви реально надішлете.

Команди часто фіксують креатив і volume раніше, ніж кого побачить отримувач. Це навпаки. Кампанія №1 починається з форми sender: alphanumeric-рядок бренду проти local DID (або toll-free, де потрібно). Помилка спалює prepaid на reject, тихих swap і строках реєстрації поза календарем запуску.

Ця сторінка — вибір покупця перед першою кампанією: зафіксуйте клас from-identity, поки бриф ще можна змінити.

IOSOR — white-label prepaid CPaaS. Поповніть wallet, hold до debit, JIT-assign номерів — лише коли numeric sender чесний шлях. Підлога USD 20; soft review біля USD 1 000/міс — коли поганий вибір sender проявляється як необґрунтований burn. Стек: чекліст купівлі SMS API.

Оберіть тип sender до брифу кампанії

До copy і volume-annex: перелічіть кожен ISO першої хвилі; позначте, чи alphanumeric відкритий, потребує реєстрації чи закритий для вашого класу повідомлень; вирішіть, чи потрібен local DID (або toll-free) для two-way / STOP/HELP; лише потім зафіксуйте from-identity. Якщо продажі пообіцяли один brand string скрізь — відкрийте бриф знову.

Alphanumeric vs local DID: таблиця для першого запуску

Потреба Краще alphanumeric Краще local DID / numeric
Бренд на one-way OTP/alerts Open або registered alpha дозволено Alpha блокується чи тихо підміняється
STOP / HELP / two-way Corridor підтримує MO на цю alpha За замовчуванням для справжнього two-way
Строк реєстрації Закладіть дні/тижні за потреби JIT assign після hold, якщо шлях numeric

Coverage і обмеження corridor, що диктують вибір

WORLD-only corridor може прийняти пілот, поки реєстрація alpha передбачає named zone. Узгодьте from-identity з напрямками zone / WORLD / setup — Перевірте coverage перед volume-цифрами в пропозиції. Якщо хвиля один змішує відкриту й закриту alpha — розділіть кампанії або sender’и.

Prepaid hold і failover — не рішення про sender

Hold резервує prepaid до debit; він не створює зареєстрований sender. Failover Live доводить ordered backup; він не скасовує реєстрацію corridor. Тримайте смуги окремо: prepaid-резерв до першого списання, Гейти failover до будь-якого бейджа Live і цей вибір sender.

Чеклист покупця до першого send кампанії

  1. Для кожного ISO хвилі один явне рішення alpha vs DID?
  2. Строк реєстрації (якщо є) записано до go-live?
  3. Coverage-лист збігається з цими напрямками (Перевірте coverage перед volume-цифрами в пропозиції)?
  4. Пілот використовує ту саму from-identity і клас повідомлень, що production-креатив?

Почніть з IOSOR

Оберіть тип відправника (Alphanumeric або local DID) у консолі IOSOR для кожного ISO-коду першої хвилі до остаточного затвердження тексту розсилки. Перевірте статус коридору в карті покриття: якщо альфа-ім'я вимагає реєстрації, зафіксуйте терміни або оберіть резервний числовий ідентифікатор. Лише після фіксації підтвердженого Sender ID переходьте до налаштування вебхуків для DLR та тестування маршрутів.

Підсумок IOSOR

Цей матеріал довів, що вибір відправника визначається географією хвилі та типом трафіку: альфа-імена підходять для односторонніх OTP та сповіщень, а локальні DID необхідні для двосторонніх відповідей та обробки STOP-команд. Резервні шлюзи та препейд-холди забезпечують технічну стійкість, але вони не здатні обійти відсутність зареєстрованого ідентифікатора у регульованій зоні.

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

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