How can I handle colleagues messaging several people about the same problem?

Question

As a part (not the main part) of my work I help colleagues with technical issues and answer their questions. I work in a very big company (10k+ employees), so colleagues rarely approach me in person. Generally, there are 3 ways to report an issue or ask for support:

1. Messaging me or someone else from my team directly in Slack.
2. Asking the question in the Slack channel dedicated to our team (so a lot of people will see it).
3. Creating a ticket in a ticketing system.

People use options (1) and (2) more often than (3), because in practice they lead to getting a reply quicker.

The problem is that some colleagues (maybe 1% of them) often message me AND at least one of my colleagues with exactly the same problem, so we both end up working on the same thing without knowing that.

I tried just telling everyone to create a ticket or send a message in the channel, but handling this takes more time.

If somebody messages me directly, we usually have the following dialogue:

• Colleague: Hi Alice, X isn't working.
• Me: Have you tried turning it off and on again?
• Colleague: Thanks, that helped!

If I tell someone to describe the problem somewhere else, I'd first need to explain why I can't answer a simple question right here, and then go and answer it somewhere else. If they create a ticket, I'd need to perform additional steps: assign the ticket to myself, change its status, close the ticket, write "Turning X off and on helped" in the close notes etc.

So, in most cases (when the issue can be resolved within 1h) it's way more convenient for everyone involved to just use direct messages.

How can I handle colleagues contacting multiple people with the same problems/questions? Is it possible to resolve this without asking everyone to avoid direct messages?

Answer 1

You first need to reach a consensus amongst your team that Direct Messages are not a good way to raise issues. Your team need to understand that even if it's a 'simple' issue; a DM is not the correct place to answer the question.

Next, try to reach an agreement amongst your team for the correct place for certain types of questions. Should everything be raised as a ticket or do you still want to encourage participation in the team slack channel? Define a clear line between what type of query requires a formal ticket, and what type of query can be answered via the public slack channel. Once agreed, it would be advisable to publicise this to the wider organisation - try to frame this communication positively, e.g. "Please do this to get hold of us!", instead of "Don't do this to get hold of us".

With these agreements in place with your team, have everyone agree to respond to DMs in the same way. For queries requiring a ticket, have them first check a ticket has not been created, then create the ticket and begin troubleshooting via the ticket. For queries suited to the slack channel, write a message to the channel @ing the person who DM'd you and then begin troubleshooting via a thread.

I've had great success asking people to bring conversations "in-channel" when DMd. I ensure I still answer their questions promptly, and have also explained to a couple of serial-DM offenders that I prefer to work in-channel so the information is available to everyone in future.

Answer 2

The problem is that some colleagues (maybe 1% of them) often message me AND at least one of my colleagues with exactly the same problem, so we both end up working on the same thing without knowing that.

I tried just telling everyone to create a ticket or send a message in the channel, but handling this takes more time.

Clearly the correct way is to require that everyone use the same ticketing system. This would avoid multiple folks working on the same issue. It would still allow everyone to see all the incoming issues. And it would make for simpler distribution of problems with less interruption.

It would also permit analysis of the incoming issues so that you get a better handle on the who/where/what/when/how of problems. That might lead to an ability to prevent problems, which is better for everyone.

Even if you cannot convince/require colleagues to use the ticketing system, you could write the ticket on their behalf.

How can I handle colleagues contacting multiple people with the same problems/questions? Is it possible to resolve this without asking everyone to avoid direct messages?

If for some reason you don't want to formalize the processes, and still want to have multiple paths for requesting help, you could try something like this:

Colleague: Hi Alice, X isn't working.

Me: Okay. But first, is anyone else already helping you with this issue?

Answer 3

Answering this bit specifically:

So, in most cases (when the issue can be resolved within 1h) it's way more convenient for everyone involved to just use direct messages.

Imagine what happens when you're in the middle of that half-hour task, and someone else asks a 'quick' question that also takes half an hour. A few of those and you lose track of the first one.

Every time you get interrupted, you lose time by switching between tasks and back again - even for one-line questions. It's not just the time you spend answering the question, but the time it takes you to get back to whatever you were doing before the interruption.

Most importantly, you can spend all day on low-priority tasks because people find they can jump the queue by DM'ing you. That leads to important tasks not getting done, and stress from trying to do too many things at the same time.

Everything should be a ticket.

Also, if people find your ticketing system inconvenient, look to see if it can be improved. Is it tedious to log in? Are there too many mandatory fields?

