Mike Daniel, founder and technical director of HI Technology and Innovation, ponders why fleet management systems aren’t really fit for purpose.

Mike Daniel, founder and technical director of HI Technology and Innovation

This article cannot possibly hope to supply the ever-elusive answer to the age-old question of “Why has it done that?”, but we can certainly give it a crack. It seems to be a recurring issue that businesses come to us with – simply put, the systems they’ve brought in to help make their lives easier are causing an almost equal and opposite amount of angst.

To get to the bottom of why, we have to start with the people who create software – and finish with the people who use it. After all, despite the image we have in our minds when talking about technology, it is fundamentally all about humans.

One of the greatest, yet weakest, traits of the people who build software is that they often think like the very computers they programme. To us, that means converting ideas into logic and procedure into algorithms. This process is great for data efficiency and scalability, but creates rigid structures that struggle to adapt when the real world comes stomping in. All of a sudden, to satisfy as much of the market as possible, software engineers have to standardise and systematise every conceivable use case they can think of. As you can imagine, this feasibly isn’t possible and it’s the underlying root cause of the majority of bugs, issues and frustrations of software. One company’s standard operating procedure can quickly become another company’s bug – and no software engineer, no matter how great, can think of every eventuality.

So what happens when the rigid structures start to feel the stress? When your personnel unexpectedly change one morning and so a driver jumps into an unanticipated van? Hiccup. When your FNOL system isn’t tied to the location and traffic data of long tunnels? A bigger hiccup. Or when you have no discernible way of determining which vehicles in your fleet have fridges? (See KFC’s experiences in 2018).

Bring in the humans

To begin to resolve this problem, the software world has developed the ‘product owner’. These survey-wielding, metric-obsessed evangelists are all about converting the needs of real humans into products that actually do something positive – they bridge the gap between the people creating the software and the people using it. And while there are many methodologies, most product owners do all of their work while sitting at their desks. That makes sense when you’re building software for hundreds of businesses, but, because of this, the software they build will never truly be a perfect fit for your specific business; it’s an impossible task. To resolve this, we’re big proponents of what we call ‘investigative’ product ownership. This is where we send our product owner over to your depot and get them to physically watch how your fleet operates and, dare I say it, speak to your colleagues (insert audible gasp). It’s only by doing this that you can truly start to pick up the nuances of each fleet and build a bespoke solution that actually works. From there, they’re unleashed and can get stuck into delivering useable tools that improve the efficient operation of your fleet.

The other side of the equation

Now we have the foundation for building great products, we should turn our attention to the users of those products. One of the hardest problems of any software product is getting people to actually use the darn thing and, moreover, use it habitually. Instagram is an example of a company that has got this down to a tee, using highly addictive videos of dogs in sunglasses in a vertically scrolling format. For obvious reasons, this isn’t a tactic we can use in the world of fleet, so, instead, we have to look at other ways of building habits.

That means when it’s time for your drivers to perform a vehicle check, they think of your tool. And when it’s time to report personal/business mileage, they also think of your tool – and so on and so forth. Ultimately, everything is a habit, which is why it’s one of the other areas we’ve been exploring with our partners (and the fleets of some of the largest retailers in the country) – rewarding people for using the right tool at the right time. We’ve quite literally built an entire gamification platform to support fleet management tooling and, while it may seem like cracking a walnut with a sledgehammer, it’s actually delivered incredibly positive results in terms of engagement with the software ecosystem.

It’s also a great way to give back to people who are doing the right things and are embracing changing processes with open arms… After all, who likes change? On top of this, of course, we have to continually learn through both qualitative and quantitative data exactly what is and what isn’t working for people – and this is a big part of product development. Everything we develop has to be driven by some kind of expected value to the end user, and all our efforts must be focused firmly on the person at the other end. If you’re interested and want to learn more about this, I’d highly recommend reading around the ‘build-measure-learn” cycle and similar variants that can help you develop not just software but anything from sales pitches to new processes. However, be aware that for such an incredibly simple paradigm, it is remarkably hard to implement continuously.

The wrap

And there we have it – our unique take to building unique tooling for unique companies. It’s all about bringing in the humans from all the different points on the spectrum and building stuff that is fun, habitual, easy to use and, importantly, that manifestly works for all stakeholders.