Piloting a fleet charging provider: Measurable criteria for approval

A pilot with a fleet charging provider is meaningful when you define before the start which results will lead to approval. Test real drivers, important routes and at least one complete billing process. A successful card start alone is not enough: vehicle assignment, costs, corrections and support must also work in the intended operation. The pilot ends with a justified rollout decision and documented limitations.

Write a short, binding pilot brief

Summarise on one page what you want to decide. For example: can the proposed setup handle public charging for the intended field-service group with correct corporate billing? Record which product configuration is being tested and which services remain outside the pilot.

Name responsible people on both sides and the internal approvers. Fleet management assesses operational suitability, finance checks the month-end close and drivers assess practical use. One person brings the results together. Also agree costs, duration, support channels and what happens to access accounts after the test.

Market research findings can help choose areas to test. The Dataforce fuel and charging card study covers provider selection and charging criteria, among other topics. However, it does not replace an assessment of your own operating profile. A good pilot answers the questions a general market overview leaves open.

Select participants by use case

Do not recruit only technically confident volunteers with convenient home charging. If the future user base includes employees without private charging, pool car users or drivers in rural regions, these groups need suitable representation in the pilot.

The necessary size depends on the diversity of your processes. A small fleet with a uniform use case needs fewer different cases than several companies with changing vehicles. What matters is coverage of the relevant variations. A pilot with ten similar drivers can be less informative than one with six deliberately selected people.

Before starting, record how participants currently charge and handle billing. Without a baseline, you can describe the new solution afterwards, but it is difficult to demonstrate an improvement. Record charging locations, transaction volumes, typical problems and processing effort.

Build a test catalogue with normal and difficult cases

The test should follow the whole journey from invitation to invoice. Give every case an identifier, an owner, an expected result and an observation. This allows specific failures to be retested.

Simulate exceptions in a controlled way. You do not need to leave a driver with an almost empty battery at an unsafe station to test a support case. An agreed trial with sufficient reserve also tests the process.

Our fleet onboarding guide explains the first test charging session. In a provider pilot, it is only one test case within a broader acceptance process.

Define metrics with a clear denominator

“Most charging sessions worked” cannot be assessed properly. Count start attempts and successful starts separately. An abandoned attempt belongs in the denominator even if the driver subsequently charges successfully at another charger. Document known causes without confusing the number of successful business trips with the technical start success rate.

For billing, you can measure the share of fully assigned transactions. State what “fully” means: for example, corporate account, vehicle reference, kWh and an amount that can be reconciled. Check when the information becomes available. A charging session may still be incomplete on the test day but be correctly supplemented before month-end closing.

Also measure additional processing time and recurring queries. Separate setup from routine work. A one-off explanation of a new profile must not be extrapolated into permanent monthly effort; conversely, a regularly required manual export must not disappear from the calculation.

Set approval thresholds before seeing the results

Approval criteria follow your operational requirements. For safety-critical or time-critical work, even one unresolved charging access issue may be a stop signal. A missing optional chart, by contrast, can be dealt with later. Define error categories instead of counting every issue equally.

One possible, explicitly illustrative rule is: all critical use cases have been successfully tested, no open error prevents month-end closing and every deviation has a documented resolution process. Only set quantitative targets if the sample and observation period can meaningfully support them.

With 20 observed charging sessions, even a single failure represents a large percentage. Conversely, 20 successful sessions do not prove lasting availability. Always report absolute numbers, the time period and the cases covered. Avoid a level of precision your data cannot support.

Actually test corrections and month-end closing

Have finance reconcile the first complete report with the invoice. Check additional fees, credit notes, late transactions and the desired cost centre logic. If the final invoice arrives only after the planned pilot end, commercial approval must take place later accordingly.

Test at least one traceable query. Can the provider find a specific transaction? Is it clear which information is still missing and who is handling the case? The speed of the first response is only part of the result. What matters is whether the session is fully clarified and corrected if necessary.

Record agreed service targets separately from response times observed by chance. A fast response during a closely supported pilot is not a general service commitment. Ask which support is actually included in the subsequent contract.

Decide between approval, limited rollout and retesting

Full approval is appropriate when the relevant cases have passed and no significant unresolved limitation remains. A limited rollout can make sense when the setup already works for certain driver groups but others need further testing. State that boundary explicitly.

A retest should examine a specific fault and a changed solution. Do not simply repeat the same pilot without a new question. Fundamental problems may also lead to a decision against rollout. That is a useful result when it is based on transparent criteria.

Finish with a written record: scope tested, observations, open points, responsible people and the approval decision. This document becomes the basis for rollout and subsequent success monitoring.

Prepare a meaningful pilot with StromNow

StromNow Business combines a driver app, central billing and cost reports. The appropriate pilot scope should test precisely the processes your business intends to use afterwards.

For a pilot discussion with StromNow, bring your driver groups, typical routes, a billing month and your approval criteria. This allows a test to be agreed that prepares a specific procurement decision and makes its limitations clear.