Veggie Day: Customer support for engineers

At Buffer, we’ve been experimenting quite a bit with the support/engineer relationship. A high bar for support is one of the key pillars of Buffer.  We have three full-time ‘happiness heroes’ for a team of 10 and answer 60% of emails and tweets within the first hour.  Where we get slowed down are with the more technical issues that are reported, which require deeper investigation.

For a few months we had established ‘the 5 veggies rule’ where it was highly encouraged that each developer did five support tickets per day. The name was coined by Alyssa, where tickets for engineers can be thought of like vegetables–something you may not want to do, but they’re good for you and you need to do them.  This worked in keeping response times low, but it had major flaws.  First, I found myself measuring productivity by the number of tickets I closed.  This meant that it didn’t matter whether I closed easier or harder tickets since they were weighted the same in my mind.  So if I was in a hurry, I’d skip harder tickets for the simpler ones. It wasn’t in my best interest as a developer to dig deep into an issue as it would cut into my productivity for my regular tasks for the day.  When we hired our third Happiness Hero, Asa, our inbox pending average reduced, but it became clear that we needed a better way to tackle the tougher tickets.

We switched things up a few weeks ago, and while it’s a bit early to tell for sure, we think we’ve come up with something that works well for us. We call it ‘Veggie Day’ – an on-call rotating support day for engineers.  Our heroes carry on with their answering of tickets, and the moment they’ve noticed a ticket that requires much deeper developer investigation, they triage the ticket for the on-call engineer to work on.

This change overall has helped our effectiveness in tackling tougher tickets.  Some of the key changes and benefits from the developer side are:

Knowing that the day is dedicated to support

This has been important especially for me because I work well when I know at the start of my day what my goals are. Being in the zone is important, and that can be tough when I never know if/when I’ll be interrupted for fielding a ticket.  Specifying the schedule in advance allows us to have the expectation that a full day is spent on support and not other tasks.  And knowing that support is the goal for the day allows me to feel more productive.

Full focus on support

This gives me a chance to fully focus and dig deeper on a ticket. I no longer have the feeling that fully investigating a ticket takes time away from my other tasks. Some tickets require that time, attention, and persistence.  If I was worried about finishing my five tickets a day, I wouldn’t spend the necessary time to understand the full context of an issue.

Better understanding of our application

We also look at ‘Veggie day’ as a day to work on other stuff.  It’s sort of a wildcard day, we never know what area of our product we’ll be working on.  On any given veggie day, I may look at Payments, the iPhone app, Facebook oAuth, a Feedly integration and our image scraper.  It gives each of us an opportunity to work on and learn about random areas of our product, and as a team, our knowledge of the platform is solidified.  For example, Michelle and Hartley, who work on a separate internal metrics product, get a chance to learn and solve issues completely different from their day-to-day tasks on their Veggie day.

Talking to customers

Every engineer at Buffer talks to customers. This is one of the key pillars of Buffer culture.  We get an overwhelmingly positive response from customers who get a chance to talk to the developers who actually build the app.  They don’t talk to a ‘support engineer’.  Instead, when customers require more technical answers, they are able to talk to the engineers who build the product and who can push a fix in less than an hour.  This makes what is initially an annoyance for the customer a much better experience. They often leave with much more respect for the product than if they had never had the problem at all.  That is the power of providing awesome support.

While we’re only three weeks into this experiment, we’re very excited about the initial results.  I’ll be sure to post more details of how this is working out over the next few months.  We’d love to hear from you about thoughts and experiments you’ve done to better the relationship of engineering and support.