How to scale community support for APIs

Transcript of Josh’s talk

Hello and thank you for coming, and thank you for that wonderful welcome. My name is Josh Dzielak, and I’m a developer advocate at Algolia. Developers use Algolia’s search API to build the search features of their websites and mobile applications. And inevitably, some of those developers get stuck.

They hit a wall. And sometimes they can’t find an answer using documentation, Google, or Stack Overflow. What they need is to talk to a human. And what they need is to start a conversation. Now, at scale, when your API or developer tool is being used by thousands of developers, that’s a lot of conversations. And that’s too much for one developer experience or one developer relations or one customer success team to handle. But that’s where community support comes in. Community is a great way to scale conversations.

A community support program can address the needs of a large heterogeneous group of developers, and for whom paying for private email one-on-one support just isn’t going to work. Now many of us as makers of API’s and developer tools, we do offer some sort of community support for our free tier developers. But the question is, what do we mean by community support? And then how do we deliver on that promise? And so that’s what I’m gonna talk about today.

Community support at Algolia

I’ll tell you what community support means, specifically, at Algolia, and I’ll talk about the tools and the processes that we have in place to scale it, and then I’ll talk about how we use outreach to get more people involved. And eventually, our goal is to cross that chasm from few to many support where it’s a lot of us and a little bit of the community to where it’s a lot of the community helping each other.

So first, we need to talk about what community support does not mean. Community support does not mean good luck on the Internet. Community support does not mean ask your question on Stack Overflow. Stack Overflow is for programming questions only. And that’s just a small subset of questions related to APIs. If too many non-programming relating questions get asked on your Stack Overflow tag, the mods will flag you, and that actually happened to us earlier this year.

API support is not just about programming. And unless you provide detailed information about how you plan to support your users on Stack Overflow or any third party site, you’re sending a mixed signal. But the reality is that many companies just don’t do a great job at responding to open Stack Overflow questions or open questions on GitHub, even their GitHub issues. And so there’s a skepticism. When you say, “We’re gonna support you on Stack Overflow,” there’s a skepticism because there are a lot of companies that just haven’t lived up to that promise.

Also, on any kind of third-party site, you don’t have full control. If there’s a bad actor, say, someone asks a question, and an honest and fair question about your API, and then someone else from the community comes in and says, “Oh, that’s obvious. That’s a dumb question.” You have very little control in a third-party site. You can flag it. You don’t know if the mods will remove it. You can’t really guarantee the developer experience.

So if you, fundamentally, if you don’t control the support site, you don’t control the developer experience. And if you want the most control over your entire developer experience, then just like you host your own docs, you wanna host your own conversations. And so by carefully creating and maintaining a space for your community, it shows that you have a true commitment. And if you eventually want the community to commit, you have to do it first.

Own your support space

In December, Algolia launched our first wholly-owned community support space. We chose Discourse to power it because it’s open source, because it’s deeply customizable, and also because it has web books now. So what about timing? Why did we release a community forum last December? So we had grown a lot in the previous year. And we were starting to feel a lot of growing pains in our email support process, particularly, with users of new integrations. We had released integrations at that point for WordPress, for Magento, for WooCommerce, for Shopify, for Zendesk, and this is a brand new type of developer who is coming to us for support. And not usually a paying developer.

These are a lot of people experimenting with the integrations. And it created a ton of private support in email. And the problem with doing that in email is that nothing really ever gets better. And that’s because what happens in email support stays in email support. It doesn’t create content. It doesn’t help you deflect future tickets. And it practically, I mean, it does guarantee that you’re gonna have to do the support, and there’s no way for someone for the community to be involved. So we’ve had a lot of success in the last six months, particularly, with a few of these integrations and actually reducing the load on the team that’s building them.

So, in WordPress alone, we’ve seen about 88 topics be created and then it has led to about 400 posts. And for six months of activity, I think that’s pretty good because we’re starting to see something very important take place, which is community members answering other community members questions. And for us, that’s really the milestone where it’s the leading indicator that you’re actually gonna be able to build a successful community.

So here’s this KPI again. What percentage of questions are answered by members in the community? So you have to measure this. And ideally, you measure it with some segmentation because it will be different based on the sub communities within your community. It might be the case that you have Ruby developers who are actively helping each other, but on the PHP side, maybe you’re having to do it all, and maybe no one in your community has a commitment level high enough yet where they’re helping other people answer their PHP questions.

