The eSIM That Vanished Between Teams
When a single connectivity product touches provisioning, billing, coverage, support and escalation — each owned by a different team — no one sees the full picture until the customer does.
Composite story · Composite scenarioThis is a composite application scenario. Names, dialogue and operational details are illustrative; no customer outcome or testimonial is claimed.
Signals to watch
- cross-team coordination
- provisioning failures
- no single source of truth
Composite industry case. This page describes a reusable operating problem and decision method. It does not represent a named customer, real conversation, contract, revenue result or testimonial.
The connectivity handover you did not know existed
A traveler lands in a new country. Their device roams onto a local network — standard behaviour. But the data session does not start. The device shows signal, the eSIM profile is present, yet throughput sits at zero.
The provisioning team sees an active profile. The roaming partner’s network confirms the device attached. Billing shows no bar. Coverage maps say the location is served. Support has no error to trace. Escalation waits for a ticket to arrive.
Each team’s system reports green. The customer sees a flat line.
This is not a coverage hole, a billing block, or a provisioning failure. It is an ownership gap — a zone between handovers that no team owns, because no workflow was ever written for it.
Why teams misread the gap
Connectivity operations teams are organised around discrete technical domains. Provisioning owns profile delivery. Billing owns rating and balance checks. Roaming operations owns partner agreements and network attachment. Support owns the customer conversation. Escalation owns the incident path when everything else fails.
Each domain operates with its own dashboard, its own SLAs, and its own definition of “normal.” When an eSIM session passes every individual check but still fails, every team clears itself. The gap is invisible from inside any single domain.
The pattern repeats because the operations model mirrors the legacy SIM world, where each function touched the physical SIM card at a known moment. With eSIM, the device is always connected to the back end. Provisioning, activation, suspension, swapping and deactivation can happen in any order, on any timeline, triggered by the user. The number of possible handover states multiplies, but the team boundaries stay the same.
The result is a class of incident that no one owns and everyone explains away.
Evidence review framework
When an incident crosses four or more team boundaries with no clear failure, use this lightweight method to surface the ownership gap.
Step 1 — Map the handover chain. Draw every step the connectivity product passes through, from profile download to data session to billing event. Do not skip steps that “always work.” Every arrow between boxes is a potential gap.
Step 2 — Name an owner for each arrow. Each handover must have a named person or team responsible for verifying the handover works. If the arrow has no owner, it is a gap. Write it down.
Step 3 — Collect evidence per handover. For the incident in question, gather one piece of evidence per handover that shows the handover either succeeded or failed — a log line, a timestamp, a status code. If no evidence exists for a handover, that handover is unverified.
Step 4 — Produce one action. Based on the evidence, write a single concrete action: “Provisioning team will verify that activation acknowledgements from partner networks include a coverage class field by next Thursday.” The action must name an owner, cite the evidence that prompted it, and set a decision window.
This framework works with any ticketing system, spreadsheet, or whiteboard. The tool is not the method.
Team next step
The most useful thing a connectivity operations lead can do this week is run one incident through the four steps above with the teams involved. Do not attempt to map every product at once. Pick one recurring issue — a roaming data session that fails silently, an eSIM swap that did not trigger a billing refresh, a profile download that completed but the device never activated.
Run the meeting in 45 minutes. Have each team bring their logs for their domain only. Map the handovers together on a shared screen or whiteboard. The gaps will appear in the first pass.
The output is not a fix. The output is an owned action with a deadline. That action becomes a test: if the owner validates the handover, the gap closes. If they cannot, the gap is real and needs a workflow change.
What automation cannot replace
Continuous signal discovery — monitoring handover states across domains — can surface gaps before a customer calls. Evidence organisation — collecting logs, timestamps and status codes per handover — turns raw telemetry into a reviewable record. Both are tasks that software handles better than people.
But naming an owner for a handover requires a human decision. Choosing which incident to investigate first requires judgment. Writing an action that is specific enough to test requires someone who understands how the teams actually work, not how the org chart says they work.
Automation can flag the gap. It cannot decide who fills it, or by when. That decision — the human review action with an owner, evidence and a window — is the output that changes how connectivity operations work across domains. It is the difference between every team clearing itself and one team taking responsibility for a handover that was never anyone’s before.
Frequently asked questions
Why do eSIM roaming issues expose ownership gaps more than traditional SIMs?
eSIM profiles can be downloaded, activated, suspended and swapped remotely, which means the operational touchpoints multiply across teams that historically worked in sequence, not concurrently.
How do I start mapping ownership gaps without a new tool?
Pick one recurring incident type, list every handover it crosses, write down which team owns each handover, and flag any handover with no named owner.