Support Workflow

From noticing an issue … through resolution

1. Someone notices something in our product not working correctly or needs help getting our product working. This could be a prospect, a paying customer, open source users, or anyone at Sourcegraph – we consider all of them customers, regardless of what “type.”

2. Someone engages the support team for help. Our customers are able to initiate conversations for help via several methods (Slack channels, support@ email, Discord, etc – (more details below). Allowing customers to initiate conversations via several methods increases the likelihood that we become aware of issues or questions as quickly as possible and can get our customers the help they need. We use Zendesk to keep track of every request from a customer. Zendesk simplifies what would otherwise feel complex through out-of-the-box configuration and integrations, allowing us to have almost everything in one place for easy prioritization and powerful data tracking. We get the benefit of everything coming to one place and customers have the lowest barrier possible to interact with us. Our teammates will almost always reach out to us over Slack. The primary exception is when there is an outage (about, /search on sourcegraph.com, or docs is fully unreachable) and engineering pages us via OpsGenie.

3. An application engineer decides which conversation needs attention next. As a general rule, we help in the order the request was received and aim to not have anyone waiting more than a couple of hours for a meaningful first response. We are mindful of our SLAs. We personally follow our guiding principles around prioritization. We all triage based on our availability.

4. An application engineer takes accountability for a conversation in Zendesk. From that moment, the application engineer is accountable for making sure the issue is resolved. How many open, active issues an application engineer can handle simultaneously depends. The team will always have to work together to make sure everyone has the time and space they need to solve issues effectively. If any of us feel overwhelmed, we make that known and employee the case transition process to balance the workload.

5. The application engineer builds context. Upon taking a case, you build context to determine how to proceed. You do this by:

   1. Determining who the customer is and where they are at in their lifecycle
   2. Review any applicable #stripe-alerts (in the event that it is a self-service customer who does not have a CE assigned)
   3. Reviewing relevant deployment and/or account info docs found in the customer notes folder or in Salesforce.
   4. Talking with the CE who is assigned (listed in the Salesforce app in Zendesk), if one is assigned. Depending on where the case originated, you may want to check with internal teammates to ensure we have full context. For example, again, a quick check with the CE might yield invaluable information. If the issue is from marketing, we should see if they have any considerations for our response.
   5. Looking for special notes about the customer in our Exceptions for Customers document
   6. Relevant Looker dashboards (for example the customer version board)
   7. Looking at other recent cases. A good starting point is the database of resolved tickets.

6. The application engineer does two extra things ASAP if the ticket originated from Slack.

   1. Signal accountability. Comment in the thread from the customer in Slack with something along the lines of: “I’ll help you with this. I need a few minutes to dig in and then I’ll share my thoughts with you/see what questions I have.” – to signal your accountability to the CE and let the customer know we are on it. The goal is for this to be super quick and then you move on to the real initial response after you have had more time to dig in.
   2. Taking accountability for more than one issue at a time. If you see a customer has posted a few questions at once, go ahead and take accountability for them all. Often when customers do this the issues end up being related and it will be a better experience for everyone involved if the same person handles them all. This may require you to get help on other tickets and that is okay! Just let the team know and we will figure it out.

7. The application engineer responds within our SLA response time. The goal of our first responses is to be helpful, show progress, and not ever have anyone wondering what’s next. As such, our first response is always informed by 1) considering full context for the customer, the issue, and the situation (we did most of this in step 5) and 2) first trying to solve the issue. If you need more time, that’s okay - share that update with the customer.