Answer 4

Use a good process

You've noted a couple of properties that a good process would need to have:

• Not too many busywork steps
• Quick responses
• One and only one caseworker

You also mention that your ticket system... doesn't quite meet those requirements. It seems that there are lots of required fields and bureaucratic steps. Sit down with whoever manages the ticket system and configure it better; un-require required fields that aren't helpful, put in clever pre-fills for common issues and so forth.

Alternatively, use a Slack channel that people can post issues to, and whoever picks up the issue posts a Thread-reply to the question with "I'm picking this up". If the channel is configured normally, people will only get the initial notification, and not get any noise from the in-thread followup.

In general I would say that a well-configured ticket system is preferable; it's got better features for storing information in case someone else needs to follow up, you can put in priority-estimation and SLA-tracking features, and do analytics on what kind of issues are frequent and which ones are not handled fast enough. You can also use (not too many) required fields to make sure people input any required information you'll need to efficiently handle their issue.

Insist that the process is used

Your clients don't use the ticket system because they perceive that sending direct messages gets them helped faster. And it seems they're correct: directly messaging a bunch of people gets them a faster result than putting in a ticket or asking a question in a channel. It's a bit like placing a phone call to a whole room and nobody feels personally obligated to pick it up, or phoning individual desks.

So your office needs to change its habits a bit: don't accept issues dropped via direct messages, but make sure the general support channel / ticket system is vigorously watched. Perhaps one person should have the responsibility of ensuring someone responds to the issue within X time.

When you've got that set up, start enforcing it. Reply to people who start with direct messages with something like "Please make a ticket" or "Please ask in the Support Pool channel (on Slack)".

If people whine that they need help fast so they're doing direct messages, calmly reply that you and your colleagues have multiple issues to handle. If your caller will just put the issue in the ticket system/support pool channel, they'll be helped by the first of you and your colleagues that's available. You may have to be stern a bit, but you can point out that this will result in faster and more accurate service.

Answer 5

You could raise it in your team meeting so people are aware of the situation as a start.

One solution is to post in the Slack group and if you don't get a response in a few minutes, ping the help request. When the ping happens, a tech lead deals with it, or assigns someone who can help. A little formal but will not leave people waiting long.

However the method I have used myself is to simply let other people that you message know when another person is helping you:

• Me (0:00 m/s) -> person A: "Is the widget broken?"
• Me (2:00 m/s) -> person B: "Is the widget broken?"
• Person B (2:10 m/s) -> Me: "Hey, which widget?"
• Me (2:30 m/s) -> person B: "The roundabout one"
• Person B (3:00 m/s) -> Me: "I don't think so, let me check"
• Me (3:10 m/s) -> Person B: "Thanks appreciate it"
• Me (3:20 m/s) -> Person A: "Hey, no worries, person B is helping me out"
• Person A (5:00 m/s) -> Me: "Okay sorry was AFK for a while..., np"

The point being, when someone asks for help but the helper is AFK, and they ask for help from a second person, it is nice for them to notify the first person they asked, so that person does not start to delve into code.

In general if you are the helper: message the person you are going to take a look before taking a look.

If you are the person seeking help" notify the people that you asked that you no longer need help.

Answer 6

The problem is that there is not the one clearly defined way of contacting you.

You have to implement the policy that users can only get support through a ticket.

However, before you can force such a policy onto your users, you have to ensure that the QoS will be the same afterwards, or users will start to complain. Tickets take some time to create, your response times are longer through tickets, and I presume that currently there is not enough feedback from the ticket system about ticket status, and this is why the users go to slack.

So you have to

• make ticket creation as easy as possible, for instance by using mail-to-ticket (maybe even a slack-to-ticket adapter exists for your ticketing system?)
• work on tickets as quickly as if it was a slack DM, for example:
  • send a slack message to all free supporters on ticket creation.
  • maybe even have someone dedicated work the ticket queue; that person is tasked to send out the appropriate standard answers, to ensure that the information in the ticket is as complete as possible, and to assign it to an available supporter.

• ensure that the user is updated about the status of his ticket. The user should receive, within minutes of creation, individual info (through email and/or slack) that

  • the ticket has been created, and what the ticket number is
  • someone has triaged the ticket
  • the ticket (if complete) has been assigned to a supporter (and which one)
  • (if the work is done in the background) that work has started on the ticket
  • that the supporter may contact the user within the next (whatever-your-SLA-is) minutes