My interviewee today has a potentially controversial idea to share: Zendesk is just as important as Salesforce.

Whereas fewer than 25% of people in a company will ever touch the CRM, nearly all touch the support system. And whereas the CRM is just for customer relationships, a support system like Zendesk is for all relationships—customers, HR, legal, and more.

Nick didn’t arrive at this theory overnight. He’s worked in tech for 15 years, three of which he spent at Zendesk, and he has supported businesses like Uber and Airbnb which have tens of thousands of agents. He’s built his career on knowing more than anyone about the magnificent variety of Zendesk use cases. If you take away one thing from his interview, let it be this: Zendesk is a tier one system of tier one importance, and it’s time it got a tier one owner.

‍This conversation has been lightly edited for brevity.

You’ve said support tools are under-prioritized. Why is that?

Nick Erickson: This is a really interesting topic. I see support solutions like Zendesk get bucketed in with less crucial tools like learning management and owned by the business. But your support tool is probably the second-most used system, second only to email.

Salesforce, Jira, or Google Workspace tend to get a full dedicated team with engineers and business analysts, but Zendesk doesn’t. Even though it’s the thing that impacts the majority of your employees' day to day. Support uses it, success uses it, HR uses it, legal uses it. Maybe 90% of the business touches Zendesk, whereas maybe only 25% touches Salesforce. I’ve talked to the teams at companies like Netflix and Universal Media Group and they see the same thing.

Frankly, this is why I took the job at Pinterest—they saw the need for Zendesk to have one owner.
‍

‍

Can you tell me more about all those different use cases?

Nick: Zendesk is useful anywhere people make requests. There are an infinite number of use cases for support. By contrast, there is not an infinite number of use cases for Salesforce or Jira.

Companies are starting to see the advantages of allowing lots of different business teams to deploy it for their support. But they’re also starting to see, “Oh, we can’t just have 25 Zendesk instances across the company.”

This is actually an issue we have here at Pinterest—Zendesk is so useful, it tends to grow organically. It’s just so easy to spin up a clean new instance. But around each instance is a data moat, and if users don’t distinguish between whether a problem is an HR issue or a payroll and benefits issue, that creates a confusing experience. Suddenly you have to create four tickets and four transfers. It’s as confusing for agents as it is for users, who just want their question answered.

The solution to organic growth is having one thought leader, architect, or enterprise owner. Because, if I wasn’t here, we could easily have 45 Zendesk instances at Pinterest by the end of the year.
‍

‍

Tell me more about this architect. Who should own Zendesk?

Nick: Every reasonably sized business needs someone to question things rather than fulfill every request. They need to understand how new configurations fit into the enterprise architecture of what’s already there. Their job is to ask, “Does this actually solve the problem?” Because small fixes applied liberally can create more problems.

Just think about having to recreate a Salesforce integration you built for one team, for every team that needs it. That’s not scalable. I can’t get pulled into remaking the 30 pieces of code for these instances. Every change potentially creates operational overhead, and if none of it gets updated, eventually, nobody knows what’s going on for these 30 different versions of the same code someone wrote three years ago.

When you’re supporting tens of millions of users, the question you run into is, how do you standardize processes like deployments, onboarding, security posture, or workflows? How do you have good overlap and transfers between all these teams when they're so inherently dispersed and segmented?

Indeed—how do you do that?

Nick: One of the things I've been working on is defining the pillars of support at Pinterest. I'm breaking it down into five key pillars: technical support, people support, external support, legal, and sales. Those are five different support architectures that should cover pretty much every situation most companies have.

And the way I'm segmenting them out is the overlap of work. So, teams like payroll, HR, benefits, and equity all go into a “people support” instance because they overlap. They deal with the same type of people and issues and often transfer tickets between those teams. Help desk is our technical, workplace, facilities, and procurement stuff. Our external support is an exception because it's supporting external users, so it’s a bit broader.

What I’m trying to do is define what ownership means for this tool and guide the organic growth by consolidating 25 instances into just five.

What’s the danger of a business unit owning a support tool?

Nick: I think they're not going to have the same ownership mindset. They’re not going to audit their users, for example. I have evidence that they don't. You need someone not measured on what the business is measured on responsible for standardizing access, configurations, and things like trigger naming conventions. If you leave the business units to it, those trigger names are just random text.

The pandemic really increased the adoption of support tools and uncovered so many more use cases. But that organic growth eventually leads to the realization, "Oh, we can't scale our support.” And hopefully, that leads companies to think, "We should probably treat our support tools like we do our other enterprise applications."

How do you build for scalability?

Nick: For me, it’s trying to make things as simple and generic as possible. Ensure what you build applies to as many use cases as possible. I’ve seen both sides of scale and lots of reference points. I’ve been an administrator and consultant. I’ve been an analyst for extremely large companies and scaled support orgs from 10 to 1,000. I’ve had to tear it all down to build it back up again, and that’s become my philosophy: Build simply.

I’ll give an example: notification triggers. As an administrator, you don’t want surprises. If you have 30 notification triggers, how are you supposed to troubleshoot or deal with the operational overhead of knowing what gets sent to the end user when they submit a ticket? The more triggers you add, the exponentially complex that grows. Whereas the simpler you keep it, the easier it scales.

That’s one of the biggest opportunities when I look at a company’s instance. I look in there and say, there’s complexity here, but is it actually necessary for you to deliver a good experience to end users? What if it’s hurting rather than helping? Tools should enhance and simplify the agent and end-user experience. But in many companies, that’s now how the tools are being used.

What questions are you asking yourself right now?

Nick: Hmm. Maybe, how do you integrate Zendesk into your tech stack? How are you making your support tool benefit the other tools that your teams use? Whether that's Slack or Gmail or Salesforce or Jira or Snowflake or Tableau.

Because, you can use a support tool and data to help more than just the agent and end user. How are you impacting the lives of other people on other teams? How do you help them make better decisions? We have a ton of data and support. Support is the frontline of the company. We have all the data that sales or marketing could ever care about. How are you making it really easy to leverage that input and those insights?

That’s a really important question to ask, and a difficult one to answer. But as long as the business owns the tool, I’m sure you’ll never figure it out.

‍