Building tools for teams — how we’ve built the internal tools that help us help our customers
Simply put, Monese is made up of two sides. On the one side, there are the outward-facing mobile apps available on both Android and iOS. The apps, translated into 9 languages, enable our customers to open a banking account on their mobile in minutes, order a card, get their salaries paid in and make both local and international payments.
And then there’s the inward-facing side that consists of all the logic keeping the accounts opening, payments moving, tasks creating, emails firing and all the other magic happening that makes us, well, us.
Part of that latter side is also a web application, otherwise known as Backoffice, that we’ve built for our internal teams to help them do their thing.
In Backoffice our teams can answer video calls, help customers get their accounts opened and questions answered when they run into any problems, resolve automatically generated tasks and localise emails and notifications to name but a few of the features.
Although hidden from the public eye, Backoffice is an integral part of our product. As the primary tool for our internal teams it has a big role to play in the overall service we provide to our customers.
But building great internal tools, while also wanting to provide the best features and functionality to our customers on the mobile apps, has been a challenge.
A brief history
In the months leading up to the launch of Monese in September 2015, we had been heavily prioritising getting a beautiful, secure and functional mobile app in the hands of our customers as quickly as possible. In this race against time, we knew something had to give, and so we launched with a rather basic version of our Backoffice web app.
It was built on React, using Semantic UI for the visual side, and it was meant to be robust, reliable and secure rather than pixel perfect — a sturdy mule, rather than a show-stopping stallion, if you will.
Luckily, our lead Backoffice developer at the time had studied graphic design and so the result looked as beautiful as it was humanly possible within a short time frame and with limited development resource. It was a good-looking mule.
Of course, the very first version of Backoffice was missing a lot of functionality which only became evident once we opened up to the public and there was enough live data for the problems to start surfacing.
One of the more painful ones was that there was no search functionality on the platform at all. Needless to say, the first days were a little rough on the team.
Thankfully our customer support and compliance teams were working in close proximity to the engineering team and so if something needed to be improved on Backoffice, it would usually get done within minutes.
Back then, the engineering team would on some days make about 90 commits and 5 deploys a day to improve the Backoffice system. We simply had all hands on deck focused on ironing out any kinks we found.
With time, the platform became more stable, as we fixed and improved it. We even moved it to a different framework called Vaadin, whichat the time, allowed us to develop new functionalities quicker.
The challenges, however, have shown no signs of disappearing. They only change, as time goes on, we build new features for the mobile apps, the customer numbers increase, and we expand our teams.
In addition to functionality we add to our mobile apps that our internal teams need to be able to manage on the Backoffice platform, we now have separate payments, localisation, business intelligence and finance teams as well, each of them increasing the number of development requests for improvements.
Here are some of our biggest challenges we’ve had as we’ve been building and improving Monese’s mobile-only banking experience for our customers.
The challenges
As the platform is used by all of our internal teams, it’s essentially a product on its own, with a user base, stakeholders and a product backlog.
- The internal teams and their different needs
Our internal teams have different functions that reflect in the way they use Backoffice. Not only does our customer support team use the tool differently from, say, our payments team, but the customer support team also has sub-teams that have different functions, such as verifications, calls and chats.
As an example, our verifications team are there for the customers who don’t yet have an account, which means that they use different parts of the platform and need to have access to different information than our calls team, who support existing customers in their day-to-day needs. Additionally, our compliance team use Backoffice as well, but focus on a whole other set of functionality.
This means that although the tool is the same, it needs to act differently for different teams. The trickiest parts are usually when a particular view has to serve the needs of multiple teams.
A good example is the transactions view. When a customer calls us to inquire about a specific payment they’ve made, our calls team needs to be able to find the relevant information quickly and efficiently.
On the other hand, our compliance team needs to be able to see a whole host of additional data, and have additional functionalities on the same screen that become a real nuisance for the agent on the call with a customer.
Inevitably, we’ve had to make compromises where we wouldn’t have wanted to. So the compliance team today needs to make a few extra steps to get to the info relevant to them in the payment’s view than the calls team. We simply decided to prioritise the needs of the team who are in immediate contact with the customer, over the needs of those who aren’t.
This is not a long-term solution, however, and we’re working to customise the views in a way that would take into account the user’s role, and adjust itself to his or her specific needs. Which actually brings us to our next challenge — prioritising resource allocation.
2. Comparing apples to oranges
We’re not going to lie — it’s been hard to divide resources between customer-facing features and improving internal tools. Not only because it’s tempting to always want to build a better product for the customer, adding features and improving the experience, but also because measuring the value our customers get from us improving the Backoffice platform is much more difficult than that of a customer-facing feature.
How do you know whether you should focus your team’s precious resource on building a feature your customers have been waiting for for months, or developing an improvement for the internal teams that would cut the time they spend on resolving tasks by a third?
It’s easy to argue that we’re building the service for our customers, and therefore our internal teams’ needs will always come second. However, it’s crucial that these needs are taken care of as well, because it all circles back to the customer in the end.
The tools that the teams have at their disposal, how convenient they are to use and how quickly they get updated if something doesn’t work or needs improving, determines the quality of the service as a whole.
It’s tied to how quickly the agents find answers to the customers’ questions, how much visibility they have into what’s causing a customer’s problem on the system level, how much time they’re spending on different activities that can be automated and not on helping the next customer in line, and much more.
We haven’t struck the right balance just yet, but we’re working hard to get there. What we’re now reminding ourselves, is that to compare apples to oranges you have to realise that they’re all fruit in the end. In other words, we can reduce anything we see needs to be improved, to a few common denominators that help us analyse where they should be placed on the roadmap.
We use scoring mechanisms that take into account the customer value, business value, technical effort and other metrics, to prioritise roadmap items, regardless of whether they are customer-facing or not.
What’s more, as a banking service, security and compliance-related categories have a higher rank than others. That means we always make room for them on our roadmap even if that means pushing back other features.
3. Scaling product teams and its impact to Backoffice development
In a recent article our Head of Product wrote, he talked about introducing full-stack product teams or squads, working towards a common goal. Now that these product teams are already working on anywhere between 6 to 10 different features at any one time, we have a whole new challenge on our hands. It’s that the Backoffice platform is missing strong design and usability guidelines.
As I mentioned above, we are currently using the Vaadin framework for developing the platform. However, as we’ve found that we need much more design flexibility than Vaadin enables us to have, we’re moving back to a JavaScript-driven solution — this time with Angular.
This poses a new issue — with more design flexibility, the full-stack teams need to make more design and usability-related decisions than before. Every developer who’s ever built something for Backoffice has already contributed to it with their own handwriting that hasn’t always taken UX best practices into account.
Vaadin as a more conservative framework has so far kept it from getting out of hand, but now it’s time for a new approach.
To welcome this new era of full-stack teams, and aid the teams in their decision making, we’re working on a comprehensive style guide. This will outline the rules for usability, UI components, page structure and other aspects to make sure Backoffice will keep its integrity even with a number of teams working on it simultaneously.
It’s also important to have adequate self-help guides woven into the tool, so that the platform acts as a documentation for itself. This is so that the teams wouldn’t have to maintain the documentation on an internal wiki, where it’s subject to being expired as soon as a small improvement is introduced to the platform. Or worse yet — have the agents rely on tribal knowledge that has inevitably evolved in the team over the years and that nobody really has control over.
The road ahead
There’s a lot we’ve learned in the past 3 years building Monese and the internal tools for our teams. For one, we fully recognise the need to — in addition to feature teams — have a dedicated Backoffice team working on day-to-day improvements. We have also decided to have that team to be part of the wider Core Banking team.
The Core Banking team is responsible for maintaining the crucial parts of our system, taking care of legacy, improving infrastructure and everything else that allows us to keep improving the banking experience for our customers.
Having the Backoffice team be part of Core Banking helps us to always have indisputable resource available for the ongoing improvements of the internal tools, and expand our Backoffice product team to eventually become a standalone team of its own.
These are steps we as an early-stage company didn’t have the luxury to make a few years ago, but with so many customers to serve, and with the ambitions we have for the future, it’s the only way to go.
This article was written by Hanna-Mari Kirs, Product Manager & Engineering Team Lead @Monese. This is the seventh post in a weekly recurring series from the Product & Engineering team @Monese.
