Post navigation

Telematics: It is 10 AM, do you know who is driving your vehicle?

SafetyFirst has been helping fleets with telematics (tracking specific data about vehicle location and performance) since 2002. At that time, we initiated a relationship with a local firm that handles hardware design and manufacturing of advanced telematics units. Over the past ten years, we’ve seen a lot of changes in the industry, and we have worked hard to stay current on the latest trends.

Recently, I was talking with a colleague about telematics he was surprised to learn that one of the “hidden” challenges of systems is connecting data back to the driver from the vehicle.

I pointed out that most telematics devices are tied to the vehicle, not the driver. This is a management reporting obstacle for fleets that don’t assign particular drivers to specific vehicles. In our Safety Is My Goal hotline program, very few of our clients make such assignments: most drivers swap vehicles from day to day.

In fleets whose drivers do operate the same vehicle day in and day out, it is straightforward to link the vehicle data to the driver since they operate as an integrated pairing.

Unfortunately, those fleets whose drivers exchange vehicles periodically must find a way to connect performance data to the appropriate driver. A failure in this area could lead to mistakenly crediting John’s risky driving to Sally’s record.

Once management negatively impacts a driver by using someone else’s data to coach/counsel them (or discipline them for breaking rules), the system’s credibility is going to be suspect in many of the driver’s eyes. After all, if we make the mistake once, could we make it again?

Tying data from the vehicle to the driver takes an additional logistical step (or two or three).

There are a number of approaches to linking drivers to data from the simple/mundane (maintaining a database of who was dispatched on each vehicle each day, etc.) to something more “automatic” and self-administrating such as electronic interfaces.

Naturally, as we add complexity to the process, there are additional “failure” points possible. Drivers may forget to punch in their ID code, swipe a card, insert a key device, or whatever method is needed to “link” the driver to the vehicle electronically. It would be possible for a driver to “code in” on Monday and forget to “code out” and so on. Algorithims can cap off some of this forgetfulness, but it is likely that these processes will require the cooperation of the individuals to monitor and correct data errors on a daily/weekly basis. Unfortunately, this administration takes productivity time away from supervisory staff, but is needed in order to assure data quality and reporting value.

Ultimately, I would speculate that there may be a shift (in the next several months or years) away from simply hardwiring the vehicle to acquire data towards using “apps” downloaded to smart devices such as tablets or phones that stay with the driver and link him/her to the vehicle via some “over the airwaves”. Perhaps a link via “WIFI” or a “Bluetooth-type” interface could be used to create a hybrid situation between on-board hardware and floating devices which stay with the driver.

It is especially vital to tie safety performance to the driver since personal habits and behaviors generate the exceptional data. Traditionally, data about speed, sway, harsh braking and heavy acceleration are monitored. These indicators represent only a fraction of the total driver safety picture which is a mosaic of many tiles or data points (i.e. telematics doesn’t tell us about running red lights, load securement issues, failure to use or improper use of turn signals, and so on).

A balanced program includes layers of programming such as MVR profiling, “Safety Is My Goal” Hotlines, driver risk profiling and so on. Such a layered approach to driver safety programming can fill in gaps and provide a greater, clearer “big picture” of needs and results.

While telematics data can be a very valuable tile in the mosaic picture, it would be easy to overwhelm a constituent with raw telematics data. This flood of data, if unfiltered, could make it difficult to differentiate the “urgently actionable” from the “background noise” without hiring additional data analysts. To the greatest extent possible, information should be self-selecting and self-prioritizing through appropriately tested filters to float the cream to the top of the bucket. This is one of the areas that SafetyFirsthas been helping clients transform their data pile into scoring and results tied to particular operators.

Finally, telematics (or any other data pile) is only going to be useful if it is translated into management action — if actual behavior isn’t changed, then the data’s intrinsic value diminishes. Ultimately, a translation of engineering derived data to soft skills communication such as practical coaching and education must happen for the various system goals to be met. Otherwise, we may be banking on an expectation that drivers would self-correct merely for fear of sanction, and such a system would be hard pressed to provide long term or sustainable results.

So use your telematics system wisely:

Make certain that you can tie your data back to specific drivers with certainty.

Be prepared to filter your data from a “pile” into a workable set of key performance indicators.

Create a game plan to translate “engineering data” into a “person friendly” coaching experience so that individual drivers may receive a compassionate intervention.

The goal should be sustainable, enhanced performance, not contrived short term gains.

SafetyFirst specializes in driver safety results. We are the preferred “in-network” choice of commercial insurers and fleet operators throughout North America. Let us help you overcome your driver safety challenges.