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.
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|
|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, CS will answer questions, but will not write, nor maintain these without pre-agreement via the tech review process.|
|CE-created script not working||In the event that CE opts to provide a customer a script of any kind, it is best to initiate the tech review process to seek pre-agreement on whether questions/issues will be routed to CS or any other team within engineering.|
|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 email@example.com, these go into the CS queue and are only closed if the CE engages before an application 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 application engineer.|
|Configuration not working as expected||CS|
|Bug report/security bug report||CS|
|Deviations from best practice guidance||This needs to be determined via the tech review process. That process will determine the path for the customer which could vary from decision to decision.|
|Incident communication||CS as described here|
The shared Slack channels and firstname.lastname@example.org 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.
You can learn all you need to know about our SLAs here.
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.
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.
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 email@example.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 firstname.lastname@example.org 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.
Add email@example.com in cc (keeping the customer in copy, too) and share that you have copied in our support team to help out.
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.
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.
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.
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.
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.
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.
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.
Any context you have to share is valuable, otherwise, nope: We have you and the customer covered!
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.
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.
CS, which is short for customer support, which is the name of our function.