FAQ for CE about how support works at Sourcegraph

A customer needs help, which team should help them?

Whose superpowers are needed to help the customer will depend on what the customer needs help with. At a high level, CEs work proactively, providing guidance to the customer, setting them up for success, etc; and CS works reactively, helping when something isn’t working as expected. Here are the most common examples to bring the high level descriptor to life:

How does support know a customer needs help?

The shared Slack channels and support@sourcegraph.com link to Zendesk, the tool that CS uses to triage and manage their workflow. A handful of channels created within our customers’ Slack accounts (instead of ours) don’t respect the sync logic, but CS has a way to keep an active eye on these channels and manually create something in Zendesk; all such channels can be found via the customer exceptions page.

What are our service level agreements (SLAs)?

You can learn all you need to know about our SLAs here.

Can I have access to Zendesk?

There is no need! We offer a window into Zendesk per customer in Salesforce. Navigate to the account record, then the Zendesk tab, and there you will be able to see all ticket history, internal notes, which application engineer is responsible for what ticket, etc. What you see in Salesforce is what you would see in Zendesk; there is no additional information in Zendesk. Most support work happens in Slack, so if you crave to see the full back-and-forth with the customer, that is where you will be able to read that. If you would like to understand more about the support team’s workflow (how we use Zendesk statuses, etc), feel free to read our application engineer workflow or triage workflow. If you have any specific questions beyond that, ask the AER responsible for the relevant case.

I am worried a shared Slack channel isn’t going into Zendesk, how can I be sure?

All customer trial- and support- channels are meant to sync to Zendesk. If ever you are unsure if things are working correctly (ie, you see no one has engaged on a post) let us know in #customer-support and we can investigate. Some channels do have to be manually triaged, so it could be we need to add that channel to the list or the integration is not working; letting us know lets us figure it out for you so you can have peace of mind our customer will get the help they need.

What if I am on a call and I realize we need an application engineer to debug?

We like to be prepared for calls. If ever you are on a call and it feels relevant for an application engineer to join, create a post about the issue in the customer Slack channel or email support@sourcegraph.com with the customer included. An application engineer will take responsibility and can arrange a time for a call once they understand the issue and have time to prepare.

What do I do when a customer wants to have a call and I think it would be helpful to have an application engineer join?

Post sharing this in the customer Slack channel or email support@sourcegraph.com with the customer in copy (making it clear you are posting so an application engineer can engage to determine a time); and work with the application engineer who takes responsibility to 1) make sure they have what they need to be successful on the call and 2) the call happens at a time that works in their schedule. Due to the fact that application engineers are managing multiple cases for a number of different customers, it is likely not possible to get an application engineer on a call with a customer immediately. This is why allowing the customer support team to communicate with the customer about availability is critical. But more than that, the application engineer responsible wants to show-up prepared and that can take time. It’s very similar to running any customer call – no one at Sourcegraph wants to show up without being prepared.

There may be times when we see such a request as we triage and we realize the request isn’t relevant for support. In those cases, we will post in #customer-support and create a thread for us to discuss.

What if an email I have with the customer turns into something for support to handle?

Add support@sourcegraph.com in cc (keeping the customer in copy, too) and share that you have copied in our support team to help out.

What if I have context to share that could be useful for support?

If you know which application engineer is responsible (you can tell this by the thread with the customer or in Salesforce by looking at the details for this particular issue), either DM them or create a thread in #customer-support and address it to them to share the context. If you don’t know which application engineer is responsible, post in #customer-support and a member of the team responsible for triage at that time will help you make sure context goes to the application engineer who needs to be aware.

What if I disagree with the way an application engineer is handling something or feel I need to escalate for any reason?

Disagreements will happen, especially when technical troubleshooting is involved – when given an issue, if you ask every application engineer to try and solve it, it is normal and healthy to get a different way of going about that from each person. As with any disagreement, practice clean escalations as outlined here.

Can I ask that an issue be reassigned to another application engineer?

It is very rare that support leadership will agree to reassign an issue to another application engineer. We have a limited number of people to help customers and doing this ultimately only succeeds in eroding trust with the customer. If an application engineer makes a mistake, we want them to take accountability, learn, grow, and correct the situation – this is a practice that nurtures trust and benefits us all in the long run. If you feel this is necessary, it is expected that you do so via a clean escalation as outlined here.

Additionally, customer experience research over the last decade has shown that transitions are very hard for customers; too much context is lost and customers feel like they have to start over (because they essentially do). In general, we try to avoid transitions and only do them as a last resort when an application engineer has extended time off or has reached critical level capacity and is not able to serve all customers they are responsible to well.

What if I am worried the customer feels solving an issue is taking too long?

