Charging Point Management System: A Practical Pilot Test Checklist

A charging point management system can look convincing in a sales demonstration and still create expensive problems after deployment. A charger connects, a dashboard turns green and a test session finishes. Yet none of those observations tells you whether the platform will recover a session after a connection loss, explain a disputed invoice or give your team usable data when a contract ends.

This guide turns a software evaluation into a practical pilot. It is written for charge point operators, charger manufacturers and fleet teams comparing CPMS platforms. Instead of another feature list, it explains what to test, what evidence to retain and how to make a defensible go-live decision. The scenarios below are recommended acceptance tests, not results from a TrendPower customer deployment.

What should a charging point management system pilot prove?

A useful pilot proves that your specific combination of chargers, firmware, connectivity, payments and operating processes works together. It should answer three questions: can drivers charge successfully, can operators resolve exceptions, and can finance reconcile the resulting money and records?

Start with your operating model. A public network needs clear pricing, accessible payment and reliable settlement. A depot prioritizes departure readiness and site capacity. A manufacturer may need tenant separation and repeatable onboarding across customers. Give each requirement an owner and an observable result before inviting vendors to demonstrate it.

Write acceptance criteria before the demonstration

Replace “supports billing” with a testable statement: the system must produce an itemized record for a session crossing a tariff boundary, with the applicable currency, timestamps and rounding rules. Replace “has APIs” with: our integration team can retrieve a completed session and reconcile its identifier against the invoice export.

Do not impose an arbitrary universal success percentage. Agree thresholds appropriate to your service, sample size and commercial risk. Record every attempted test, including failures. A pilot containing only successful demonstrations cannot show how the platform handles real operations.

1. Build a representative charger and firmware matrix

List every model intended for launch, its firmware revision, protocol version, connector configuration and connection method. Include the equipment you already own, not just a vendor’s preferred demonstration charger. Where a fleet is large, select a representative sample and document what remains untested.

Separate protocol support from tested compatibility

OCPP defines communication between charging stations and management systems. It does not make every product combination identical. The Open Charge Alliance runs a certification program for conformance testing; a buyer should still verify the relevant product, version and certification scope and test the intended hardware combination.

Ask the supplier to show connection, authorization, session start and stop, status changes, meter reporting and supported remote commands on your matrix. An “accepted” remote command is not the same as a vehicle receiving energy. Retain both the command response and the subsequent session evidence.

For each unsupported behavior, distinguish a charger limitation from a firmware issue, platform gap or configuration error. This makes responsibility visible and prevents the same integration problem from returning during rollout. Read the OCA certification guidance when checking a supplier’s claims.

2. Test the complete driver journey

Begin outside the dashboard. Find a charging location as a first-time driver, identify the correct connector, read the price, authorize, plug in, start charging and end the session. Check that the displayed connector identifier matches the physical label and the back-office record.

Include the uncomfortable cases

Try an expired credential, a declined payment and a connector that becomes unavailable between selection and start. Confirm that the interface explains what happened without exposing internal diagnostic codes as the only guidance. Test repeated taps on the start button: the expected result should be one controlled attempt, not duplicate payment activity or confusing parallel sessions.

For app-free access, use a fresh browser session and the intended mobile experience. Check whether a driver can obtain a receipt and contact support. Do not use a browser’s success screen as proof of charging: compare the station state, session record and metered delivery.

If a session fails, your support agent should have enough context to distinguish authorization, payment, communication and charger-side problems. Our CPMS session-start troubleshooting guide provides a diagnostic sequence for that investigation.

3. Verify what happens when connectivity fails

A stable office connection hides many operational weaknesses. Schedule a controlled interruption on test equipment with permission from the site owner. Never disconnect a production network or interfere with a live customer session simply to create a test case.

Observe before, during and after the interruption

Run separate cases for a charger offline before authorization and a connection lost during an active session. Agree expected behavior with the charger manufacturer first. Offline authorization and local buffering depend on equipment, configuration and implementation; do not assume every charger supports them.

After reconnecting, compare the final station state, session start and end times, meter values and billing outcome. Check for missing records, duplicate sessions, stale “charging” states and delayed events presented in the wrong order. Confirm that timestamps retain enough information to interpret time zones consistently.

Ask how operations identify an incomplete session that needs manual review. A platform that makes exceptions visible is more useful than one that silently replaces missing evidence with a plausible number. Record the recovery steps and who is permitted to perform them.

4. Reconcile a charging session from energy to money

Choose a small set of sessions and follow each from the charger record to the customer charge, payment-provider transaction and finance export. These are related records, not interchangeable proof of the same event. An authorization hold, a captured payment and a settled payout can occur at different times.

Use a deliberately awkward tariff example

Consider a hypothetical tariff of 0.40 currency units per kWh. A session delivering 18.6 kWh has a base energy charge of 7.44 before any other applicable components. This arithmetic is only a test fixture, not a recommended retail price. Add the actual tax, time-based fee or parking rule used by your business and verify the documented order of calculation.

