There are more than 11,000 financial institutions in the US. As consumers go digital for everything from expense tracking to buying stocks, there’s a huge need to connect these financial institutions to the apps people want to use.
That’s where Plaid comes in. Plaid integrates with all 11,000+ financial institutions so apps like Venmo and SoFi can use one API to connect to any bank account consumers use.
Chris O’Neill joined Plaid in 2017 as part of the product support team, eager to help their B2B customers get the most value possible from Plaid. And after a year and a half, he transitioned to technical support engineering, where he handled more complex issues and could build lightweight internal tools to help the broader support team work better.
That was 2018, and Plaid was on a winning streak. The company would end up doubling their customer base, growing to 175 employees, and raising a $250M Series C by year’s end.
All of this change came with growing pains for a roughly 20-person support team. So, with the help of his manager and the head of support, he became laser-focused on one major target: making support workflows better and faster using internal apps.
This is the story of how Plaid empowered customer support to adapt (and re-adapt) workflows at a huge inflection point in their growth, and how a small engineering team played a critical role in making it happen.
The trials of managing integrations with 11,000+ financial institutions
When it came to tackling his first project, Chris lasered in on an all too common problem: customers would write in to support because one of Plaid's integrations was down, not working, or difficult to connect.
Here’s how the process looked on the inside:
- A user would write in to support because they had trouble connecting financial accounts using their Plaid Link modal
- A Plaid support rep receives a support request in Zendesk and kicks off a few workflows:
- Check prior resources in Zendesk
- Look up the logs in an internal database
- For certain logs, trigger an action via an internal API (REST, GraphQL and gRPC)
- Review if there are any related tickets or create one in Jira
- Tag escalation engineer in Jira and Slack - The rep gets confirmation that the issue is resolved
- The rep lets the customer know and resolves the issue in Zendesk
Rather than focus on the symptom (support tickets), Chris and his leadership team wanted to focus on the cause: limited visibility into integration health with each institution meant they were always on the defensive.
To build this visibility, his first option was to ask the internal tooling team for support.
But scaling startups have to be ruthless with prioritization, and the internal tooling team was focused on major initiatives that couldn’t budge. Their mandate was across every department, and they didn’t have bandwidth to concentrate deeply on this problem.
So his next option was to consider building on their homegrown internal system.
The system was reliable and powerful, and the backbone of many internal tools. But developing a net-new app on a complicated topic—where he admittedly didn’t have the full scope—would take more effort than it was worth.
In particular, it was difficult to:
- Add additional data sources like Jira, Zendesk and gRPC
- Build a quick frontend, as everything was custom React
- Collaborate with support teammates on the user interface
- Setup tracking out of the box to see how the tools were being used
So he decided to build a better solution.
Getting institution(al) knowledge all in one place
Chris wanted to build an app that could pull together quite a few pieces of information about institutions into one place:
- General institution knowledge
- KPIs on integration freshness and longevity
- Logs of management/integrations changes
- Recent Jira tickets that are open for that institution
- Recent PRs and commits in GitHub related to the integration
He ultimately chose to build the app on Retool because he needed a functional app fast.
Let's take a closer look at the Retool app the support team uses:
A custom homepage gives each support rep quick navigation between high-level and detailed breakdowns of integration health for each of their thousands of integrations.
Reps can navigate to a Health tab within the app where they can dig into real-time health metrics without leaving Retool.
They can also set global KPIs (success metrics) for different integrations, allowing support management to understand the connection between different integrations and overall team metrics.
As Chris was building the app, he talked to a support teammate and they mentioned it’d be really great if you could create a Jira ticket directly from the app when you noticed something looked wrong.
This was not something Chris had scoped, or admittedly thought about before. But his teammate was able to jump into Retool and build that functionality in.
With that simple adddition, support reps can create Jira tickets directly in the same Retool app, and a lot of the ticket information is already pre-populated based on the institution the rep is submitting a ticket about. According to Chris:
My colleague might not have had the ability to add this functionality in our legacy system. But the more accessible nature of Retool allows for this kind of iteration. You can solve other relevant use cases and add them on since the cost of development is so much lower.
Building internal apps while in hyper-growth
Chris first heard about Retool from a colleague on the support team. That colleague demoed Retool, and it sparked a conversation about building for change.
If workflows and processes were destined to change every few months as the team grew, how could internal tools ever keep up?
For Chris, Retool seemed to flip the script. A platform that promised to speed up every aspect of building apps felt right for a team stuck in a constant transitionary period. He adds:
We couldn’t justify the development costs to work on our traditional internal tooling to solve for something like this. But Retool was a different conversation. We could actually spin up a new workflow in a matter of hours. There’s no deployment pipeline to speak of. There’s no code reviews where delays are fully out of our control.
So Chris moved fast to implement Retool on top of Plaid’s internal tools framework. Given the internal framework interacted with most of their internal databases via gRPC, this gave him a jumpstart to get going on the institution health app he wanted to build.
It also completely changed his development process.
Historically, he’d have to do heavy research and validation before investing in building a UI for the team to test—after all, it required weeks of work to make it happen. But extending existing infrastructure with Retool on the frontend changed the game.
Given each UI took minutes to build, Chris could just walk over (pre-COVID) to the support team and sit with them for a few hours. He could then create multiple iterations of the same app and test them live with support reps to understand which way to go:
Using Retool, we can throw up a few different versions of a workflow into apps, we can test all of them with the support team, and then quickly move forward with best one. Retool allows us to be a lot more nimble, and you can spin up in 15 minutes what would normally take you a couple of hours.
This was incredibly timely because their consumer-facing side of the business was just starting to take off, and customer support was preparing for all kinds of new support workflows.
With new products, there’s no clear understanding of what workflows will look like. It changes every day. And the last thing that team needed was a 3-week delay to start using internal apps to improve their process.
Retool fit well with this environment, giving him the ability to build durable tools without over-investing into workflows that would eventually evolve.
Staying scrappy as the company keeps expanding
Plaid has about 700 employees today, recently raised a massive $425M Series D, and is far from slowing down their growth. Their support team, now closer to 60, has also grown in size to support a large catalog of customers, products, and institutions.
Chris and his team (no longer a one person show) recently compared their legacy workflows and Retool workflows to measure their team’s progress, and found Retool workflows were 80% faster than any of their old ones.
Now, around 10 Retool app builders own custom tools that the support team uses regularly and recently rated as highly useful. Emily Haahr, head of customer support, had this to say:
Our teams enjoy using Retool for customer success and, most importantly, they can champion new ways of working because Retool makes it easy to build any workflow we need. It’s helped us turn critical expertise into better support metrics across the board.
It's also helped forge a close relationship with the engineering team. Chris and team continue to uncover valuable insights only context-rich support reps can provide, while giving engineers more time to solve the biggest problems. Jean Denis Greze, head of engineering adds:
Plaid is looking to build a strong engineering culture, where innovative ideas can be turned into best-in-class internal apps that help teams work how they want. The work our engineers have been able to do with Retool supports our goals, has made meaningful contributions to supporting our customers, and has high ROI from the engineering efforts invested so far.
And coming back to Chris, he's excited to expand his team and keep helping the support team meet the next challenge. When asked how Retool helped him reach this point, he had this to say:
Retool is speed. Developers care deeply about how long it takes to do something. And Retool makes development and ideation so much faster. Even if you’re going to change something multiple times, Retool helps you get there and prove out a concept super quickly.
See how to build faster financial operations like Plaid, Brex, and Coinbase.