How Lucidchart’s Support Team Drives Revenue by Helping Customers Help Themselves

Lucidchart, by Lucid Software, is a visual productivity platform that helps people share ideas, information, and processes with clarity. Through a robust help center, online community, and one-to-one assistance, Lucidchart’s support team services over 15 million happy users, all while keeping team size and ticket volume flat. We sat down with Keyvan Sadigh, Senior Director of Customer Operations at Lucidchart, to find out how his team has scaled their support capabilities and driven revenue without scaling their team.

Thanks for joining us, Keyvan! Can you walk through your background and give a little context around how you came to be Senior Director of Customer Operations at Lucidchart?

Sure! I’ve had a long career with a lot of twists and turns. I graduated from Cornell with a degree in biology and thought that I wanted to get my PhD in genetics. I worked for two years in a biomedical lab out in Boston doing genetics research, and then decided that that life was not for me. I was a bit confused by what I wanted to do because I had studied science my whole life, and now I didn’t want to go down the research path.

So instead I did Teach for America in Philadelphia, where I taught high school math to freshmen and juniors for two years. I thought it would offer a good opportunity for me to reflect and take a step back from everything that I had been doing. At the end of my time there I began looking for jobs and reached out to a buddy of mine who was working at Google and encouraged me to apply for a role out there. I joined Google at a time when they were very much focused on building out their help centers. Gmail was a relatively new product offering, but its user base was growing very very quickly. Google didn’t have a phone number people could call or an email for support, so we worked on a strategy to build a help center where users could help themselves and help each other.

I did that for about four years in different capacities, and then wanted to try my hand at people management, so I transferred to Google’s Dublin, Ireland office where I helped launch their community strategy across several European markets. So again, the thinking was that if we could provide a platform for users to help each other, then they would be able to get a high-quality answer much more quickly than they otherwise could.

I was supposed to be in Dublin for one year but ended up staying for almost four. I loved it, it was such a good time. I was able to manage people from different cultures which was a very new experience for me that was really great. Towards the end of my time there, I felt like the company was a very well-run engine that I was playing only a small piece in, and I began to miss the scrappiness of the earlier days at Google where I could get exposure to many different types of tasks and it was more of an all-hands-on-deck philosophy.

I started looking into much smaller companies and wanted something with a similar culture to Google, so I looked at the Google Ventures website to find companies that Google was investing in and Lucid was one of them. Our CEO Karl Sun is actually a former Google employee too, and what I liked about my conversation with him was #1, his emphasis on people and really building a culture that empowers people to do great things; and #2 building a platform, Lucidchart, that allows people to communicate visually through software.

That was a new concept for me. We’re all aware of what it means to communicate visually but traditionally we’ve relied on things like meetings or notes or spreadsheets to communicate with each other. Lucid had begun to push the boundaries of what people can do in a browser and aimed to allow us to think visually in a more collaborative way. So I was really bought into the company’s mission.

When I joined, the support team was only four people, and it was very much focused on email support. The task I was given was that our user base was growing extremely quickly – it had doubled every year for four or five consecutive years – but we were confident the right strategy was to allow our users to get their best, fastest answer by helping themselves. So that’s what I was brought on to do.

Wow, it sounds like you really got that scrappiness that you were looking for moving from a Google-sized support team to a four-person team at Lucidchart!

Absolutely.

So now that you’ve scaled up at Lucidchart, I've heard that you have since kept your support team steady at 10 people and ticket volume flat over the past few years. What role does having a small team play in your support strategy?

My strategy is really focused on providing rich content that our team can measure to allow users to help themselves to what they’re looking for. I always use the example of an ATM to illustrate this: When you go to a bank during normal business hours, you're faced with this question: Do I want to walk into the bank, wait in line, and ask my question? Or do I want to help myself at the ATM? Usually, it’s the ATM. And if we take that analogy and apply it to the tech world, at Lucidchart we think that a very well-written help center article is not only sufficient, but actually preferable for 90% of what our users are looking to do.

On top of that, the help center is actually a great way to measure demand for a lot of different things. If you can show that tens of thousands of people are coming to an article about a certain topic, you can then take that information to engineering and push for changes that are backed by real customer data. Whereas when users submit emails to our support team, the volume tends to be much lower and thus the data is less actionable when we present it to our engineering team. It’s been great for us to be able to show that even if only 15 users have emailed asking for a feature, thousands of users have visited help center articles also related to that feature.

The second piece is that our help center content is now localized into six different languages, so there’s an inherent cost into having high-quality content written by your team. So for long tail content, we provide a community where users can go to submit their own content, and other users can benefit from it. The example I like to use for this concept is we have an Android app for Lucidchart, and there are literally thousands of different Android phones, so if a user has an issue with their specific phone and how it interacts with our software, the chances of us actually being able to get a hold of that particular phone are pretty low. But one of our 15 million users probably has that phone and may have even experienced that exact same issue. So sometimes our role is connecting our users with one another so they can help each other.

