The most expensive part of selling eSIM is not acquiring the customer. It is the twenty minutes after they pay, when they have a QR code, an unfamiliar process and, quite often, a plane to catch.
Almost every refund, bad review and support ticket in this category originates in that window, and almost all of it is preventable through copy and sequencing rather than engineering. This is what to design and what to write.
The principles that prevent most failures
- Check the device before you take the money.
- Installation needs internet, so it has to happen before departure.
- Installed is not activated. Say so explicitly, twice.
- Instructions must differ by platform, because iOS and Android genuinely differ.
- Send the code again before travel. Nobody can find the original email.
Why this is a design problem now
Cumulative eSIM-capable device models announced
Source: GSMA Intelligence device tracker. Hardware compatibility is no longer the constraint on adoption, which means the activation experience is.
Source: GSMA Intelligence; GSMA Remote SIM Provisioning architecture.
For years the honest explanation for activation failures was that devices were inconsistent. That is much less true than it was. When something goes wrong today the cause is usually that the customer was not told something, or was told it in a way that did not survive contact with an airport.
The seven moments where it breaks
Each of these has a specific fix, and none of them require changing the underlying product.
| Moment | What can go wrong | What to do about it |
|---|---|---|
| Before payment | Selling to a device that cannot install a profile | Compatibility check with a clear explanation, not a dead end |
| Immediately after payment | Customer files the email and forgets | Prompt installation now, while they are on a working connection |
| During installation | No connection, or a network blocking the request | State that wifi is required; explain the error in plain language |
| After installation | Profile installed but not enabled or not set as data line | A second, separate instruction; this is not the same step |
| Before departure | Code lost, or validity misunderstood | Reminder with the code attached and validity stated plainly |
| On arrival | Roaming off on the profile; wrong line selected | An arrival message with the two settings to check |
| Approaching the limit | Silent disconnection abroad | Threshold alert with a one-tap top-up |
The row that matters most is the fourth. Installation and enablement feel like one action to a customer and are two distinct operations technically. A profile can sit on a device, visible in settings, delivering nothing, because it has not been enabled or because the home line is still carrying data. If your interface treats these as one step, your customers will too, and they will conclude the product is broken.
The gap between belief and reality
Most support conversations are a collision between a reasonable assumption and how the technology actually works.
What customers believe
- Scanning the code finishes the job
- The QR image is the plan itself
- A screenshot is a spare copy
- Validity starts when they land
- Data will just work on arrival
- Their number will change
What is actually true
- Installing and enabling are separate actions
- The code is an address plus a one-time identifier
- It can only be redeemed once, ever
- Validity behaviour depends on the plan; state it
- Roaming must be enabled on the new profile
- Their number is unaffected on a data-only plan
The screenshot assumption is worth addressing explicitly in your copy. An activation code carries a one-time identifier that is consumed on first use, so a saved image is not a spare and will not help if the profile was installed on the wrong device. Customers cannot be expected to know this, and discovering it while abroad is a bad moment to learn.
Copy that prevents tickets
Most of the improvement available here is in wording rather than interface.
| Instead of | Write | Why |
|---|---|---|
| "Scan the QR code to activate" | "Scan to install. You will enable it in the next step." | Sets the expectation that there are two steps |
| "Valid for 30 days" | State exactly when the 30 days begin | Removes the single most common billing complaint |
| "Install before you travel" | "Install now while you have wifi. You cannot install without internet." | Explains the reason, which makes people act |
| "Enable data roaming" | Name the exact setting path for their platform | Generic instructions fail because the menus differ |
| "Your eSIM is ready" | "Installed. Now set it as your data line." | "Ready" implies finished when it is not |
| "Contact support if you have issues" | Give a channel that works on hotel wifi | A phone number is useless to someone with no service |
The validity row deserves emphasis because it produces disputes rather than merely confusion. “Valid for 30 days” answers nothing: thirty days from purchase, from installation, or from first connection are three different products. Whichever applies, state it in the same sentence as the number, on the product page and again in the confirmation.
A sequence that works
Gate the sale on compatibility
Check device eligibility before the payment sheet, and when it fails, explain why and what the customer can do instead. A dead end at that moment produces a support message; an explanation produces an informed customer.
Prompt installation immediately
The best moment to install is the moment after purchase, while the customer is engaged and connected. Every hour that passes reduces the chance it happens before they are standing in an airport.
Write two instructions, not one
Installation and enablement are separate actions and must be presented separately. Combining them into a single "activate your eSIM" step is the single most common cause of avoidable tickets.
Detect the platform and show only that path
Do not present iOS and Android instructions side by side. Detect where possible, ask if not, and show one set of steps with the actual menu names for that platform.
Send a pre-departure reminder
Attach the code again, restate when validity begins, and list the two settings to check on arrival. This one message prevents more failures than any interface improvement.
Alert before the allowance runs out
A threshold alert with a one-tap top-up converts a support incident into a sale. Silent disconnection in a foreign country is the worst experience this product can deliver.
Step five is the highest-return item on the list and the cheapest to implement. Customers buy at booking and travel weeks later, by which point the confirmation email has been buried. A single pre-departure message with the code attached, the validity restated and the two arrival settings listed prevents more failures than any redesign of the purchase flow.
Frequently asked questions
Build on a platform that lets you fix things yourself
eSIM Island provides profile diagnostics, self-service reissue, real-time usage and threshold webhooks, so activation problems are something you resolve rather than escalate. Tell us about your product and we will set up test access.
Book a Free Demo
Leave a Reply