Connectivity for Distributed Teams

Distributed teams tend to solve connectivity by accident. Someone expenses a local SIM in Bogotá, someone else buys a consumer eSIM on a personal card, and finance ends up reconciling eleven small receipts in five currencies at the end of the quarter. Team connectivity replaces that with a console, a single monthly invoice, and rules you set once.

The underlying product is the same as our consumer plans: profiles issued over the SM-DP+ activation flow, attached to partner networks in the markets you buy. What changes is everything around it — who can order, who pays, what the limits are, and who can see what.

Provisioning

You add people to the account by email, and each receives an activation link that installs a profile on their own device. Nobody in your finance team ever handles a QR code, and nobody has to be talked through the settings app over a video call. If a phone is replaced, the profile is reissued to the new EID from the console rather than reordered.

Profiles can be assigned in advance and left dormant. A field team flying out on Monday can have plans installed the previous week, activating only when they land. Because prepaid validity generally starts on first network attachment, nothing is wasted by preparing early.

Control without micromanagement

• One invoice per month, in your billing currency, itemised by person and by market.
• Per-person spend ceilings. Set a monthly limit; top-ups above it need an approval rather than a conversation after the fact.
• Usage reporting by profile and market — volumes and allowance state, never browsing history or traffic contents, which we do not have.
• Role separation. Administrators manage profiles and billing; travellers see only their own plan.
• Reissue and revoke from the console when a device is lost or a contractor's engagement ends.

What we can and cannot see

This matters more than most vendors admit. As a reseller of connectivity we see provisioning metadata — the EID a profile was installed on, its ICCID, its state, the market it is roaming in, and how much of its allowance is consumed. We do not see the sites your people visit, the contents of their traffic, or their location beyond the market their profile is attached to. Nothing in the console can reveal those things, because nothing in our systems holds them.

That constraint is deliberate. A connectivity tool that doubled as an employee-monitoring tool would be a different product, sold to a different buyer, and we are not building it.

Devices, ownership and who holds the profile

Two structures are common and they behave differently. Where devices are company-owned, profiles are issued against handsets the company controls, and reissuing after a replacement is straightforward because the administrator already knows the new device. Where staff use personal phones, the profile lives on hardware you do not control, which makes revocation and offboarding the parts worth thinking about in advance.

Neither structure is better in the abstract. What matters is deciding which one you are running before profiles are issued, so that console permissions, spend rules and the offboarding checklist all assume the same thing. Mixed fleets work too; they simply need the distinction recorded per person rather than assumed.

Getting set up

Tell us the headcount, the regions your people actually go to, and whether devices are company-owned or personal. Those three answers determine plan shape, whether identity-verification markets are in scope, and how the console should be structured. Most accounts are configured within a couple of business days; the slow part is usually confirming which handsets in the fleet are carrier-unlocked.

Company-owned devices bought on carrier finance are the single most common obstacle. If a batch is still locked to its original operator, no eSIM from anybody will attach, and unlocking has to be requested from that operator before anything else can happen. We would rather flag that on day one than after the profiles have been issued.