Book electric pool vehicles: Plan availability properly

Booking an electric pool vehicle must bring together the time required, vehicle suitability and energy demand of the planned assignment. An available calendar slot alone does not confirm readiness for use. Your fleet software therefore needs a process that connects reservation, checks, handover and return in a traceable way.

Whether a booking module is available or a separate solution needs to be connected belongs in the requirements assessment. The operational process remains the same in either case: the team must recognise which vehicle is promised for which period and under what conditions it can be used.

What information should a booking contain?

Record collection and return times, location, expected distance and required vehicle features. These may include the number of people, cargo space needed or specific equipment. For recurring assignments, predefined choices help, provided they fit the actual tasks.

Avoid unnecessarily detailed free-text fields. An operational assignment category is often sufficient for vehicle dispatch. Personal information and specific destination details should only be collected to the extent necessary for the defined purpose and legally assessed. The article on data privacy in fleet software explores the fundamentals.

Also record how changes are handled. An extended booking can affect the next assignment. The person making the change should recognise this impact and know who may issue a new confirmation.

Distinguish between reserved, available and ready for use

A reservation initially blocks a period. Operational availability also accounts for maintenance, damage, location and other restrictions. A vehicle is only ready for a particular job once the necessary conditions for that job have been clarified.

Define these states so that every user understands them. For example, a booking may initially be provisional and confirmed after a check. Another checkpoint takes place shortly before issue if the previous assignment may affect energy availability or the return time.

If the software is to use current vehicle data, check its availability and freshness. Alternatively, a confirmed report at vehicle return can provide the starting point. In either case, there must be a clear way to handle missing or conflicting information.

Schedule buffer time between two bookings

Handover, a visual inspection, cleaning and charging may be necessary between return and the next departure. Plan this time deliberately. A vehicle expected back at 12:00 noon cannot be promised again for the same time without a check.

The buffer should fit the usage profile. A short errand may have different requirements from a long off-site appointment with an uncertain return. Define when a fixed standard buffer is enough and when individual approval is required.

Check how recurring bookings are handled. A regular reservation should not block vehicles indefinitely when they are hardly used. Agree on a review date and a simple cancellation process. Vehicle utilisation analysis helps manage the fleet’s size and composition.

Practical example: A late return affects the afternoon

Fictional practical example: A pool vehicle is booked until 11:00 am. Its next assignment begins at 1:00 pm. A return inspection and a planned charging stop are scheduled in between. At 10:30 am, a report says the vehicle will not return until 12:15 pm.

Dispatch now rechecks the conditions for the second assignment. It considers the updated energy state, required distance and remaining time. As long as this information is missing, readiness for use remains unresolved.

A suitable available vehicle is firmly assigned to the second appointment. The person affected receives updated handover information. The late return is resolved without leaving two conflicting commitments in the calendar.

This case works well as a software test: it shows whether the calendar, ownership and current feedback actually work together. All times are illustrative assumptions.

Checklist for the complete booking process

Test the process once from request through to return:

• Request: Are the period, location and required features clear?

• Check: Are existing bookings, restrictions and buffers taken into account?

• Confirmation: Is it clear who gives binding approval for the vehicle?

• Change: Are affected subsequent bookings identified and handled?

• Handover: Are the vehicle’s condition and necessary assignment information confirmed?

• Return: Are the return time and relevant issues recorded?

• Closure: Have cancellations and unused reservations been cleared up?

Add a fallback process for an outage of the booking interface. The person responsible then needs an up-to-date overview of confirmed commitments and a clear contact route. After service is restored, interim changes must be entered in a controlled way to avoid double bookings.

You can develop the digital vehicle handover as a separate process step to record condition and responsibility. The booking overview should refer to this step without making unnecessary personal details widely visible.

Record your booking and charging requirements in a concrete workflow and review your needs with StromNow.