Review your HOS portal and logs every day. This process should usually take place at the beginning of your drivers’ day. Initially after implementation, you may want to do this process several times a day. Remember, during the initial implementation, your drivers are required to continue to use paper logs until you feel confident in their ability to correctly use the system everyday.
Review the following every day:
| Done? | Task | Description |
|---|---|---|
 |
Manage Unidentified Driver Events | Reach out immediately to drivers who failed to sign in. The sooner you solve this issue, the fewer edits you will need to make. It also lets the driver know you’re watching closely and you’re managing this project properly. |
|
Correct all conflicts | A conflict is an indication of some omission or inconsistency in a driver’s log. Because some conflicts affect the quality of information provided by the HOS application (e.g., the number of hours remaining in a driver’s shift, the ability for a driver to download logs to a mobile device, etc.), you should resolve conflicts as soon as possible. |
|
Review Hours Worked and Available Data | - Look to ensure all drivers who are working at the moment are in fact ON DUTY. - Make sure they have available time (or an edit may be required). - Make sure location data is reasonable and correct. - Make sure all your drivers show up on the list (especially important during initial implementation). - When adding a brand new driver, make sure to record an artificial 8 day history so the first time a driver signs in they have same day HOS calculations. |
|
Manage DVIRs with defects | Does your mechanic (or designated person(s)) get emailed notifications yet? Does your mechanic (or designated person(s)) sign in and complete the DVIR process after the repairs are made? |
|
Review the Violations Report | Work with your drivers to edit logs in the event they failed to go Off Duty. |
|
Review the Device Failure Report | These events are also added to the drivers log. - Power failures can be caused by drivers manually powering off the tablet, or they may be an indicator of a power problem. Work with Support as needed to resolve. - Device Undocked can be caused by the removal of the tablet from the dock, or if the system temporarily lost communication with the vehicles ECM port. If the problem persists, contact Support. - EOBR Disconnects are reported when we see the ignition as being ON and no data from the ECM port. Have the driver either start the truck again (clean air Idle) or turn off the key. This event should recover on its own. Do report this event immediately to Support if the problem occurs while the vehicle is being driven. |
|
Drivers Logs | Do a quick visual inspection of each log, especially important when you begin using the system. (Once your drivers are educated on how you expect them to use the system, this step can be reduced to only reviewing when needed.) Ensure the following: - Driving events are being recorded and that no driving events point to lack of valid odometer data. If so, contact Support immediately. - Trailer #s on the logs (if applicable) - Shipment Info is correct and appropriate for your company - Recorded events, such as power failures, EOBR Disconnects, Device Undocked. Determine the cause by asking the driver about them, and report to Support. - Does the driver appear to be entering extra manual entries? - Did the driver go Off Duty at the correct time and place? - Do you require your drivers to add remarks for things like Load Check, Fuel or Road Side Inspections? If so, then watch for those remarks as well. |