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.

Pre-Sales Customer Touchpoints

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.


Technical Design

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. Every single prospective customer must have a techincal design document estbalished, starting as early as Stage 2 - Qualification and completed into Stage 4 - Technical and Business Validation. We begin by capturing details about their pre-Sourcegraph business and document first their Trial design and configuration, and subsequently their Production design and setup.

For complex engagements, we have internal technical reviews with cross-functional teams (see technical deal reviews below) that occur before approval to proceed to a trial deployment, to ensure we at Sourcegraph are colletively aligned on their needs and expectations, and so that the customer has the right expectations set and is positioned for success.


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.

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 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)
  • Business value assessment planning (AE-led)
  • User survey planning (AE-led)
  • Deployment support and checklist (CE-led)
  • Technical configuration review (CE-led)
  • Trial rollout plan (CE-led)
  • Communication and ongoing support (CE-led)

During the trial, CE is enabling and educating the customer on how to use Sourcegraph. CEs orient our activities during the trial against the defined use cases and metrics for success to ensure developers are set up for success. It is the CE’s responsibility to deliver the technical win for the trial.


Security Reviews

Many customers send security questionnaires to complete. They are required to proceed with the partnership. The current process for completing them is:

  1. Work with the AE to get access to the security questionnaire.
  2. Note the customer preferred deployment type (self-hosted, managed, or cloud).
  3. If you (the CE) feel comfortable doing so, take a first pass at the questionnaire. Use the source of truth document.
  4. Talk to your region’s CE in charge of security reviews. Have them take a pass at it and review it. Please ensure timelines are properly communicated and enough notice is given to all involved stakeholders.
  5. If the Security CE feels it necessary, they may involve the product manager on the security team. Typically this involves asking one-off questions in the security source of truth document, but they may also request full security questionnaire reviews. Note that full reviews may require extra time to get prioritized and worked on by the security team.

The current CE’s in charge of security questionnaires are Max Wiederholt for US West / APAC and Shawn King for US East / EMEA. We occasionally rotate team members in this role.

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:

Post-Sales Customer Touchpoints

Post-Sales Engagement Kickoff

Once a customer signs on with Sourcegraph, we need to:

  • Generate a full license key.
  • Plan a kickoff call with our main contact(s) to plan the engagement.

On the kickoff call we plan our ongoing engagement with the customer. Different customers have different needs, so it’s important to talk through topics such as:

  • How often do they want to have check-in calls?
  • What types of trainings, webinars, or Q&A sessions could their team use? When?
  • Would they like any assistance or resources to integrate Sourcegraph into their developer onboarding process?
  • Anything else we can look to help them out with? Upcoming iniaitives they could use Sourcegraph for?


Webinars / Trainings / Q&A Sessions

The webinar you will most-often run is a Sourcegraph 101/102 (basically a longer and more in-depth version of the typical demo flow). It’s important to relate use cases to customer needs.

We may also hold specific topic trainings or Q&A sessions, depending on customer need.


Check-in calls

Check-in calls may be weekly, bi-weekly, monthly, or as-needed. Going in to a check-in call you should be familiar with:

  • Usage data
  • Current Sourcegraph version & upgrade info
  • New features in the latest version(s) and/or the product roadmap
  • Any recent or active questions or support issues or feature requests from the customer



We often hold QBRs, or Quarterly Business Reviews (sometimes referred to as an Executive Business Review), with our customers which recaps how Sourcegraph has been integrated into and creating value for their organization over the past quarter. These QBRs are typically created and presented by the CE assigned to the account, in conjunction with the account’s AE. They are typically presented in a slide deck format to executive-level leadership, and highlight usage metrics and use cases for their org. Additionally, they are used to gather feedback and comments from leadership regarding Sourcegraph.


Expansions and Renewals

Expanding Sourcegraph to a new team or unlocking new enterprise features could involve a full cycle of CE discovery and demos and value mapping. It could also include a trial for a new user group or with that new feature. A basic renewal or seat expansion may not involve CE beyond generating a new license key.

Ongoing Customer Support

While our CS team is primarily responsible for reactive technical support, we help keep an eye out on Slack for any questions or issues that come through. You can view any support issues in Zendesk by using our SFDC <> Zendesk integration. Go to the Account page in Salesforce and click the “Zendesk” tab to view.

At times a customer may raise a feature request or provide product feedback. It is our responsibility as CEs to gather that feedback and share with the product teams.


