Take two CPOs running their charging networks on the same white-label platform. Different names, different logos, different color schemes. Open both apps and try to register. Select a charge point. Start a session.
The screens look different. The experience is the same. The steps are the same. The moments that form a driver’s opinion of a network: what registration felt like, whether the app asked anything useful before the charge started, what happened when they tried to cancel. Those moments play out identically across both operators, because both operators are working with the same default flows.
That’s the baseline every charge point management platform hands its customers. And most operators accept it as the structural reality of white-label software: you brand the surface, but the experience underneath belongs to the platform.
That assumption is worth questioning. AMPECO’s Embedded Web App gives operators a set of specific points in the driver journey where they can insert their own flows, collect their own data, and make their own decisions, without building a native app and without touching the platform’s core functionality. This post covers what those points are, what operators are doing with them, and what the driver experiences on the other side.
White Label Gives You a Brand Identity. It Doesn’t Give You a Brand Experience.
The white-label promise is real, and it’s worth being precise about what it delivers. An operator deploying AMPECO gets a driver app with their name on it, their logo in the header, their colors throughout, and their listing in the App Store. For drivers, it looks like the operator’s product. That’s the whole point.
What white-label branding doesn’t deliver is a differentiated experience. Every AMPECO customer running the standard driver app gives their drivers the same registration flow, the same pre-session screens, the same navigation, the same settings menu. The branding differs. The experience does not.
That gap matters more than it might seem. The moments that shape a driver’s relationship with a charging network are not the logo or the color palette. They’re the moments of friction or ease in the experience itself: how fast registration was, whether the app asked for anything relevant before the charge started, what happened when they wanted to cancel a subscription. Each of those moments is a small judgment on the operator’s brand. Out of the box, all of those judgments go through the same default experience.
For years, operators who wanted to own those moments had two options: accept the default, or build a native app from scratch. Building from scratch is not a realistic path for most CPOs. It takes years, a dedicated development team, and ongoing maintenance; by the time the custom app ships, the shared platform it was competing against has released dozens of updates. The economics don’t work unless the operator is at a scale where the investment is justified by the size of the driver base.
Working with 220+ operators across more than 70 markets, we’ve seen this pattern consistently: the moment that shapes a driver’s opinion of a network is rarely the logo. It’s the experience underneath it.
The Embedded Web App exists because there’s a third option, and it doesn’t require a native app.
The Driver Journey Has More Brand Moments Than Most Operators Realize
The Embedded Web App is a configuration layer, not a development project. An operator sets it up in the back office, specifies a URL they control, and the platform handles the routing: when a driver reaches a configured trigger point in the app, a custom web view opens, the driver completes whatever the operator has built, and the native app flow continues. The operator controls the web page; AMPECO controls the plumbing around it.
The trigger points cover the full arc of a driver’s relationship with a charging network.
At the onboarding stage, two triggers are available. The sign-up trigger replaces the default registration screen with a custom flow. Whatever the registration process needs to collect, validate, or connect to an external system can be designed into that page. Once complete, the driver is authenticated and returned to the app. The login trigger fires immediately after a driver authenticates, making it the right moment for anything that matters once a driver is identified: updated terms, a loyalty milestone notification, or a welcome-back message after a long gap in usage.
At the charger, the options expand. The “On EVSE selected” trigger intercepts the moment between station selection and the start screen, so operators can collect information or require confirmation before the session is offered. Two separate triggers fire when a driver presses the start session button: one launches the custom web view while the session starts normally in the background; the other hands full control of session initiation to the operator’s external system, so AMPECO doesn’t create the session record until the external flow instructs it to. On the EVSE details screen, a configurable button opens any operator-defined interface. On the map, a floating action button gives operators a way to put tools in front of drivers that would otherwise require hunting through the side menu.
For ongoing relationship management, three more trigger types handle the higher-stakes moments. The balance top-up trigger redirects the payment flow to an external interface, useful for operators with preferred payment providers or custom top-up mechanics that the standard flow doesn’t accommodate. The subscription cancel trigger intercepts before the cancellation is confirmed, opening space for a retention offer or a reason-capture survey. The custom menu item places any branded tool in the app’s sidebar for on-demand access: an RFID card ordering page, a loyalty rewards dashboard, a support portal.
These triggers compose. An operator can run a custom registration flow alongside a cancellation save flow and a map button linking to a route planner, each configured and maintained independently. Each configuration can also be scoped by operator, user group, or market, so a network serving both corporate fleet accounts and general consumers can run different flows for each segment without conflict.
Three Examples Worth Stealing
The trigger list describes the capability. These three scenarios are where it becomes concrete enough to be useful.
Fleet account provisioning at sign-up
Take a CPO serving corporate fleet customers. The standard registration flow collects an email address and a password, then drops the driver into the general user pool. Connecting that driver to the right company account, assigning the correct tariff tier, and placing them in the right access group requires either a manual intervention by the operator or a follow-up process easy to miss. The error rate is low, but it compounds quickly as fleet enrollment scales.
Using the sign-up trigger, the operator replaces the native registration screen with their own page. That page validates the driver’s corporate email domain, collects any additional fields the operator needs (a fleet ID, a cost center code, a vehicle registration number), and calls the AMPECO API to register and authenticate the driver. From the driver’s side, registration happened once and everything worked. From the operator’s standpoint, every fleet member enters the system correctly provisioned, with no manual reconciliation required.
License plate capture before the session starts
At locations where parking and charging run together (shopping centers, municipal garages, airport parking), CPOs often face a pre-session data requirement: the driver’s license plate needs to be on record before charging begins, both to link the charge to the correct parking transaction and to satisfy the site’s requirements.
The “On EVSE selected” trigger handles this without adding a separate post-session step. When the driver selects a charge point, the trigger opens a short form. The driver enters their plate number, submits it, and the data is passed to the parking management system. The charging start screen follows. From the driver’s side, it’s a brief, purposeful moment before a charge begins. From the operator’s side, the parking integration runs cleanly, without a reconciliation backlog building in the background.
When the cancel button becomes a conversation
Consider a CPO running a subscription charging plan. A driver taps cancel. On a default platform, the cancellation goes through, and the operator’s first indication is the record in their dashboard.
The subscription cancel trigger intercepts that moment. The cancel button opens a custom page instead of the confirmation dialog. A driver who’s been subscribed for six months and is leaving because of cost might see a discounted renewal offer. A driver who’s been inactive might see an option to pause rather than cancel. A driver who has already decided might see a short survey asking for the reason before the cancellation is confirmed. The operator builds the page and decides what each scenario looks like. AMPECO passes the driver ID, subscription ID, and operator context to the web view. If the custom page needs additional data to personalize the offer (subscription tier, account history), it can call the AMPECO API directly. The platform renders the view inside the app and returns the driver to the correct state when the flow ends.
Each of these configurations is set up in the back office, with no development work required on AMPECO’s side. The operator builds the web page; the platform handles the trigger logic, the context passing, and the navigation.
If any of these scenarios maps to a problem you’re working on, book a demo and we’ll walk through it for your specific setup.
What Drivers Experience Is One App
The natural question at this point is how the custom web view looks from the driver’s side.
It renders inside a native web view within the app. Drivers see no browser chrome, no visible URL, no external browser in their flow. The transition from the native app to the custom page and back is controlled by the platform’s navigation logic: a “Close URL” returns the driver to the expected next screen in the app when they complete the flow; a “Back URL” handles early exit. Drivers don’t see the mechanism behind it.
The custom pages can match the app’s visual context closely. When a trigger fires, the platform passes the app’s current theme (light or dark), language, and country settings to the web view as parameters. An operator who wants their custom registration page to look and feel consistent with the rest of the app has everything they need to build that.
On the reliability side, the platform handles failures without blocking drivers. If the external web app doesn’t respond, non-critical triggers (the EVSE custom button, the map button, the menu item) dismiss the web view automatically and let the driver continue their session uninterrupted. The sign-up flow is the one exception: it can’t be skipped. Operators can review any failures in a dedicated error log in the back office, showing which trigger was active, when the failure occurred, the HTTP response code, and which user was affected.
The driver’s experience of all this is one coherent app. What the operator has done behind it is entirely their own.
The App Is the Same. The Experience Doesn’t Have to Be.
Every CPO on AMPECO shares the same underlying platform, the same white-label foundation, the same hardware-agnostic infrastructure. That’s part of what makes a shared platform valuable: no one rebuilds what’s already built, and every operator benefits from the same rate of development.
But the driver experience (the moments that determine whether a driver renews a subscription, recommends a network to a friend, or quietly stops using the app after one frustrating registration) is not fixed by the platform. They’re configurable. And the operators who treat them as configurable will build a driver relationship that reflects their specific business, their specific users, and their specific decisions.
White label gets your brand into the app. The Embedded Web App is what you use to put your brand to work.
AMPECO handles the platform logic. You own the experience and the relationship with your drivers.
To see the Embedded Web App configured for your specific network, book a demo with our team. We’ll walk through the trigger points that are relevant to your business and show you what the driver experience looks like from both sides of the configuration.
