A lot of what we do is hard to codify, and much of it is based on personal style. Nonetheless, here's an attempt to document some best practices. Sometimes these work well together, other times Socratic teaching is going to be a better answer for a frequent correspondent than "here is how to X: ..."

We've hired smart people (yeah, you!), so take some initiative and use your best judgment while you apply these. Don't hesitate to ask your teammates for help - we like to help or we wouldn't be doing this work! And, teaching you helps us out tomorrow - please remind us of this when we seem to be too busy to do a good job teaching!

Ticket practices

Starting out: New Tickets, or ones that are new to you

  1. Read the subject and the whole ticket. It's easy to fail to read a subject that has vital information in it, or read only the first and last paragraph and miss out on a key message (Example: "I'm trying to pay you more money but my account will lapse tomorrow") buried in the middle of a long question.
  2. Summarize your findings for a long ticket in a private comment before or after you answer to the customer. This will help the next person who has to reply to a 3-month long saga.
  3. Check the ticket's category. This could either give you a hint in case the question is otherwise vague, or else give you the opportunity to add that context & make sure it's properly categorized. Setting the correct category will help give the next reader, or someone from another team who is helping us work tickets, that important context. Example: "javascript troubles" could apply to any of our agents, our core app, or even our partner integration.
  4. Is the problem well-known? Now's the time to cut and paste a stock answer in if you have one, and also a chance to realize that we have a FAQ in progress that should be added to our online documentation.
  5. Is the problem completely undefined? Can we politely request more information from the customer and make sure that we request enough that we've not only got the problem defined, but also gotten them to include the info we would have asked for if we understood the initial question? Example:
  6. When analyzing the symptoms, it's important to identify what the customer is trying to accomplish so that time is not wasted on attempting to solve a symptom instead of a problem.

Deep dive - The problem is well specified and is not trivial, an obvious known bug or feature request

  1. If there's a clear path, eg: "I want to report custom metrics about X for Y purpose", verify that their request seems possible and then start guiding them to a solution. If you aren't convinced it's possible, ask around amongst your teammates or the domain experts in development.
  2. Make sure you're investigating the correct problem.
  3. Don't hesitate to report a bug the customer hasn't noticed if you notice it-especially if your answer is going to take them to a situation where they are likely to!
  4. Check their account to make sure that subscription issues aren't to blame. We have a lot more insight into account status and history than our customers.
  5. Check our view of their environment & settings to make sure that nothing jumps out at you as problematic. (Examples: unsupported OS/library)
  6. If the situation doesn't make sense to you and a teammate, sometimes all you can do is shake the tree and see if anything falls out. Example: "I see that your listed config on your dashboard doesn't seem to match what was in that config file you sent. Could you also send me the application logs 'debug' log level so I can investigate more deeply?" This gives you a chance to notice that the appname in the logs doesn't match the config file they sent!

Merging a Ticket

When merging a ticket, be aware that the merged-from ticket is marked as closed and the customer will know this. In light of this, the following will lead to less customer irritation, from experience. During merge, you can set a message for each ticket and make it private or public. Please:
  1. Leave a public message in the new (duplicate) ticket saying that "Since we are already discussing this in another ticket [give link to other ticket like], I will merge this ticket into that ticket so we can continue the conversation in just one location."
  2. If the "old" (existing) ticket has gone awhile without reply (or customer is complaining about perceived sloth), also apologize for our slowness in replying in that ticket, and say we are working on tickets in order and set expectations for a reply (eg: "You're near the top of the list of tickets to answer so we will get to you soon" or "We will get to your ticket in the order in which we received it - but as fast as possible.")

Finishing Up

General practices

New Support Engineer practices

As long as we keep hiring, we'll put new hires on the lower priority customer tickets, to learn.

It's helpful to give "bulk" guidance when there are learners working that part of the queue, so here's my process for a Senior Support Engineer to drop 1-minute troubleshooting/solution suggestions into those tickets. Don't hesitate to say something leading: "do investigation X and Y and then ask for someone's advice on the results" or "search for another ticket with the same keywords, it's a FAQ" or "go read the doc on X, it will explain the answer so you can explain to customer while you link them to the doc". These are not intended to be real answers, just "a trail of breadcrumbs" to help new folks set out in the right direction while investigating.

Also: don't do much clicking-just read request and suggest relevant docs and troubleshooting paths:

It is also helpful to provide this explicit advice to new engineers following your breadcrumbs: If something doesn't make sense, ask after you spend a few minutes trying to figure it out. These aren't intended to be day-long odysseys, they're intended to get you to a response in under an hour-and this may not necessarily be a complete solution.