Fleeta Limited: fleet technology with a real workshop foundation
+44 (0) 1284 844114
← Back to all articles

One defect system for nil returns and reported faults

Set up one defect reporting system that records nil defects and reported faults properly, with a clear audit trail for DVSA and daily fleet control.

One defect system for nil returns and reported faults

If you want to know how to record nil defects and reported defects in one system, the answer is simple. Every daily vehicle check must end in one of two outcomes in the same record set. Either the driver found nothing and submitted a nil defect return, or the driver found a fault and raised a defect that stays open until it is assessed, repaired or deferred with a clear decision, then signed back into service.

That sounds obvious. In practice, many fleets split it across paper books, WhatsApp messages, workshop whiteboards and spreadsheets. That is where gaps appear. The check happened, but there is no nil return. The defect was reported, but there is no rectification note. The repair was done, but no one recorded who authorised the vehicle back on the road. For a UK operator, those gaps matter to roadworthiness, to your O-licence, and to what you can prove when DVSA asks.

Why one system matters

A defect system is not only there to capture faults. It is there to prove control.

If a vehicle goes out every day, you need evidence that a daily walkaround check took place every day. Not only on the days when something was wrong. That is why nil defect reporting matters. A run of missing entries does not read as "everything was fine". It reads as "we cannot show what happened".

When nil returns and reported faults sit in the same system, you get a complete daily sequence for each unit and trailer. Monday, nil. Tuesday, offside marker lamp out, repaired same day. Wednesday, nil. Thursday, tyre cut reported, inspected and taken out of service. That is a usable history. It shows routine, response and oversight.

This matters in three places.

First, operational control. Transport needs to know whether a vehicle is fit to go. Workshop needs to know what has been reported. Drivers need to know that someone has actually seen what they submitted. One shared system stops the usual argument about whether the defect was reported at all.

Second, audit trail. DVSA and the Traffic Commissioner do not judge you by good intentions. They look at records. Can you show that checks were done, defects were assessed, safety related issues were not ignored, and rectification happened before return to service? If the answer sits across four places, you do not really have an answer.

Third, O-licence risk. Roadworthiness failings are not only about serious mechanical faults. They are also about weak systems. Missing nil defect records, defects closed without evidence, and no link between the driver report and workshop action can all make your controls look poor. Poor control feeds into OCRS and into how your operation is viewed if there is an investigation.

This is one reason we keep pushing for one set of records for workshop and transport office. It is not a software slogan. It is how you avoid blind spots between the yard and the office.

What a nil defect record must show

A nil defect record has one job. It must prove that a check was done on a specific vehicle, by a specific person, at a specific time, and that no defects were found that needed reporting.

That record should include, as a minimum:

  • vehicle registration or fleet number
  • trailer number where relevant
  • driver name
  • date and time of the check
  • location, if your process requires it
  • confirmation that the inspection was completed
  • confirmation that no defects were found
  • driver signature or secure electronic sign-off

If your fleet runs units and trailers separately, the system must handle both. A nil return for the unit is not proof that the trailer was checked. That catches people out.

The record also needs to be reviewable later. That means it cannot just be a green tick on a live dashboard that disappears. You need a retained entry against that asset and date. If someone asks six months later whether vehicle AB12 CDE had a driver check before leaving on 14 March, you should be able to pull up the exact return.

It also helps if the nil return follows a defined checklist. Lamps, tyres, wheel fixings, mirrors, body security, load security equipment, glass, number plates, leaks, warning lights, and anything else relevant to the vehicle type. For specialist fleets, add the obvious extras. Tail lifts. PTO equipment. Curtains. Tipping gear. The point is not to turn the driver into a technician. The point is to show a consistent walkaround process.

In the UK, the expectation is not identical to every EU member state because operator licensing and enforcement practice are not the same. Here, the daily defect check sits squarely inside the wider duty to keep vehicles in a roadworthy condition. Your nil defect record should support that duty, not just tick a box.

A good nil record is short, but not vague. "Checked OK" is weaker than a proper dated submission tied to the vehicle and driver. If your system allows skipped days with no explanation, that is weaker still. For more on what stands up when records are examined, see which maintenance records stand up in a DVSA audit.