8. The application engineer ensures the issue is resolved. This step is the biggest step. It could mean identifying and filing a defect. It could mean helping the customer figure out what they need to do. It could mean refocusing our efforts to not settle for symptom-focused solutions, but pushing ourselves and our engineering teammates to find the root cause. If we get stuck, that’s okay! It will happen. A lot. Here are the steps we take when we are stuck:

   1. Ask our teammates in our #technical-customer-collaboration Slack channel.
   2. If we collectively don’t know the answer, then we engage engineering following the steps outlined here.
   3. A few additional tips…
      • If ever an issue seems a bit bigger than helping a customer fix something that isn’t working correctly or explaining how something works (for example, the customer needs to make a decision about doing something one way or another), then it’s a good idea to loop in the CE and see if they want to offer any additional ideas/thoughts to the customer to help them from a strategic perspective.
      • Try to make sure that what you are helping a customer with is fully supported. You can check this by referring to the resources found here.
      • For features tagged beta or experimental in our docs, it’s okay to err on the side of engaging engineering sooner rather than later (since we don’t yet know if we will want to release these, we keep our docs light in case we opt to remove the feature after all).

9. The application engineer resolves the issue. We don’t consider something resolved unless the customer does/would. Resolution happens in a few ways. Only when one of these is true do we designate a case “closed” in Zendesk – and if we were working in Slack, we leave that channel.

   1. We help the customer figure out what they need to do and they confirm they have done it and agree the issue is resolved AND we complete any internal tasks born from working on the ticket (like updating documentation or filing a GitHub issue for a docs update).
   2. We identify a workaround to get the customer on their way AND we file a defect or product improvement (in the public GitHub tracker) to address the underlying root cause and share the link with the customer.
   3. We help the customer figure out what they need to do and they stop responding. After a couple of attempts, if we are confident the issue would be solved, AND we complete any internal tasks born from working on the ticket (like updating documentation), we go ahead and consider it resolved. Often in these situations we give the CE a heads-up of our decision.
   4. We identify a defect, engineering fixes it, the customer confirms the issue is resolved OR we share the public defect link with the customer (always do this when possible instead of keeping the case open) AND we complete any internal tasks born from working on the ticket (like updating documentation). Until then, we consider the case open and while engineering prioritizes the defect for a fix, we place the case “on-hold” in Zendesk.
   5. We confirm the issue is a feature request and tag in the CE to handle the request if there is a CE assigned to the customer. Otherwise, you can file the issue yourself. Before doing so, however, make sure that the request you’re making does not reveal any security vulnerabilities. If we are unsure, we start a thread in #customer-support-internal and ask. If the issue does NOT reveal a security vulnerability, we file the issue in the public repo and share the link with the customer AND we complete any internal tasks born from working on the ticket (like updating documentation). If the issue DOES reveal a security vulnerability, file the issue in the security-issues repository. We do not share security issues with the customer, but we do inform them that the issue has been filed.
   6. If we are still working on finding the answer and the customer stops responding, we email a couple more times to see if they had a chance to look at our last response. If they still don’t respond, and they have a CE, talk with them to see if they have another way to get in touch and see what’s going on. If not, or if the customer does not have a CE, AND we complete any internal tasks born from working on the ticket (like updating documentation), then it’s okay to close the ticket at this point.

10. While we work, we keep Zendesk, Slack, and/or Salesforce up-to-date. If a ticket originates in Slack, you’ll still need to keep Zendesk up to date. Switch the requestor to the person asking for help in Slack so that the issue ties to the right customer. Use the internal notes function in Zendesk to leave notes for yourself to track your progress and decisions (these will also appear in Salesforce for others to see). A summary of what happened should be obvious in Zendesk even if all the work happened in Slack. Also, we will often learn details about a customer’s environment, etc that we should keep in Salesforce. We update and enter new such data in Salesforce as we learn it via a Google Form as outlined here and/or the account info doc in the customer notes folder, if one exists (be sure to talk to the CE as part of updating it, in the event that what you are updating ends up being invaluable information to them for what else may be happening with the account). This data is then rendered in Zendesk so we don’t have to ask the customer for it again. Zendesk also always reflects where we are at in our process by using the status function.

Details about all the methods via which our customers can ask for help

As explained above, our customers are able to initiate conversations for help via several methods.