Driver management should connect the person, the vehicle assignment and the evidence needed for an authorised operating decision. Start with a responsibility sheet for licence checks, assignment changes and exceptions. Then test a planned change of driver and a vehicle-service issue using fictional records so the next colleague can identify the current position and required action.
The organisation’s authorised owner should supply the licence-check requirements applicable to its actual operation. Record the source of those requirements, the evidence reviewed and the decision owner. Software can help organise records and tasks, while the acceptance brief should state what the business expects that evidence to establish.
The original assignment-and-exception worksheet below uses fictional drivers and vehicles. Narrow product examples come from Odoo 18 Fleet vehicle and service documentation, retrieved on 24 October 2026. Broader business systems and document management decisions remain separate.
Which person is assigned to the vehicle?
Odoo 18 provides a Driver field on the vehicle record. Odoo 18 also provides a Future Driver field for a planned change. Its vehicle guide illustrates how current and proposed assignments can be distinguished in a specific product.
Populating Future Driver exposes an Apply New Driver action in Odoo 18. Odoo 18 provides an Assignment Date indicating availability for another driver. Include those documented details in a planned-change demonstration. Record the expected person before and after the change and ask the reviewer to explain when the new assignment becomes relevant.
Odoo 18 says a fleet driver need not be an employee record. Keep the person’s identity and relationship to the organisation explicit in the brief. A driver reference, an employment record and the evidence used for an operating decision can serve different purposes, even where the organisation links them.
For the fictional exercise, assign Sample Driver A to Vehicle North and propose Sample Driver B as the future driver. Write the intended handover date and the evidence each role needs. The resulting test should assess whether the proposed record makes the current and planned positions understandable.
How should licence evidence be organised?
Create a proposed licence-evidence register with the person reference, document reference, applicable requirement source, review date and authorised reviewer. Agree which details are necessary for the actual operation and how access is restricted. Leave a requirement unresolved where its authority has not been established rather than inserting a familiar rule from another jurisdiction.
Ask the implementer to identify where this register or equivalent evidence would sit in the proposed system. Keep the observed feature separate from the original requirement until the demonstration establishes the configured route. A vehicle assignment field should not be treated as a substitute for the business’s distinct review decision.
Define what happens when evidence is missing, unclear or awaiting review. The process should identify the next responsible person and keep the decision visible to the role handling assignments. Record the agreed action and its authority so an unresolved evidence check does not disappear inside an ordinary contact note.
| Record area | Proposed evidence | Exception to demonstrate |
|---|---|---|
| Driver identity | Stable person reference | Similar names or changed contact detail |
| Licence review | Required source, evidence and authorised decision | Missing or unclear evidence |
| Current assignment | Vehicle and current person | Record conflicts with the proposed handover |
| Planned assignment | Future person and intended point | Change is postponed |
| Service issue | Vehicle, observation and responsible role | Vehicle needs review before assignment |
| Resolution | Decision, action and supporting evidence | Exception remains unowned |
This is an original requirement sheet. Configure and test it against the chosen product without assuming every field is a built-in Fleet feature.
How should vehicle-service exceptions remain traceable?
Odoo 18 service records require Service Type and Vehicle. Odoo 18 service records populate Driver from the selected vehicle. Its services guide describes the relationship. Include the selected vehicle and displayed driver in the acceptance record so a service issue remains attached to the intended assignment context.
Odoo 18 allows the driver on a service record to be changed. Ask the reviewer to explain whether the current default or another person is relevant to the recorded event. Retain that decision alongside the service reference rather than assuming the automatically displayed person supplies the whole history.
Odoo 18 service records include an odometer value using the vehicle’s configured unit. Odoo 18 service stages include New, Running, Done and Cancelled. These documented fields provide specific questions for the proposed exception workflow: which observation is being recorded, what does its state mean and who decides the next action?
Keep the service record’s state distinguishable from permission to assign or operate the vehicle. The authorised owner should define what evidence is required for that decision. The worksheet can then assess how the proposed system communicates the unresolved issue to the person making the assignment.
Agree how supporting documents are referenced and who may retrieve them during a review. Keep the ordinary assignment view focused on the decision its user needs, while authorised reviewers retain access to the relevant evidence. This makes the handover useful without distributing unnecessary personal details across every vehicle note.
Original planned-driver-change exercise
Create fictional Drivers A and B and Vehicle North in a separate test environment. Record the current assignment, proposed future assignment and intended handover point. Add a licence-review requirement whose authority and reviewer are explicitly identified by the organisation’s owner for the exercise.
First, ask a normal user to locate the current driver and explain the planned change. Then postpone the fictional handover and inspect the resulting record. Ask a second colleague to identify which person is current and what remains planned, using only the available evidence.
Next, introduce a missing-evidence licence-review case. Record the unresolved item and ask the authorised reviewer to identify the next action. Inspect how the proposed assignment process makes that decision visible. Keep the expected business response and the observed software behaviour in separate columns.
Then add a fictional service issue for Vehicle North. Compare the selected vehicle, default driver, relevant event person and odometer unit with the worksheet. Ask who investigates the issue and who makes the separate assignment decision. Retain the actual record references and observed state.
Finish by resolving one fictional exception while leaving another open. Have the next colleague identify the supporting evidence for the resolved item and the owner of the remaining work. This checks that the record supports a useful handover rather than merely storing a completed form.
For implementation connections, see web development. To discuss the assignment workflow and evidence still needed, get started with the worksheet and the organisation’s applicable requirements.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.