What a reported defect record must show

A reported defect record needs more than the driver saying "light out" or "brakes bad". It has to carry the fault through from report to decision to rectification.

Start with the report itself:

  • vehicle and trailer identification
  • driver name
  • date and time reported
  • defect description in plain language
  • where on the vehicle the fault is
  • supporting photos if practical
  • whether the defect was found before departure, en route or at end of shift

Then record severity and immediate decision. This is where many systems fail. A defect should not sit as an unstructured note. Someone competent must decide whether the vehicle is safe to use, safe with restrictions, or not to be used until repaired.

That decision should show:

  • who assessed it
  • when they assessed it
  • whether it is safety related
  • whether the vehicle is VOR, can return under controlled conditions, or can remain in service
  • any temporary control measures

Be careful here. "Driver informed workshop" is not a decision. "Will look later" is not a decision. If the issue affects roadworthiness, the vehicle should not quietly stay available because the workshop is busy.

After that comes rectification. The record should show:

  • what work was done
  • who did it
  • parts used, where relevant
  • date and time completed
  • whether the repair fully rectified the defect
  • if not repaired immediately, why it was deferred and who authorised that decision

Deferral needs discipline. Not every defect needs instant repair, but every deferral must be deliberate and justified. A cracked mirror glass, a tyre issue and a bodywork scuff do not sit in the same category. The record must make that obvious.

Finally, return-to-service sign-off. This is often missing. The system should show who confirmed the vehicle was fit to go back into operation and when. If the defect was safety related, that sign-off matters. It closes the loop.

This also needs linking to any workshop job card, PMI outcome, preventative maintenance inspection, MOT preparation or follow-on repair where relevant. If a driver reports uneven brake feel and the vehicle is then booked into the workshop, the defect record should not die in the driver app while the repair lives somewhere else. One chain is the whole point.

How to build one workflow that handles both

The cleanest process is this. Every check starts the same way and ends in one of two ways.

Step one, the driver selects the vehicle, and trailer if attached, then completes the daily check on a standard checklist.

Step two, the driver must choose an outcome. No defects found, or defect found. There should be no third state like "save and leave" that lets records drift unfinished.

If no defects are found, the system creates a nil defect return with the required sign-off and stores it against the asset.

If a defect is found, the system requires a description and pushes the report into a live defect queue. At that point it becomes visible to transport and workshop, not buried in a driver's phone.

Then the office or workshop triages it. Safety critical defects are escalated at once. Minor defects are assessed and booked. The key is that the same record remains open until there is a repair decision and a close-out.

A workable small fleet workflow usually looks like this:

  • Driver submits morning check.
  • Nil return, vehicle remains available.
  • Or defect reported, vehicle status changes pending review.
  • Workshop controller or transport manager reviews new defects.
  • Decision is recorded, stop, restrict, monitor, or book repair.
  • Job is created if work is needed.
  • Technician records findings and rectification.
  • Responsible person signs vehicle back into service.
  • Record closes, with full history retained.

That is how to record nil defects and reported defects in one system without gaps between driver reporting and workshop action.

The hard part is not the form. It is discipline around status. Open means not yet dealt with. Closed means assessed, rectified or formally deferred with a reason. Nil means checked and nothing found. If your system lets people bypass those states, it will become a message board, not a compliance record.

It also needs to work alongside the rest of your maintenance records. Defect reports should relate cleanly to booked inspections, PMI schedules, and workshop jobs. If a repeated driver report leads you to bring a vehicle in early, that should be visible in the history. We cover that practical link between reporting and repair in workshop job tracking that stops missed defects.

The mistakes that cause trouble at audit

The first mistake is assuming silence means nil defects. It does not. If there is no return, there is no proof of a check.

The second is recording nil checks in one place and defects somewhere else. That creates broken timelines. Auditors and investigators notice when the story has to be assembled by memory.

The third is free-text chaos. If one driver writes "NSR tyre", another writes "back wheel bad", and another just ticks "reported to gaffer", your records are hard to review and harder to defend.

