How Plaid scaled customer support workflows as the support team tripled

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.

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:

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:

So he decided to build a better solution.

Chris wanted to build an app that could pull together quite a few pieces of information about institutions into one place:

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:

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:

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:

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.

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:

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:

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:

See how to build faster financial operations like Plaid, Brex, and Coinbase.