The Whipcar use case for policy admin systems

As we all know, legacy IT systems are the major stumbling block to new initiatives from our business folk. And I was reminded once more this week how the business can ask some pretty crazy stuff from IT. Here in the UK, there is a new business called Whipcar, which is a crowd-sourced rental car model.

Reduced to it’s basics, you rent a car from a street near you through this intermediary website. The model is about leveraging spare capacity in the existing car market by renting the car out when it’s not needed. This works well in large metropolitan cities such as London when a car is seldom used on a daily basis. With Whipcar, you can “sweat your asset” for the periods when you don’t need the car. One of the principles is that you are likely to be more careful with your neighbours car than with some faceless global car rental company and so the rentee has little to worry about. But insurance is still a requirement.

So how does insurance work? As the car owner, you will already have a car insurance policy in place. Whipcar has negotiated an agreement with a London Market insurer to provide an overlay to that insurance policy whilst the car is being rented out. This is a unique product (variable time for the policy, insurered value variable, billing requirements variable) that would test any current policy admin application.

So my challenge to you is this. You may be well down the path of legacy simplification or modernization, or you may be still considering how best to approach it. I would propose that in ascertaining if your target (or new) application stack is fit for purpose, the small case study of Whip-car is an interesting little use case scenario. Let us know how it goes.