The fourth is no closure evidence. We see this often. The defect was genuine. The workshop did fix it. But the only record is a verbal update or a line on an invoice. There is no clear rectification note tied back to the original report.

The fifth is closing defects too early. A defect should not be marked complete when a job is booked, only when the assessment and necessary action are done. "Booked for Friday" is not rectified.

The sixth is weak sign-off on return to service. If a vehicle was taken out for a safety related issue, someone must positively put it back in. Do not leave that implied.

The seventh is poor handling of trailers. Units often get the attention. Trailers get patchy nil returns and ad hoc fault notes. That looks bad quickly, especially where trailer use moves between drivers.

The eighth is letting related records drift apart. A defect linked to a tyre replacement, a lamp repair, a brake inspection or a PMI should be traceable. If the defect system and workshop records do not meet, you end up proving the same event twice and still not convincingly.

The ninth is relying on paper that never gets reviewed. Paper is not automatically bad. Unreviewed paper is. If defect books stay in cabs until they are full, you do not have live control.

The tenth is forgetting the wider context. Defect reporting is one part of your maintenance case. If your defect records say one thing, your PMI sheets another, and your MOT history shows repeated avoidable failures, that pattern will be noticed.

What good looks like in a small UK fleet

Take a fleet of 25 vehicles and 40 trailers. One transport manager. One planner who also answers the phone. A small in-house workshop or a regular local repairer. This is where spreadsheets usually start breeding.

Good looks like one daily process, not a bigger admin burden.

Drivers complete checks on their phone before first movement. Agency drivers use the same process. Each check creates either a nil return or a defect report. Nothing is left hanging as "not submitted yet" after the vehicle has gone out.

The transport office sees a morning list by exception. They do not read twenty nil returns one by one. They see that checks are in, and they see the defects that need decisions. Missing checks stand out.

The workshop sees the same defect queue. A lamp defect can be handled fast. A steering complaint gets immediate attention. A tyre issue can be matched to stock and booked. If the defect needs a job, that job is created from the same record, not retyped onto a whiteboard.

When the repair is done, the technician records what was found and what was rectified. If the complaint could not be reproduced, that is recorded too, with the assessment. If the vehicle needs to stay off road, its status stays off road. If it is fit to return, a named person signs it back into service.

The transport manager can then answer basic questions quickly:

  • Did every vehicle checked out today have a daily defect check?
  • Which open defects are still awaiting action?
  • Has this unit had repeat reports on the same issue?
  • Was that fault repaired before the vehicle went back to work?
  • Can we show the defect history before the next PMI or MOT?

That is the difference between a controlled fleet and a fleet that is getting by on memory.

For fleets in the five to one hundred vehicle range, this does not need an enterprise project. It needs one record structure, clear statuses, and workshop and transport using the same truth. If you are still trying to reconcile driver books, spreadsheets and job cards, start by fixing that split. Our view is simple because we live with it in a working HGV workshop as well as in software. The process has to make sense on the floor, not only in a demo.

If you want your defect records to hold up under pressure, build them so every day ends with a visible result, nil return or reported fault, and every reported fault stays alive until there is a proper decision and close-out. That is how you protect roadworthiness, support your O-licence, and avoid nasty surprises when DVSA, the Traffic Commissioner or your own customers start asking for the paperwork.

Do we need to record nil defects as well as actual defects?

Yes. A nil defect record shows the daily check was carried out and nothing reportable was found at that time. Without it, you can struggle to prove the check happened at all.

Can nil defects and reported defects sit in the same system?

Yes, and they should. One process is easier to train, easier to monitor and easier to evidence. Each check should end in one clear outcome: nil defects or a reported defect.

Should minor issues go into the same defect record?

Yes, if they are being reported by the driver as a defect or concern. The important part is to record the issue, assess roadworthiness and show what was done next.

Who should sign off a reported defect?

The person authorised by the operator to assess and control vehicle roadworthiness. In practice that is often the workshop, fitter, transport office or manager, depending on the operator's setup.

Is a photo enough on its own?

No. A photo can help, but it does not replace the record. You still need the vehicle, date, driver, defect details, action taken and a clear decision on whether the vehicle stayed in service.