Support tools and communication

Customer support is all about communication: communicating with customers, with other teams within your company, and with other people on your team. If you work in Support, you're most likely talking all day.

Communication—with customers and with teammates—has changed over the past decade. And I don't think we've all been keeping up with the changes as much as we'd like.

three vintage phones on the wall
Photo by Pavan Trikutam on Unsplash

There's already a lot of advice floating around the internet about what communication tools you should use and how you should use them. They often sound like:

  • Use a chat app, like Slack, and make it standard practice for all teams.
  • Have no unnecessary meetings. But when you have to have meetings, make it the norm to use video chat.
  • Document EVERYTHING. Use Google Docs or Dropbox to keep all of your internal knowledge organized.

I think most people already know this stuff, or have heard this advice somewhere, even if they haven’t put it into practice. There is a lot of information and a lot of opinions on how to put these things into practice. I don’t think I need to add to that pile. (If you want to hear me rant about proper Slack etiquette and emoji in GitHub issues, find me at a coffee shop that doesn't mind loud noises.) This advice mostly addresses how teams talk to each other, where they talk, and how they mitigate physical and time zone differences as they grow and become more distributed. I think there's another aspect of talking that's often missed.

Maybe—and this is just my theory here—maybe we’re spending a lot of energy finding better ways to talk to each other when we should be spending energy finding better ways to not talk to each other. Here’s an example I ran into at a previous company:

The company produced hardware, and each product required input from a lot of teams that each had their own software models they used to design their components. From a basic set of requirements, one team would go off and start work, then present a plan, or email some data, or mail everyone a disk with some data (yeah, I know). Then another team would go off and start work on their models and come back to the other teams with their data.

Eventually, the broader team had a working model of how the product worked. Maybe it worked the way we all wanted, maybe not. Did it meet our requirements? Did it need to change? We'd start that whole process over. It could have taken months. It usually did. Then at the end, it might have been a working design that didn’t quite meet the requirements, so we’d have a discussion about maybe changing the requirements after over a year of design work.

This was real. I saw it happen. I was a part of this problem for a long time.

It was frustrating, so we looked for ways to do better. We got shared servers for the co-located teams to minimize the time they spent sending data back and forth. We did some preliminary discovery to make sure we were closer to meeting requirements earlier, then iterated to get more detail. This helped, but I felt like we were still wasting a lot of time.

A coworker and I built a tool that allowed engineering teams to collaborate on projects by sharing tools and models, rather than by sharing data. It cut out the need to get together in person to talk through our models’ inputs and outputs.

The software each team wrote was not designed to talk to other software. All of it was designed and developed with the idea that a human user would put data in and get data out. We spent years building APIs for one team’s Fortran code to talk to another team’s Visual Basic in Excel model, for Mathcad to talk to Pro/ENGINEER.

After a while, we could run a design simulation over a weekend that would've taken three months to work through the old way because now all of our systems could just talk to each other directly. We didn’t speed up how people communicated, or find better tools for sharing data between teams. We eliminated unnecessary communication and let computers do what they’re good at.

two old people chatting in the street
Photo by Cristina Gottardi on Unsplash

That may seem great but kind of tangential to the scope of work that many of us in support do on a regular basis. Let's consider an example from the support world of two systems that can and should talk to each other, instead of people talking to each other to handle data entry:

  1. A support team receives a Zendesk ticket about a bug.
  2. The support agent responds to the user and opens an issue in Jira for the engineering team.
  3. The engineering team reviews the Jira issue and begins working on a fix.
  4. Engineering fixes the bug.

But how does engineering tell support that the bug is fixed? Does the support team repeatedly contact the engineering team to get a status update?

One solution that often speeds up the process is to have Jira notify the support agent that the bug is fixed so they can, in turn, update the user. This addresses the speed of the communication, but the communication itself is largely unnecessary: Jira should tell Zendesk that the bug was fixed and Zendesk should tell the user.

These integrations and automations already exist, or can be built with existing APIs, to reduce human error with communication. When there are hundreds or thousands of bugs and just as many Zendesk and Jira tickets, tracking all of this manually becomes a large part of a support team's work, not to mention a major cognitive overhead for individuals. Software has a higher capacity for this kind of work than people do. Once we’ve automated away as much communication as possible, we can consider what we should be spending time talking to each other about.

How do we define the impact of a problem or solution?

Where do our needs align with our customers’ needs?

Where do they conflict?

Where do our values align with our customers' and where do they conflict?

These are questions we likely aren’t talking about as much as we should be. And we, in support, are in a great position to be at the center of these conversations. Instead, we are often too busy talking about other, smaller things—like how long a bug has been sitting in the backlog or how many customers have been complaining about some button on the home page.

This is why we're building Yetto. We want support teams to have tools that talk to other tools and other teams. We want support teams to spend less time trying to get engineering teams or product teams to see what bugs customers are finding, so they can spend more time making an impact on the conversations that matter most.

To see how Yetto works and sign up for the beta program to give it a spin, check it out on our home page. Or get in touch with us if you just want to know more.