Pair Ticketing

Originally published on Medium, on 2021-01-19.

This article will share the concept of Pair Ticketing for experienced support teams, which I believe to be a better alternative to conversation reviews, if you’re dealing with complex tickets.

I will also suggest an implementation, designed for small remote teams, which we’ve been experimenting since October 2020 at 360Learning.

TL;DR

Pair Ticketing is the action of answering support tickets as a team of two humans:

(All this is blatantly stolen from Pair Programming.)

Here’s the implementation cheat sheet:

You now know enough to implement Pair Ticketing in your team. You may read the rest of the article if you like details. It is divided into three parts:

  1. advantages of Pair Ticketing
  2. the case against reviewing
  3. recommendations from 4 months of Pair Ticketing at 360Learning

Advantages of Pair Ticketing

When thinking about improving skills and harmonizing the quality of answers across a team, the standard solution is to use a conversation review tool. After testing this approach for a few weeks, we realized it didn’t fit our organization. Specifically, we disliked the following aspects:

We designed Pair Ticketing as a counter-proposition to all those problems. Its objective was to provide a collaborative framework to improve agents’ skills and ensure that people in the same team follow the same guidelines — all this in a benevolent environment. It also had some incidental benefits:

The case against reviewing

Pair Ticketing solves in one swoop all the problems of conversation reviewing:

Let’s go through each of them, to understand what’s at stakes.

Rating with categorization

Note: this is only about categories for evaluation — different from the internal tags that you may need on a ticket for internal reporting.

As the person creating the categories to rate a ticket (“tone”, “correctness of answer”, etc.), you are faced with the dilemma between:

As the person who is reviewing the tickets, you will have to transform a human exchange into a score. This will require you to interpret, judge, and take decisions. All this creates fatigue, and generates approximation.

This is especially true if you’re dealing with complex tickets. I’ve spent hours trying to find a standard set of categories, only to stumble upon a ticket which doesn’t fit it at all. This went on for several cycles, until I realized we would always have special cases.

Which leads to a final remark: when designing your categories, ask yourself if you’re trying to capture reality, or enforce a set of values. Real life tickets are more complex than a list of values on the company wall.

Stick & carrot effect

Reviewing means you will award good points and bad points. This may lead to cramming, with support agents focusing on getting good points, instead of the broader picture.

Complex tickets require a creative approach to problem-solving. By enforcing fixed quality dimensions, you encourage the application of a playbook, rather than focusing on the best way to help a customer (which may require thinking outside the playbook).

This is the surest way of annoying top performers (“it’s forcing me to do something stupid!”), and giving weapons to low performers (“if I follow these rules blindly, I can’t be blamed.”).

Missing analysis

Categorizing tickets is meaningless if you don’t analyze the results.

Why is a specific agent (or a whole team) getting 2/5 on average on the dimension “tone”? What does that mean exactly? And, more important, how can we improve it?

Those questions require investigation. Digging into the details of each ticket, and maybe talking with the involved parties. This takes time, especially when you thought that “reviewing” would yield magic results.

Reviewing is an indicator. It will not tell you how to improve.

Process-blind

Reviews will tell you nothing about your internal processes.

Maybe the support agent made a great response, but tagged the ticket incorrectly (or any other internal process you have before closing tickets).

Maybe the agent raised hell to find an answer, corrected a product spec, updated the public help site, and created an internal process in the journey — all this to provide the best answer to the customer and make sure the topic would never be raised again.

This behavior is top of the class. Yet despite all those actions, the agent may get an average rating in your review software. There is no greater deterrent than going above and beyond, only to be meagerly rewarded (or just plain ignored).

Yet another tool

Tools don’t fix a broken process.

If you suspect that some agents have a lower-than-average satisfaction, dig into it. This may lead to revamping your training program, or fine-tuning your hiring criteria.

But be wary of adding another workflow-based tool to your stack. Tools require maintenance, and adding recurrent actions generate mental pressure.

Hierarchy

While often sold as a decentralized (“peer-to-peer”) way to improve everyone, reviews end up being owned by managers.

Conversation reviews’ primary audience is managers, because it is a neat way to measure quality with a number. Again, measuring is not improving.

Productivity

Support teams answer tickets. Any action pulling them away from that core objective should have one of these direct consequences:

Reviewing conversations does neither (regarding the second point: reviewing does not directly improve the quality of a ticket— it only rates it).

A clarifying word on measuring vs improving

Although measuring is often a prerequisite to improving, we should be careful about the balance of energy.

Energy — and especially the energy from support agents — should be focused on improving. Measuring should be transparent, and ideally require no energy (or, at most, only from the manager).

Conversation reviews strike me as problematic, because they masquerade as an improvement process, when they are a measuring tool.

Recommendations from 4 months of Pair Ticketing at 360Learning

Since its inception in early October 2020, we made several minor adjustments to our practice of Pair Ticketing, and one major.

This chapter is intended as a list of recommendations; you may steal some of our solutions if they apply to your organization and team profile.

Avoid Pair Ticketing for onboarding

Enroll people for Pair Ticketing once they’ve passed their probation period.

Don’t underestimate the gap in product knowledge between a newcomer and a tenured member. Even with the best intentions of turbo-sharing knowledge to newcomers, this may only result in tetanizing them.

Plan for Pair Ticketing in early afternoon

I recommend 3 p.m.

Pair Ticketing requires a lot of energy and focus. Doing it at the end of the day may be tiring.

Write drafts, not final answers

I recommend writing the answer as bullet points in internal notes, and send the answer when you’re out of Pair Ticketing.

Writing under scrutiny is excruciating. Pair Ticketing works best when investigating — not when writing in your name.

Don’t force Pair Ticketing (and allow for default cancellation)

You should be excited about doing a Pair Ticketing session. If someone in your team feels uncomfortable doing Pair Ticketing, don’t force them.

Also, make it crystal clear that people may cancel their session without justification.

Promote bug suspicions

Tickets tagged as bug suspicions are particularly good candidates for Pair Ticketing sessions. You may require more than one good brain to write a clear reproducible scenario, or recall past cases.

Steal from the Tech

Ask for advice to the Tech/Dev team.

Even if they don’t use Pair Programming themselves, the concept has been around for years; odds are, they have already tried it and can give you feedback on what worked for them.

Our first implementation is almost entirely plagiarized from our Tech team’s practice.

Rethink everything every quarter

Make purposeful changes to your Pair Ticketing rules. Every quarter, take something that didn’t work as well as expected, and put it at the center of the new quarter.

We made up names for our Pair Ticketing seasons. This makes big changes more enjoyable.

Final words

Pair Ticketing will not magically turn everyone into super-performers. Nor will it harmonize quality in a quarter, or turn old-timers into geeks just by witnessing the power of keyboard shortcuts.

But it’s a light process that you can implement and increment quickly, at no additional cost. It’s also a fun way to share small tricks, run adventurous investigations, and make remote less lonely.