.jpg)
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.