Re-inventing customer service
You’ve probably already read about a hundred articles that banking is facing their own Kodak-moment? Right… So, you already know that banking is changing. But what about customer service? Customer support used to be answering phone calls and sending paper forms back and forth. Entering an API economy, things couldn’t be more different. At this stage of Nordea Open Banking, most users are consuming our open APIs on the free sandbox environment. If the concept of sandbox is not familiar to you, it basically means a safe environment where you can experiment and test out the service with mock data.
I have a dark technical background but for the past few years I’ve been finding myself working a lot with areas such as customer experience (CX) and content marketing. I never studied nor put any emphasis on marketing, but through social media I’ve quickly learnt that everything that you do or say as an employee is marketing (like it or not). Every comment you make on social media paints a picture of you and your employer. Vice versa, statistics show that 95% of social media users are passive listeners and the minority 5% gets to choose the discussion topics. It’s almost like 5% of companies are DJs at the club and others are forced to listen to their songs.
From B2B to B2D
But enough for branding, let’s get back to customer centricity. How can you design a service if you don’t know what problem your service fixes or what motivates your customers? As we know, buyer personas and customer journey maps have pretty much been bread & butter when designing services to maximize customer experience. But what rules apply when your customers are software developers? Do any B2B- or B2C-learnings apply in a B2D (business-to-developer) context?
The answer is: yes and no. My newest role in Open Banking support has lead me down a rabbit hole from the well-studied field of B2C to setting up a B2D support team. And this is what I’ve learned.
“What rules apply when your customers are
software developers?”
Developer experience comes first
Developers want self-service — quick and dirty. They want help without queueing. They want to sort out problems themselves. In a similar way that ecommerce giants such as Amazon invest heavily in removing impediments from the purchase journey, maximizing the developer experience should be your top priority too. If APIs are your products, consuming them should be easy as paying for coffee with ApplePay.
Sandbox promotes experimentation
On our developer portal, registration takes a minute or too. After that, developers can launch our developer console and make their first API calls in a matter of minutes. There are detailed code examples of all API endpoints carefully documented on our portal. Moreover, based on feedback, we’ve recently launched tutorial videos explaining technical concepts such as OAuth2 and confirming a payment.
A small piece of warning though: all developers are not the same. So be careful not to flatten your field too much. If you’re unsure, just ask your developers what they value. That’s what we’ve been doing in Nordea Open Banking, again and again. This experimental, agile & feedback-based model is new for a tanker of a bank such as Nordea, where we’ve learned the hard way to avoid all risk taking. We’re happy to launch our roadmap publicly on our portal, so you can check what our development teams are working on. Don’t agree with our thinking? Drop a comment! We appreciate feedback, good or bad. Because we believe transparency and openness is the way forward.
About the author
Janne Uggeldahl is a recovering engineer, Customer Experience & Agile enthusiast with a passion for digital solutions. He acts as a Head of Third Party Support, and his team is responsible for community & technical support in Nordea Open Banking.
