Emily Chapman is a Support Specialist for Trello. She previously worked for MailChimp and Mandrill. Her professional blog is available here. She likes writing style guides, performing improv, and spending an inordinate amount of time on Twitter.
When the Trello support team received news that the company was going on an all-hands retreat to Puerto Rico, we were psyched. (Who wouldn’t be?)
But right after that excitement, panic set in: how were we going to manage to answer support tickets during the retreat? We didn’t want to make the Support team work when others were having fun, but we couldn’t leave our customers hanging, either.
Our solution was to create an all-hands support training crash course. If employees passed, they earned the distinct privilege of helping out the Support team whilst on vacation! (And our eternal gratitude.)
What originally started as a response to immediate needs for our retreat turned out to be an unexpectedly great way for our engineers, systems gurus, and managers to gain more individual empathy for our users and direct knowledge of just how frustrating pain points in the app can be. We realized that product design improves when as many members of the team as possible have a chance to experience queue work and other one-on-one user interactions.
Things generally went well—but, as with any first-time project, we definitely would have done some things differently in retrospect. The general format of our training was that volunteers would undergo a one-hour, self-managed training course with multiple-choice quizzes (machine-graded) and would write a few sample responses (human-graded by me).
Our basic idea was solid, but the system we chose to manage the course was frustrating to administer and confusing for test-takers, which we learned from post-course feedback. If we could start from the ground up, we’d go with a different course management system with better reviews (possibly even a paid option). In particular, we’d want something that made it easier for users to sign themselves up to take the course.
The other big lesson was to adjust expectations around background skills for training materials. The majority of the content in the training was pulled directly from the onboarding materials that new Support team hires receive as part of their training.
Though not intended to be daunting, I received reports from multiple test-takers that they found the example responses overwhelming because they were substantially different from how they were used to writing. An engineer who mostly writes to-the-point internal bug reports is going to have a different context than a marketing person whose tone and style is upbeat and cheerful, and they’ll be worried about different things going in.
Having trusted colleagues from other departments write example responses may have been a better option for this specific training.
Of course, I wouldn’t be writing this post if I hadn’t been able to get buy-in on the all-hands training concept from within Trello. Every company is different, but in our case we benefitted from having buy-in from high level executives before we started designing the course. In particular, our VP of People was the first person to give the go-ahead on setting up the training. If you’re setting up all-hands support, I strongly recommend top-down buy-in so that you can feel comfortable recruiting colleagues to the cause.
In our case, having buy-in from the People team meant that we got a space on the retreat schedule (for concentrated bursts of in-person Support time), and were given the option to talk about training at our once-a-month all-hands meetings.
In terms of who to ask for help actually handling support tickets, in our case we benefitted from having a significant number of engineering, systems, and product team members joining us. After confirming that we would have buy-in from our people team for the retreat, we announced the recruitment effort at our all-hands meeting (since that’s when the entire company comes together). Additional recruitment happened in the form of periodic posts in the Slack channel devoted to the retreat.
We welcomed everyone, of course, but (in our case) having people who actually build the product see what people’s feelings are had a huge impact on empathy for a group who could actually make later changes (and have!).
As an added benefit, these particular colleagues had access to production data and general knowledge about how the app works, which meant that they were fairly self-sufficient in terms of the content of their replies. That gave us space to focus on making sure that tone was on-point.
Even though everyone who participated was a volunteer, I still heard from a few folks that they were nervous about the quality of their writing. It wasn’t warranted (as far as I can tell, everyone who works at Trello is a phenomenal writer), but it was totally understandable: thinking back to my first support job, I remember being petrified that I’d tell an end-user something wrong, or tell them the right thing in the wrong way.
So, to help the nervous participants, I scheduled two practice sessions for the group. Each one lasted for an hour. During that time, the group hopped into a Zoom call, and I had them all head into the support queue. They began to pick cases for themselves that they thought they could answer, and wrote out the responses.
Any time someone was unsure about the response or wanted help with phrasing, they brought it up in the group video call, and we hashed it out. That way the whole group was able to learn, and to contribute their ideas about what they might do.
That prep session meant that by the time we were in Puerto Rico, the group felt comfortable during our in-person all-hands support sessions. (You really haven’t lived until you’ve seen a bunch of startup employees in their swimsuits, typing away on user responses.)
Increased Empathy For Users
The all-hands support program meant that the Trello Support team was able to enjoy as much of the retreat as possible, and—more importantly for future plans—was an unexpectedly great empathy exercise for our participants. It was truly heartening to see product engineers get mad on a user’s behalf when something wasn’t working right, or to dive headfirst into the database to see why a board wasn’t displaying.
The increased user empathy from employees, the people who have the ability to make changes to the product, was hands-down the most unexpected benefit from all-hands training. Support can collect user feedback and advocate for users until the cows come home, but we’re not able to actually make changes to the product.
Even the most empathetic engineer (and we have a lot!) is going to be more moved by speaking directly to users than reading a feature request ticket built by Support. Data is important, but so is direct empathy from non-Support teams—combining them is a powerful one-two punch.
We had a few major requirements for our training: it had to be mostly self-administered, and it had to be mostly machine-graded. Since I was still in the queue during the day, we needed to have something that could train as many people as possible without my needing to be physically present.
This meant that we settled on some in-house best practices that I’d recommend to anyone trying to implement all-hands training:
- Training should rely on typed exercises and multiple choice quizzes, where possible. Save human-reviewed answers for writing exercises.
- When prompting trainees to write practice responses, have them edit bad responses rather than start from scratch. This helps conquer the fear of a blank page, which is common among first-time writers.
- Edit any auto-responders to let users know that the people answering emails may not be support agents.
- Rely on volunteers when first configuring the program. Universal participation is a goal for an established program, not getting something off the ground.
And it seems like it paid off! Checking our happiness stats on the plane ride home, I saw that every single one of our all-hands participants received a perfect 100% satisfaction score. And the feeling is mutual, as one of our engineers told me, “It was really rewarding to actually take some cases because of the ability to directly interact with our users, especially if it was in regard to something I had been responsible for making.” Job well done.