So it can really depend. And that’s why segmentation and understanding what’s happening is very good. So we couldn’t find something existing that did the kind of segmentation that we would want to figure out these KPIs, so we built a little bit of our own tools. So here’s a quick look at our Algolia community tech stack. It’s basically some open source projects and some Sass API services that we use. And this represents how we listen to activity that’s happening in the community, and then how we respond to it, whether that’s a manual response or whether that’s an automated response.

Automation

So we’re using Zapier to listen to Stack Overflow RSS feeds. And then when that happens, Zapier sends an invitation to web tasks. So we have a lot of web hooks running on Webtask, and we’ve had a lot of success there. We’re at DevXCon so I should really congratulate Webtask on having a great developer experience. It’s really nice if you haven’t tried it out, very lightweight, function as a service. And as I said before, we use Discourse, we have Stack Overflow, we also use Help Scout as our sort of primary support tool. And Help Scout has an API and it also has Web books so we get to plug it into everything we have.

We do use a bit of Algolia to make community member information searchable if we need to go back and type someone’s name in because we might want to connect them with an opportunity or with another person. We use Keen IO for the analytics. So every time something happens in the community, we turn that into JSON, we added lots of properties to it, everything that we might know about that interaction or that community member, and then we log it. And that is something that we can make dashboards out of later and it’s something we can make triggers out of later. And then we use Slack. For sure, we have a variety of channels that we’re putting community activity into.

So here’s an example of one of the dashboards that we’ve built just using the tools that I showed on the previous slide. This is using Keen IO’s Responsive Dashboard Templates Library. And we, you know, the nice thing about all these APIs in tools it just took us a little bit of time to put together a quick view at the metrics and the KPIs that we want to collect, and do it in a way that’s fun to work on. And we actually invite other engineers in the company to come and contribute to this repository. And eventually, we’d love to open-source a lot of the work that we’re doing here.

So, of course, it’s important to be able to measure KPIs, but the next thing is you have to move them. You have to change them. And what I think the community support chasm is, as I mentioned before, is how you go from few-to-many to many-to-many. And few-to-many where there’s a few of you, maybe a few developer advocates, maybe a few advocates and a few of your engineers who just like to hang out on the forum, and how do you move from that to actually a self-sustaining community that answers a lot of its own questions.

Some to many

So to go from few-to-many to many-to-many, there’s a step in between that I call some-to-many. And so you start small. You wanna add some key people into your few bucket. And one of the best places to start looking for those people is inside of your engineering team itself. I think it’s critical that you have to get the whole community involved…I’m sorry, the whole company involved in your community and particularly in the community support process because you will never have enough time.

Developer advocates do not have a subject-matter expertise in every topic that’s going to be open on the forum. There’s no way. So you have to be able to spread the load around. So if you’re thinking about setting up a forum at your company, that’s something you should really think about. How am I gonna get everybody in the company involved? So I can tell you a bit about how we’ve done it.

All members of the team do support at least once

So one thing we do in Algolia, new employees join the forum during their onboarding. And so for everyone who joins the company, we have some onboarding tasks that they do in their first week, and we’ve added joining the community and joining the forum to that. And one nice thing we do is we have everyone introduce themselves. So if you want to go read all the introductions, I think we have about 70 of them there today, and it’s just people, both employees and community members saying, “Hey, I’m here. This is what I’m working on. This is what I do. This is what I can help you with.”

And it’s just a nice way to get people…a simple way to get them to create their first post and increase their commitment and their interest level just a little bit. So that’s nice to get people engaged the first time, but then there’s the other question. How do you keep them engaged over time?

And how we’re doing that and Algolia is by plugging into the primary support process, sort of the primary customer success process as it comes to technology questions. So here’s what it looks like in Slack when a new Discourse topic is created. We don’t use the default connector. Discourse has a great plugin for sending messages to Slack, but we do a couple of things that made us want to build our own. One is that we have the email address of the person, and you can see it’s kind of blotted out here for obvious reasons, but we can actually trace when someone…well, put it this way.

When someone opens a ticket on Discourse, we also wanna know if they’ve been involved in private support before. We wanna know if they have open Help Scout tickets. Maybe they did private email. And then they came to the forum to try to answer the same question. We want to know that. And so part of why we wanted to build some of this stuff ourselves was to get that extra level of visibility. We also do things like pass tags and category names all the way from Discourse in to Help Scout. So even in Help Scout, you can do analytics or filter or search by tags that people are using on the forum, which is pretty cool.

Share cool content on the forum