And that’s been really great to see because when we look at the traffic for our help center and the community, it’s actually exceeded the user base growth. And then to your point, when we look at product support ticket volume over the last three years, it has essentially remained flat. Which to me implies that users actually really enjoy and are gravitating towards this self-help model.

When it comes to your online community, do you have any idea what kind of people are contributing knowledge and helping other users? It’s a cool concept to think about someone spending their own personal time talking about your product to help people they don’t know.

Our community is still a work in progress – a lot of times users will ask questions and we are the ones responding to them in the community, but then other users are still able to benefit from that answer. Increasingly, however, we are seeing that other users are coming in and supplying the answer, which is the best case scenario for our purposes.

To answer your question of why, there are very few products in the world that users are very passionate about, but I've been lucky enough to work on one like Lucidchart that definitely falls under that category. Because even when our product does not exactly match a user’s needs, and they have to go through sometimes crazy workarounds to continue using it, they choose to do so.

One example of this passion is a user who actually set up the Lucidchart iPhone app to be their daily calendar. This is a use case that our team never would have envisioned for the product, but for whatever reason this user decided that our solution was actually better than Google and Apple’s calendars, and despite the fact that we just don’t target that use case at all, they went above and beyond to make it work with their use case.

So if we think about that mentality, a lot of what users are trying to do is push the boundaries of what our product is able to do. And by helping others and sharing their use cases, it fuels their passion. They love this product and they want to share that passion with others.

That’s amazing. How does your team keep up with these user ideas and submissions?

Within our community we have a section called share your diagrams; we want to hear from users about the novel ways that they’re using our product. So that’s one way we hear about some of these use cases. The more prevalent way is that our team is still very much involved in answering emails. Even though the ticket volume is flat, we still get roughly 600 product-related support emails per week. And so a user will reach out to us and say, “This is what I'm trying to do but I've come across this obstacle. Would you mind taking a look at my document and helping me through this issue?” Oftentimes the documents they want help with are pretty straightforward uses of our templates, but other times we see some really innovative use cases of our product, and in those cases we’ll often ask them if they wouldn’t mind posting them in the community so other users can benefit from it as well.

Do innovative ideas that come in that way ever make it back into your product? How do you share that work internally?

We partner with our Customer Success and Solutions Engineering teams to put together a Voice of the Customer report which compiles feature requests coming from all of our customers. And in the case of template requests, we have a product template team that we submit new and user-generated ideas to. That team does their own research into the submissions and then evaluates the possibility of adding an official template to the product. We also have a template gallery within our help center, and some of our user-made content ends up in there and is discoverable that way.

I think our long-term vision is for the help center and community combined to be much more of a place for inspiration and proactive help as opposed to somewhere users only go when something is broken. We want to get people beyond that perception that’s still the general standard across the industry.

It sounds like you’re envisioning more of a two-way street between your company and your customers.

Absolutely.

That reminds me of Lucid’s core values: Teamwork over ego; innovation in everything we do; individual empowerment, initiative, and ownership; and passion and excellence in every area. Creating a two-way street speaks to so many of those. How else do you embody those core values in your CX approach?

It’s cool because these core values are set at a company-wide level, and they ring especially true for us because we’re on the customer-facing side of the company. Beyond that, these core values are something that we emphasize at every company kickoff, and at every company update. And once a year we have a company-wide retreat where we take three days off to go to Zion National Park or Bear Lake to team build and focus on our strategy for the coming year and also reemphasize our core values to all the new people who are attending their first retreat.

That’s awesome to hear. We try to embody our core values in everything we do at Guru as well.

So how does your team approach proactive customer education? What is the breakdown between the proactive and the reactive sides of being a CX team?

Let’s start with the reactive, which is something that I think we currently do very well. If a user knows what they’re trying to do in the product and they come to our help center or community trying to figure out how to do it, we will get them the content they need and oftentimes supplement it with videos and screenshots to make sure they’re set up for success.

I think the model we’re trying to move towards, which is the proactive model, is not just telling people how to do something, but telling them why to do it that way. Imagine a user comes to our help center and through other means and signals we know that they’re a biology teacher. We want to take that teacher to customized content that not only shows them step-by-step directions on how to do what they're looking to do, but actually shows them which template to use to do it. Our specialized teams – in this example, the education team – are working on providing better, more informative use cases.

So if a customer is reading about how to use a certain feature, we can capture some of the product signals from other users that have used that feature and serve that information to the customer, along with other features that similar users have worked with. So then we take that concept to the help center and say, “Okay, you’ve just read an article about presentations. Now you should read this article about layers and showing and hiding different layers because we know that those two features go hand in hand in the product.” That’s a little bit of what we’re trying to achieve.

So how do you formalize this strategy into goals? It sounds like your goals go beyond just keeping ticket volume flat and reducing first response time.

