IOSOR База знань
Live / In setup / Coming next: чесний шлях покупця
Прочитайте три стани каталогу до кліку Open — Live відкриває трафік, In setup це запит, Coming next ще не можна купити.
Каталог, де кожен продукт намальований як Live, — prepaid-брехня. Покупець мусить бачити три стани до Open: Live, In setup і Coming next. Ця сторінка — чесний шлях покупця, не чекліст купівлі SMS API і не есе про setup WhatsApp/RCS.
Пов’язані: Гейт Live у каталозі має збігатися з vault, Гейти failover до будь-якого бейджа Live, Day-1 runway: що має бути зеленим, Каталог шаблонів перед Live каналу, prepaid-резерв до першого списання.
IOSOR — white-label prepaid.
Три стани перед будь-яким кліком Open
Live означає: workspace відкривається, prepaid-трафік може йти з чесним статусом. In setup — продукт є в shop, але Open заблоковано, доки не пройде запит на активацію — не silent pass. Coming next — рядок видимий заради чесної roadmap; його не можна купити й не можна списувати гроші. Змішування трьох invents false greens.
Що дозволяє кожен стан
| Стан | Дія покупця | Гроші / трафік |
|---|---|---|
| Live | Open workspace | Prepaid hold + send, якщо інші гейти зелені |
| In setup | Request access | Немає production debit до approve |
| Coming next | Лише читати roadmap | Немає Open, немає hold, немає pilot burn |
| Off / hidden | Немає в shop | Не вигадувати sales URL |
Це не SMS buyer checklist і не WA setup
Чекліст SMS API питає, чи готові API, гаманець і compliance до купівлі SMS. Чесний setup WhatsApp/RCS — чи готові шаблони й канал. Тут інше питання: чи збігається chip у shop з тим, що покупець може відкрити сьогодні? Продукт може пройти SMS readiness і все ще сидіти In setup у каталозі. Чеклісти пов’язані; evidence розділені.
In setup — шлях запиту, не fake Open
In setup мусить показувати Request access, а не Open, який 500 або silently no-ops. Request → triage → approve або keep blocked з чесним статусом. Не малюйте Live, щоб обійти чергу. Класи шаблонів усе одно потребують свого каталогу до class-level Live: Каталог шаблонів перед Live каналу.
Чекліст покупця: стани каталогу
- Можете назвати Live vs In setup vs Coming next без Slack?
- Live Open лише коли інші production-гейти дозволяють трафік?
- In setup показує Request access — не зламаний Open?
- Coming next non-buyable (немає hold, немає debit)?
- Soft USD 1 000/міс blocked, поки стани — theatre?
- Пілот USD 20 довів один Live open і один blocked запит?
Почніть з IOSOR
Перевірте статус своїх продуктів у консолі IOSOR та переконайтеся, що бейдж In setup запускає сценарій Request access, а не імітує кнопку відкриття воркспейсу. Налаштуйте шлюзи перевірки так, щоб статус Live дозволяв рух трафіку лише після повного проходження всіх супутніх гейтів. Переведіть заплановані модулі в стан Coming next, унеможливлюючи помилкові списання або генерацію порожніх DLR.
Підсумок IOSOR
Цей матеріал довів, що чесний шлях покупця вимагає суворого розмежування між реально доступними ресурсами, етапом налаштування та роадмапом. Відображення непідготовленого сервісу як Live створює хибні очікування та помилки 500, тоді як прозорий статус In setup із процедурою триажу забезпечує кероване підключення.
Чи був матеріал корисним?
Пов’язані гіди
- Обмеження доступу до преміум-каталогу через пороги обсягу
Дізнайтеся, як налаштувати автоматичні шлюзи доступу до високопродуктивних SKU для суб-акаунтів на платформі IOSOR на основі щомісячних обсягів трафіку.
- Налаштування відображення валют у каталозі для міжнародних реселерів
Дізнайтеся, як налаштувати правила відображення цін в IOSOR для суб-акаунтів у їхніх локальних валютах, зберігаючи при цьому єдиний розрахунковий баланс у доларах США.
- Контроль доступу до налаштувань каталогу та ціноутворення
Захистіть свою платформу, обмеживши права на редагування цін та статусів продуктів лише для авторизованих адміністраторів у вашій системі.