You’ve got email, but not from your life insurance company

You’ve got email, but not from your life insurance company
When was the last time you received email communications from your life insurance company? For most of us, the answer is never. Contrast that with the last time you received email communication from your bank, your financial advisor or your favorite retailer. Life insurance is so far behind that it is not even in the e-delivery race. E-delivery allows the customer to elect to receive documents such as contracts, letters, account statements, and billing notices via email rather than paper mail. Generally, a notification is sent that a document has been posted to a secure website, or, in the case of general notifications, mailed directly to the policy owner’s email address. Areas of opportunity for e-delivery in insurance span all processes, from field administration to customer acquisition to claims. The benefits of using e-delivery are typically derived from reducing scanning, mailing, and printing, lessening process complexity, and increasing automation and systems integration. These drivers lower costs, reduce cycle times, and increase customer and agent satisfaction. I recently published a report titled, You’ve Got Mail Two Decades Later, Why Are We Still Talking About E-Delivery Rather Than Doing It, where I interviewed 17 life insurers about their current and future e-delivery plans. Although e-delivery can bring multiple benefits to life insurers, it has been poorly adopted. In fact, only 25% of the surveyed insurance companies are using e-delivery. Areas of focus within the report include: • Progress of e-delivery. • Targeted documents for e-delivery. • Benefits and challenges associated with e-delivery. There are a number of challenges life insurers face when it comes to e-delivery, including legacy systems, policy holder adoption, and agent engagement. However, other industries have found a way to overcome these challenges. It’s time for life insurers to set aside the excuses and find a solution. Life insurers have been left in the e-delivery dust and need to run with haste to catch-up.

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.