Most charge point management system RFPs ask the wrong questions. They check for OCPP support (every vendor claims it), request a feature comparison matrix, and evaluate the dashboard’s visual design. The result is a shortlist of platforms that look equivalent on paper but diverge dramatically in production.

The gap between an RFP response and operational reality is where CPOs lose time, budget, and competitive positioning. A vendor can truthfully claim “OCPP support” while implementing only OCPP 1.6J, which lacks the security model, smart charging depth, and ISO 15118 readiness that multi-site networks require. A platform can offer “multi-tenancy” through shared database rows rather than genuine architectural isolation.

This checklist defines 12 requirements that separate a charge point management system capable of scaling to thousands of charge points from one that reaches its ceiling at a few hundred. Each requirement includes the specific RFP question that reveals whether the vendor actually delivers it. The requirements are ordered by the frequency with which vendors fail to meet them: the first four are where most SaaS CPMS platforms fall short.

1. Full OCPP 2.0.1 Compliance, Not Just 1.6J

OCPP 1.6J remains the most widely deployed EV charging protocol globally. Most CPMS vendors claim OCPP support based on 1.6J alone. OCPP 2.0.1 is a fundamentally different protocol: it introduced mandatory TLS security, a new device model architecture, transaction-level energy metering, and the smart charging profiles that multi-site load orchestration depends on. In late 2024, the Open Charge Alliance published OCPP as IEC 63584, making it a formal international standard that procurement teams can reference in binding contracts.

For networks receiving US federal funding, the NEVI program mandates OCPP compliance. In Europe, AFIR’s interoperability requirements assume current-generation protocol support.

The vendor gap: Many platforms implement OCPP 2.0.1 partially, supporting basic session management but lacking the advanced smart charging profiles, certificate management, or firmware update orchestration that the specification defines.

RFP question: “Which OCPP versions are you OCA-certified for? Provide certificate numbers for each version.”

2. Grid-Services Integration (OpenADR, IEEE 2030.5)

OCPP governs charger-to-backend communication. It does not address backend-to-grid communication. For CPOs planning to participate in demand response programs, monetize flexible load, or comply with grid-services mandates, the CPMS must support northbound protocols that most SaaS vendors have never implemented.

OpenADR enables the CPMS to receive and respond to utility DR signals. IEEE 2030.5 governs DER communication in California (Rule 21, CSIP) and states adopting similar frameworks. The Pacific Northwest National Laboratory’s 2025 assessment of EV standards for grid services confirms that no single protocol covers the full stack; the CPMS must orchestrate OCPP, OpenADR, and IEEE 2030.5 simultaneously.

The vendor gap: Grid-services integration requires deep protocol engineering. SaaS CPMS platforms are optimized for charger management, not grid participation. DR support, when offered, typically requires third-party middleware with separate licensing.

RFP question: “How does your platform participate in utility demand response programs? Which grid-side protocols (OpenADR, IEEE 2030.5, OSCP) do you support natively?”

3. V2G and Bidirectional Charging Support

OCPP 2.1 added functional blocks for vehicle-to-grid (V2G) bidirectional power transfer. ISO 15118-20 extends Plug & Charge to support bidirectional energy flows. The EU’s AFIR mandates ISO 15118 for V2G-capable chargers from January 2026. Implementing V2G at the CPMS level requires managing reverse energy metering, grid export settlement logic, and coordination between the vehicle, charger, and utility systems.

The vendor gap: V2G is architecturally complex. It requires changes across the entire stack: the charger firmware, the CPMS session model, the billing engine, and the grid-side protocol interface. Most CPMS platforms have not implemented OCPP 2.1’s V2G blocks.

RFP question: “Can your platform manage bidirectional energy flows? Which ISO 15118 versions do you support, and how is V2G settlement handled in the billing engine?”

4. Custom Billing Logic and Dynamic Pricing

CPOs operating at scale rarely use flat per-kWh pricing. Multi-site networks need time-of-use rates tied to utility tariff schedules, fleet-specific contract pricing, split billing between site hosts and network operators, subsidy pass-through for NEVI compliance, and dynamic pricing that responds to wholesale energy markets or real-time grid signals.

The vendor gap: SaaS billing engines are designed for the most common pricing models. Custom logic, such as pricing formulas that adjust based on grid stress signals or fleet contract terms, requires either vendor-side custom development (expensive, slow, and the IP belongs to the vendor) or integration with an external billing system (adding complexity and data reconciliation overhead).

RFP question: “Can we implement custom pricing formulas? Can pricing respond dynamically to real-time grid signals or wholesale spot prices? Who owns the IP if custom billing logic is developed?”