Account Management

As CEs we are responsible for the technical success of our customers. Post-sales we nurture these relationships and manage the accounts by paying attention to customer health metrics. Usage, adoption, and customer sentiment are important indicators that we monitor and address. It is recommended that CEs routinely monitor this to keep a pulse on customer metrics. There is also a link to this from the Salesforce Account record.



To enable CEs and ensure consistent practices, our team may produce playbooks from time-to-time. These playbooks should serve as a useful onboarding resource to new CEs and a helpful refresher for CEs as well.

Customer Discovery

The customer discovery playbook provides CEs with a framework and tools to successfully prepare for and conduct your first meetings with prospective customers (or even new stakeholders within existing customer organizations). These inputs should serve as the prerequisites to any customer demo because it enables you to tailor your content and talk track to what’s most relevant to the customer. It also provides key areas for CEs to consider and specific steps to take to ensure the CE has the correct context and knowledge to properly support a successful customer engagement beyond the initial meetings


Similar to playbooks, processes exist to ensure consistent practices amongst teams. Processes that the CE team either drives or heavily contributes to are outlined below.

Red Accounts

As the team accountable for our customers’ technical success, usage, and adoption of our products, CEs must keep a close pulse on the health of our customers. The Red Accounts Program exists to ensure we as a company are assessing customer health at all times.


For any account that is designated as having a health rating of red - either via calculated score or by a member of the account team - the AE and CE will jointly provide a current status of the account, identify any necessary asks of the business in order to best serve the customer, create an appropriate action plan, and track through to resolution (ideally promotion of the health from red to yellow or green).

Red Accounts Process

In slack, the #red-accounts channel has been created so that when the Customer Health field on the Salesforce Account record is set to Red, a post is auto-triggered in the slack channel and a corresponding row will be automatically added to the Account Tracker tab of the Red Accounts Google Sheet. The AE / CE will jointly fill in relevant information to understand current state, needs, and the intended actions. Any asks or needs against the intended action plan should be initiated via a thread on the auto-generated slack post; this allows for visibility and transparency.

Roles and Responsibilities

The CE will monitor the Customer Health dashboard and where appliable update the Customer Health field on the Salesforce Account record to red.

Should an AE or CE feel that an account which isn’t designated as red via the health dashboard, is in fact red for any reason (eg a champion leaves, etc) they should align, and the CE should update the Salesforce Account record to red.

Both the AE and CE are responsible for participating in the creation of the action plan, and overseeing the action plan through to resolution.

Technical Deal Reviews

There are three scenarios in which we would perform a Technical Deal Review:

  1. As the team accountable for our leading our prospective customers’ to the technical win, it is important that CE consistently captures appropriate business and technical context about the customer. When a non-standard or high-risk need emerges, a CE initiates a technical deal review. When a technical deal review is required, the opportunity must complete review before proceeding forward.
  2. For any Sales leadership-designation key prospect, a Technical Deal Review will be done before proceeding to trial.
  3. For any Sales leadership-designation key prospect, a Technical Deal Review will be done before the deal closes to review their Production needs.

Technical Deal Review Process

When a Technical Deal Review is needed, the CE initiates this process by doing the following:

  1. Completes a peer review with another CE
  2. Records a 5 min loom video (stored here) to give a short verbal overview of the deal, the key risks for the opportunity including tradeoffs and pro’s or con’s where applicable, and articulate specific asked of Product, Engineering, and Support.
  3. Initiate the request in the #tech-deal-reviews channel via the ‘Request TDD Review’ shortcut in slack; include a link to the loom video and to the TDD.
  4. Product Directors will review and assign the appropriate Product Managers (or others involved) to review the TDD.
  5. Complete async review within 3 business days.
  • If there are additional questions the Product team member can request a synchronous review. The review will be recorded and documented to show the decision-making process and provide additional context. The CE know is responsible for scheduling the synchronous review.
  1. Acknowledge completion in the TDD.

Roles and Responsibilities

  • CE

    • Responsible for creating the Technical Design Document (TDD) for each new customer.
    • Responsible for identifying any non-standard or high-risk requirements.
    • Responsible for communicating with their AE when non-standard or high risk requirements emerge.
    • Responsible for initiating the process to get the TDD reviewed prior to the deal progressing toward deployment or trial.
    • 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, responsibile for prioritization decisions.