The Mine! Project

open source project for online data and relationships logistics

Mine! insurance story

Tags: , , , ,

Not the most thrilling heading, I grant you, but being able to manage your insurance is not to be sniffed at. This is also the first in a series of scenarios, or Mine! stories, about how the Mine! could be used for specific uses. Some scenarios won’t be realised until vendors come on board and this is obviously one of them. That said, the Mine! is first and foremost for the user and works independently of vendors, platforms and third-parties.

So I am looking for some home insurance. I already have in the Mine! information about the belongings in my house to be covered or I input them – I can add descriptions, upload photos, links etc. I include my postcode and any essential information insurers need to quote. Then I create a feed from the Mine! containing that data. This feed would be specific to each insurer even if the information contained within is identical. That way I will be able to cut that feed off without disrupting feeds to others. Then I drop the feed URL into a field on insurer’s website and get a quote.[1]

Big assumption alert: Insurers will have added a field to their sites, and the way they extract the information is similar to you filling in a form, the difference being that you are choosing what data you share. I know better than trying to get vendors to change their system at this stage but with sufficient usage and incentive, this should be possible. The Mine! starts from the user, not the vendor.

The insurance companies respond. I choose the quote best for me and provides the insurer with my identity details needed to complete the transaction and whatever other personal data is required to establish a relationship. I can do this by updating the original ‘quote’ feed – this would be done by adding more objects or tags to the feed – or by generating an entirely new one. That will depend on the user preference and own data management.

The feed the insurer is given will provide updates about any changes to the shared data – contents, address, other relevant information. These can be used for timely policy amendments to avoid being uninsured or underinsured as well as for renewal quotes.

The insurance company benefits as they now have a direct connection with me, the customer, with a flow of potentially useful data that would be hard to obtain otherwise. The higher quality of data is inferred from the motivation behind it – I maintain data in the Mine! for my own purposes and needs – which seems a reason more powerful than anything else. And finally, the direct relationship cuts out the brokers, which is something that most insurers would like to see at least in the areas where insurance coverage has been commoditised.

The customer wins because he gets a deal more closely tailored to his needs and circumstances, cheaper insurance (brokers are often used to put together lists of items and the average fee paid to brokers for such service is £50+), reduces the hassle of re-insuring and avoids underinsurance when something does go wrong.

Over time, there would be other areas of improvement and impact. Better rating due to higher quality or relevance of data, better customer relationship, less paperwork. I realise I am veering into the utopia here, especially when it comes to insurance but one can but hope…

Similar scenarios could apply to any insurance products and services where details from the customer are essential to the quote and/or brokers and intermediaries are pushing out insurers from a direct relationship.

[1] Here is Alec’s ‘translation’ or elaboration of the process for the more technical amongst us, based on the current Mine! functionality.

So I am looking for some home insurance. I already have in the Mine! information about the belongings in my house to be covered or I input them – I can add descriptions, upload photos, links etc. [ALL THIS DATA GETS LINKED INTO AN "ENVELOPE" OBJECT THAT SAVES YOU HAVING TO GO AN RE-TAG IT SPECIFICALLY FOR THE PURPOSE OF INSURANCE] I include my postcode and any essential information insurers need to quote. Then I create a feed from the Mine! containing that data [IE: CONTAINING THE "ENVELOPE" OBJECT WHICH DRAGS ALL THE OTHER DATA IN ITS WAKE]. This feed would be specific to each insurer even if the information contained within is identical. [PERSONALLY I WOULD DESCRIBE THIS AS "DROP THE ENVELOPE INTO THE FEED FOR EACH INSURER"] That way I will be able to cut that feed off without disrupting feeds to others. Then I ["THE USER"] drop the feed URL into a field on insurer’s website and get a quote.

Tags: , , , ,