Our “Holy Grail” for support metrics is tying what a user does in the help center to what they then do in the product. When looking at a particular article, say about data linking, we want to then have a goal like: out of every 1,000 users that read that article, 700 of them then go into the product and use the data linking feature. And as of late, we’ve been able to tie the usage of the help center back to the usage of the product. So we can then extrapolate from there, and find correlations between help center usage and product usage.

That I think is really the crux of what we’re trying to do: increase usage of our product. And then being able to put a value to user retention. We can then say that if we compare 1000 users who visited the help center with 1000 who did not, our retention rates went up this percentage because we taught them something valuable. Or even going a step beyond retention and looking at whether their engagement rates also went up.

I love that. I've spoken to several CX leaders recently and the theme of support being a revenue generator rather than a cost center keeps coming up. You sound like you subscribe to that model of support being able to drive revenue rather than just incur costs?

Absolutely, but our team goes even beyond that. A lot of times, a user will reach out to us and they’ll be like, “Hey, we love using Lucidchart, but we’re having an issue with a document import. Our imported documents look funky. If we were able to fix this problem then we would be able to expand our Lucidchart usage at our company.” So we’ll help with the support issue, and then we’ll pass it off to our sales team.

“In the last year, support was actually the third largest source of sales leads at the company. If you look at the amount of revenue coming in through this channel of support, it far exceeds the salaries of what the team is being paid. So we actually are NOT a cost center at all.”

That’s extremely impressive! What other metrics does your team track? And which metrics would you recommend that other support leaders who admire your model track?

One of the things that we pride ourselves on is how quickly the help center and community sites are growing – what we called scaled support – compared to one-to-one support, which is emails, phone calls, and chat support.

One way to measure the growth of one-to-one support is by looking at the number of emails per user base. So we track how quickly our user base is growing, and we track how quickly each of our support platforms are growing, and then we normalize one across the other to find out the number of emails being sent per 10,000 active users of the product. And in contrast, how many help center page views are we getting per every 10,000 active users of the product.

If I look at the one-to-one support side, that’s more traditional: we look at things like first response time, customer satisfaction, and what we call user wait time, which is the time it takes from when a ticket is submitted to when it is resolved, subtracting any time that we are waiting for the customer to get back to us with more information.

When we look at scaled support, it’s a little different than one-to-one support. So, of those users who are using scaled support – whether it’s the help center or the community – what are they then doing in the product? What is their seven day retention rate vs 30 day retention rate vs the retention rate of people who aren’t using the help center? And then we can also tie it to revenue as well. People who are visiting the help center, do they tend to upgrade more? Do they tend to expand the number of users on their account? I'd say those are the major metrics that we have been tracking though this remains very much a work in progress.

You said something earlier about digging into how often a certain article in your help center is used and that data informing future product decisions. That speaks a little bit to what we do at Guru in terms of knowledge, so how do you think about the data and knowledge that you gather through your help center as playing into your strategy?

That’s a great question. We always like to say that our one-to-one support informs our scaled support. So if we see an issue that is taking off in the community, like if a user posts something in the community that they want to know how to do something and we see that it’s getting a lot of page views, then we’ll actually upgrade that into a help center article and get it localized to drive even more traffic to it. And then, if I look at the ticket volumes, the same thing can be said. If we get a lot of emails about how to do something in the product, then we’ll look at those emails and think, “Okay, well does this make more sense as a community post or as a help center article?” So there’s kind of this graduation process where if we see a lot of emails on something, then it graduates to a community post. If that then gets a lot of traffic, it graduates to a help center article.

And then, we can measure the success of what we’re doing. So once we create this help center article, we can then go back and see if we got a decrease in those types of tickets because we’re now driving more traffic to the scaled support.

The last piece is around page views. Page views for us can often substitute for email volume. If we get a community post that is a feature request, we can show the engagement and page views on that community post and take that data to the engineering team and say, “Hey, there’s demand for this. Let’s get this on the product road map.”

Do you have any last tips for support leaders looking to scale their orgs like yours?

My other tips focus around how to recruit and retain top talent. A lot of support organizations have huge challenges in that their retention tends to be pretty low. One of the things that’s really allowed us to be successful is that our team retention is extremely high. In the last 18 months, only one member of my team has transitioned off, which is kind of unheard of for this field. And those individuals that have left my team in the last three and a half years have all stayed within Lucid and fed into other departments, taking the user insights they’ve acquired to other parts of the company. But I think if you empower people in the support organization to really take ownership of the top-level strategy, rather than just busting through emails or tackling phone calls, it really is empowering for them and helps them build skills that they can then transition into other arenas, whether it’s another role at the company or internally within the team.

That’s the thing that I like to reiterate time and again: include the team in as much of the strategy as possible, because ultimately that’s going to be what keeps them excited and passionate and growing.

What a great way to end. Thanks so much for your time, Keyvan! How can our readers get in touch with you if they have questions about your support philosophy or Lucidchart?

You can connect with me on LinkedIn.