EV Charging RFP and Tender Specification Support

Protocol clauses that mean something

Requiring OCPP support is close to meaningless on its own, because two compliant systems can still fail together. The clause worth writing requires demonstrated interoperability with your intended platform, at named versions, with evidence.

Data and exit

Who owns session data, in what format it can be exported, and what happens to chargers if the contract ends. Without exit provisions the procurement creates a dependency that outlasts the contract, and the second tender has only one bidder.

Service levels that can be enforced

An availability target needs a measurement method, an exclusion list, a reporting obligation and a consequence. Targets without those four are aspirations, and both parties know it at signature.

Structure bids so they compare

Mandating a response structure, a pricing breakdown and an evidence requirement per clause makes evaluation possible. Free-form responses guarantee that the strongest technical bid and the strongest bid-writing team are confused with each other.

Our position

RIOD supplies charging hardware and software, so we could bid into a specification we helped write. Where that is unacceptable, we will either write the specification and stand out of the tender, or bid and not write it. We will not do both on the same procurement.

Write requirements that can actually be tested

Most charging tenders contain a line reading OCPP 1.6J or later. It is close to unenforceable, and we have watched a buyer discover that after award rather than before.

A charger sold to one of our customers as an OCPP unit was not interoperable with the platform they had already committed to. The vendor had not misdescribed it. The specification had asked for a protocol version and the buyer needed a working integration, and no part of the document connected the two.

• Name the platform and release the units must interoperate with, and require evidence of testing against it
• Require the message set your operation depends on, listed, including the failure paths
• Require a demonstrated remote change of management platform, without a site visit, before acceptance
• Require a stated field failure rate with its definition, so that answers can be compared to each other
• Require over-the-air firmware update to be demonstrated, not described

Every one of those is testable at acceptance. A version number is not.

How we work with you on this

We manufacture chargers, so we should not write a specification that only we can meet. A tender document with our product shape embedded in it is worth nothing to you and will be spotted by every bidder.

So the specification is written to be vendor-neutral and testable, with your procurement and technical teams, and we are content to be one of the bidders against it or to stay out of the bid entirely. Say which you would prefer at the start.