You probably already know that Estimote is a developer-oriented company. But we’re not just building things for developers. We’re building things with developers. We’ve been fostering a community around our products for a little over two years now, and through those efforts have exposed over 50,000 people to our technology. These people are now a hive mind fueling product development. We wanted to share why and how we do it.
Why is the question
Why community? We’re working hard to push the boundaries of mobile with our Location Intelligence Platform but the history of technology shows that all innovations can be copied – and often are. Much more difficult to replicate are the relationships you have with your users. If people care about your product enough that they want to collaborate and contribute to its development, you’re in a pole position for two reasons. First, these users are so invested in you that the competitors will have a hard time poaching them. Second, you have the brainpower of a dispersed yet enormous hive mind behind the product.
And if you look at successful developer-oriented companies, the trend is clear. GitHub, Docker, Xamarin, Braintree, SendGrid, Twilio, Heroku, Stack Overflow, MongoDB. They all have a common denominator: community.
So that’s the why. As for the how, allow us to rewind to Estimote’s early days…
High time
It was late 2013. We were fresh out of Y Combinator, had just won TechCruch Disrupt Best Hardware Startup, and were on our way to raising a seed round from great investors. Good, right? Not so fast. All the awards in the world aren’t worth anything if you’re not satisfying your customers - and we weren’t. We had an inbox swollen with hundreds of unanswered inquiries from eager developers and customers. Sure, that’s a “good problem to have” – but a problem nonetheless. People were frustrated and we were risking losing them before they even really arrived. So we took action. The Estimote Community Team was created to repair and improve our relationship with developers and then expand into community building.
Customer service was the immediate priority. We decided that response time would be the primary KPI. First, because developers should be able to move fast and break things, which requires access to rapid troubleshooting. It would be a waste to lose an early adopter because they were stuck on an issue and their enthusiasm waned before we reacted. Second, because differentiating here is low-hanging fruit. The global state of customer service is dreadful. For most people a fast resolution to their problem is a delight, because it’s the opposite of what they’re used to. See for yourself:
We started fixing. To put the challenge in perspective: in January 2014, our support ticket backlog was several weeks long and our median response time was almost eleven hours. Unacceptable. Fast forward to June 2015 and median response time had been cut to 24 minutes, with only a few customers ever waiting for more than 24 hours for a response. That’s with six people and no use of autoresponders.
How did we get there? The answer is deceptively simple: process. We know, we know. Few words evoke as much eye-rolling and disdain in early-stage startups. We hate a bad process as much as anyone. A bad process is a set of abstract rules into which managers stubbornly try to cram reality. But a good process is a life saver. Good process is one you build around reality, considering both goals and resources. And it needs to be flexible. Change is constant and the process should evolve accordingly.
Process: Zendesk shifts, power hours, and an evangelist
We set a goal: median first reply time should be less than one hour. Then we looked at the distribution of support tickets over time to design the team’s schedule. But it wasn’t a simple calculation of if most tickets arrive at Time X then make sure everyone is present at Time X. The devil lies in the details. Our Community Team is in the Central European time zone, yet Estimote has clients all over the world. Plus there should always be overlap between shifts: if someone needs help solving an issue, we didn’t want to leave them hanging. And no one wants to work late shifts on Friday. And people go on vacations. And sick days catch you off-guard all year long. And we had to make time for the team’s other responsibilities (e.g., managing social media, hosting events, creating content, assisting our dev teams with QA, and more). If we weren’t flexible, the process would break down.
We spent weeks testing different schedules and processes, all the while measuring their effectiveness against our response time. We landed on a system in which every Community Team member rotates shifts. These spanned past normal working hours and also weekends, to ensure full coverage for our global customer base. We also set up Zendesk shifts. While on a Zendesk shift, you were responsible for replying to a new inquiry immediately. But with over a hundred tickets coming in daily, even that wasn’t good enough. So we instituted power hours twice a day, during those periods our data told us were the highest traffic times. During a power hour it’s all hands on deck for support.
That worked really well for 90% of inquiries, the easy ones. The rest were trickier. They were often from developers further along in their development cycle with Estimote and often required us to consult with our engineering and product colleagues. These were the most rewarding tickets to solve. By helping a sophisticated customer overcome a complex issue, we seized an opportunity to provide a great customer experience and a moment of delight. But on the other hand, it’s also a temptation to disrupt the work of product teams with support tasks.
To balance that tension, we hired our first Technology Evangelist in mid-2014. You may have met him on Twitter or at one of a dozen of hackathons around the world. He not only responds to most intricate technical inquiries, but he’s also responsible for teaching the complexities of our APIs and SDKs to the non-technical crewmembers. This latter piece was key. Obviously one person could never scale fast enough with the growth of our community, so sharing knowledge internally to make the rest of the team proficient at answering technical inquiries has had a huge impact on our reply time and customer satisfaction.
Eighteen months of constant iteration on our process has paid dividends. That’s the evolution of our median reply time:
By the people, for the people
Having established a great process for customer service and achieving our main goal of driving down response time to less than an hour, our team was given an additional charter: go from servicing the community to building it. We’d already seen how quality support and a proactive attitude could yield outsized positive benefits, for instance via partnerships with companies like Xamarin and Evothings that bring iBeacon to thousands of non-native developers. Going further, we knew that as our community was growing, it was time to shift focus from talking with the community to making the community talk amongst themselves. It was time to harness the power of a hive mind.
So we created a new goal: rather than simply focusing on reducing response time, we wanted to reduce the number of inquiries by making support self-service. So we spent weeks drafting and updating content for our Knowledge Base. We renamed articles to improve search, merged overlapping entries, and deleted redundant posts. The changes made articles most important for beginners easier to find. Even more important was the creation of the Estimote Developer Portal. Officially launched in June, it has become the go-to place for resources about building apps with beacons. And this is how it grows as we populate it with more tutorials and documentation.
The Knowledge Base and Developer Portal succeeded in helping us educate the community, but neither impacted the number of incoming inquiries. What really moved the needle was the launch of Estimote Forums. Prior to March 2015, we only used a QA component in the Knowledge Base but it just didn’t work. The same questions would pop up repeatedly. Replacing the QA with forums (by the way, join here) made it much easier for people to find information and share their knowledge. Discussion between developers facing similar issues or brainstorming new ideas quickly took off, creating more value than we could have imagined. There’s also another benefit for us. Our Zendesk inbox is exclusively the Community Team’s jurisdiction. The forums, on the other hand, are actively monitored by Estimote’s engineers and product teams too. They now stay in touch with the community directly and understand their pains and gains using Estimote hardware and software. The hive mind works.
Just look at the graph showing evolution of the number of tickets and forums activity over the same period. Tickets go down 40% as the traffic on forums rises steadily.
Understanding the pains and gains is another thing we now focus on much more. Throughout 2015, we’ve been fostering relationships with our developer community by proactively reaching out to them, instead of waiting for them to contact us. We’re supporting meetups and hackathons all over the world. Tens of them this year. That’s more events than we can attend, so we often supply resources while the community takes care of organizing and evangelizing. It’s a testament to the relationships we’ve built over the last two years.
But we don’t just talk to developers at events. We talk to them all the time. With the abundance of data-gathering tools like Google Analytics, Heap, and Mixpanel, you can track everything. So we do. We track usage of features and then reach out to people. Why do you use it? Why not? How can we improve? If not for talking to people who had spent inordinate time shielding beacons with ovens and fridges, we never would have thought of features like Flip to Sleep. It’s as important to follow up when they release an app. We want developers to be able to share their success, so we feature their work on the Get Inspired page. We want them to get recognition whether they’ve built a simple hack or a whole new platform backed with VC money.
Lessons learned
Don’t think everything along the way has been rainbows and butterflies. Trial and error only works if you actually get some errors. We’ve learned a few difficult lessons that we’ve shared below. Though these may help your team, they also very well may not. The beauty (and the curse) of Community Management is that every group is different. One thing will work, the other will totally fail. All you can do is test.
1. It’s always about people, not tickets
“Wow, we’ve crushed 500 emails this week!,” a Community Manager might say on Friday afternoon. Impressive! But what happens if we swap the word “emails” with “people”? A massacre. When dealing with really big communities, it’s easy to forget that there’s a person behind every message. And when you don’t remember there’s a human asking a question, it’s impossible to empathize with them and deliver the highest quality service. It’s also easy to think the 10th person asking the same trivial question is an idiot. Fight this thought as soon as possible. Otherwise your brain will soon do a mental shortcut: inquiries = idiots. Rather than looking for flaws in people that write to you, search for the flaws in your product that caused the inquiry in the first place.
2. Don’t push it
It’s en vogue at startups today to be obsessed with speed. Fail fast. Deploy daily. Iterate immediately. This often translates well for product and engineering teams but can backfire when building a community. Despite the temptation, don’t try to shortcut the process of building an authentic and engaged community that not only wants to talk to you, but to each other. Community quality develops when users really understand your product. Community engagement develops when they acknowledge there’s a value in talking with other members. We all know dozens of strategies that help foster both - emails, direct conversations, gamification. But don’t push it and don’t do this:
Building communities is a marathon, not a sprint.
3. Aim for simplicity with all your internal tools
The example above isn’t something we’re doing at Estimote, but at one point we came close. With the proliferation of business tools in use today, each with their own API’s for integration (or services like Zapier), it’s tempting to want to design a flow in which your Zendesk talks to your Slack and creates a record in Salesforce and a card in Trello and sends an email to a Google Apps alias. Don’t do it. Almost always, those flows work better on a whiteboard than in practice. Start with simple solutions and only look to standardize them with technology when you know they work and are ready to scale. For instance, the easiest way to pass feedback to product managers is with Post-It Notes. Only turn to Trello and subsequently an API integration with a Zendesk widget after you’ve validated that flow over time. Keep it simple!
4. First, remove all pain points
When it comes to product development, it’s more fun to dream up new features than focus on fixing bugs or optimizing existing flows. It’s normal: features are sexy. But community managers need to remember that every obstacle a user encounters in your app, website, etc. is a wall that shields them from enjoying your product. And, by extension, from joining the community. At the end of the day, your job is to make your users awesome (tip of the hat to the Kathy Sierra’s great book). So empathize with your community and when discussing priorities internally, be sure to advocate for solving the pain points that exist today, before building the features of tomorrow.
5. Burnout is a normal thing, don’t fight it
We all know that feeling. The frustration when you’re looking at your next email. The weariness when you need to jump to another conversation, and you just don’t want to do it. As a community manager you will be exposed to complaints, problems, bug reports, and arguments. Even when you get tons of positive feedback, it’s the negative comments that stick with us and make our work hard. You can try to fight/hide/run from burnout. It will benefit you in the short term, but it will hurt your team and company in the long run. There is no easy solution. But one good thing you can do about that is a conversation. Talk with your manager, talk with your colleagues. If you don’t want to answer emails for two or three days, it’s fine. Everyone needs a break sometimes. If you tell your colleagues you need a rest and want to jump to a different project, you will avoid being accused of slacking or not helping your team. Be honest, it’s as simple as that.
Rethinking (with) the hive mind
With community building, you’re always only 5 percent done. And the remaining 95 percent changes all the time. The role of a Community Manager evolves with the community. Recently we’ve completely restructured the Community Team and moved several people to a new Customer Success Team, devoted to building lasting business partnerships. The Community Team is shifting its focus again to new goals and challenges. Good thing we have the power of a 50,000+ strong hive mind to back us up.
By the way, if you want to join Estimote Community Team and help us go from 50,000 to 500,000 and beyond, we’re hiring. Dare to join the mission!
Witek Socha, Community Manager at Estimote
Wojtek Borowicz, Community Evangelist at Estimote