5. True Multi-Tenant Architecture

Multi-tenancy is not a feature; it is an architectural decision made at the database and service level. CPOs managing sub-brands, operating across utility territories, or offering white-label charging services to site hosts need tenant-level isolation of data, billing configuration, user permissions, and API access.

The vendor gap: Some platforms claim multi-tenancy through row-level database filters, which share a single schema across all tenants. Genuine multi-tenancy provides schema-level or service-level isolation with independent configuration per tenant, tenant-scoped encryption keys, and separate audit logs. The difference surfaces when tenants need distinct compliance settings, regional data residency, or independent third-party integrations.

RFP question: “Do tenants share a database or operate on isolated schemas? Can each tenant configure independent billing rules, API keys, and compliance settings?”

6. API-First Architecture with Full Programmatic Access

A CPMS does not operate in isolation. It connects to payment processors, fleet management platforms, ERP systems, utility APIs, and hardware diagnostics tools. The depth of API access determines how effectively the CPMS integrates into the CPO’s broader technology stack.

The vendor gap: Many CPMS platforms have APIs that expose a subset of the platform’s functionality: read-only session data, basic charger status, and user management. Full programmatic control over tariffs, charging profiles, firmware deployment, and reporting is often missing. Webhook support for real-time event notifications is inconsistent.

RFP question: “Provide your API documentation. What percentage of platform functionality is accessible via API? Do you support webhooks for session events, fault alerts, and payment notifications?”

7. OCPI Roaming and Interoperability

OCPI 2.2.1 (Open Charge Point Interface) enables cross-network charging. A driver on Network A charges at a station managed by Network B, with seamless billing and session management. AFIR mandates cross-network roaming in the EU. In the US, roaming is increasingly expected by drivers accustomed to aggregator apps.

The vendor gap: Basic OCPI implementations handle session data exchange but lack full support for tariff transparency, real-time authorization, CDR (Charge Detail Record) settlement, and token management across roaming hubs. Some vendors support OCPI only through a specific hub partner, limiting flexibility.

RFP question: “Which OCPI version do you support? Do you support both CPO and eMSP roles? Which roaming hubs are you connected to, and can we add additional hubs?”

8. White-Label and Multi-Brand Capabilities

CPOs operating multiple brands, or offering white-label access to site hosts, need per-brand theming across driver apps, web portals, email communications, and charging session receipts. A white-label CPMS goes beyond cosmetic customization: it requires independent App Store publications, brand-level analytics, and the ability to run multiple branded experiences from a single backend instance.

The vendor gap: Most SaaS platforms offer logo and color customization but publish the driver app under the vendor’s own App Store account. Genuine white-labeling requires the CPO’s own app store presence, which demands a separate build and deployment pipeline.

RFP question: “Can we run multiple brands with separate user-facing experiences from a single backend? Is the driver app published under our App Store account or yours?”

9. Firmware OTA Management at Scale

OCPP supports firmware updates, but managing over-the-air (OTA) deployments across thousands of heterogeneous chargers (mixed vendors, mixed firmware versions, mixed OCPP versions) requires orchestration that most platforms lack. Staged rollouts, automatic rollback on failure, per-site scheduling, and version tracking across the fleet are operational necessities at scale.

The vendor gap: Basic firmware update support exists in most CPMS platforms. Orchestration features, such as staged rollouts by percentage, geographic region, or charger model, automatic rollback, and rollout monitoring dashboards, are rare in SaaS offerings.

RFP question: “How do you handle firmware updates across a mixed-vendor fleet? Do you support staged rollouts, automatic rollback, and version tracking per charger model?”

10. Smart Charging with Multi-Level Load Balancing

Basic load balancing distributes available power equally across active sessions. Advanced smart charging manages load at the circuit level, site level, and portfolio level simultaneously, incorporating departure time optimization, priority queuing, renewable energy availability, and external capacity signals (OSCP, utility API).

The vendor gap: Equal-split load balancing is standard. Dynamic smart charging that responds to real-time grid signals, optimizes across multiple sites, and integrates with building energy management systems (BEMS) is architecturally demanding and rarely found in off-the-shelf platforms.

RFP question: “Does your load balancing operate at the circuit, site, and portfolio level? Can it integrate external capacity signals such as OSCP or utility APIs?”

11. Multi-Site Fleet Management with Hierarchical Permissions

Managing 500+ sites with regional managers, site-level operators, maintenance technicians, and fleet customers requires a role-based access control (RBAC) model that goes beyond simple admin/user roles. Permissions must be scoped to site groups, individual sites, or specific chargers, with audit trails for every configuration change.

