Category: Work

Tickets Non-Ownership: New Data!

I am lucky in that I have some seriously smart coworkers – working at Automattic is a constant gut-check; the level of drive, creativity and ability are at a very high level. It would be exhausting if it weren’t so inspiring. We’re all lucky to work somewhere where we’re given time to work on side projects – in fact, some of these side projects take the form of project-based meetups, where a crew of Automatticians travel to a new city, and buckle down to work toward a goal.

I’m secondarily lucky that one of these project meetups came to a close at the end of last month, and some members of my squad came home with some very interesting insights. They had spent a week diving into the mountain of data that we have on feedback from our customers, looking for correlations. What was most closely associated with happy customers? How could we better calibrate ourselves to what makes our customers happy?

Data!
Data!

Admittedly, this is not the cleanest data set: the feedback mechanism leaves something to be desired, and that is certainly on our radar. But, this is the data that we have, and after some validation and cleaning up, they came to a surprising conclusion:

Reported User Happiness was most closely tied to the length of time between our first response, and resolution. 

Why is this surprising? Because it turns out that the amount of time between a customer submitting a support request and when they first hear back from us is does not appear to be not all that impactful: falling around .1 points per day (on a 10-point scale.) That’s only a 1% loss per day.

When a customer has heard back from us, time passing has a much greater negative impact, going from an average of 8.8 after 24 hours to 8.0 in our largest queue. That negative impact is eight times greater than the same amount of wait time between their submission and our first response.

This data indicates to me that the idea of leveling the wait time across all tickets is not the right approach: it assumes a roughly even wait time sensitivity regardless of the ticket’s state. This does not seem to be the case: our customers do not mind a bit of a wait to hear back from us, but once they’ve heard – they want our full attention.

The question remains: how do we move forward with the lessons from April and the implications of this new data?

Ticket Non-Ownership: Reflections

After doing some ruminating here as well as the discussion over on UserCentered, I decided to iterate a little on the idea of Ticket Ownership with my squad over at Automattic.

For the month of April, we eschewed  all ownership of our incoming support requests. What does this mean, exactly? Traditionally, our approach is this: the first Happiness Engineer to respond to a customer then replied to that customer each time they supplied more answers or information, until the issue was resolved. This past month, rather than seeing tickets as being owned by an individual, we owned our entire queue of tickets as a team – focusing not on ownership, but rather replying to the tickets strictly in terms of wait time – whichever customer waited the longest got the next reply, regardless of who had interacted with them in the past. Another way to look at this is this: we were evenly distributing the wait time across tickets, which is reminiscent of line balancing, a method of improving capacity use in production settings.

Wonderland_Walker_2
As April came to a close, I spent some time talking with the rest of my squad, seeing how they felt about the whole idea, if they wanted to continue, and what they saw as the upsides and downsides of this sort of non-ownership. Here are the two big advantages that non-ownership offered:

  1. It created an informal peer review: in reading through a support request’s history, you are able to see in very clear terms how other members of the squad approach different problems, as well as getting a first-hand look at their writing style, tone, and use of outside links (both to WordPress.com support documents and other tools).
  2. It allowed the Happiness Engineer team to much more quickly identify bugs when compared to full ticket ownership: this is because we were exposed to a much larger number of conversations per day, thus making patterns in customer reports much easier to spot than a traditional ticket ownership system, where it is much easier to write off a customer’s problem as misuse or misunderstanding rather than as a broader systemic bug. You can imagine if a Happiness Engineer replies to one customer 6 times regarding a potential bug, it will be cognitively less obvious as a problematic pattern than if the same Happiness Engineer replies to 6 customers a single time each.

And the negatives:

  1. Each particular support request felt less personally involved, and less personally invested, and at least from the Happiness side, thus felt less hospitable.
  2. Working on a request that someone else had already replied to felt more time consuming, as the Happiness Engineer had to re-do the legwork of researching the customer’s site, background information, etc.
  3. Highly time sensitive replies are answered at the same pace as other tickets, since the wait time load is evenly distributed.

Moving forward, we’re hoping to find a way to embrace the advantages while removing or reducing the negatives.

P.S. Does this sound fun to you? Does working on a small team providing hospitality to an enormous userbase seem like a worthwhile pursuit? Would you be able to restrain from strangling a Squad Lead who pulled this kind of experimentation on you? Good news – we’re hiring.

 

Bad Process Kills

To do good work consistently, you have to have process – a way that you approach The Work that allows you to create a feedback loop, allows for continual improvement, and ideally helps you to identify the important things that are sometimes buried in the day-to-day. Process helps you to be satisfied with The Work – good process helps you to be happy, and great process is rare and fleeting but worth the chase. Bad process fails in one of these ways: perhaps you don’t get the information that you need. Perhaps you don’t know who to ask for help. Maybe it’s as simple as not knowing the best way to organize your day.

Have you heard of Jack Phillips?

On the evening of 14 April, in the wireless room on the boat deck, Phillips was sending messages to Cape Race, Newfoundland, working to clear a backlog of passengers’ personal messages that had accumulated when the wireless had broken down the day before. Bride was asleep in the adjoining cabin, intending to relieve Phillips at midnight, two hours early. Shortly after 9:30 pm, Phillips received an ice warning from the steamship Mesaba reporting a large number of icebergs and an ice field directly in the path of Titanic. Phillips acknowledged the Mesaba‘s warning and continued to transmit messages to Cape Race. The Mesaba‘s wireless operator waited for Phillips to report that he had given the report to the bridge, but Phillips continued working Cape Race. The message was one of the most important warnings Titanic received, but it was never delivered to the bridge.

The Titanic’s epic capsizing can be attributed at least in part to bad process: Phillips had the information that he needed, and he knew what he needed to do – transmit that information to the bridge. What his process lacked was a mechanism that helped the important stuff float to the top. Instead, this urgent message that would have changed history sat beneath a stack of messages from the passengers to their friends back home.

Bad process kills. Get rid of it before it gets rid of you!