So another way that we keep employees engaged over time is that we ask them to post new topics on the forum that maybe was something they would have just shared internally before. So a great example of this is an event summary. We have a lot of engineers and non-engineers that go to events. And we had a wonderful tradition inside of the company of sharing the outcomes of those events in an email that everyone would send to the whole company. And when I saw that email from a few people, I said, “Why can’t this go on the forum? Why can’t we also share this update, share what we learned at the event, share how we felt about it with the rest of the community?”

And so now, it’s basically a standard practice. Sometimes they still have to ask and do a little bit of nudging as developer advocates and community builders tend to have to do. But in general, if you go to the events tag now on our forum, which is where this link maps to, then you can see where our Algolia people going, what events are they attending to, what’s their take. This one is for HackBordeaux show, a wonderful MLH sponsored hackathon a few weeks ago in Bordeaux. I heard there was wine tasting there at a hackathon. How nice is that? Super cool. I wish I would have been there.

Let’s see. So getting the company involved in community support is essential, but it’s still just one part of the story. We’re still only at the some too many phase. Remember we want we wanna get to many to many so we’re gonna need to do more. And we’re going to need to do outreach. And this is the thing I think that people underestimate how much you actually have to do to get to the many-to-many stage. Outreach means asking individual community members to respond to a question that you think that they have an answer to, or tell them about a topic that they might be interested in. That requires a ton of knowledge about the community member. It requires a bit of a relationship.

And so outreach is time-consuming. It can be emotionally draining because every time you ask someone to do something for you, you feel a bit vulnerable. It takes a bit of your energy. Like, what if they say no? So I think you have to build tools to make outreach easier, and you have to build the tools that make outreach a bit more automatic. And so, to that extent, I think you can build an outreach toolkit that has a bunch of tools in it that you can use.

Templates are effective

Now the first tool I’ll tell you about is not very sexy, but it’s very effective. Templates. Very simple. You can get a lot of time back if you’re doing a lot of personalized responses in your community for the same thing over and over again, just use a template. It’s much easier, will save you lots of time, you can still keep things personal. But I think that’s a very quick win, very easy. You don’t need any technology for that. Help Scout has a saved replies feature, and we take advantage of that quite heavily. So in each of our mailboxes, we have saved replies. Someone chimes in, you hit a button, and then a reply goes out. It’s very easy. So it’s personal, but it’s easy.

The next tool in your outreach toolkit is search. Again, you wanna be able to search for community members. You wanna be able to pull them up by tag, by programming language, framework, location. If someone on the forum asks a question about go about GoLang, you wanna be able to connect…you want quickly to be able to find someone else in your community that knows that and put them in touch. Let’s see. And I’d also recommend including some activity metric in that process so that you know when you’re reaching out too frequently to some members or you know when no one’s really been reached out to.

Incentives

So in addition to the knowing what the skills of those people are, you also wanna know how committed are they in their community and how much should you be asking them. So the final tool in the toolkit here, and there could be many, I’m just pulling up three for us today, is incentives. So you wanna make this part really easy. You wanna make it easy to reward the community for participation. You don’t wanna have to take 20 minutes of your time every time you wanna send someone a t-shirt. You really need to automate that. If any of you want swag right now, by the way, you can use our automated forum, which is just at the bottom of the thing.

You can also just go out to our table and grab some, but depending on what you like to do, or what sizes we have, if we don’t have any sizes over there, then just right here for you. But I think, for us, it makes it so much easier to offer something to someone when you know that you’re not gonna have to take 20 minutes of your time. That will never scale. I think we’ve had about 500 t-shirts go out just in this forum in the last maybe five or six months and since we set it up, and we just have a small link to it on our developer portal, but people find it.

Reach the right person at the right time with the right incentive

So, this brings me to my final point, which is that there are many ways to do outreach. These included. So you need some principles to guide your decisions on what you’ll do. At Algolia, we have a very simple framework, three keys, we call to a successful outreach. And it’s about reaching out to the right person at the right time with the right incentive. The right person means choosing the appropriate person to get involved based on their skills, interests, or location.

The right time means asking with the right frequency. Don’t overwhelm someone. Don’t ask them for help twice a week. That’s probably too much unless they’re really really dedicated. But you also don’t want months to go by before you reach out to someone who could be a champion because you probably lost some opportunity there. So the right time matters. The right frequency matters. And the right incentive means trying to overmatch contribution with recognition. And don’t be afraid to say, “Thanks,” in a big way. You should take whatever you’re thinking about how you wanna say thank you and double it, and that’s a good rule of thumb to follow.

So I think if you can learn how to do good outreach without it taking up too much of your time, then I think you have the best chance at crossing the API community support chasm, going from few-to-many to some-to-many all the way to many-to-many, the thing we all want. Thank you.