The vendor gap: Flat permission structures (admin, operator, viewer) are common. Hierarchical RBAC with custom roles, site-group scoping, and granular permission inheritance is an enterprise feature that many CPMS platforms have not built.

RFP question: “Describe your role-based access control model. Can we create custom roles with permissions scoped to site groups, individual sites, or specific chargers?”

12. Uptime SLA with Transparent Incident Reporting

Vendors quote “99.9% uptime” but definitions vary. Does the SLA cover only the backend platform, or does it include charger-level availability? Is scheduled maintenance excluded? What are the financial penalties for breach? The NEVI program requires 97% uptime per charger, a metric that demands monitoring granularity most SaaS platforms do not expose.

The vendor gap: Platform-level SLAs (backend availability) are standard. Charger-level SLAs (individual station uptime) and transparent incident reporting (root cause analysis, post-mortems, real-time status dashboards accessible to the CPO) are not.

RFP question: “What is your SLA definition? Does it include charger-level availability? What are the financial penalties for breach, and do you provide real-time uptime dashboards and incident post-mortems?”

Charge Point Management System RFP Checklist — 12 Requirements Summary
# Requirement Vendor gap RFP question
1 OCPP 2.0.1 compliance: Full IEC 63584 certification, not just 1.6J Most vendors implement 1.6J only; 2.0.1 support is partial Which OCPP versions are you OCA-certified for? Provide certificate numbers.
2 Grid-services integration: OpenADR VEN/VTN, IEEE 2030.5, OSCP SaaS platforms lack northbound grid protocols; DR requires middleware Which grid-side protocols do you support natively for demand response?
3 V2G bidirectional support: OCPP 2.1 + ISO 15118-20 V2G functional blocks not implemented; settlement logic absent Can your platform manage bidirectional energy flows and V2G settlement?
4 Custom billing logic: Dynamic pricing, fleet contracts, subsidy pass-through Templated pricing only; custom logic requires vendor dev (IP retained by vendor) Can we implement custom pricing formulas? Who owns the IP?
5 Multi-tenant architecture: Schema-level isolation, per-tenant configuration Row-level filtering, not genuine isolation; shared config limits Do tenants share a database or operate on isolated schemas?
6 API-first architecture: Full CRUD, webhooks, versioned endpoints Partial API coverage; read-only endpoints; no webhooks What percentage of platform functionality is accessible via API?
7 OCPI roaming: CPO + eMSP roles, multi-hub, tariff transparency Basic OCPI; limited to single hub; no CDR settlement Which OCPI version? Both CPO and eMSP roles? Which roaming hubs?
8 White-label / multi-brand: Own App Store presence, brand-level analytics Logo swap only; app published under vendor’s account Is the driver app published under our App Store account or yours?
9 Firmware OTA at scale: Staged rollouts, rollback, version tracking Basic update support; no staged rollout or rollback orchestration Do you support staged rollouts, automatic rollback, and per-model tracking?
10 Smart charging: Circuit/site/portfolio load balancing, external signals Equal-split only; no real-time grid signal integration Does load balancing operate at circuit, site, and portfolio level?
11 Hierarchical RBAC: Custom roles, site-group scoping, audit trails Flat admin/user roles; no site-group scoping Can we create custom roles scoped to site groups or individual sites?
12 Uptime SLA: Charger-level availability, penalties, incident reporting Platform SLA only; no charger-level metrics or post-mortems Does SLA include charger-level availability? What are breach penalties?

When the Checklist Reveals the Build-vs.-Buy Decision

The 12 requirements above form a scoring framework. A vendor that checks all 12 boxes is the right choice for your network. In practice, most SaaS CPMS platforms satisfy requirements 6 through 12 reasonably well but fall short on the first four: deep OCPP compliance, grid-services integration, V2G readiness, and custom billing logic.

That pattern is structural. SaaS platforms are built for the broadest possible market: single-region CPOs with standard pricing, basic load management, and no grid-services requirements. The first four requirements on this checklist represent capabilities that require deep protocol engineering and architectural decisions made at the foundation level. They cannot be added as features later.

When the gap analysis reveals persistent shortfalls in requirements 1 through 4, the RFP itself has answered the build-vs.-buy question. The missing capabilities define the specification for a purpose-built charge point management system. Codibly’s engagement building a scalable OCPP server for the IMP PAN research consortium illustrates the pattern: multi-site management across three countries, V2G protocol support, and RFID authentication. No off-the-shelf platform could accommodate that combination. For CPOs whose requirements exceed the SaaS ceiling, the RFP checklist becomes the engineering brief.