At Keen IO, we have individuals from every team — Engineering, Infrastructure, Web, Developer Community, Customer Success, and People Team — doing support. We use the term Support Pool to describe the pool of people who are running support at any given time. Being dedicated to helping customers on Support Pool means that we don’t have regular meetings or work on our regular projects. We’ve experimented with ways to create a schedule that works for everybody, but the basic idea is that we have a dedicated, diverse, and cross-functional subset of the company to support customers.
As a result, support is super personal. If a customer wrote into our Intercom system or reached out to us via email, they would receive a response from a real human from Team Keen. This is awesome for our customers, and helps reinforce that authenticity, a core Keen value, is important to us.
Why does everyone do support?
If you’ve ever read “The Ten Faces of Innovation”, the book talks about how individuals and organizations need to constantly gather new sources of information to expand their knowledge and grow. The first of the ten faces is a learning role: the Anthropologist. This persona’s goal is to remind everyone what’s actually going on from our customer’s perspective and exercise putting on our customers’ shoes. Adopting some of an Anthropologist’s learning persona helps to keep your team from becoming too internally focused, and remind the organization not to be so smug about what you “know”. It can be all too easy to be blinded by one’s own biases and beliefs and end up missing the point. By dedicating time for this anthropology, each individual is empowered to see the business holistically, and is reminded that our business exists to provide value to our customers.
To further drive this point home, our CEO Kyle Wild wrote this in an all-hands email:
When the “customer” is just some abstraction out in the distance, it becomes more and more abstract, and less accurate over time. On the other hand, when the “customer” is a collective persona — a mental model in progress — based on interactions with hundreds of real live human beings, it gets more accurate over time. And when everyone in a company has an accurate (and increasingly so) mental model of the customer, there’s magic.
That’s why at Keen IO, customer support is part of everyone’s job, and I hope it always will be.
Turns out there are also lots of other beneficial and positive reasons for people from many roles in the company here at Keen IO to do support. We’ve found the following three to be particularly salient.
- Individuals from separate teams get the chance to work together, share knowledge, and get to know each other better.
- Product design and development is always informed by direct customer feedback, and shortening the feedback loop.
- Everyone feels responsibility for our collective internal and customer pain points. When everyone does support, everyone contributes to making support (and our product) better and easier.
Iterating for Success
Because we believe firmly in authentic, human support, we have people from every team at Keen doing Support Pool. But this doesn’t mean that we haven’t evolved to make Support more efficient.
A long time ago, we once used a Google Group to serve as our main method of Support at Keen IO. The group served as the main point of contact to us for current and prospective customers. It functioned a lot like a forum, so it also had the unfortunate habit of emailing everyone in the company whenever a message was sent or replied. Because everyone on the team was on the email list, that meant every team member received every piece of inbound customer communication. Customers received excellent customer support: messages grabbed the attention of everyone in the company, the expert on that topic could respond, and the responses were quick.
This system, however, had some obvious downfalls — whenever the customer base scaled and we gained more users, there were more questions, more messages, and scaling our team became an issue. We found that this system demanded attention away from projects and was also very distracting every day.
We had every-single-person on Support, and eventually it really acted more like no-single-person was. Everyone still had their day-to-day tasks and it grew difficult trying to figure out big chunks of time for work. Then worse, as ticket volume and our customer base grew in parallel, our customer’s tickets were sadly sometimes forgotten.
This is when we decided to change things.
Instead of the entire team, we have a dedicated subset of people who are running support on a particular day. Being dedicated to helping customers on Support Pool means that we don’t have regular meetings or work on regular projects. And we schedule each volunteer for our shifts so that it is at a convenient time and has a dedicated calendar date. We have a partner on each support shift and the time spent feels like a special project and acts like a rotation. The shifts are scheduled in a way such that support runs every other work day. We learn about where in our product our customers are experiencing problems, hang out with someone from a team different from ours, and also take the wheel on using our own platform from someone else’s eyes. This teaches us a lot about empathy.
Because support has at least one person’s full attention on their Support day, tickets are not forgotten or dropped on the floor. We also selected Intercom as our support tool that helps us track and account for incoming messages as well.
By adjusting the format and layout of Support Pool and selecting the most appropriate platform to organize support, we were able to become 100% more efficient and choose a tool that provided the ability to answer 3x more tickets.
Scaling Customer Support
Before you can begin being truly effective at scaling your support processes: do me a favor and write it down. All of it. How you answered a previous customer’s question, when did you decide to pass the question along to your engineering team? Where do you store and send feedback, what kind of support volume do you get?
The single most powerful support tool we created was documentation. Internally, we create helpful articles for each other such as: “How to Answer Questions Effectively”, “A First-timer’s Guide to Support Triage & Escalation”, and “Common Requests”. By leveraging a library of internal documentation and frequently asked questions, we’ve helped make the time spent on Support Pool more effective. Additionally, we started a brief “Intro to Support” class when onboarding our new hires. This time spent on education helps new hires feel familiar and comfortable with our product and therefore also empowered to help our customers. In our internal documentation and education, along with going over support tooling and how Keen works, we also let the team know the reasons why everyone does support (the exact topic you’re reading now 😛)!
We’ve invested a lot into creating external-facing documentation as well. By updating and maintaining our SDK libraries, writing guides and helpful blog content, we help our users help themselves. In our support platform, we’re using an Intercom feature called “Educate” which allows us to create a searchable, FAQ-style knowledge base for our customers as well. Having good documentation not only helps mitigate the need for support, but when we are helping customers it is helpful to have a resource to supplement an answer and have a reference to point to that they can re-visit over time.
Developer content must be insightful, reliable, show how and why an application works, and always: helpful.
No matter how many features you have: your product is only as good as it’s documentation. Documentation adds value to your product and helps facilitate ease of use for your product. Since a well-documented product is easier to use, it is therefore more valuable and useful.
The End Goal
There’s nothing like the feeling you get when you have successfully delivered a high-level support experience, helped a customer, and receive a compliment like this:
“It was really easy to get started, and I am already making meaningful discoveries with the queries I have created.”
This is why we work so hard to deliver a high-quality developer experience. This one also makes me blush 😊
“I don’t have any questions. Your documentation and examples look very straightforward and easy to implement!”
They engaged with us, just to tell us we’re awesome! With that, well we’re going to keep working hard. Having an API product and strong documentation is a reputation we’re proud of and will keep living up to.
In closing, here at Keen we’ve created some amazing developer tools to help companies build data streams, compute, and customer-facing dashboards into their own products. My team and I have spent a lot of time developing support tools and writing quality documentation about our analytics API Platform to enhance ease of use but very importantly to also provide our developers with a great experience.
We believe in investing in creating relationships with our customers, and keeping it human. At the end of the day, when you talk to a human at Keen, know that it’s someone real that is interested in helping you.
Calls to Action
- If you liked this article then recommend it by clicking the heart 💗
- If you feel inspired, share it with your own teams on Facebook and Twitter. You’ll find me on @jandwiches 🍞
