From 31849b0398d28af5bd0e6849ba78b741f0f23ac3 Mon Sep 17 00:00:00 2001 From: amenne Date: Mon, 8 Jan 2024 17:10:44 -0700 Subject: [PATCH] updates to CE handbook pages (#8414) Delete old processes (tech review, tech design docs, references to CE being post-sales) and made updates to reflect new messaging (new first call playbook and demos) and procedures (CE leading troubleshooting on trials), etc. --------- Co-authored-by: Aimee --- .../departments/technical-success/ce/index.md | 19 ++-- .../ce/process/tech-reviews.md | 56 ------------ .../ce/process/tech-win-process.md | 43 +--------- .../ce/team-culture/index.md | 21 +++-- .../ce/team-culture/team-norms.md | 1 + .../ce/team-culture/working-with-customers.md | 86 ++++--------------- .../support/process/ce-faq.md | 14 ++- 7 files changed, 51 insertions(+), 189 deletions(-) delete mode 100644 content/departments/technical-success/ce/process/tech-reviews.md diff --git a/content/departments/technical-success/ce/index.md b/content/departments/technical-success/ce/index.md index cb0071b05991..2a0c863b52ab 100644 --- a/content/departments/technical-success/ce/index.md +++ b/content/departments/technical-success/ce/index.md @@ -2,7 +2,7 @@ ## Who we are -Customer Engineering at Sourcegraph is responsible for the pre-sales technical success of prospective dev users. We serve as the product experts during the sales cycle, leading product demonstrations, technical solutioning, and trials for new prospects and new opportunities within existing customers. +Customer Engineering at Sourcegraph is responsible for the pre-sales technical success of prospective dev users. We serve as the product experts during the sales cycle, leading technical discovery, product demonstrations, technical solutioning, and trials for new prospects and new opportunities within existing customers. ## Our Team Purpose Statement @@ -10,18 +10,25 @@ Building trusted relationships with prospective dev users by aligning our soluti ## Team KPIs / Measures of Success -The two primary team KPIs for CE are: +The three primary team KPIs for CE are: -- iARR +- New Annual Contract Value (New ACV) - Technical Closure of Trials +- Trial Cycle Time -### iARR +### New ACV -As the pre-sales technical leader, CEs play an integral role in closing incremental annual recurring revenue. This dimension looks at the number of new customers acquired, net number of opportunities successfully closed, and number of products sold whether on a net new prospect or within a new team at an existing customer. +As the pre-sales technical experts, CEs play an integral role in closing new business that leads to new incremental revenue for Sourcegraph. This dimension looks at the number of new customers acquired, net number of opportunities successfully closed, and number of products sold whether on a net new prospect or within a new team at an existing customer. ### Technical Closure of Trials -During the sales cycle CE's typically lead a customer through a technical validation (trials). A primary measure of success is the technical closure of a trial, which we refer to as achieving the technical win. For any deal that enters Stage 4 (technical validation), we expect the CE to lead the customer through a successful technical validation based on their stated needs and evaluation criteria. +During the sales cycle CE's typically lead a customer through a technical validation (trials). A primary measure of success is the technical closure of a trial, which we refer to as "achieving the technical win". Achieving the technical win means that the prospective buyer agrees that our solution and capabilities meets their technical requirements and expectations. + +For any deal that enters Stage 4 (technical & business validation), we expect the CE to lead the customer through a successful technical validation based on their stated needs and evaluation criteria regardless of outcome of the overall opportunity. Our target is 80%. + +### Trial Cycle Time + +This looks at the efficiency and duration of the technical evaluation (trial) itself. The technical evaluation happens during Stage 4 of the sales cycle. Our goal is to complete a complex trial within 30 days, and complete the majority of standard trials within 21 days. ## Team Reference Resources diff --git a/content/departments/technical-success/ce/process/tech-reviews.md b/content/departments/technical-success/ce/process/tech-reviews.md deleted file mode 100644 index cf3e6d9cc5d0..000000000000 --- a/content/departments/technical-success/ce/process/tech-reviews.md +++ /dev/null @@ -1,56 +0,0 @@ -# Tech Review Process - -## Background / Context - -In Q4, we initiated a [technical review process](tech-win-process.md#tech-review-process) to enable collaboration between CE and Support, Sales, and Engineering around non-standard or high-risk customer technical requirements. This effort directly impacted our ability to positively influence our revenue goals as a company and drive deals to successful closure. - -As part of the pre-sales process, CEs capture the technical requirements and design of a customers’ intended architecture in the Technical Design Doc. For any Sales-designated Key Prospects or any prospective customers with non-standard or high risk requirements, the TDD is sent through the Tech Review process for review by EPS (Engineering, Product, Support) before initiating a Trial. Subsequently, prior to Production deployment, the TDD is then updated and reviewed by Engineering for any prospective customers with non-standard or high risk requirements intended for their Production Infrastructure. - -As part of the pre-sales process, this has proven to be a success in gaining internal alignment and collaborating to benefit our prospective customers. Moving forward, however, we continue to require close alignment and collaboration internally to ensure the long term technical success of our customers. - -## Post-Sales CE & S/Sales <> Engineering Collaboration - -With respect to concerns about asks that customer facing teams may have or work that may be required to make our customers successful after the sale is complete, additional technical needs may arise from time to time at different points in their partnership with Sourcegraph. - -Today, where a customer need falls outside of what exists or is supported in our Product, CE logs [Product Gaps](tech-win-process.md#surfacing-product-feedback) in Salesforce to surface these requests to Product for consideration onto the [Roadmap](https://docs.google.com/document/d/1XNrbBtkS8_lsjKxV8zvNfb1sn1Ug9Zhc24LFLCOa-Ic/edit). If / when added to the Roadmap, CE and Sales can track progress from the Roadmap. - -Where we uncover that, in order to make a customer successful technically, they require Engineering resources / effort that is unplanned and un-prioritized, the account CE is expected to write up the details: capture the clear asks (concern / problem statement / etc), provide context if it impacts any other customers, and provide any other business context in order to raise the request through the technical review process employed for pre-sales opportunities today. This allows for transparent alignment and collaborative decision making between Sales, CE & Support, and Engineering. - -Where we encounter situations that we are unsure if a customer is following a best / supported practice, the account CE is expected to write up the details: capture the clear asks (eg validation required) and provide context around the ask and the customers’ technical design and raise the request through the technical review process employed for pre-sales opportunities today. This allows for transparent collaboration on defining the expectation or best practice and aligning on next steps in support of the customer's needs. - -Where an existing customer runs into an issue, Support leads and guides the customer to resolution. If and where CE can provide context to Support to they do; however, Support are the drivers of these activities. - -All communication around the decision to proceed with an opportunity based on technical requirements / needs should occur in the #tech-reviews channel for visibility from the appropriate stakeholders. Although we aim to run this process asynchronous through the #tech-reviews slack channel, any individual can request a synchronous meeting, as warranted, to discuss and align on next steps. - -## What the tech review process is / when to employ it - -- Think of this like an RFC for our customers when we have found ourselves in a situation where input/comments/buy in/decisions are needed to move something forward. -- When cross-functional alignment and a decision or commitment is needed from Product/Eng/Customer Support/CE/TA/Sales for a customer. -- If technical and business context needs to be provided to EPS to either gain alignment on a solution and go forward plan in support of a customers’ (or multiple customers) needs, or if tradeoff / prioritization conversations need to be had to align on timelines amongst leadership. -- Some common scenarios when we want to perform a tech review prior to proceeding to a trial: - - Airgapped instances - - Anything using docker-compose + batch changes - - Support risks or considerations (eg language barriers, no access to screen share) - - A permission model dependent on Explicit permissions API - -## What the tech review process is not / when not to employ it - -- Typical support workflows (including support escalations) on reactive customer issues -- A mechanism for escalating a customer need in general. We have other processes and avenues for handling these scenarios. -- When in doubt about how to route a question, reach out to your leadership team and they’ll help determine the best course of action forward. - -## Expectations - -- Each request should include, at minimum the following: - - What is the current misalignment or gap between the customer and Sourcegraph best practices or documented product limitations? - - When does the customer need a decision or commitment by, and why (context as to what the timeline impacts)? - - Is this misalignment based on a new or existing customer requirement - i.e., what prevented us from catching this during technical qualification? - - What are the customers’ expectations; what happens if we don’t meet this request? - -## Decision Making Process - -Once a Tech Review has been submitted, the following process will be used to approve/deny requests. - -- CE VP will make a yes/no recommendation on the request based on feedback from the account team and Eng stakeholders. -- If we are going to say “no” to a request, we’ll document the reasoning and send to CE VP, VP Eng and Sales VP for final decision. -- If we are going to say “yes”, we will work with CE to craft messaging with the customer to establish they are operating outside of our normal guidelines and the impact of that, etc. diff --git a/content/departments/technical-success/ce/process/tech-win-process.md b/content/departments/technical-success/ce/process/tech-win-process.md index 49b9b5421dae..567c77f138af 100644 --- a/content/departments/technical-success/ce/process/tech-win-process.md +++ b/content/departments/technical-success/ce/process/tech-win-process.md @@ -4,7 +4,6 @@ - [Assets](#assets) - [Process](#process) - [Gates for Progressing Through Technical Win Phases](#gates-for-progressing-through-technical-win-phases) - - [Tech Review Process](#tech-review-process) - [Surfacing Product Feedback](#surfacing-product-feedback) - [Weekly Tech Win Review](#weekly-tech-win-review) - [Engaging Subject Matter Experts](#engaging-subject-matter-experts) @@ -140,7 +139,7 @@ The following criteria are used to determine whether a technical win should prog - Has the CE completed technical qualification of the customer’s usage scenario? - Has the CE recorded the technical landscape information (on the account level) and the trial technical landscape information (on the opportunity level) in Salesforce? - Has the CE defined the technical validation plan (demo, self eval, trial, etc.) which will be used to determine whether they have achieved the technical win? -- If the opportunity has non-standard or high-risk technical requirements as defined by the technical qualification criteria, has the CE gone through the [Tech Review Process](#tech-review-process) and received approval to proceed? _Note: the definitions of non-standard and high-risk change with each release of Sourcegraph, and it is the responsibility of the CE to be aware of the definitions at any point in time._ +- If the opportunity has non-standard or high-risk technical requirements as defined by the technical qualification criteria, has the CE documented risks and raised to leadership? _Note: the definitions of non-standard and high-risk change with each release of Sourcegraph, and it is the responsibility of the CE to be aware of the definitions at any point in time._ Not all opportunities will require a trial of Sourcegraph. The CE should be prepared to achieve a technical win by performing customized demos or workshops when possible. If the customer _must_ perform a trial, use the criteria below. @@ -177,46 +176,6 @@ Any artifacts created to support a prospective customer's Sourcegraph deployment - For complex deployments, CE has updated artifacts in the the [Technical Design Documents](https://drive.google.com/drive/folders/1o-4rB24vcYsOiUzSEr_vzJsC7pE03yYC) folder with details about the customer’s production deployment plans (unless IE is leading the Production Implementation) - Introduce TA to the customer -### Tech Review Process - -Deals flagged as having non-standard or high-risk requirements must go through the Tech Review Process before moving to Trial Deployment (late Stage 3). - -#### How the Process Works - -When a Tech Review is needed, the CE initiates this process by doing the following: - -1. Completes a peer review of the opportunity with a peer CE. -2. Records a 5 min loom video (stored [here](https://www.loom.com/team-videos/CE%20Technical%20Reviews)) to give a short verbal overview of the deal, the key risks for the opportunity including tradeoffs and pros or cons where applicable, and articulate specific asks of Product, Engineering, and Support. -3. Initiates the request in the #tech-reviews channel via the ‘Request TDD Review’ shortcut in Slack and includes a link to the loom video and to technical design artifacts (i.e. the Implementation Discovery Questions, architecture diagrams, etc.). -4. Documents the results of the Tech Review in Salesforce under Open Issues & Risks. - -[Product Directors](../../../../team/org_chart.md#product) will review and assign the appropriate Product Managers (or others involved) to review the video and artifacts. This asynchronous review should be completed within 3 business days. - -If there are additional questions, the Product Team member can request a synchronous review. That review will be recorded and documented to show the decision-making process and provide additional context. CEs are responsible for scheduling the synchronous review and including the appropriate stakeholders. - -#### Roles and Responsibilities - -##### Customer Engineer - -- Responsible for understanding and documenting the technical landscape and trial design details in Salesforce. -- Responsible for storing any technical review artifacts (such as Implementation Discovery Questions and architecture diagrams) in the shared Technical Design Documents folder. -- Responsible for identifying any non-standard or high-risk requirements. -- Responsible for registering Product Gaps against non-standard or high-risk requirements as required. -- Responsible for communicating with their AE when non-standard or high risk requirements emerge. -- Responsible for initiating the tech review process, when appropriate. -- If a request is made for a synchronous review, the CE will schedule and facilitate. - -##### Product, Engineering and Support - -- When a deal review request is raised, Product Directors are responsible for designating appropriate individuals to review. -- Initial feedback on the review should occur within 3 business days. -- Any member from Product, Engineering, or Support may request a synchronous review. - -##### Sales - -- Responsible for providing necessary business context around the deal. -- Where applicable, responsible for prioritization decisions. - ### Surfacing Product Feedback Because CEs work directly with Sourcegraph users in the course of assessing the technical fit of the product for a prospective customer, they will likely receive feedback about the product and identify product gaps which might potentially block adoption. All such feedback should be shared with the Product Team. diff --git a/content/departments/technical-success/ce/team-culture/index.md b/content/departments/technical-success/ce/team-culture/index.md index 29c2bdcd1aa5..b38b74873fe0 100644 --- a/content/departments/technical-success/ce/team-culture/index.md +++ b/content/departments/technical-success/ce/team-culture/index.md @@ -8,18 +8,23 @@ CEs interact with most every other team at Sourcegraph. This page details those - **How sales adds value to CE:** Sales, with their focus on the commercial relationship, introduces CEs to the customer relationship and helps CEs nurture the relationship. Both Sales Development Reps (SDRs) and Account Executives (AEs) share context with CEs prior to introducing them to the customer. - **Collaboration overview:** AEs and CEs are stably paired together on accounts throughout the customer journey. SDRs, during their prospecting efforts, are able to get support from the CE team via the @ce-sdr-collab slack user group. SDRs should post their question and tag this user group in the #ce slack channel. CEs in this user group are individuals on the CE team that are in their first 120 days; this provides great learning opportunities for the CE team to craft answers and confirm their product understanding; it in turn provides more structure and responsibility for responding to Q&As to help the SDR team be successful. -### Customer Support (CS) +### Technical Advisors (TAs) -- **How CE adds value to CS:** CE has nuanced context that is valuable to how support works with a customer; CE can also help clarify / remind customers we need information (during regularly scheduled calls) on the more tricky issues. -- **How CS adds value to CE:** CS is the go-to technical team for our CEs. CS resolves issues for customers both pre- and post-sales, allowing CEs to do more proactive work by taking on the reactive technical troubleshooting work when customers experience issues. -- **Collaboration overview:** CEs (or others -- including customers -- but primarily CEs) may engage support at any point during the pre-sales and post-sales customer engagement process. When a customer runs into an issue, the CE will allow support do the heads-down troubleshooting work. - - An account CE often collaborates with support engineers on issues. For example, CE may have a particular understanding or context about the customer or the situation. This is welcomed collaboration in support of customer issues! -- **What should CE do if the customer needs more help:** Given the relationship between the CE and the customer, it's not uncommon for our customers to reach out to CE for an update. In instances like this, the CE should work directly with the Support Engineer. If additional assistance is needed, the CE should reach out to @cs-leadership for additional guidance in the #customer-support channel, sharing context around the situation and the specific request. +- **How CE adds value to TA:** CE, as the team closing new business opportunities, have both important context and relationships with stakeholders that need shared and transitioned to TA so that they are successful, post-sales. +- **How TA adds value to CE:** TA, when working with existing customers, gain important knowledge and understanding about the customer which can benefit CEs during any upsell or expansion opportunities. +- **Collaboration overview:** CEs tend to hand off new customer engagements to the TA team. As part of this hand-off, CE shares knowledge and resources. When an expansion opportunity arises, TAs share important information with the CE team that benefits the sales cycle. + +### Support Engineering (SE) + +- **How CE adds value to SE:** CE has nuanced context that is valuable to how SE works with a prospective customer; CE can also help clarify / remind customers we need information (during regularly scheduled calls) on the more tricky issues. +- **How SE adds value to CE:** SE is the go-to technical team for our CEs. While CEs take the lead on all pre-sales issues, SE is always there to help if needed. +- **Collaboration overview:** CEs (or others -- including customers -- but primarily CEs) may engage support at any point during the pre-sales engagement process. When a prospective customer runs into an issue, the CE is the first line for resolving the issue. If needed, CEs can raise a Zendesk ticket for help or request help in #discuss-support-engineering. +- **What should CE do if the customer needs more help:** Given the relationship between the CE and the customer, it's not uncommon for our customers to reach out to CE for an update. In instances like this, the CE should work directly with the Support Engineer. If additional assistance is needed, the CE should reach out to @cs-leadership for additional guidance in the #discuss-customer-support channel, sharing context around the situation and the specific request. ### Software Engineers (SWEs) -- **How CE adds value to SWEs:** CE provides important insights from prospective and current customers which inform and serve as important inputs to Product roadmap. -- **How SWEs adds value to CE:** SWEs create a high quality product and when needed, helps educate CEs on how certain features work so that they can educate customers. SWEs also conduct via planned training sessions, periodic pairing, deep-dives on new features/products, etc. +- **How CE adds value to SWEs:** CE provides important insights from prospective customers which inform and serve as important inputs to Product roadmap. +- **How SWEs adds value to CE:** SWEs create a high quality product and when needed, helps educate CEs on how certain features work so that they can educate prospective customers. SWEs also conduct via planned training sessions, periodic pairing, deep-dives on new features/products, etc. - **Collaboration overview:** CEs can pose how-to questions and provide feedback via Slack ### Product diff --git a/content/departments/technical-success/ce/team-culture/team-norms.md b/content/departments/technical-success/ce/team-culture/team-norms.md index 5fa509c21527..56c850fced93 100644 --- a/content/departments/technical-success/ce/team-culture/team-norms.md +++ b/content/departments/technical-success/ce/team-culture/team-norms.md @@ -3,6 +3,7 @@ ## Recurring Team Meetings - **Team meeting** (weekly): Regular syncs for the CE team to discuss relevant topics +- **CE Teachbacks** (monthly): Regular sync for CE team to learn from each other - **TS Department Meeting** (bi-monthly): Sync for all teams in TS to share progress, updates, wins, and kudos ## OOO Protocols diff --git a/content/departments/technical-success/ce/team-culture/working-with-customers.md b/content/departments/technical-success/ce/team-culture/working-with-customers.md index 204f3084d56d..7a83b5c34d15 100644 --- a/content/departments/technical-success/ce/team-culture/working-with-customers.md +++ b/content/departments/technical-success/ce/team-culture/working-with-customers.md @@ -1,6 +1,6 @@ # Customer Engineering: Working with Customers -A CE, being both a pre-sales engineer and a post-sales technical account manager, works with customers in a number of different ways throughout the customer journey. This page captures high-level descriptions of the ways in which we work with or on behalf of our customers. Each section contains links to some supporting documents, templates, processes, playbooks, and recordings. +A CE, being the pre-sales technical sales engineer, works with prospective customers in a number of different ways. This page captures high-level descriptions of the ways in which we work with or on behalf of our prospective customers. Each section contains links to some supporting documents, templates, processes, playbooks, and recordings. - [Pre-Sales Customer Touchpoints](#pre-sales-customer-touchpoints) - [Discovery and Demo](#discovery-and-demo) @@ -12,8 +12,7 @@ A CE, being both a pre-sales engineer and a post-sales technical account manager - [Customer Discovery](#customer-discovery) - [Processes](#processes) - [CE Technical Win Management](#ce-technical-win-management) - - [Tech Reviews](#tech-reviews) - - [Creating Tickets -Trial Support](#creating-trial-support-tickets) + - [Creating Tickets -Trial Support](#creating-support-tickets-during-trials) - [Pre-to-Post Sales Handoff](#pre-to-post-sales-handoff) --- @@ -22,18 +21,22 @@ A CE, being both a pre-sales engineer and a post-sales technical account manager ## Discovery and Demo -The initial conversation(s) with a customer can vary in length and scope, but always involve discovery, that is uncovering their needs and motivations, and demonstrating product capabilities. This could range from an abbreviated 30-minute intro call with a smaller prospect, or multiple hour-long calls across various stakeholders and teams at an enterprise organization. +The initial conversation(s) with a prospective customer can vary in length and scope, but always involves discovery. That is, uncovering their needs and motivations, and demonstrating product capabilities. This could range from an abbreviated 30-minute intro call with a smaller prospect, or multiple hour-long calls across various stakeholders and teams at an enterprise organization. ### Resources - [Customer discovery playbook](#customer-discovery) -- [Demo education resources](../onboarding/education.md#trainings-and-demos) +- [First Call Playbook training](https://docs.google.com/presentation/d/11xnb8kU8al0nu5swyprfUqFQs88CU1wDYLy65uimZBs/edit#slide=id.g260d5c6e87d_0_0) +- [First Call deck](https://docs.google.com/presentation/d/11Nz_PCy-RP5uPExtao9Hx-UM1-EykHdaft66sH6BTcs/edit#slide=id.g28295ca06f6_0_323) +- [First Demo Script](https://docs.google.com/document/d/107vpU01GNuoW64iSOEMYE5iFsusiDPbk2uqB3VQCWjE/edit#heading=h.dmholmrckdap) -## Technical Design +## Technical Qualification -Early on in the process, we begin to understand the needs of our prospective customers. As we learn about them - their needs, their tech stack, their business, etc. we begin to document both the product and technical requirements and the business context of the deal in Salesforce. A subset of customers, especially those on self-hosted deployments, require the capture of additional information in order to successfully design a Sourcegraph deployment. Those additional artifacts, such as Implementation Discovery Questions, architecture diagrams, and other technical design elements should be stored [here](https://drive.google.com/drive/folders/1o-4rB24vcYsOiUzSEr_vzJsC7pE03yYC). These artifacts should also be linked from within your respective prospective customer [folder](https://drive.google.com/drive/folders/1gjXWQ1l0Fnt2pVS2ohx3w0cw-gaJ_Ez0) by creating a [shortcut](https://support.google.com/drive/answer/9700156?hl=en&co=GENIE.Platform%3DDesktop) in Drive. +Early on in the process, we begin to understand the needs of our prospective customers. As we learn about them - their needs, their tech stack, their business, etc. we capture technical details on the Salesforce opportunity. -For complex engagements, we have internal technical reviews with cross-functional teams (see [technical deal reviews](#technical-deal-reviews) below) that occur before approval to proceed to a trial deployment, to ensure we at Sourcegraph are collectively aligned on their needs and expectations, and so that the customer has the right expectations set and is positioned for success. +If a CE encounters a non-standard deal - that is, the requirements extend beyond our known scale or compatibility - the CE should document those risks on the opportunity and raise with leadership for review. + +For complex requirements, CEs should be on the lookout for opportunities to position Professional Services to help ensure successful outcomes. ### Resources @@ -41,11 +44,11 @@ For complex engagements, we have internal technical reviews with cross-functiona ## Customer Trials -Trials are an important and strategic part of our sales cycles because when developers start to use Sourcegraph, they love it and want to use it forever. Seriously! Typically, our trials run for about a month but sometimes longer. Before, during and after, you collaborate closely with your account executive to ensure a successful experience for the customer. +Trials are an important and strategic part of our sales cycles because when developers start to use Sourcegraph, they love it and want to use it forever. Seriously! Ideally, our trials do not run longer than 30 days - 21 days ideally. Before, during and after, you collaborate closely with your account executive to ensure a successful experience for the customer. Before the trial, you're working with the AE to scope and plan the trial - both use cases they'll test (which you'll enable them on) and technically how they plan to deploy Sourcegraph for the trial. -CE and AE should use the [Trial and Deployment Planning Template](https://docs.google.com/spreadsheets/d/1mi_540InPEs6_xmCE2gHzw6Vt9QHDx-IdGogQZN6Ezw/edit?usp=sharing) to complete planning activities in advance of trial start. Here's a breakdown of who leads which aspects: +CE and AE should use the [Joint Success Plan template](https://docs.google.com/spreadsheets/d/10nXs7INmzvKxGb5xPOTju8yxnkQXcBc3SEYdu20xFtM/edit#gid=1991584268) to complete planning activities in advance of trial start. Here's a breakdown of who leads which aspects: - Documenting their technical landscape (CE-led) - Trial use cases / metrics for success (CE-led) @@ -65,13 +68,11 @@ During the trial, CE is enabling and educating the customer on how to use Source ## Security Reviews -Often during a customer’s technical validation process for our product, they will have security-related questions about either Sourcegraph or the manner in which Sourcegraph is deployed (Cloud, Managed Instance, Self-Hosted). The process for handling customer security reviews and questionnaires is detailed here: [Responding to Customer Security Reviews](../process/security-reviews.md) - -The current CE Security SMEs are [Max Wiederholt](../../../../team/index.md#max-wiederholt) for US West / APAC and [Shawn King](../../../../team/index.md#shawn-king) for US East / EMEA. We occasionally rotate team members in this role. +Often before or during a customer’s technical trial, they will have security-related questions about either Sourcegraph or the manner in which Sourcegraph is deployed (Cloud, Managed Instance, Self-Hosted). The process for handling customer security reviews and questionnaires is detailed here: [Responding to Customer Security Reviews](../process/security-reviews.md). Many of the answers can be found on [Safebase](https://app.safebase.io/portal) which prospective users can directly request access to. ## License Keys -CEs are the team responsible for generating and maintaining license keys for customers. Here's some useful resources on how to do that: +CEs are the team responsible for generating license keys for prospective customers. Here's some useful resources on how to do that: - [Creating and maintaining license keys for customers](../process/license_keys.md) - [Recording of creating a new key for demo.sourcegraph.com](https://drive.google.com/file/d/1fYsBqdzdBLd0mzAu2FJxrWznRX0k-iqr/view?usp=sharing) @@ -96,62 +97,9 @@ Similar to playbooks, processes exist to ensure consistent practices amongst tea CEs are tightly aligned with the sales team and serve as technical experts, providing strategy and guidance to AEs during the sales cycle. Ultimately it is the CE that owns the “technical win” associated with an opportunity. The [CE Technical Win Management Process](../process/tech-win-process.md) outlines expectations around how Customer Engineering tracks and communicates the status of the technical win as part of all sales opportunities. -## Tech Reviews - -Tech Reviews are employed in both pre-sales scenarios and post-sales scenarios. - -- Tech reviews in pre-sales situations are documented as part of the [CE Technical Win Management Process](../process/tech-win-process.md). -- Tech reviews in post-sales situations are documented as part of the [Customer Success Process](../process/tech-reviews.md). - -## Creating Trial Support Tickets - -Customer Engineering is responsible for creating tickets on behalf of the customer, tickets should be created when the resolution requires additional troubleshooting. - -#### 1. Create Tickets for Trial Customers - -> [!NOTE] To create the ticket in Slack use the ❓on the corresponding Slack message or email trialsupport@sourcegraph.com - -#### 2. To begin, access the Support Agent in Slack to view the created tickets. Follow these steps: - -- Go to Slack and navigate to the Support Agent integration. -- Select the `Home` tab within Support Agent to see the list of incoming tickets under the `Waiting for Help` section. - -#### 3. Assigning Tickets - -To take ownership of a ticket and determine the appropriate action, follow these steps: - -- Locate the ticket you want to handle within the `Waiting for Help` section. -- Click on the three dots `...` next to the ticket and select `Start` to assign the ticket to yourself. - -#### 4. Responding to Customers within Slack or Foqal - -- Select `View Thread` to respond to the customer within the Slack thread or the Foqal ticket number located on the left to open the Foqal web browser. - -#### 5. Handling Chat Status - End Chat - -To manage the chat status and effectively organize your workflow, follow these steps: - -- When the communication with the customer is complete, go back to Support Agent and choose `End Chat`. - -#### 6. Transferring Trial ticket to Support Engineering - -In some cases, tickets originating from trial support may require additional guidance from our Support Engineers. In such cases, the Customer Engineering (CE) team should create a post in #discuss-customer-support to request a Support Engineer (SE) to take ownership of the ticket. Once the SE has confirmed, the CE can transfer ticket ownership from themselves to the appropriate Support Engineer (SE). --To transfer the ticket from Slack, select `...` under the `Home` tab in Support Agent, select transfer, and select the appropriate Support Engineer (SE) - -Before transferring a ticket to support please ensure that you include the following information as an internal note: - -- Customer details -- Link to the specific issue -- Detailed summary of the issue or question -- Consequences of not taking the desired action -- Any time considerations and their significance -- Any additional relevant information that can assist u - -Ways to add these internal notes: - -- **Slack:** In Support Agent, under `home` > `Your current chats` > select the dropdown `Options`, and `Add Ticket Notes` +## Creating Support Tickets during Trials -- **Zendesk:** In Zendesk, in the view `Trial Customers`, you can select your existing ticket, `Apply Macro`, select `Customer Support Ticket Request`, and add the internal notes. +CE is responsible for creating tickets on behalf of prospective customers via support@sourcegraph.com. Tickets should be created when the resolution requires additional troubleshooting. ## Pre-to-Post Sales Handoff diff --git a/content/departments/technical-success/support/process/ce-faq.md b/content/departments/technical-success/support/process/ce-faq.md index c637424ef839..a4cae08a596f 100644 --- a/content/departments/technical-success/support/process/ce-faq.md +++ b/content/departments/technical-success/support/process/ce-faq.md @@ -12,14 +12,14 @@ Whose superpowers are needed to help the customer will depend on what the custom | Licensing question/issue | CE | | Security questionnaire/question | CE – see [responding to customer security reviews](../../../../departments/technical-success/ce/process/security-reviews.md) | | 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/process/tech-reviews.md). | -| 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](../../ce/process/tech-reviews.md) to seek pre-agreement on whether questions/issues will be routed to CS or any other team within engineering. | +| 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 | This needs to be determined via the [tech review process](../../ce/process/tech-reviews.md). That process will determine the path for the customer which could vary from decision to decision. | +| 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](serving-as-a-messenger-during-incidents.md) | ## How does support know a customer needs help? @@ -80,17 +80,15 @@ Most bugs are filed in our public repo and we leave our engineering teammates to ## 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](../../ce/process/tech-reviews.md) to get internal alignment on how we want to proceed given the situation. +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. Nothing should get to this point without going through the [tech review process](../../ce/process/tech-reviews.md), which is when we also talk about how to communicate these expectations to the customer. +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? -We made many exceptions for customers in the earlier days before the inception of the [tech review process](../../ce/process/tech-reviews.md). All known exceptions (whether legacy or deliberately agreed to via the tech review process), can be found via the [customer exception page](customer-exceptions.md). - -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: +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](../../../../departments/product/tools/feature_compatibility.md): 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?](https://docs.google.com/spreadsheets/d/101JXaau2EPvi322AOFmNeoeuXSJqlruD8gBBsHl1fmI/edit#gid=33376279): 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.