IOSOR Learn
Live / In setup / Coming next: honest buyer path
Read the three catalog states before anyone clicks Open — Live opens traffic, In setup is a request, Coming next is not buyable yet.
A catalog that paints every product Live is a prepaid lie. Buyers must read three states before Open: Live, In setup, and Coming next. This page is that honest buyer path — not an SMS API shopping list and not a WhatsApp/RCS setup essay.
Related: Catalog Live gate must match vault reality, Failover gates before any Live badge, Day-1 runway: what must be green, Template catalog before channel Live, Prepaid hold before first debit.
IOSOR is white-label prepaid. USD 20 funds a catalog pilot on one Live product; soft review near USD 1,000/month prices “everything looks open” as recon debt. Clients see white-label states only.
Three states before anyone clicks Open
Live means the workspace opens and prepaid traffic may run with honest status. In setup means the product is in the shop, but Open stays blocked until an activation request clears — not a silent pass. Coming next is roadmap-visible only; not buyable, no money. Mixing the three invents false greens. Sibling: Catalog Live gate must match vault reality.
What each state allows
| State | Buyer action | Money / traffic |
|---|---|---|
| Live | Open workspace | Hold + send when other gates green |
| In setup | Request access | No production debit until approved |
| Coming next | Read roadmap only | No Open, no hold, no pilot burn |
| Off / hidden | Not in shop | Do not invent a sales URL |
Soft USD 1,000/month treats “Open on Coming next” as a catalog incident; USD 20 proves one Live product and one In-setup request that stays blocked until approved. Hold fails closed: Prepaid hold before first debit.
Not the SMS buyer checklist or WA setup story
The SMS API buyer checklist asks whether API, wallet, and compliance are buyable for SMS. Honest WhatsApp/RCS setup asks whether templates and channel readiness exist. This page asks: does the shop chip match what the buyer may open today? A product can pass SMS readiness and still sit In setup. Keep checklists linked; keep evidence separate. Adjacent, not substitutes: Failover gates before any Live badge, Day-1 runway: what must be green.
In setup is a request path, not fake Open
In setup must show Request access, not an Open that 500s or silently no-ops. Request → triage → approve or keep blocked with honest status. Do not paint Live to skip the queue. Template classes still need their own catalog before class-level Live: Template catalog before channel Live. Soft volume talk stays blocked while Coming next is sold as Live in a deck.
Buyer checklist for catalog states
- Can you name Live vs In setup vs Coming next without Slack?
- Does Live Open only when other production gates allow traffic?
Start with IOSOR
Audit your catalog console and backend gate engine to ensure shop chips accurately mirror runtime access. For products marked as In setup, confirm the interface displays an explicit Request access workflow instead of an active Open button that fails downstream. Test that Coming next items remain strictly non-buyable without holding funds or firing webhooks, while Live workspaces open only when all underlying channel gates pass.
IOSOR takeaway
This guide established how honest buyer paths require precise alignment between shop availability states and actual workspace readiness. Displaying a product as Live when activation requests are still pending causes unhandled runtime errors, broken pilot runs, and lost buyer trust.
Was this guide helpful?
Related guides
- Gate Premium Catalog Features Behind Monthly Volume Thresholds
Learn how to secure high-throughput enterprise catalog SKUs by enforcing volume-based access gates for subaccounts within the IOSOR platform ecosystem.
- Configuring Multi-Currency Catalog Display Rules for International Resellers
Learn how to configure IOSOR catalog display rules to show native currency rates to subaccounts while maintaining a unified USD settlement ledger for global operations.
- Enforce Role-Based Access Controls for Catalog State and Pricing Edits
Secure your white-label CPaaS environment by restricting catalog configuration changes to authorized administrative roles, ensuring pricing and status integrity.