01Solutions · Industry
The bay is your asset. Charging should raise its yield.
A parking operator already knows what a bay earns per hour, already has enforcement, and already has a payment relationship with the driver. Charging should extend that rather than sit beside it as a separate system with its own app, its own tariffs and its own support queue.
Parking operators
Does this sound familiar
Where you probably are right now
- 01You operate car parks — commercial, airport, station or on-street concessions.
- 02You already have a tariff structure, a payment method and enforcement.
- 03Charging bays have to earn at least what an ordinary bay earns.
- 04Your staff are parking staff, not charging technicians.
What gets in the way
The problems, and what answers each one
Every answer links to the feature that does the work, so you can check the claim rather than take it.
Charging revenue has to beat parking revenue on the same bay
Per-connector revenue and occupancy reporting lets you compare a charging bay against an ordinary one directly, and time-based components let you price the bay as well as the energy.
You do not want a second payment relationship with the driver
Charging can be priced and reported separately while the driver pays through your existing flow, using the API to push session cost into your own billing rather than collecting it independently.
Enforcement already exists and should cover charging bays
Live connector state tells your enforcement team which bays are occupied by a car that is not charging, which is the condition an idle fee or a notice should attach to.
Long-stay parking and fast charging want opposite things
Different tariffs and different idle treatment per site or per zone, so an airport long-stay area and a station forecourt do not have to share pricing logic.
What changes
What you can do that you could not before
- A direct comparison of yield per charging bay against ordinary parking
- Charging cost carried into your existing payment flow
- Enforcement that can see which bays are occupied but not charging
- Per-zone pricing that matches how the car park is already run
Commercial shape
Usage-based with volume tiers
Parking portfolios scale in bays rather than in sites, and tiering keeps the marginal cost of the hundredth connector below the first.
How pricing worksQuestions
What people in your position ask
Can we keep the driver inside our own app?
Yes. The API exposes everything needed to start, monitor and price a session, so the charging experience can live entirely inside your parking app with no zevOS branding anywhere.
Can we charge for the bay as well as the energy?
Yes — a time component alongside the per-kWh rate, plus idle fees after the session ends. On a constrained car park, the bay is the scarce thing and pricing it is usually correct.
What about airport car parks where cars sit for days?
Set a low or zero idle fee and a session cap, so a vehicle charges to a useful level and then stops without accruing fees for the rest of the stay. It is a different configuration, not a different product.
Related
You might also be this
Retail & shopping centres
Dwell-time charging for malls, supermarkets and retail parks — with validation, tenant arrangements and bay turnover that suits trading hours.
Cities & public bodies
Municipal, kerbside and public-premises charging with tender-grade reporting, operator oversight and pricing set in the public interest.
Talk through your parking operators setup
Bring the specifics — the sites, the hardware, the constraints. That conversation is more useful than a demo.