This year, I’d attended Post Status Publish and WooConf, learning a ridiculous amount from other WordPress professionals at each. At both conferences, I’d been asked about team and support management by a few people.
At Publish in particular, I’d delivered a sort of meta talk on building and selling eCommerce software with Brent Shepherd from Prospress. We wanted to cover several facets of building products, from strategy and hiring to product planning. We had some really interesting questions from audience members during the talk and afterwards, and one of questions we’d been asked was what we found most helpful in building teams that maintained company culture as we grew.
At SkyVerge, we’ve grown pretty rapidly in 2017, doubling our team size since the end of last year (much of it thanks to growth in Jilt). Our company culture is vitally important, as we’re a team that values high performance, but also solving interesting problems and enjoying ourselves while we do it (sprinkled with the appropriate level of gif and meme-sharing). However, building that sort of culture while keeping a growing team on the same page requires a ton of planning and hard work.
Our on-boarding process was a major part of maintaining and actively improving culture while growing our team. We’ve found that having a lot of team documentation and knowledge-sharing has helped us keep both existing team members and new additions on the same page, so we ensure everything is written down somewhere:
- approaches to how we solve problems, from code style and structure to customer service tone guides
- how to leverage team benefits, like retirement matches or how to manage PTO
- what tools we use, why we use them, and what we’ve tried in the past
- among other “caches” of team knowledge.
As we’ve been doing a lot of expansion of our customer support team most recently, one of the things that many other conference attendees seemed interested in was our process in building a support tone guide. So let’s put the “culture while growing” and “support team management” concepts together 🙂 I wanted to share how we built a tone guide that fits us, what resources I found helpful, and to publish our company tone guide publicly as a starting point for others.
Delivering quality customer service is a vital part of our team’s DNA. “Be the solution” is one of our core values, and we aim to be the solution for our customers — even that means that a different product is a better fit.
Great support and customer service is also an important deciding factor in purchasing decisions. When we choose tools and products, customer service is a decision point for our team, so merchants looking for tools should have 100% confidence in us.
We wanted to be sure that not only were these values expressed in our customer service interactions, but that the way they were expressed was also in line with our brand. To add to this problem, we also have support several “kinds” of merchants and developers across several brands and products:
- We support beginner merchants, power users, and developers for our WooCommerce products.
- The same goes for Jilt: we work with everyone from merchants who just launched their first store to agencies managing tools for their clients and looking to help them drive more sales.
- With our Shopify apps, we tend to work more directly with merchants than with developers, but customer service runs the gamut there as well in terms of store type and technical proficiency.
To provide a great experience across these different product types and for different kinds of users, we needed to have consistent tone, and a good brand voice — this, in turn, requires a clear outline for the entire team as to what this means, no matter what product you work with, or what kind of users you work with.
When developing our tone guide, I pulled information mostly from a few sources. However, I’ve started a list of resources here that make for great reading on customer support.
- Buffer: Buffer’s Tone Guide is public, and I’ve borrowed shamelessly from it. Every time I talk to their support, they’re friendly and helpful. Sometimes I think they’re almost too cheery, so our tone is close to this, but a bit more direct. I especially like their notes on instructions and apologies.
Help Scout: I’ve stolen our “points of service” from them, which is sort of based on the Ritz Carlton, so I’m not 100% sure who to credit 🙂 Their Creating a Support Lexicon is a good framework to read to think about what’s important in your own guide.
After doing a ton of reading, I wanted to determine what was most important for us: what would be vital to ensuring our customer service was high-quality, but consistent across our brands as well? I also wanted to be sure our “voice” was consistent between support and public-facing content like our blog and newsletters (though admittedly I don’t think we do an excellent job of this yet, we’re still learning).
- First, I thought that outlining customer service values was going to be most important for our team. We want support to start in a place of understanding an empathy, which can be a great driver of good tone. This is where Help Scout’s influence came into play, so we built a “North Star” and list of values for our team.
Next, we wanted practical guidelines on tone and content — what to do as you write, how to provide instructions, how to apologize, how to set expectations. These had a lot of inspiration from Buffer, who does a great job with this.
Finally, we wanted a “negative lexicon”, or blacklist. There are some phrases that simply aren’t on-brand, and that don’t add the value we want to our communication. There aren’t many of these, but we do out-right ban some words like, “actually”.
And for the bonus round, an “unseen” component: it’s important to us to have all team documents editable by team members that use and read them. (More on this with respect to our team wiki from Catherine soon 😉 — we’ve moved it from GitHub for reasons related to this.)
Since most of our support happens in Help Scout, we opted to use a Help Scout docs site so that:
- all support team members can edit docs, as these are living articles that update and change
- docs should be able to contain code snippets (Help Scout lets you embed gists)
- some parts of the documentation can be public, while other parts of our field guide (like specific troubleshooting information) can be private
With those requirements in mind, we published the SkyVerge Support Field Guide. ????
While not every part of our field guide is public, our tone guide is, and we welcome others to use this to develop their own field guides. If you’ve created one for your team, we’d also love to hear about what you did, and what you found important while building it 🙂