Revolutionising the way banks sell insurance
January 2017 marked the completion of our Brand Partners API project – a new way to sell insurance policies in various high street banks.
The online journey went live a few weeks before the in-branch journey, but it only took half an hour for the first policy to be sold using it.
On the old in-branch system, it would have taken a member of staff between 25-45 minutes to sell a policy. They would use laminates and printouts to show the customer different options, while asking questions and tapping away at their computer. They would then get a price using a web browser before finally making the sale.
The first policy sold via our brand new in-branch API took less than eight minutes. That’s absolutely phenomenal. A complete game-changer.
It also puts us on the journey towards really driving revenue and profit for DLG and our brand partners, and they’re the metrics that the business really pays attention to.
A brief history of our API
We originally started talking about building a new platform that separated the back-end from the front-end and introduced APIs towards the end of 2015.
It made a lot of sense from a Digital point of view, so we started making noise about it and became very vocal in meetings, saying, “Why can’t we do it this way?” It was clear to me that we could create something useful for our brand partners and host it in the AWS cloud.
Well, something clicked, because a whole lot of gateway submissions and meetings followed. We created a multitude of presentations to persuade key stakeholders around the business, tirelessly championing our cause.
Then, around March 2016, we finally got approval for the project to kick off.
It was approximately a nine-month build, and in that time we achieved a number of key things, namely:
1. It’s a mobile-first design
Being mobile-friendly is essential. So we started by making sure our API was responsive. To make sure it worked in branch, however, meant ensuring that it worked in IE8, which was a major challenge. I’m pleased to say though; we met the challenge head on and learnt a lot along the way.
2. It’s live in AWS
This means that our API sits within Amazon Cloud, so we can control and manage it all in-house and capture everything on it. That’s massive for us.
3. It’s based on the microservice architecture
This was our first step into microservice architecture, which puts us in a great position to drive it harder in the future. Our aim is to make services smaller as we work towards optimising and improving them.
And, as services get smaller and become specific to a particular function that the application does, we can make changes to an individual service without having to re-test everything, or redeploy the whole application.
So in short – deployments will get faster, we’ll test less, and we can introduce more functionality within the specifics. Essentially, microservice architecture has enabled us to improve the way we do everything.
4. We’ve implemented API connectivity from the Java application upwards
This is another big one. By implementing API connectivity, the front-end becomes a completely separate application.
So the front-end, built using Angular JS, now talks to the Java platform using an API. This is great because it means that tomorrow we could ditch Angular and go to something else, and we wouldn’t have to rebuild the whole application.
We’re not going to do that, of course, but it gives us a great level of flexibility.
5. Real-time analytics
We’re getting real-time analytics on a specific set of data points including sales, revenue and traffic. That’s a big first for us on this journey – to be able to get that level of detail from Adobe Analytics in seconds is fantastic.
So far, it’s enabled us to play around with the data to help with debugging and find out just what we need to know. It’s great when you start to see analytics supporting the engineering capability.
6. Awesome UX
Of course, right at the heart of this project is the customer. So in order to support the speed and usability of the app, our UX and design teams have worked extremely hard to get us to a point where staff can sign up customers quickly and easily, in-branch and with no fuss.
7. A whole new CI process
Instead of deploying the whole application every time, we’ve created a number of different instances so we can simply flip from one to another depending which one has the latest version of the code.
It’s called blue-green deployment and it means we can build and deploy everything onto the server. We can then test it online and when we’re completely happy, just repoint the web address instead of going through a huge manual deployment early in the morning (when everyone’s still half asleep!)
8. Better value for money
The creation of this new app enables us to deliver more to the bank. We’ve committed to a certain amount of optimisation sprints this year, but with this new platform in place, they’ll actually get more for their money. We’ll be able to do a lot more per sprint because we can move even faster, and that in turn means it’ll be much cheaper. We’ll be able to deploy more features, too.
We’re already working on a list of features to start building over the coming months, including a rebrand, so watch this space...
But that’s not all…
To support the API, we also delivered an iPad application, which is rolling out in UK branches as we speak.
Staff members can use the app to access product comparisons, a contents calculator and policy PDFs. There’s also search functionality and key selling proposition messages to help illustrate options.
Gone are the tired laminates and laborious sign-up process. Banks now have a faster, smoother way to sell insurance products in-branch using our brand new, visually appealing, interactive products.
as a result of our hard work, we’ve now got something live that we can be truly proud of
We will deliver success for this business
The bottom line is, we’ve launched something brand new, with completely new infrastructure in a completely new way, using a lot of new processes that still haven’t been bed down.
We had to go through a whole new change management process that involved over 3,000 approvals.
We were the first team to go through this new process and get something into production on AWS – and we’re running it all in-house.
Yes, it was agonising at times, but as a result of our hard work, we’ve now got something live that we can be truly proud of.
A word of thanks
Of course, none of this happened on its own. It’s only by working together with the support of the business teams that we were able to stand stronger and taller.
We’re currently supporting the AWS infrastructure because we didn’t want to compromise the go-live date. That’s a massive commitment from the team. As a result of doing that, we’ve shown that we’re ready and prepared to do whatever it takes to get things moving in the right direction.
So, the biggest thank you goes to the project team. Thanks also go to the design team, the insight team and the testing team (Cognizant).
And last but not least, thank you to the partnerships team. Because ultimately, they're the ones that put their trust in us. They stood and fought in our corner when we faced challenges. They believed in Digital, they thought we could do it.
And we did.