TPG Telecom’s first eSIM capability, designed so an enterprise or government administrator can order, release and activate a service themselves, without the account manager, the phone call or the queue.
Project brief
Greenfield work. TPG Telecom had no eSIM functionality at all, so there was no existing screen to improve and no internal process to copy. The brief was to invent the whole capability inside Frontier, the platform that carries AAPT, TPG, Vodafone, iiNet and Lebara: order an eSIM, release the QR code and confirmation code to the right people, activate on the handset, and let a customer administrator do all of it without contacting anyone at TPG.
Client type
TPG Telecom, ASX-listed telecommunications group, five consumer and enterprise brands
Primary user
Enterprise and government customer administrators, self-serve, managing mobile fleets on behalf of their organisation
My role
The process
2.1 Design process, my approach
Research phase
Designing a capability that did not exist yet
There was no eSIM journey to audit, no analytics to read and no support tickets to count, because TPG Telecom had never offered one. Research had to establish what the capability even was: what the GSMA activation model demands of a customer, what the network and provisioning systems could expose, and what an administrator managing fifty handsets would need to trust it.
That made the workshops the primary research instrument. Four remote sessions in Mural with mobility product, provisioning, enterprise service and the platform team established the transactions in scope, the regulatory obligations, and the boundary between what a customer could do alone and what still needed TPG.
Discovery workshops
Timed sections with a stated outcome each, run in Mural because the group was spread across Sydney, Melbourne and Manila. The boards below are blurred, the working detail belongs to TPG.
Discovery interviews and personas
Customer administrators across small business, government and enterprise accounts, plus the TPG teams who currently absorb their requests, because the whole point was to stop those requests existing. Three personas came out of it, and each one wants a different thing from the same release screen: speed, proof, or scale.
What we asked
- Who in your organisation is allowed to activate a service, and who actually does it
- What happens today when a new starter needs a phone this week
- How do you know a SIM reached the person it was meant for
- What would stop you doing this yourself rather than emailing your account manager
Key learnings
- Administrators rarely hold the handset, someone else scans the code, so delegation is the normal case rather than the exception
- Fear of getting it wrong, not effort, is what sends people back to the account manager
- Compatibility doubt kills the choice at the first screen
- Government administrators need the record more than the speed
Context
- Hires seasonal staff at short notice and needs them connected the same day.
- Has no IT department, so she is the person who orders, sends and troubleshoots.
- Runs the business from her phone and expects the portal to work there too.
Motivations
Frustrations
“A new starter begins Monday. I cannot tell her to wait until a SIM arrives in the post.”
Journey map
Context
- Answerable for every activation under the panel agreement, and audited on it.
- Delegates handsets to team leaders in six regional offices.
- Will not use a capability he cannot evidence after the fact.
Motivations
Frustrations
“If I cannot show who authorised it and why, it did not happen properly.”
Journey map
Context
- Camera crews change devices mid-story and cannot wait for a replacement SIM.
- Delegates activation to producers who are rarely at a desk.
- Judges the platform on whether it survives being used fifty times in a week.
Motivations
Frustrations
“A crew loses a handset in the field on a Friday. The story does not wait for Monday.”
Journey map
Defining phase
Four transactions, one pattern
New connect, SIM swap, SIM transfer and reconnect are four commercial events that share one moment: a credential has to reach a named human on a compatible device. Designing that shared moment once is what let a single pattern serve all four, with physical SIM kept inside the same flow instead of split into a parallel product.
Because the platform had no eSIM history, the constraints below were written rather than inherited, and each one became an acceptance criterion the build was tested against.
A new service on a new number, or a number ported in from another carrier.
A live service moving between SIM types, physical to eSIM or back.
The same service moving to a different handset, with its own code and recipients.
A suspended service brought back, inside secure checkout, with a stated reason.
The rules the design had to respect
Service blueprint
Self-serve only works if the systems behind it answer fast enough to keep a person in the flow. The blueprint set the contract: what the administrator does, what Frontier shows, what provisioning and the network must return, and what gets written down.
and network
Information architecture
eSIM had to live inside an existing platform, so the structural question was where it belonged rather than what to call it. It sits on the service itself, as a tab beside the features an administrator already uses, with three panels behind it: the code, the log and the notifications.
eSIM Actions
Service history
Related services
Related orders
Activity log, who did what and why
Notifications, what the platform did
Disconnect
Modify mobile plan
Reconnect, into secure checkout
Ideation phase
Low-fi wireframes
Greyscale first, so the sessions argued about the order of the questions and the wording of the limits rather than the styling. The release dialog went through the most versions: the attempts counter moved out of a tooltip and onto the screen, and the reason field became mandatory once we watched people release twice without thinking.
Ordering an eSIM
The order flow asks four things in plain language: which SIM type, whether a number is being ported, who the customer is, and where the QR code and confirmation code should go. Physical SIM lives in the same flow, so nobody has to back out and start again, and the compatibility link sits at the top where the decision is actually made.
What type of SIM do you need to buy?
Do you have an existing number that you would like to port?
Customer details
Customer ReferenceWhere do you want the eSIM QR Code and Confirmation Code to be sent?
What type of SIM are you transferring to?
Customer details
Customer ReferenceWhere do you want the eSIM QR Code and Confirmation Code to be sent?
Draft Order ID: CA19777542
What SIM type do you want to reconnect with?
Where do you want the eSIM QR Code and Confirmation Code to be sent?
Draft Order ID: CA19777542
What SIM type do you want to reconnect with?
Do you want to activate new SIM for reconnect?
Where do you want the eSIM QR Code and Confirmation Code to be sent?
Releasing a QR code
This is the screen the whole project turns on, and the one that makes self-serve defensible. Releasing again is sometimes legitimate, a code sent to the wrong ordering contact or a handset that failed first time, so the design does not forbid it. It states the cost up front: how many attempts are left, who is already on the list, and why this release is happening. When the attempts run out, the dialog says so plainly and hands over to a phone number rather than failing quietly.
Service Details
Mobile Plan
You have 02 attempts remaining to release a QR code
Release QR codeRelease QR code
You have reached the maximum limit of 5 recipients per QR code
Release QR code
Release QR code
Sorry, you have exhausted all 3 attempts for regenerating QR code, for help please Contact Support at 1300 055 717 between 8am–8pm, Monday to Friday AEST.
Activity log and auditability
Self-serve removes the account manager, and with them the person who used to remember what happened. The log is what replaces that memory. It answers who did this and why, one row per action: transaction type, attempt number, who authorised it, which recipients received it, and the reason they typed. Notifications answer the other half, what the platform did next, released, downloaded, error, retries exceeded. Both export, because the person asking is usually mid-call while they ask.
A note on the two design systems
The activity log and notifications live in Frontier Internal, the staff-facing admin panel, which runs on the older Frontier design system: red section headers, dense tables, an actions rail and the legacy navigation. It predates the current design language and was not in scope to replace.
The eSIM panels had to be designed twice over: as new patterns in the customer-facing platform, and as additions that sit honestly inside the older admin system without restyling the pages around them.
The email system
The last mile of a self-serve journey
The administrator never touches the handset, so the email carries the activation. Seven templates cover activation and transfer, each with a success and a failure path, a stated support window, and a three step guide numbered like the on-screen flow. The QR code and the four digit confirmation code travel in separate messages, so neither one alone is enough.
The activation email is the one that had to teach: a before you start checklist, then scan, enter, wait.
Dear Customer,
You have requested an eSIM activation for your number:
0481 676 526
Activate your eSIM
Follow the steps in this guide to activate your TPG Telecom eSIM.
Before you start, make sure you have the following:
In order for you to scan this QR Code, please either print a copy or have it displayed on another device.
Result
TPG Telecom’s first eSIM. A simple five minute process.
Ordering, swapping, transferring and reconnecting all run self-serve, so an administrator connects a new starter the same day instead of emailing an account manager and waiting.
Delegation became safe: named recipients capped at five, finite release attempts, a mandatory reason, and a log that answers who and why without a phone call.
The digital-first brands this capability serves grew to 18.3% of total mobile sales, up from 14%, and the plastic came out of the process entirely.