Updated Support Process (March 2021)
Updated Support Agent Process
Currently, the ticketing process we follow in Support looks like this:
- Ticket arrives in Support or Internal Support
- Quick triage - What is the issue? Have I seen this recently? Do I have enough information to reproduce this? Are there other tickets in the queue that are higher priority?
- Apply appropriate tags and priority status
- Gather information from testing or communication with client/CSM
- Resolve issue if behavior is expected/fixable. If resolution is not currently possible then...
- Escalate to github
With Patrick Kelly helping us now, we want to adjust this process to include him a bit more and hopefully reduce escalation rates (and strain on the developers working Support). It looks something like this:
The plan is to keep the same general workflow, but if you get to step 6 and believe you should escalate an issue, we want to hold back and give PK a chance to go over it. To do this, tag PK in a note, but keep ownership of the ticket to ensure no confusion and your ability to continue if no response is received or further communication with client is required.
At the point in a ticket's life where PK might see it, it should have a note with the information you’ve collected so far - replication steps, credentials, error messages you encountered, solutions you tried, related github issues - all that good stuff.
In an ideal situation, once a ticket makes it to him, Patrick should be able to use the notes you've added to gain context of the ticket without having to go back and re-read the entire thing from the beginning. From there, he’ll be able offer guidance on possible resolutions, take ownership of the ticket or advise that we escalate to the Support Dev team in github.
This will mean that some items in our queue will be there longer than normal. This is fine. The goal is to invest an extra 1-4 hours in the ticket lifespan usually, or sometimes as much as 24 hours, but not to create zombie tickets that live forever. If you’re not getting any help after 24 hours, time to escalate.
Obviously, there are situations where it’s going to be best to bypass PK and escalate straight to github. These will mostly be judgement calls.
Some straight-escalation situations:
- Site is down/inaccessible. We want to get as many dev eyes on that issue as quickly as possible
- Issue that requires Ops action
- Ticket Drivers. If we’re seeing multiple reports in a day all about the same problem, escalating that to github will help get it in front of more devs faster.
- Release Day Issue. If there was a recent deploy, and you are able to determine that it’s tied to that release, we ant to get eyes on that as soon as possible.
- Brand new feature: Patrick has a wealth of knowledge about Vanilla in his head, but it’s unfair to expect him to be 100% up on brand new features. If a feature has been out for less than a month, and you have a question on functionality or it seems to be presenting a bug, escalate that issue.
Some smart tickets to send to Patrick:
- SSO Issues
- API Questions
- Pocket issues
- Quick theming issues: Note that PK is not responsible for theming a client’s site. Lets only tap him in if some CSS for a client suddenly isn’t working or we need to do something quick like hide a certain button.
- Functionality Question: PK has seen just about every part of Vanilla. If a client is reporting an issue with a certain aspect of the software, and you’re unable to determine if the behavior is expected, it’s not a bad idea to check with PK so he can verify.
No matter what, the above list should not be used as a fast track straight to Patrick. Every agent should have the ability to apply some troubleshooting to all of these issues. Every agent should also know how to dig into Vanilla for relevant information that might lead to a possible resolution (old Github issues, Freshdesk issues, Success documentation, Staff documentation, Slack conversations, asking other Support Agents or CSMs etc etc etc). Try to apply as many skills as you can before sending something for Patrick to consult on.
We also don't want tickets for Patrick to sit for too long. If it's been a busy week, and PK has a lot of other issues in front of him, it might be best to just escalate to the Support dev team. It's important that we don't try to rush him on what he's currently working on. If there's an issue that you tried to tap PK on and it sits without a response for 48 hours, it's best to escalate it as a github issue.
End of Shift
With Support taking on more clients directly, it’s going to be more difficult for the queue to be completely clear before the next agent takes over. As part of our reworked process, let's start making sure the next shift has the necessary information to bring certain tickets across the finish line.
When it’s getting toward the end of your shift, take some time to go over the tickets you’re currently working on (either still testing or awaiting client/CSM responses on). On those tickets, make a note so the next Agent that opens it has an idea of 1) what you’ve done so far and 2) what your planned next step was.
This doesn’t need to be an extensive amount of information - the goal is to prevent Agents coming on shift from having to start from step one if they inherit a previously worked on ticket. Ideally you also want to leave the next Agent with a plan of action.
Examples: If you’re waiting for more information from a client because you believe a report might actually be tied to an already escalated issue, make sure the next agent is aware of that thought process (link related github issues etc).
Or
If you’re testing a convoluted notification issue, let the next Agent know what you’ve done so far so they don’t end up testing the same things again.
As Support takes on more clients directly, the queues are going to get more intense. Increased communication like this should help shift transitions go a little smoother and prevent tickets from getting ‘stuck’ (and help avoid situations where agents that are off-shift getting called back in to answer questions about things they did).
This document may be updated as Support, CSMs and the new Consultant team fine-tunes our current operation.