Next, test a session crossing a scheduled price change, a zero-energy attempt, a partial refund and a payment failure. Check currency precision, rounding, invoice identifiers and the treatment of daylight-saving changes where relevant. Your finance owner should be able to explain each difference rather than accept a total because it looks close.

For roaming, distinguish live session information from the final charge detail record. Agree which partner is responsible for pricing, invoicing and dispute handling. OCPI provides separate modules for data exchange; review the official OCPI documentation for the version and modules in your integration scope.

5. Make smart charging measurable

A schedule shown on a screen does not prove that a site stays within its operating limits. Define the point where power is measured, whether the limit concerns charging equipment alone or the entire facility, and how non-charging loads enter the calculation.

Test a changing site, not a static limit

On authorized test equipment, connect more vehicles, change their priorities and introduce a representative change in building demand. Compare the requested profile with measured behavior. Allow for agreed response time and device limitations, and document how the system behaves when a meter or communications link is unavailable.

For a fleet, add departure times and required energy. A plan that respects a site limit but leaves critical vehicles unready may still fail your business requirement. Define how an operator sees infeasible demand and changes priorities. Site electrical protection remains an engineering responsibility; software load management should not be treated as a replacement for appropriately designed protection.

6. Give support staff a realistic incident

Ask a person who did not configure the pilot to investigate a failed start or stale connector state using their intended support role. Can they locate the right charger, inspect a timeline, identify the last successful communication and provide a clear next action?

Measure the investigation steps rather than chasing a universal resolution-time benchmark. Check whether essential actions require opening multiple systems or asking a developer to search raw logs. Confirm that remote resets and configuration changes have suitable permissions and a record of who performed them.

Define escalation ownership before launch. The operator, software supplier, equipment manufacturer and payment provider should know what evidence accompanies a ticket. Otherwise, a technically small issue can remain unresolved while every party asks another team to investigate.

7. Check access boundaries and data portability

Create the roles your organization actually needs: support agent, finance user, site owner and network administrator. Test that each can complete required tasks while remaining unable to access unrelated tenants or sensitive settings. Avoid using a shared administrator account for the entire pilot.

Request an export you can use without the vendor

Export charger identifiers, location mappings, session records, tariff references and relevant financial identifiers. Check time formats, units, field definitions and relationships. A spreadsheet containing totals but no stable identifiers may be inadequate for reconciliation or migration.

Ask which data belongs to your organization, which exports are included, what happens at contract termination and how retention and deletion are handled. Assess these requirements with your own security and legal teams where necessary. For a future platform change, our CPMS migration guide explains why asset mapping and record continuity matter.

A compact acceptance record your team can reuse

Use one row per scenario. Keep the description specific enough that a second person can repeat it. A practical record contains the requirement, equipment and firmware, test steps, expected outcome, observed result, supporting evidence, issue owner and retest status.

• Connection: named charger and firmware connect and report the expected state.
• Driver journey: authorization leads to confirmed charging and a consistent final record.
• Recovery: interrupted connectivity produces no unexplained missing or duplicated billing records.
• Finance: session, invoice and payment references reconcile with documented exceptions.
• Operations: support can diagnose an incident with appropriate permissions.
• Exit: exported data remains understandable outside the vendor interface.

Use pass, fail and blocked as separate outcomes. “Blocked because the required firmware was unavailable” is not a pass. Capture limitations in the procurement decision and assign a deadline for resolving launch-critical gaps. Keep smaller usability improvements in a separate backlog so they do not conceal unresolved billing or charging failures.

Frequently asked questions

Is a CPMS the same as OCPP?

No. A charging point management system is an operational software platform. OCPP is a communication protocol used between charging stations and management systems. You still need to assess workflows, payments, reporting, permissions and the actual charger integration.

How long should a CPMS pilot take?

Use completion of agreed scenarios as the decision gate rather than a fixed number of days. Allow time for different tariffs, exception handling and retests. A short demonstration can establish basic connectivity; it cannot substitute for testing your operating model.

Does every operator need roaming in the pilot?

No. Include it when roaming is part of your launch scope or a contractual dependency. If it is planned for later, document the required modules, partner responsibilities and future acceptance tests without treating untested capability as proven.

What should prevent a go-live?

Unresolved failures that stop authorized drivers charging, create unexplained billing differences, expose another tenant’s information or prevent essential operational recovery should trigger a documented decision before rollout. Severity depends on your service and controls, not the visual polish of a dashboard.

Turn your requirements into a useful platform discussion

The best purchasing question is not “How many features does this platform have?” It is “Can our team run these scenarios on our equipment and explain the outcome?” Bring a charger matrix, operating countries, payment requirements, site constraints and integration list to the conversation.

Explore TrendPower’s EV charging point management system or request a platform discussion around your pilot scope. Confirm compatibility and deployment requirements for your project before committing to a rollout.