Use Case – Selling Travel Connectivity

This use case describes how a customer (Customer X) uses the SFT platform to commercialise travel connectivity through its own customer-facing portal.

Who Is the Customer?

Customer X is a travel-focused company offering connectivity services to travelers.

Customer X:

• Operates its own online portal

• Sells travel connectivity packages and add-ons

• Uses SFT as the backend connectivity platform

• Manages all SIMs, plans, and add-ons through APIs

In the SFT model, Customer X operates as an Enterprise account.

Business Goal

Customer X wants to:

• Offer travelers connectivity packages per destination

• Allow travelers to choose countries or regions

• Allow travelers to purchase one or more connectivity add-ons

• Manage all connectivity logic in the backend without exposing SFT to end users

From the traveler’s perspective, the experience should feel like a standard e-commerce purchase.

Initial Situation

Customer X has signed a commercial agreement with BICS and has been onboarded onto the SFT platform as an Enterprise account.

As part of the onboarding:

• An Enterprise account has been created in SFT

• API access has been granted

• An initial set of SIM cards has been assigned to Customer X

At this point:

• No endpoints exist

• No connectivity is active

• No traffic can be generated

Customer X must now define how its customer-facing portal and backend systems will integrate with SFT, including:

• Which SFT configurations are required (plans, rate zones, add-ons)

• How portal products map to SFT commercial constructs

• How and when SFT APIs will be invoked by the backend

SFT will function as the backend connectivity and commercial engine, while Customer X’s portal will handle end-customer interaction and product selection.