Why most EV charging RFPs underperform
Most EV charging software RFPs fail because they reward good demos instead of measuring deployment risk. The questions that decide whether a platform survives contact with your real fleet rarely appear on the scorecard.
Many RFPs ask vendors to confirm a long list of features. That produces good-looking answers and weak buying decisions. A vendor can truthfully check every box on a feature matrix and still hand you a platform that struggles the moment a mixed fleet, a roaming partner, or a failed firmware push enters the picture. We have seen RFPs that spend ten pages on dashboard widgets and a single line on data export, then watch the buyer get trapped two years later when they want to leave.
The problems that actually hurt show up after signature, not during the sales cycle. They tend to cluster in four areas:
- How hard migration will be once chargers are live
- Whether your operational data stays portable and exportable
- How the system behaves during incidents and partial failures
- What it costs to change architecture later
A better RFP focuses on the constraints that matter after the contract is signed. The rest of this checklist walks through each area a Charge Point Operator should test, in roughly the order it should appear in your procurement document. If you are still defining the underlying protocol baseline, the ultimate guide to OCPP is a useful companion read before you draft a word of the RFP.
Testing fleet and protocol fit
Test fleet and protocol fit by asking what breaks in production, not which standards the vendor claims to support. "OCPP compliant" is the most over-trusted phrase in charging procurement, because real interoperability lives in the gaps between the spec and each charger vendor's firmware.
In practice, OCPP support is never uniform across a charger fleet. A backend that handles OCPP 1.6J cleanly for one manufacturer can stumble on another vendor's interpretation of the same messages: a slightly different BootNotification payload, an unexpected status during a transaction, or a security profile that the charger advertises but never completed. In mixed-fleet rollouts, the failure usually shows up as a small percentage of chargers that connect, transact, then silently drop sessions, and nobody can tell from a feature matrix that this will happen.
So push vendors past the checkbox. Ask them to describe:
- Specific charger brands and models running in their production fleets today
- Which OCPP versions and profiles they support in production, not just on a roadmap
- How they handle mixed fleets spanning OCPP 1.6 and 2.0.1 simultaneously
- Which OCPP security profiles (1 through 3) are deployed and how certificate handling works
- Firmware management and update workflows, including staged rollouts
- A candid list of known compatibility gaps and the workarounds they use
In our experience, the most revealing RFP question in this section is simply: "Which charger models break most often against your backend, and how do you handle them?" Vendors who answer specifically have operated a real fleet. Vendors who deflect are selling you a slide deck.
For deeper protocol context to write sharper questions, the official OCPP specifications from the Open Charge Alliance help separate charger-to-backend concerns from roaming concerns.
What migration and coexistence questions belong in the RFP?
Migration questions should be mandatory, because most CPO platform changes are migrations, not greenfield builds. You already have chargers, sessions, and customers, and the real risk is moving them without dark sites or lost revenue. A platform that only describes the end state, never the journey, is hiding the hardest part.
The core failure mode we see is the "big bang" cutover that assumes every charger will reconnect cleanly to the new backend on the same night. In reality, a fraction always lags: a charger on a flaky cellular link, a unit mid-transaction, a site behind a firewall that needs a new allowlist. If the platform cannot run alongside your current backend while you move chargers in controlled waves, that lag becomes downtime. Coexistence is not a luxury; it is how you de-risk the rollout.
Include questions like these, and require written answers:
- Can we migrate chargers in waves rather than a single cutover?
- Can your platform run alongside our current backend during transition?
- How exactly does rollback work if a wave fails midway?
- What dependencies exist on your professional services during migration?
- How long can mixed-fleet or mixed-backend states remain supported?
The rollback answer matters most. Rollout failure is an operations problem before it is an engineering problem, and your night-shift team needs a recovery path that does not require a vendor escalation call at 2 a.m. If you need detailed technical grounding for these questions, pair this checklist with the OCPP 1.6 to 2.0.1 migration guide.
How do you evaluate roaming and interoperability in an RFP?
Evaluate roaming readiness even when roaming is not in phase one, because your contract horizon usually outlasts your initial scope. A three-year platform commitment will almost certainly cross a moment when a roaming hub, a payment partner, or an eMSP integration becomes a commercial requirement, and retrofitting OCPI onto a platform that never planned for it is painful.
OCPI is where interoperability promises get tested in detail. It is not enough for a vendor to say "we support roaming." The substance lives in how cleanly they map tariffs, tokens, sessions, and CDRs between systems, and whether their tooling lets your team onboard and monitor partners without a support ticket for every change. A platform that technically speaks OCPI but exposes no operational tooling around it will quietly push that work back onto you.
Ask vendors to describe:
- Whether they support OCPI in production today, and which versions
- Connectivity to roaming hubs and to bilateral, direct partners
- How tariffs, tokens, sessions, and CDRs are exchanged and reconciled
- What operational tooling exists for partner onboarding and monitoring
- How disputes and mismatched CDRs are surfaced and resolved
If your team is still mapping roles and architecture across CPO and eMSP boundaries, start with the complete OCPI roaming guide and the OCPI protocol overview before finalizing this section.
Why does data ownership belong in an EV charging RFP?
Data ownership belongs in the RFP because it protects every future option you have, including the option to leave. The platform you choose now will accumulate years of sessions, CDRs, and protocol events, and if that history is hard to extract, you are locked in regardless of how the contract reads.
There is a difference between a vendor who lets you read your data and one who lets you own it. Read access through a dashboard is not portability. What you need is programmatic, complete, and timely access: APIs that cover the full data model, event streaming or webhooks for near-real-time flows, and bulk historical export in a documented format you can actually reload elsewhere. Raw protocol event access matters more than buyers expect, because reconstructing a billing dispute or an uptime claim often requires the underlying OCPP messages, not just the summarized session.
Request explicit detail on:
- API coverage across the full data model
- Webhooks or event streaming for live data
- Historical bulk export, including format and size limits
- Session and CDR access for billing and reconciliation
- Raw protocol event access for audits and disputes
- Retention limits and any cost attached to longer retention
- Contract language that names you as the data owner
And include one blunt, written question: if we leave your platform, how do we retrieve all historical data, in what format, and at what cost? The quality of that answer predicts how the relationship ends. For the broader argument, see why data ownership matters for CPOs.
How should security and operations be assessed in procurement?
Assess security and operations as two linked disciplines, because a secure platform that cannot run smoothly at 3 a.m. still fails your drivers. Procurement tends to over-index on a security questionnaire and under-index on day-two operations, yet both decide whether your network stays available and trustworthy.
On the security side, you are testing whether the platform treats charger networks as the critical infrastructure they are. Charging backends touch payment data, control physical hardware, and increasingly fall under regulatory scrutiny. The questions should map to concrete controls rather than reassurances.
Security questions to require
- Identity and access control, including role separation and SSO
- Audit logs that capture who changed what, and when
- Credential and certificate rotation, including OCPP security profile support
- TLS configuration and certificate lifecycle handling
- Environment isolation between staging and production
- A documented incident response process with notification timelines
Operations questions to require
- Monitoring and alerting on charger health and connectivity
- Safe bulk configuration changes across thousands of chargers
- Change history and the ability to audit configuration drift
- Support SLAs with named response and resolution targets
- Maintenance windows and how they are communicated
- Recovery playbooks for partial and full outages
The operational answers reveal experience. A vendor who can describe how they push a configuration change to ten thousand chargers without bricking a subset has run a large network. For the security baseline behind these questions, the OCPP security profiles guide is a useful reference.
What commercial and contract terms reveal vendor lock-in?
The commercial section reveals lock-in more reliably than any technical question, because lock-in is ultimately a pricing and exit-cost problem. A platform can be technically open and still trap you through punitive integration fees, opaque renewal pricing, or transition terms that make leaving prohibitively expensive.
Pricing structure deserves particular scrutiny. Per-charger pricing that looks reasonable at a hundred chargers can become the largest line in your operating budget at ten thousand, so model the curve, not the entry price. Watch for fees that activate exactly when you grow: charges for additional integrations, for data exports, for onboarding each roaming partner. Those are the levers a vendor pulls once you are committed.
Ask vendors to explain in writing:
- Pricing behavior at small, mid, and large fleet sizes
- Fees for integrations, exports, or partner onboarding
- Contract length, auto-renewal, and termination terms
- How prices can change at renewal, and any caps
- The real cost and necessity of professional services
- Transition support and exit assistance if you migrate away
Make vendors commit on paper. Vague commercial language is the most expensive kind, because it converts into leverage against you precisely when you have the least room to maneuver. To compare how different platform models handle these trade-offs, the platform comparison page is a useful starting point.
Comparing the RFP areas on risk and timing
The areas above are not equally urgent, and they fail in different ways. Use the table below to decide what must be locked before vendor demos and what can be refined later. The point is to write the high-risk, hard-to-retrofit requirements first.
| RFP area | Primary risk if ignored | When it bites | Hard to retrofit later? |
|---|---|---|---|
| Fleet and protocol fit | Chargers connect but drop sessions | During rollout | Medium |
| Migration and coexistence | Downtime during cutover | At go-live | High |
| Roaming and interoperability | Blocked partner and revenue expansion | Mid-contract | High |
| Data ownership and export | Locked in, no clean exit | At renewal or exit | Very high |
| Security and operations | Outages and compliance exposure | Continuously | Medium |
| Commercial and contract terms | Cost escalation and exit penalties | At scale and renewal | Very high |
How should you weight the RFP scorecard?
Weight the scorecard so the evaluation stays honest under sales pressure, keeping migration and data ownership heavily weighted. Translate the priorities into explicit percentages before any demo, so a charismatic sales pitch cannot quietly inflate a low-risk feature category. The weights below are a sensible default for a growth-stage CPO; adjust them to your own risk profile.
| Area | Weight |
|---|---|
| Fleet and protocol fit | 20% |
| Migration and coexistence | 20% |
| Roaming and interoperability | 15% |
| Data ownership and exports | 15% |
| Security and operations | 15% |
| Commercial model and terms | 15% |
Questions worth copying into your RFP
Use these directly if you want a sharper shortlist. Each one is written to force a specific, written answer rather than a yes or no:
- Describe how your platform supports staged migration from a legacy CPMS or CSMS, including coexistence with our current backend.
- Explain how we export sessions, CDRs, meter values, and charger status history, in what format, and at what cost.
- List any workflows that require vendor-managed services or custom development.
- Describe production support for OCPP 1.6 and 2.0.1 in mixed fleets, including known failure modes.
- Explain current support for OCPI, roaming hubs, and bilateral partner integrations.
- Describe audit logging, access control, and credential rotation features.
- Explain rollback and recovery procedures during rollout failures.
- Describe all commercial dependencies that could limit switching or multi-vendor operations.
How to use this checklist
Sequence the work so architecture, procurement, and rollout stay aligned. Drafting the RFP in the wrong order, commercial terms before protocol fit, for example, tends to produce a document that asks the easy questions loudly and the hard ones not at all.
The order we recommend:
- Use this post to draft the procurement structure and scorecard.
- Use the OCPP platform buyer guide to sharpen the evaluation criteria for each section.
- Use pricing and contact when you are ready to move from shortlist to implementation planning.
That order keeps the technical, commercial, and operational lenses pointed at the same target. The best RFP is not the longest one; it is the one that surfaces the risks a polished demo is designed to hide.
