Context

ChargePoint runs one of the world’s largest commercial EV charging networks. For its first decade it ran a direct-sales model, a tightly managed pipeline where every station activation was choreographed by an in-house team. Four years ago it shifted to a Value-Added Reseller model, and today roughly 90% of sales flow through partners like EATON. The activation process never caught up.

The result was two people living in two separate worlds. The electrician shows up on-site, mounts the hardware, scans serial numbers, confirms connectivity, and leaves: everything through the Installer App. The org admin never touches hardware; they manage policies, pricing, and activation afterward in Polaris Suite. Before this work, those two worlds didn’t talk, and a Customer Experience agent had to bridge every single handoff by hand.

The problem

Because the field app and the platform never shared a clean data handoff, every activation stalled at the seam between them. What should have been a premium, self-serve experience became recurring operational overhead.

• Stations arrived on the platform with no owner attached: nothing linked a deployed device to the organization that bought it.
• A CX agent had to step in on every activation to manually identify the owner and connect the stations.
• Installing 10 stations at one location meant running the same standalone flow 10 times.

Iteration 1: MVP

I started by mapping the data handoff between field and platform end to end. The first challenge wasn’t screens. It was flow: at what point in the physical workflow is org identity even knowable? Mapping the deployment surfaced three gaps the CX agent had been bridging, and the first release closed them.

• Sites concept: a physical address becomes the unit of work, so stations installed together stay together.
• CMS declaration upfront: ChargePoint cloud or a third-party system (be.ENERGISED, Studio); the two paths diverge immediately.
• Org pre-assignment: org identity pushed from Salesforce and shown on the installer’s summary as a read-only signal.
• Email-triggered activation: a regional link (US/EU/CA, Prod/QA) sent to the org admin the moment the job is marked complete.

Stakeholder review: what the MVP got wrong

Taking the MVP to review surfaced four failures that reshaped the next iteration:

• Silent pre-assignment failure: when the API org link broke, there was no error feedback. The installer saw “Org ✓” while the admin received nothing.
• No asset visibility: the admin had no way to confirm from Polaris what had actually been installed.
• Per-station email didn’t scale: a 30-station site fired 30 separate emails. Still manual, just a different shape.
• Meaningless default site name: an auto-generated string like 450haciendacalifornia meant nothing to the admin; it needed a clear naming convention or a mandatory rename.

Iteration 2: Refinement

Iteration 1 exposed two problems: a per-station email model that broke at scale, and an org pre-assignment flow that leaned on Salesforce data missing in about 30% of VAR transactions. Iteration 2 fixed both, and removing the dependency entirely turned out to be cleaner than improving the error state around it.

• Org-agnostic completion: the install finishes cleanly regardless of Salesforce data. The station queues in Polaris as “Ready for Activation” immediately, and the admin gets a regional link to attach it to their org afterward.
• Job Summary screen: all installed devices grouped into one submit event. One activation per site, not per station.
• Add more stations + cluster devices: after commissioning the first device, installers can loop back and add each subsequent station to the same job before submitting.
• Regional self-activation links: sent to admins once the job is complete.

Outcome

The handoff between field deployment and platform management became a single, unified data flow: a station commissioned in the field now shows up in Polaris ready to activate, with no CX involved. Enterprise accounts get their org pre-assigned via API; the VAR channel (90% of sales) gets a regional activation link by email. Both routes land in the same place, on the admin’s own timeline.

White-glove activation stays available, now as a chargeable premium service rather than the default. That shifts agent cost from operational overhead to a revenue line.

0

CX touches on the self-serve path

1

activation event per site & org, not per station

2

clean activation routes: enterprise pre-assign + VAR hyperlink

What two iterations taught me

Both iterations came down to the same move: letting go of an assumption I’d been designing around. The first version assumed org identity had to be resolved at the moment of install, and that one belief drove the whole flow into fragility. Once I stopped defending it, the design got simpler and sturdier. The pattern that mattered wasn’t fixing screens; it was finding the locked assumption underneath them.

• Design for the data you have, not the data you need. Pre-assignment assumed clean Salesforce data at install time. The field didn’t have it. Designing from what was reliably present (the station MAC, the site address, the installer’s job record) produced a flow that survived contact with reality.
• The handoff point is the design. This was never about screens; it was about who holds responsibility at each point in a multi-party workflow. Designing the installer-to-admin handoff explicitly, instead of routing it through a CX agent, was the single decision that made self-serve viable.
• A PRD without engineering input isn’t a requirement: it’s an assumption. The “sites” grouping sat in the PRD from day one and shaped two iterations before engineering review found it wasn’t buildable as written. Earlier alignment between PM, dev, and design on what’s actually shippable would have caught it before it set the direction.
• Two users in one flow means two jobs to honour. The installer’s job is physical; the admin’s is operational. Demanding org identity at install time coupled them and violated both. Decoupling honoured both.

The bigger picture

I didn’t just design a field tool. I designed what it feeds. The Installer App is the upstream half of a two-part system; the activation flow in Polaris Suite only works because this app captures the right data, in the right shape, at the right moment. The decisions that mattered most never show up in the UI: decoupling org identity from the install event, making the job record the unit of work instead of the individual station, letting the install complete cleanly even when Salesforce data wasn’t there. That seam, not the app, is what I was designing.