This can happen for so many reasons – sometimes a customer is just feeling stressed, sometimes there is a due date they are working toward, sometimes our own sales process feels at stake, etc. And in all situations, anytime an issue doesn’t end its 2nd week with resolution (ie, it goes into its 3rd week), most customers start to feel uneasy. Whatever context you have is valuable to the application engineer responsible for handling the issue. Share it with them directly or via a thread addressed to them in #customer-support. If this turns into an escalation for you, as always, practice clean escalations as outlined here.

What if I am worried an issue/progress to resolve it is going to leave the customer unhappy with Sourcegraph?

If you are feeling worried, trust that, and share that with the application engineer responsible for handling the issue. Share it with them directly or via a thread addressed to them in #customer-support. If this turns into an escalation for you, as always, practice clean escalations as outlined here.

How does prod/eng know to prioritize a bug fix?

Most bugs are filed in our public repo and we leave our engineering teammates to assess them, prioritize them, etc. If ever something is more critical than the usual process, let the application engineer know and they can inform the engineering team responsible of whatever context may be useful to help with priority. You are also welcome to share the context directly in the relevant engineering channel, which can feel hard to figure out, so just remember it’s okay to lean on the application engineer responsible for the original issue for help facilitating context sharing internally.

What happens if a customer proceeds down an unsupported path and asks for help?

If a customer deviates from what is outlined in https://docs.sourcegraph.com/admin/deployment_best_practices, it is best to initiate the tech review process to get internal alignment on how we want to proceed given the situation.

What does “best effort support” mean?

If a customer, sales, and/or CE opt to move forward on an unsupported path, then the customer can expect “best effort support,” which means we may have to tell the customer we cannot answer their questions/help them debug a situation since we don’t have knowledge of the way they are trying to do things. Nothing should get to this point without going through the tech review process, which is when we also talk about how to communicate these expectations to the customer.

How would I know if a customer was doing anything deviating from best practice?

We made many exceptions for customers in the earlier days before the inception of the tech review process. All known exceptions (whether legacy or deliberately agreed to via the tech review process), can be found via the customer exception page.

In addition, each CE is responsible for determining whether a customer’s technical requirements are supported by Sourcegraph. Properly performing technical qualification for new customers prevents them from ending up in an unsupported scenario. There a few assets which are available to help properly qualify an opportunity:

• Product feature compatibility documentation: This page is intended as a reference of features by code host compatibility; each item will link to further documentation on the feature.
• Product feature maturity documentation: This page is intended as a reference of features by maturity level; each item will link to further documentation on the feature.
• What is supported in Sourcegraph?: Guidance provided by Engineering teams documenting supported features and functionality as well as feature limitations. This is used by CEs to perform technical qualification of customer use cases and configurations during trial planning and prior to trial kickoff.

What should I do if our customer reaches out to me asking me to follow-up on, or for an update on, something an application engineer is responsible for?

Let the customer know that you will have the application engineer responsible for the issue follow-up and let the application engineer know. It’s healthy to keep the application engineer in the driver’s seat and let them be fully responsible for customer communications on an issue they have taken responsibility to resolve.

Once an application engineer is assigned, does CS need anything from me?

Any context you have to share is valuable, otherwise, nope: We have you and the customer covered!

What is the best way to say “support will help you with this” to a customer?

The word “support” can often trigger our customers to assume they are about to have a poor experience. It’s best to say “one of our application engineers will help you with this” to help set-up for success the application engineer responsible.

What if I feel like the support request doesn’t have the proper priority (P1, P2) assigned either by support or by the customer?

Priority is determined by the nature of the issue as outlined in our contractual SLAs and is only assigned by the application engineer responsible for the issue. A customer’s frustration or timeline does not change the official priority. The customer’s feelings, timeline, etc is useful context. See [here](#What- if-I-have-context-to-share-that-could-be-useful-for-support?) for how to go about sharing that context so the application engineer responsible can prioritize their work accordingly.

What if, after cleanly escalating a concern that I have, it doesn’t feel like the situation is improving?

You and your manager should raise this to your CE director for guidance on how to proceed.

How do I alert CS to the fact that a customer issue is particularly critical - i.e., the customer is “down” or the customer is very angry or upset with us?

See [here](#What- if-I-have-context-to-share-that-could-be-useful-for-support?) for how to go about sharing that context so the application engineer responsible can prioritize their work accordingly.

Is there an abbreviation for application engineer?

AER. It’s best to just write it all out, but if you insist on abbreviations, AER is best to delineate from AE, which stands for account executive. For fun context, AER is a play on the trend in the US in the 80s when mechanical and electrical engineers would have badges for work that said Er or MEr, like Dr (short for doctor), where the Er was short for engineer.

Is it CS or CSE?

CS, which is short for customer support, which is the name of our function.