Not the best CPMS.
The right one.
How Stackbox guided a charge point operator through selecting and rolling out its CPMS – from its own use cases through a weighted requirements catalogue to a signed decision. Vendor-neutral, because we have built CPMS ourselves and sell none.
01 · Challenge
Six vendors, six demos, no comparison.
The market for charge point management systems has matured – there are several genuinely good systems. That is exactly what makes the decision hard: when vendors look comparable at their core, there is no basis left on which to tell them apart.
Every demo shows the happy path
What gets presented is the smooth standard flow. The cases that actually cause trouble later – edge constellations, bulk processing, tariff logic, data export – appear in no demo at all. What ends up comparable is the presentation, not the system.
Requirements without weight
A two-hundred-line catalogue in which everything is a must means every vendor scores almost the same. The decision then falls to price or to the most likeable sales team – not to functional fit.
The system landscape enters too late
The CPMS gets assessed in isolation. That it will later have to talk to ERP, CRM, billing, and the asset system only surfaces during the project – long after the decision is made and the contract signed.
Switching costs stay uncalculated
What happens if it does not fit? Data export, roaming agreements, migration path, ownership of charge point data – questions that belong before the signature and are almost always asked after it.
A CPMS today is largely a commodity: every relevant vendor covers the core functionality. So the decision is no longer driven by the feature list, but by fit – with your own use cases and your existing system landscape. That fit cannot be seen in any demo. It has to be defined and weighted first.
02 · Solution
Your use cases first. Then the market.
Stackbox reverses the usual order: the criteria catalogue comes from your own business processes, not from a vendor. We guide the entire path – from requirements gathering through the RfP to rollout and connection into the existing landscape.
Use cases instead of feature lists
We start at the business processes: which charging products, which customer segments, which billing models, which operational routines. The requirements catalogue grows out of that – not out of a vendor brochure.
Weighting before scoring
Every requirement gets a weight and a class: knock-out, differentiating, or desirable. Only that separation turns a scoring table into a decision you can also defend in front of a supervisory board.
A longlist built on fit, not market share
We know the relevant systems from practice. What makes the longlist is what fits volume, region, and product model – including the honest statement of which vendors are not a candidate for this case at all.
An RfP with verifiable questions
Instead of “Do you support OCPI?” we ask for the version, the specific modules, and production references. Answers you can check – rather than questions every vendor answers with yes.
Proof of concept on the edge cases
What gets tested is not the standard flow but the three or four constellations that experience says will cause trouble. That is exactly where systems that looked identical in the demo come apart.
Rollout and connection into the landscape
After the decision we guide the rollout and connect the system to ERP, CRM, billing, and asset management. Selection does not end with a signature – it ends with a system that works in operations.
Use case → Test criterion
| Use Case | Criterion | |
|---|---|---|
| Ad-hoc charging by card | → | PSP & terminal integration |
| Roaming via partners | → | OCPI 2.2.1 · modules |
| Fleet customers & tariffs | → | Tariff model & tenancy |
| Calibration law & receipts | → | Transparency software · export |
| Existing data from asset system | → | Import & API capability |
| Billing into the ERP | → | CDR export · posting logic |
Scoring Model
Verified in the requirements catalogue
03 · Impact
What a guided selection changes.
The difference does not show on decision day. It shows twelve months later – when the processes nobody checked beforehand are the ones running the business.
vendor interest of our own in the scoring – we sell no CPMS
as the starting point of the catalogue instead of a vendor feature list
criteria classes scored separately: knock-out, differentiating, desirable
run on the edge cases, not on the standard flow
exit scenario and migration path settled before signing
guided through to connection with ERP, CRM, and billing
We would have decided after the second demo – and we would have decided wrong. The catalogue made it visible that two of our most important processes were not covered by the front-runner at all.
Stackbox · CPMS Selection
Facing a CPMS decision?
We look at your use cases and tell you what actually matters in your selection – with no system of our own in the race.
Let's talk →