As product builders, we have collectively built internal tools for the customer support functions at 3 major unicorn companies over the past 7 years. These customer support teams were responsible for supporting over $1B annually in GMV. We shipped products internally that helped those teams save over $5M/year by reducing average handling time and scaling operations. So we intimately know there are powerful things that any customer support team can achieve with the right blend of technology.

Yet most customer support teams are left in the dust. They are given no engineering or product resources because "support" is by definition not the company's core product (we worked on many of these things as part of internal hackathons and on our own time). Additionally, we were advised by our leaders that "building things for customer support efficiency is bad for your product or engineering career."

We believe strongly that Ops leaders everywhere are underserved because of this.

What it does

Our product is a no-code app builder designed for an Ops leader to build support tools and integrations on their own. Our MVP allows you to connect your SOPs and Admin tools together in Zendesk, so your agents never leave Zendesk to resolve anything again.

We picked this MVP very specifically because at every enterprise we've ever worked at (3 major unicorn companies), the customer support department always had a custom Zendesk app built that internally connects their systems together to make solving specific SOPs efficient. Here's a publicly available support training video from Uber where you can see in the video their internally-built Zendesk widget (in the right sidebar) that supports their Zendesk agent flow. These integrations were built once by an engineering team and then never supported again. It's hard to believe, but we've worked at 3 other companies that did exactly the same thing internally. It's just something all support teams do when they start to scale.

So by doing this MVP, we are specifically NOT changing any support team behavior, but providing a way for these apps to be self-created, self-managed, and self-sufficient.

How we built it

We used the Zendesk Apps Framework to build an interface for support agents directly in their Zendesk environment. We then built a no-code configuration dashboard designed for an Ops leader. It walks the Ops leader step-by-step to deploy a new Zendesk app for an SOP and connect it with their company's internal Admin. Specifically, we:

  • Architected a re-usable framework for any support team SOP to be represented as JSON
  • Designed and built an intuitive frontend for any Ops leader to build a library of these SOP representations
  • Our Zendesk app loads the correct SOP for a ticket on the spot, on which agents see data from their Admin relevant to solving the ticket and one-click actions they can take

Challenges we ran into

We got feedback on our tool from a major food delivery company (we know decision-makers at every on-demand company from our previous work experiences), and actually had to re-architect some of our earlier assumptions when we saw their real live SOPs.

Accomplishments that we're proud of

We landed a proof-of-concept launch with the major food delivery company and are already installed on their Zendesk platform. We are gearing up for a POC period with one of their most complex SOPs (today a 15-20 step process for the agent!).

What we learned

From interviewing customers and showing them our app designs, we learned why they would pay for our solution. As soon as we learned, we published those value points to our temporary product landing page at (in the "Built for the modern support team" section). We already knew that reducing Average Handling Time and not having to wait on engineering are two major benefits our approach provides, but we learned that Ops leaders also expect our tool to deliver:

  • Faster onboarding times for their agents: they think ZenRPA can make new agents into experts on Day 1 by loading living SOPs dynamically onto tickets
  • The ability to secure their Internal Admin system: they want to remove god-mode for their hundreds of support agents for security reasons, and see our tool as the path to doing that
  • Analytics: they hire a lot of data analysts today that build post-facto reports on Ops efficiency, but they think the data from this tool's usage can help them remove the need for at least one analyst

What's next for ZenRPA

We're gearing up to run a POC with a potential enterprise customer and are focused on making that a success by July.

+ 8 more
Share this project: