Fleet maintenance software should connect a vehicle, the work it needs and the evidence that it can return to use. Compare service records, defect handovers and availability decisions separately. A completed repair entry answers a different question from whether a vehicle was available for its next assignment.
Start with one recognisable maintenance event rather than an entire fleet dashboard. Ask who reports the problem, who schedules work, who records completion and who decides what happens next. Write these responsibilities before choosing fields. This turns a demonstration into a test of the handover your operation actually needs.
Odoo 18 Fleet provides a concrete example of service and vehicle records. The original worksheet below extends that documentation into a proposed evaluation exercise. Its extra evidence fields are requirements for your shortlist, so the demonstrator should explain where each belongs in the proposed configuration.
What should a service record tell you?
Odoo 18 allows regular maintenance services to be logged in advance. That makes advance entry a useful starting point for a scheduling discussion; it does not by itself establish an automatic recurring maintenance engine. Ask how the next service is identified, who checks it and how a changed date reaches the person allocating vehicles. See the service documentation.
Odoo 18 requires Service Type and Vehicle on a service record. A record can therefore meet the software’s minimum entry rules while still lacking information your maintenance team needs. Decide what your own handover requires: a clear description, a reporting reference, an assigned owner and an explanation of the requested work are sensible candidates to test.
The service Date can represent work already provided or work scheduled. Agree which meaning applies before comparing dates across a report. A request entered for next week is different from evidence of work completed last week. Ask the demonstrator to show how a reviewer distinguishes those cases without reading every free-text note.
Selecting a vehicle populates its current driver on the service form. Check that value against the person involved in the actual event, especially after a reassignment. A convenient default should prompt confirmation rather than replace it. Keep the vehicle identifier visible throughout the exercise so similar model names cannot conceal an entry against the wrong vehicle.
How do you keep vehicle identity and responsibility clear?
The vehicle form requires a Model. Your operational identification standard can be stricter than that minimum. In the test copy, use a distinctive vehicle reference and ask the reviewer to follow it from the vehicle record to its service history. The vehicle documentation explains the form and its surrounding fields.
Odoo 18 permits a driver who is not an employee. This matters when deciding how to represent temporary or external drivers. Agree who maintains the contact and what information is necessary for the handover. Avoid building the workflow around an assumption that every driver must already exist in an employee register.
The vehicle record includes a Fleet Manager selection. The vehicle Location field records where the vehicle is typically located. Use these fields to start the responsibility and location discussion, then test their meaning. A usual parking location is not automatically the place where a vehicle with a reported defect can currently be found.
Ask what happens when a vehicle moves to a workshop while its normal location remains unchanged. The useful answer identifies the record used for the temporary situation, the person responsible for updating it and how the dispatcher sees the update. Capture that explanation in the evaluation notes instead of assuming the location field is live tracking.
Which scheduling, defect and downtime questions belong in the demonstration?
Keep the three questions distinct. Scheduling concerns intended work. A defect record concerns an observed problem and its handling. Downtime concerns the period during which the operation treats a vehicle as unavailable. They may refer to the same event, but they need not share the same start or end point.
| Evidence needed | Documented starting point | Demonstration question |
|---|---|---|
| Intended maintenance | A service can be entered in advance | Who checks that the next required event has been entered? |
| Work status | A service has a Stage | What operational action follows each stage change? |
| Vehicle identity | Service Type and Vehicle are required | How do reviewers catch a service attached to the wrong vehicle? |
| Usage context | A service carries an odometer value | Which reading, unit and event does this value represent? |
| Defect ownership | Proposed handover requirement | Where are the report, assigned owner and next decision retained? |
| Availability period | Proposed downtime requirement | Which evidence starts and closes an unavailable period? |
The service odometer unit follows the selected vehicle configuration. Include the unit beside the reading in your comparison sheet. A bare number copied from a job note is insufficient for a meaningful check. Ask the demonstrator to change between two test vehicles with different configured units and explain the displayed result without altering real fleet data.
Odoo 18 lists service stages as New, Running, Done or Cancelled. Use those documented labels when discussing the software. Separately define what your business means by available, awaiting assessment and released for allocation. Require an explanation of any relationship between those concepts; a label that sounds reassuring is not evidence of an enforced operational decision.
Original worksheet: follow one defect through a cancelled job
This hypothetical exercise uses vehicle VAN-A and a reported vibration. It is a record-handling test, with no maintenance diagnosis or instruction to operate a faulty vehicle. Run it in a separate test environment with the person responsible for fleet decisions present.
Create the event envelope. Write a reporting reference, vehicle reference, reported symptom, reporter and recorded time. Add the reading and its unit only when they are available. Mark missing evidence as missing. The purpose is to preserve what was actually reported, rather than make a complete-looking record by filling gaps from memory.
Open the intended work. Create a service request for inspection and identify its proposed date. Record who owns the next action. Beside that service entry, write the business’s current availability decision and the evidence on which it rests. Ask the demonstrator to show where both can be found during an allocation discussion.
Introduce the exception. Cancel the first planned workshop visit in the exercise. Keep the defect open on the worksheet until its owner makes a separate documented decision. Ask whether cancelling the service silently removes any indication that further action is needed. This is the central acceptance question: an administrative cancellation should have an explicit operational consequence.
Create the replacement path. Arrange a replacement service in the test copy and retain the connection to the original report. Ask a reviewer who did not enter the records to explain why two service entries exist. They should be able to distinguish an abandoned appointment from evidence that the reported problem was addressed.
Close each question separately. Record completion evidence for the replacement job. Then record the authorised availability decision according to the business’s own process. If downtime reporting is required, capture the chosen start and end events and calculate the interval from those events. Do not substitute the booking date merely because it is easy to export.
Read the chain backwards. Start from the final decision and trace it to the completion evidence, replacement request and original report. Identify broken references, ambiguous dates and unowned actions. Record whether each issue needs configuration, a different application or a process decision. This produces a concrete scope for follow-up work.
What should you retain before choosing a system?
Keep the completed event worksheet, the product version, enabled features and a short recording or screenshots of the relevant transitions. Ask the fleet owner and the person allocating vehicles to describe the same event independently. Differences in their explanations expose unclear definitions before they become daily reporting disputes.
Compare products on the evidence they can show for your event chain. For broader context, read fleet management records and trips and the business systems pillar. To discuss a defined requirement, get started with the worksheet, the unresolved transitions and the people who own those decisions.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.