Introduction

Support should be a collaborative experience where we work with the people we support. Communicating early and often is key, and feedback should be gathered whenever possible.  

This article outlines practices to improve the support experience for both IT and the greater Roivant team.

Support Practices

In its basest form, providing support to an enterprise is an act of offering problem-solving-as-a-service. Our goal is not to close tickets - tickets are just a way to track work. Our goal is to solve problems, large and small, for our colleagues, so they can focus on their work.

First Response

The function of “First Responders” in the support system is to triage incoming support requests. Triaging involves two steps:

  • Route: To use our ability to read and understand a ticket to route the ticket to the right place/team with a high degree of accuracy.
  • Communicate: To use that same understanding to give our requesters a human point of contact where we can ask helpful questions, offer advice and generally start the conversation with the requester before a “doer” performs actions on the ticket.

Triaging Tickets

RESPONDING ≠ RESOLVING

The First Responders queue should be monitored throughout the day. This doesn’t mean someone working FR needs to be staring at it all the time, but it should be checked frequently.

  1. Before assigning a ticket, reply to the requester to let them know we’ve received their request. This lets them know a human is working on it. Be aware, requesters already get an automatic “We received your ticket” automated mail so there’s no need to repeat that.

    1. Empathize with their problem.
      • This isn’t fake, so don’t fake it - consider how their problem would feel to you and talk to you colleague about it with respect and empathy.
    2. Ask questions that will help ticket workers perform actions once the ticket is prioritized and started.
      • What error messages do you see?
      • Has this happened before?
      • And so on…
    3. Be clear and specific about any actions you will take, even as a First Responder (“This looks like [subject], I’ll assign it to [group]”)

  2. If you can resolve a ticket instantly - take it! As a first responder, we are responsible for getting people the answers they need as quickly as possible. If you know the answer to their question, or can quickly pair with someone to get the answer, own the ticket from start to finish. We want to avoid escalations and delays whenever possible. You might call this the “5-minute rule”. If you can solve a ticket immediately, and it would only take about 5 minutes - go ahead and do it.

For example, if a ticket comes in asking “How do I order lunch in the NY office?”, and you know the answer is Relish and have a link, you should respond to that ticket. Despite it being a facilities-related ticket, it does not necessarily need to go to their queue.

  1. When a ticket comes in on behalf of someone else, reply to the requester before updating the ticket to the person who needs the help.

“Hey John, Thanks for letting us know about Jane’s issue. We’ll be reaching out to her shortly.”

Responding to Tickets

We’ve all had experiences where you reach out to a company for support and receive little to no response – the frustration is REAL. This scenario is something we don’t want our people to experience.  

When someone reaches out to support, they are looking for help from a human (not a robot). Make sure to respond to requests as quickly as possible so the person knows their issue is on our radar.

Anti Patterns

  • “Null” replies
    Avoid replies that don’t say or add anything to the conversation with our colleagues.

    • Examples
      • “We’ve received your ticket and will work on it shortly”
      • “This will be handled”
      • “I will work on this” (unless you’re actually doing it now, in which case say that)
      • “We can do this” / “We can help with this”

    Why are these bad?
    Requesters already receive an automated reply to a ticket they submit, so not only do these essentially repeat the same acknowledgement, they offer no new information regarding the issue. Folks know that the request was received, that it will be worked, and hopefully soon - it’s why they’ve contacted us in the first place.

  • Robot (canned) replies
    It’s undeniable that some tickets will become repetitive, but still, they are submitted by a human colleagues who need assistance. Even if it’s the Nth one on a subject today, don’t fall back to repeating Null replies, or copying and pasting “form” replies.

Always make progress

Every response to a support case should serve one or more of three purposes:

  1. Asking questions necessary to perform the work to deliver a solution.
  2. Communicating the work being done which moves the ticket towards resolution.
  3. Keeping the requester informed and connected, in case the ticket ends up in a waiting state.

(again) RESPONDING ≠ RESOLVING

Keeping someone in the loop with a reply does not mean you have to immediately resolve their issue.

For example:

“Hey team! I’m having an issue with Chrome, can you help?”

An appropriate reply might be:

“Hey!  

Sorry to hear you’re having trouble with Chrome. I have a few quick questions that should help us narrow down what might be causing the issue:

Are you seeing any error message when you visit a website?

Is it all websites are just one specific site?

Does the issue occur if you use another browser?

Are other apps that use internet (like Outlook) connecting and working properly?

It could be worth quitting and relaunching Chrome or even rebooting the computer to see if the system just needs a quick refresh.”

By asking probing questions, the person can provide additional information that may help us resolve the issue faster (it also buys some time). Another great idea is to offer possible solutions and troubleshooting steps in that initial reply. Sometimes the person may reply with “Hey, rebooting worked!”, and now you have one less ticket to worry about.

Troubleshooting

In addition to asking probing questions, there are some other techniques you can use to quickly identify the case of an issue.

Split-half search is a technique for systematically isolating the source of an issue. You start by eliminating roughly half of the items you are checking, then trying to re-create the issue.

For example:

An application installed for all users on a computer won’t launch.  

You’ve tried updating it and relaunching, but it still won’t open. Before jumping to a complete reinstall of the software, you log into another user account on the computer to see if the app opens there.

Why do this? By logging into another user account, you should be able to tell if the issue is system-wide or limited to one user. If it doesn’t open in the other user account – the issue is system-wide and a reinstall of the software might make sense. If it does open, the issue is isolated to one user account and a reinstall would likely not resolve the problem.  

Taking Notes

Another important part of support success is ticket notes. Internal ticket notes are a way for you to asynchronously communicate to the team the steps you’ve taken to resolve an issue.  Along with interacting with the requester, tickets are the focal points in which relevant information can be gathered.

Every ticket should contain sufficient notes and information such that any other agent can pick up the work and have enough information to keep the momentum going. This is the primary function of ticket Notes.

For example:

“Hey team! I’m having an issue with Chrome, can you help?”

Let’s say in this case we determined the issue was specifically with Chrome and quitting and relaunching the app resolved the issue.  

An internal note might read:

  • No error message, just a blank page

  • Person was able to open website in Firefox

  • Determined issue was only with Chrome

  • Person quit and relaunched Chrome app – issue resolved

Now if that person opens a ticket a day later for the same issue, the next person can see what was done previously and take additional steps if necessary.

Internal notes help track recurring issues and can help support team members solve repeat issues quickly. Think of it as an ever-growing FAQ, with each issue resolved adding to the team’s knowledge base.

Combining Information From Other Systems

It’s common that coversations about a ticket may expand out to chat, side-mails or other media than the ticket itself. When this occurs, do copy and paste or screenshot relevant parts of the conversation so that the requester and/or other agents will gain the context of that conversation.

However: Do not paste in 3rd party conversations without permission. Meaning, do not post conversations from private Slack channels, or mail threads inculding unrelated individuals. You may post links to Slack conversations, which will rely on Slack permissions.

Remember, “Private” notes are only private from the requester, but are visible to all agents in the support system.

Last Response

Not dissimilar from the habits around first response and triage, we also maintain a set of habits around our final response on a ticket before marking a ticket resolved.

(almost) Never close a ticket silently.

A close second to the first response, the last response is critically important for out requesters to understand what is being done. Always close out a ticket with something like “<thing> has been completed, so I’m marking this as resolved”.