3 Responses to “Mine! insurance story”


  1. Craig Overend
    on Oct 20th, 2008
    @ 2:04 am

    Hi Adriana,

    While I think it’s mostly a great idea, I always like to flip great ideas on their head and attack potential weakness. While it may or may not be a big concern in the domain of insurance, I’ve been wondering about the potential cost of broadcasts such as RFPs, RFQs [Alec's ENVELOPES] , RFIs on service providers.

    Curious as to whether you’ve thought about combating SPAM RFQs, etc that only waste a service providers resources. Is there a transaction history and reputation side of this utopia or will automation and honeypot filtering – just as we do with email – become a domain specific necessity?

    I’m assuming both will be necessary more so in some domains than others, and that the Mine! Project may need to encourage 3rd party services to provide request/reputation management and SPAM filtering systems per domain.
    Take your example, an insurer then only has to drop a 3rd party service form into their site and the third party does the rest, thereby lowering the barrier to entry for the insurer. Or perhaps instead of a form, as an API that can be automatically discovered using something like the recent /site-meta format proposal. Enabling the Mine! app itself to search or crawl for service providers, providers the Mine! owner could then simply click to either broadcast to, or send selective requests to providers by type, region, etc. Perhaps building a personal collection of providers in one’s Mine! such that owners could easily broadcast new and related requests to. Sites could display an r-button? to advertise Mine! support. Users then clicking to transact or just add the site to one’s Mine! to signify some form of relationship.

    I think the most important aspect of this, is that everything be in one coherent idiot-proof interface. If my mum has to think and leave her Mine! to deliver an envelope (URL) to some form, it’s too difficult.

    Craig.


  2. alecm
    on Oct 20th, 2008
    @ 4:11 pm

    Hi Craig!

    While I think it’s mostly a great idea, I always like to flip great ideas on their head and attack potential weakness.

    My cats used to do that to each other, too; it’s so *cute*.

    While it may or may not be a big concern in the domain of insurance, I’ve been wondering about the potential cost of broadcasts such as RFPs, RFQs [Alec's ENVELOPES] , RFIs on service providers.

    Errrr… I am afraid you have the wrong end of the stick, there; I don’t think you get what the Mine is about.

    It’s a place where a user can upload their data, crunch it a bit – tag it, poke it, prod it, format it, whatever – and then then may elect to share it by means which I will detail in a future posting, but which at the bottom line mean “sharing the URLs for those objects with the third parties who may be interested in them”.

    Thing is: you don’t want to have to share the URLs of (say) 400 objects separately and individually with the aforementioned third parties, so instead you wrap the URLs up in a blob of data and share the URL for that with them, instead.

    The previous paragraph describes equally well a “feed”, or alternatively some manner of “container object” (something to which I was alluding by the word “envelope”) – so I should not need to describe it much further.

    Curious as to whether you’ve thought about combating SPAM RFQs, etc that only waste a service providers resources. Is there a transaction history and reputation side of this utopia or will automation and honeypot filtering – just as we do with email – become a domain specific necessity?

    Utopia? Dude, this is a tool and a phenomenon, not a hype curve. Also, most of what you are saying is not applicable to the model – “spam” is not possible in a Mine environment, for instance – so I have no idea how to respond to you.

    And in a Mine! environment all notions of reputation are those of the user – eg: if I think someone’s crazy, I elect to avoid them in future. End of story.

    If someone deals with me and decides that I am a bad debtor or something, then the world already has mechanisms to deal with that sort of thing. End of that story, too.

    [...deletia...]

    Enabling the Mine! app itself to search or crawl for service providers

    You’re thinking about “agent-based computing” or similar. That’s not a Mine thing.

    [...deletia...]

    I think the most important aspect of this, is that everything be in one coherent idiot-proof interface.

    Oh indeed.

    If my mum has to think and leave her Mine! to deliver an envelope (URL) to some form, it’s too difficult.

    I look forward to finding out.

    - alec


  3. Craig Overend
    on Nov 7th, 2008
    @ 10:33 pm

    Hi Alec, thanks for replying! I however may still be confused. :)

    I just can’t see how delivering a Mine! URL containing a feed of my current possessions, to a form on an insurers site – means the insurer’s form isn’t vulnerable to being spammed by bots. However, I will go and think further as to what you’ve said, after reading again, and writing the rest of this comment as to how I feel a Mine! should work – I need to get this out of my system somewhere!

    The main reason I bring this up, is that the way I see it, the Mine! needs do both; produce and consume for user experience and to help adoption. Not just produce and require manual labour (feed delivery) as I understand your Mine! does.

    If there are no tools to consume the Mine! feeds, ensure their reputation, or find services that can take them from the get-go, who will implement and market it? On the other hand if my Mine! could talk to your Mine!, and your a freelancing graphic-designer whose services I’d like a quote from – one users Mine! could then produce a feed of structured requirements, and the other consume depending on which way the transaction needed to happen. This way user-driven relationships can be established immediately, no separate app to consume the feeds and therefore a much lower barrier to entry. Thereby helping adoption, because individuals become empowered to both manage & share their personal information, and- if they choose to – become a provider and recipient of users structured content. Both sides just needing to install a Mine! from the get-go. If they want to customise it into their business process, or write their own, they have a template they can work from, aka “stand on the shoulders of giants (your standard implementation)”.

    I understand you wanting to keep this as simple as possible, dishing out just feeds with structured content from the Mine!. Why my thinking is that AtomPub is a RESTful(like) API, so why not publish insurance quote feeds to a service providers Mine! using the AtomPub API, instead of a form on a website? Additionally, have a service providers Mine! publish a feed with structured content for services it provides, such that consumers can find Mine! service providers to give feeds to. This would work by having a service provider Mine! ping aggregators with service updates. Consumers then subscribe to service aggregators by category in their own Mine! in order to learn of new company offerings, and also to bookmark them for later. Not unlike how feedreaders and blogs work now. Services could publish document structure they support in their feeds, and standards would emerge from that experimentation for different kinds of services saying what they want and users saying what they’ll give. A drag-and-drop interface like Yahoo pipes used by users to mix and match structured Mine! information to produce compatible feeds. And just like Yahoo Pipes, these compatible feeds could be saved and shared, with standards rising to the top based on a zeitgeist of users supported Mine! document structure, again in a feed. This way the service providers can publish the structure of data they want either privately or publicly, and users can choose to respond with a list of supported public & private feeds, thereby creating a standards market conversation.

    I must be way off Mine! track by now… :)

Leave a Reply

© 2009 The Mine! Project. All Rights Reserved.

This blog is powered by Wordpress and Magatheme by Bryan Helmig.