Scaling Empathy: Support at Sanity.io

At Sanity, there are seven values that underpin everything we do. Of these seven, empathy is the most important one for support. As people learn about Sanity, they may first hear about concepts like structured content and content as data. They may also be new to the wider ecosystem, implementing a headless CMS, static site generator or front-end framework for the first time. They may even be completely new to programming. As people navigate these unfamiliar territories, we believe the need to be heard and understood is important - particularly at a time when people are also adjusting to other circumstances such as working remotely in a post-pandemic world. Empathy allows us to connect with people’s feelings, thoughts, and attitudes, sometimes beyond the support question itself.

However, empathy is notoriously difficult to scale. As our organization, community, and customer base grow, it becomes more challenging to have meaningful interactions with every single person and to convey their concerns internally to other teams so they too can engage empathically with our users, albeit indirectly. A tension emerges between the need to run efficient support operations and the wish to maintain the casual and personal character of our current efforts. Yet, equipped with a Sanity Content Lake and a flexible Sanity Studio, we set out to create the support infrastructure needed to run an empathic support organization at scale.

This article lays out how we reason about support at Sanity. It is secretly written for anyone looking to join our support team, so if that is you, we hope it inspires you to get in touch.

Six Areas of Responsibility

Sanity’s support organization covers six areas of responsibility, as shown below.

1. Customer support – Help people succeed
   Drive customer satisfaction by providing first-class technical support.
2. Customer self-serve – Help people help themselves
   Develop and maintain a high-quality and comprehensive self-serve support portal.
3. Reporting – Help understand what we should optimize for
   Maintain a metrics-based approach to support performance, signal, and customer satisfaction.
4. Operational excellence – Help improve our product
   Identify technical escalations when necessary to help Product and Engineering improve the product.
5. Incidents – Help manage uncertainty
   Ensure incidents are identified early on and that we communicate to our community and SLA clients while resolving issues.
6. Enablement – Help us help others
   Develop infrastructure and automation to improve our support processes.

Each of these areas is heavily interlinked with others. For example, while we do customer support we identify common themes in our answers, which we then turn into knowledge base entries or self-help resources, which in turn reduce the load on support as people can now find these solutions themselves. Support tickets may also uncover a need to improve our onboarding to the platform, producing important signal that we can report to other teams. This may trigger a new initiative that improves people’s first experience with Sanity. A feature request filed on GitHub may be discussed in our Voice of the Consumer meeting and subsequently placed on the roadmap. Once released, this new feature may then lead to new support requests, bug reports, or documentation improvements as people start implementing it in their studio.

Many Channels but Mostly Slack

As a support team, we cover multiple surfaces, including external platforms like GitHub, Stack Overflow, or Twitter, web properties like the Exchange and documentation section on our site, and channels like Slack, email, and phone. Among all of these, Slack is by far our largest and most important channel. We use Slack for enterprise support in the form of dedicated channels that we share with client organizations. We also host our community of over 17,000 developers and content creators on Slack.

On Choosing Slack

Our choice to run most of our support on Slack was deliberate and can be summed up in three advantages that all tie into our vision of empathy in support.

Proximity
Slack allows us to meet people where they are. For enterprise clients, this means having a dedicated support channelthat is shared with their organization, so we can easily interface between developer teams and loop in people on both sides.For the community, because many people already use Slack for their own work, it means having us just a single click away as another workspace. It is like having us in the next room rather than needing to get all packed up, unlock your bike, and make your way to a distant forum. The context switch is smaller.

Informality
As a platform for real-time group messaging, Slack combines the relaxed and friendly nature of chats with the advantage of having more people in the room to get help and learnfrom. It is particularly suitable for community-building. You can see this in the way people cheer each other on in channels like #i-made-this or in the way conversations naturally extend beyond our content platform alone. We have specific channels around topics like content modelling and content creation, use cases like asset sourcing, localization, and migration, and front-end frameworks like Next.js, Gatsby, and eleventy. Channels come cheaply with Slack, so we have a bias towards saying yes when users suggest a new channel to see if a niche community shapes up.

Efficiency
Compared to more traditional platforms like web forums, Slack also offers a more efficient way of communicating.

Challenges

However, it’s not all bees and butterflies. Slack comes with its own set of challenges, especially when a community grows beyond a few thousand people as we are currently experiencing. For one, it becomes harder for people to hear above the noise. As the volume increases, it also augments fear of missing out as even regular users struggle to keep up with the influx of new messages. As a support team, we also struggle when juggling a growing number of channels and tickets using only Slack’s built-in tracking tools. Even the most seasoned Support Engineer may miss a Slack reminder or oversee a saved thread.

Additionally, anything that happens on Slack, stays on Slack. If you are not part of our Slack community, you are literally missing out on thousands of helpful threads and a vast community of developers that could answer your question. This may read like an ad to come and join sanity-io-land (and why not, please join!), but the point here is that nothing is available outside of Slack. To make matters worse, Slack applies a 10,000-message limit on its generous free offering, meaning that even if you are a member, you will miss out on any answers that lie beyond the 10k horizon. And because the community is growing, this limit is a smaller time window every month. Today, it means having search access to roughly 7 weeks of history.

To capture the value of all the contributions people generously make every day, we had to find a way to move beyond Slack without deprecating the Slack community itself. In the next section, we will show how we use tooling to mitigate the disadvantages.

Home-Grown Tooling

We recognized early on that we needed a separate system to track and triage incoming tickets from Slack. In early 2020, we tried an out-of-the-box solution but found it too noisy and unwieldy for our taste. Instead, we decided to build our own as part of a company-wide hackathon. In less than a day, we were able to put together a Slack integration that let us track Slack messages and their threads as a ticket in the Sanity Content Lake by placing a [ticket] emoji on it and then mark the ticket as resolved by adding a [resolved] emoji.

Community Studio and the Exchange

Throughout the year, we extended our tooling to what we dubbed the Community Studio, although it was just an internal tool at the time. In Q4 of 2020, we decided to open this studio for the entire community and reshaped it to power the newly published Sanity Exchange – a home for the community on our site. The Exchange currently holds over [x] contributions and the Community Studio now functions as a bridge between Slack and the Exchange. As part of our efforts, we also ran a successful experiment to publish a batch of Slack threads on sanity.io/answers to see if they would get indexed by search engines to provide more value to the wider community and ecosystem.

[figures 3 and 4]

Throughout 2021, we realized our efforts were still too fragmented. Although we had a good grasp of what happened on Slack, none of the activity captured there was easily linked to bugs and feature requests people kindly filed on any of our public GitHub repositories. And even if we found a connection between the two, it required yet another manual step to enter the resulting work into Shortcut – our project management tool – for our engineering teams to pick up. Finally, if something made it through that cycle, the disjointed nature of the process meant there was no clear signal going back to the customer-facing teams notifying them to loop back to people having originally brought up these issues.

Enter Hyperdrive

We set out to build a single source of truth that would help tie together all our support efforts in a wider sense. The project’s objective was to use our existing content platform to create an integrated workflow where we could track support tickets, tie them to synchronized GitHub issues, and easily enter them into Shortcut, with the advantage that any updates in one step of this process would automatically spread to all other parts. The result is called Hyperdrive.

We're Hiring!

If our approach to support resonates with you and you would like to learn more about our open positions, please DM @Peter for a chat. Currently, we have these open roles:

• Support Engineer (EU, US, Remote)
• Full-stack Engineer, Support (EU, US, Remote)

In part 2 of this series on support, we will dig deeper into the technological implementation and will open source our Hyperdrive studio.