Point-of-sale
The example that I would like to give is smart phone insurance. For insurance companies, smart phone insurance is something that needs to be acquired when the phone is sold, otherwise the chances are very small that the people will ensure their smart phone at all. With the exception, of course of people that are very careless with their phones and that is exactly the group of people that you do not necessarily need in your insurance pool. However, what smart2cover needed was a way to sell insurance at the point-of-sale. This is a place where speed is important and you do not have time to explain or talk about insurance because it will surely annoy the next person in line. So they developed something that you can simply pick up, almost like buying a candy bar at the register.
At the register people except the smart to cover insurance that will ensure any smart phone that was purchased in the last six months for a specific amount tied to the monthly premium. A monthly premium of let’s say €3.95 will insure a phone to a price of €175. Higher premiums will offer higher payouts. Within a month the buyer needs to signup for the insurance and amounts will be debited from a bank account.
IT implications
When you look at the IT implications of such a move to sales at point of sale there are a number of things you need to make possible. First of all, suddenly there are access points like a POS terminal that need access to your API’s. Do you have an API that is able to be connected too?
These are not trivial questions. If a terminal is able to make a sale for insurance that also means that coverage is needed. The (high level) three-pronged approach is:
- Make sale
- Check payment
- Create coverage record
But this is the big bad outside world where you should trust nobody. So, you need security as well. Think about OAUTH2 tokens, username/password, perhaps IP whitelisting.
Then there are the users who need to activate the service. They also need a landing page with similar functionality:
- Create user
- Check policy
- Create standing order
- Activate policy
These users are from an even other domain where you have less control (IP addresses could be from anywhere, including VPNs) etc. This is only the signup procedure, there is a need for claims management.
API Manager required
All this suddenly makes that you do not so much require API’s, you actually require an API Manager. There are so many things that you need to take into account since you are outside of your IT network.
Some of the features have to do with security, like tokens, user id and password and such. Others have to do with findability and integrate ability of your services like a API store. Others concern management and monitoring of services. A nonfunctioning API at the point of sales is often a lost sale. Users also have little patience with errors on the backend.
What about expansion? Because brick and mortar sales are only one part, what about online sales? You don’t need the tangible retail product but you do want the API’s. Even brick and mortar stores have online web shops, you would like to offer the same product as a final step in the sales process.
All the more reason to look into an API Manager solution today. But what exactly should you be looking for in a API Manager? I will not go into detail to all of the elements but in general you look for an API Manager that allows you to manage, monitor and monetize your API’s securely. If you want to learn more, please read our white paper on API Selection.
The example of smart2cover is a good example of offering a service when it makes sense, in this case the sales of mobile phones in shops. Going digital can also mean going partly analog. Who would have known?
