Happy New Year everyone!
It’s no secret that we’re API-first. We’ve been this way since before some marketing-grad coined the term ‘API’. Back in 1996 they were called webservices – something I learned at the time, ironically, from a Microsoft whitepaper about how the future was about interoperability. Their vision stuck with me even if they went a different path themselves.
There’s an obvious question around “why” we’re API-first which I’d like to explore because the answer is not obvious.
One might assume it saves money – customers doing things themselves rather than highly paid colleagues doing it for them – but as we see from the plethora of competitors who have simply outsourced operations to Indian call-centres or BPOs, there’s more cost-effective ways to achieve that. In fact, the discipline of consuming our own internal APIs rather than just reinventing the wheel several times, and maintaining a highly available architecture, costs more in the short-run.
Then there’s conformity. A rigid API does force valid input whereas well meaning colleagues will always find a hack to make the system behave the way they want. Arguably though, the API shouldn’t be any different in what it accepts to a well written interface. If the interface is built on the API, they have to conform but we know competitors rely on ghastly alternatives such as spreadsheets with ActiveX macros for their business logic. Amusingly, their own firewall blocks the ActiveX so they have another workaround for that. Is it any wonder things go awry?
Then there’s customer convenience. For me this is a huge one but it has to be well-intentioned and capture all of the above. I remember in about 2000 I needed to change the address on my driving licence and, as someone fundamentally anti-social, was delighted to see that the DVLA had moved the process on-line. I filled in the form and celebrated how this Internet thing was going to change the world. A few days later I received a letter from the DVLA, at my new address, saying how they knew my address had changed (in a tone that suggested they’d uncovered my deceit) but I hadn’t told them about the change, and a heavy fine and maximum public sector wankery would ensue if I didn’t phone them. I feel the same when I need to change something with my bank, but rather than a simple interface (behind which I’d expect an API), I have to navigate IVRs or fill in paper forms.
If one considers what has happened here, they’ve changed processes for themselves and any benefit to the customer is purely tokenistic. I consider it pretty disrespectful to my time and custom when I can’t self-serve in an efficient, flexible way, or where the process has gone backwards saving them money and costing me more in time. Most people add APIs for the wrong reasons and that leads them down the wrong path, one which doesn’t benefit their customers at all.
By contrast, we have APIs that have existed for years where we wanted to give our customers the convenience of, for example, submitting porting requests, even though our process on the backend didn’t change at the time. They had a consistent front-end to a broken industry process, and could automate and save money even though the benefit to us was zilch. Extend that across every business process we have, from customers topping up credit automatically (rather than us telling them there’s nobody to check the bank over Christmas), updating fraud settings dynamically, or integrating us deeply into their own processes. We know this works because we see millions of API requests every month, at all times of day and night, although I sometimes wonder how much this difference is appreciated by those who have never experienced anything different – be it lifetime Simwood customers or those who don’t use us and just read these blogs to get cross. Yes, we get the conformity benefit, yes, the portal is based on the API, and yes, for some processes we save some money, but the key thing here is that our customers are able to wring efficiencies and savings out for themselves because we respect them and the need for them to do so.
That I think is the crux of it: APIs come from a place of respect. Depriving customers of the ability to save costs and drive efficiencies is hugely disrespectful and selfish. Giving them limited options for engaging, none of which benefit them, is downright insulting and really shows true colours. Please think of this next time you do the same process as you’ve done hundreds of times in a supplier portal or spreadsheet. If they respected you, they’d either give you the white-glove treatment and fill in their forms themselves every time at their cost, or they’d give you an API!
But this is a long game too and we’re still working towards 100% API coverage after all these years. As an example of how this plays out though, I mentioned how we had a porting API to a purely manual process years ago. Many customers integrated with this years ago, deriving the benefit from it over all that time until now, when we’ve been smashing away at the internal process. I won’t repeat what I’ve said in other posts about our porting automation work but it follows this same theme – respect. I’m not a slave driver – our colleagues enjoyed the festive season like others, but we didn’t close our porting desk for two weeks like seemingly everyone else. It stayed open and the APIs and automations did the heavy lifting. Of course, some ports have to wait until other people at other CPs return to work, but many were just processed. Over the key festive days where nobody was working, several of our customers (who have clearly integrated our APIs with their apps and websites), were submitting porting requests and seeing them accepted 100% automatically and often in minutes. Contrast that with those who have to tell the excited end-user they have to wait two weeks (by which time they’ll be back at work), or even worse, wait two weeks for someone to send them a form! It isn’t just about respect for our customers directly but that percolates down the line all the way to the end-user and their experience.
As this industry matures, costs and efficiencies are going to be key. There are carriers who haven’t spent a penny since the 90’s, instead passing the costs on to you to make their business viable. Do you want to depend on their old infrastructure, while taking on their admin costs, all to give your customers an inferior service? Or do you want to respect your customers, give them class-leading levels of integration and features, while respecting your staff, stripping the costs out of your own business so you are simultaneously more competitive and more profitable?
If the second one is your preference, do please give us a call. To those who are already on board, thank you, we appreciate you and I really hope you’re seeing the benefits. If there’s more we can do to drive efficiencies for you and your customers, please let us know.
