Why Not a Bot? Adjuster Bots for Connected Cars

Why Not a Bot? Adjuster Bots for Connected Cars

We’re not quite there yet. But there is a path to get there—probably in only a few years.

We’re already at the point where fender bender claims can be estimated with a set of smart phone photos (offered by esurance and many other carriers)

But what more serious accidents which involve damage to a car’s mechanical systems? 

Here is one element of an Adjuster Bot solution: electonic control units, ECUs. For years, automobiles have been manufactured with dozens ECUs which control, monitor, and diagnose a broad away of systems within the vehicle, including its engine, power train, brakes, steering, airbags, electronic stability control. Information from ECUs can be accessed from vehicle’s On-board Diagnostic Port (OBD-II). The primary purpose of the OBD-II is to enable maintenance and repair of the various systems. (Telematics devices–aka dongles–plugged into the OBD-II port have been the primary method to gather and transmit telematics data to insurers.)

A second critical piece of the puzzle falls into place: communication. Automobile manufacturers are racing towards creating connected cars—typically using 3G or even 4G LTE cellular modems.

So this is what an automobile Adjuster Bot ecosystem would look like:

  • A cellular modem which tells the Adjuster Bot that an accident has occurred
    • And transmits data from ECUs describing the functional/non-functional status of major car systems
  • The AI-powered Adjuster Bot which, through deep learning, identifies the probability of repairing or replacing components within those systems; and which:
    • Alerts police and/or medical assistance as warranted (e.g. if airbags deployed)
    • Queries repair estimation and total loss systems
    • Integrates with the insurer’s Direct Repair Program
    • Creates an initial estimate of cost and time to repair
    • Presents a customized video to the driver, describing:
      • Arrival of tow trucks, transportation to a rental car facility, the split of insurer and policyholders financial responsibility; links to download a claimant app

Next up: Adjuster Bots for Connected Homes

Robotics, bots and chocolate teapots

Robotics, bots and chocolate teapots
Increasingly in operational efficiency and automation circles we’re hearing about bots and robotics. As a software engineer in days past and a recovering enterprise architect I have given up biting my tongue and repeatedly note that, “we have seen it all before.” I’ve written screen scrapers that get code out of screens, written code to drive terminal applications and even hunted around user interfaces to find buttons to press. The early price comparison websites over a decade ago used these techniques to do the comparison. These techniques work for a while but are desperately fragile when someone changes the name of a button, or a screen or a screen flow. However, they can help. I recall a while ago a manager lamenting ‘the solution’ was about as useful as a chocolate teapot. A useful 10 minutes hunting for this video of a chocolate teapot holding boiling water for one whole pot of tea made the point for me. Sometimes all you need is one pot of tea.
Tea poured from a chocolate tea pot

Tea poured from a chocolate tea pot

So it’s not new, some bots may be fragile and with my “efficiency of IT spend” hat on (the one typically worn by enterprise architects) stitching automation together by having software do what people do is an awful solution – but as a pragmatist sometimes it’s good enough. Things have moved on. Rather than a physical machine running this with a ghost apparently operating mouse and keyboard we have virtual machines and monitoring of this is a lot better than it used to be. Further machine learning and artificial intelligence libraries are now getting robust enough to contribute meaningfully smart or learning bots into the mix that can do a bit more than rote button pressing and reading screens. In fact this is all reminiscent of the AI dream of mutli-agent systems and distributed artificial intelligence where autonomous agents collaborated on learning and problem solving tasks amongst other things. The replacement of teams of humans working on tasks with teams of bots directly aligns with this early vision. The way these systems are now stitched together owes much to the recent work on service oriented architecture, component orchestration and modern approaches to monitoring distributed Internet scale applications. For outsourcers it makes a great deal of sense. The legacy systems are controlled and unlikely to change, the benefits are quick and if these bots do break they can have a team looking after many bots across their estate and fix them swiftly. It may not be as elegant as SOA purists would like but it helps them automate and achieve their objectives. The language frustrates me though, albeit bots is better than chocolate teapots. I’ve heard bot referred to as a chunk of code to run, a machine learning model and a virtual machine running the code. I’ve even heard discussion comparing the number staff saved to the number of bots in play – I can well imagine operations leads in the future including bot efficiency in their KPIs. Personally, I’d rather we discussed them for what they are – virtual desktops, screen scraper components, regression models, decision trees, code, bits of SQL were appropriate, etc. rather than bucket them together but perhaps I’m too close to the technology. In short bots may not be a well-defined term but the collection it describes is another useful set of tools, that are becoming increasingly robust, to add to the architects toolkit.