FAQ for CE about how support works at Sourcegraph
This page is for new members of our CE organization. It expands on the snippet summaries of how CE and CS work together found in the CE section of the handbook, as well as the CS section. It translates the support workflow to something more relevant for the CE perspective. It is written question-answer style to make it a useful reference document beyond the onboarding phase.
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:
| Request from customer | Which team is responsible for helping |
|---|---|
| Feature request | CE – see surfacing feedback for details |
| Licensing question/issue | CE |
| Security questionnaire/question | CE – see responding to customer security reviews |
| Deployment guidance | CE is responsible for suggesting the deployment method and tooling based on the customer’s environment and our documented deployment guidance and best practices. Errors that arise during deployment, or when something is not working as expected, should be routed to CS for troubleshooting, though CEs are always encouraged to troubleshoot to the best of their ability. |
| CE-written Kustomize overlays | The expectation for self-hosted customers is that they can write these themselves; if they need help, SE will answer questions, but will not write, nor maintain these. |
| CE-created script not working | In the event that CE opts to provide a customer a script of any kind, help from SE will be best-effort. |
| How to drive adoption, usage, change, etc. using the product | These types of requests are considered more along the lines of strategic guidance and are the responsibility of the CE team |
| How to do X in the product | CEs are encouraged to answer how-to questions, but CS is ultimately responsible for ensuring these are answered. If a question comes up on a call, a CE can either seek the answer in #ask-prod-eng or engage CS to help the customer. If the CE chooses to research and provide the answer themselves, they are responsible for ensuring they respond back to the customer and confirm that the question has been addressed completely. If the customer asks via the shared Slack channel or by emailing support@sourcegraph.com, these go into the CS queue and are only closed if the CE engages before an support engineer. This is the biggest gray area and it’s always okay to coordinate in the #customer-support channel. A CE can ask @cs-triage how they plan to triage something; and similarly, a member of @cs-triage might ask a CE for more context to determine whether to put these in the queue for an support engineer. |
| Configuration not working as expected | CS |
| Debugging/troubleshooting | CS |
| Bug report/security bug report | CS |
| Deviations from best practice guidance | Capture the risk in the Salesforce opportunity and raise for discussion within the internal prospect channel and in your next 1:1 with your manager. |
| Incident communication | CS as described here |
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 support 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 support engineer workflow or triage workflow. If you have any specific questions beyond that, ask the SE 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 support engineer to debug?
We like to be prepared for calls. If ever you are on a call and it feels relevant for an support engineer to join, create a post about the issue in the customer Slack channel or email support@sourcegraph.com with the customer included. An support 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 support 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 support engineer can engage to determine a time); and work with the support 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 support engineers are managing multiple cases for a number of different customers, it is likely not possible to get an support 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 support 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 support 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 support 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 support engineer who needs to be aware.
What if I disagree with the way an support 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 support 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 support engineer?
It is very rare that support leadership will agree to reassign an issue to another support 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 support 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 support 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 support 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 support 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 support 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 support 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, SE will do their best to help the customer; however we cannot guarantee anything.
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.
How would I know if a customer was doing anything deviating from best practice?
Part of the technical qualification stage of the deal (Stage 2) is for the CE to determine whether a prospective 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.
- 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 support engineer is responsible for?
Let the customer know that you will have the support engineer responsible for the issue follow-up and let the support engineer know. It’s healthy to keep the support 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 support 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 support engineers will help you with this” to help set-up for success the support 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 support 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 support 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 support engineer responsible can prioritize their work accordingly.
Is there an abbreviation for support engineer?
SE.