Commercial SA Engagement Model

Vision

The Commercial SA team is the best place for demonstrating technical talent and product passion motivating the commercial customer to establish their unified DevOps strategy.

Structure

The Commercial Solutions Architecture team is a part of the global SA Organization that focuses on primarily Mid-Market customers aiming to lead technical evaluation efforts in an efficient and effective manner. The team is divided into two main geographical regions: AMER and EMEA. Each region has its own team of Solutions Architects (SAs) who are responsible for supporting customers in their respective areas.

Team Roles

  1. Solutions Architects (SAs)
  2. Demo Architects
  3. Solutions Architecture Managers
  4. Director of Commercial Solutions Architecture

Commercial Solutions Architecture Engagement Model

SA Engagement Considerations

  • Solutions Architects (SAs) help prospects and new customers that are wanting to buy and consume more of GitLab’s offerings. Customer Success Managers and Customer Success Engineers guide a customer’s adoption of what the customer has already purchased. Professional Services works with a customer to implement what the customer has already purchased.
  • All requests for SAs are submitted using the SA Request button on the Salesforce Opportunity.
  • Salesforce opportunities should have MEDDPPICC (and required 7 methods applied).
  • Compelling events are to be clearly defined in the Command Plan on an opportunity with a positive Net ARR (or negative Net ARR when the account needs deep technical knowledge or needs to be resold).
  • When SAs engage, their notes and activities are logged across Salesforce (review the SA Activity Capture page) and the Customers & Prospects Google Drive directory.

Segment-Specific Engagement Models

The SA team’s engagement is segmented by the AE role, so that the SA engagement model is aligned with the Sales Organisation’s structures. See individual AE’s role, area, and segment in this report

Mid-Market

  1. Mid-Market First Order (FO): Early-stage 2-Scoping through 4-Proposal for opportunities where a Command Plan and Custom Pitch Deck are being leveraged where an SA is necessary. The goal is to complete the 3-Technical Evaluation prior to 15 days of the Close Date.
  2. Mid-Market Named (Key): Opportunities (regardless of stage) where an SA is necessary through the course of the opportunity. The goal is to complete the 3-Technical Evaluation prior to 30 days of the Close Date.
  3. Mid-Market Territory (Terr): 3-Technical Evaluation for opportunities where a Command Plan and Custom Pitch Deck are being leveraged and where an SA is necessary. The goal is to complete the 3-Technical Evaluation prior to 30 days of the Close Date.

SA Request Triage Process

The Commercial SA Triage Process is a structured approach to managing and prioritizing incoming Solutions Architect (SA) requests. This process ensures efficient allocation of SA resources and timely response to customer needs. The key steps in the triage process are:

  1. Request Submission:

    • All SA requests are submitted through the SA Request button on the Salesforce Opportunity.
    • Requests should include a completed Command Plan and MEDDPPICC information.

  2. Initial Review:

    • SA Regional Team (EMEA or AMER) members review new requests. The service level objective for these reviews is one business day.
    • The review includes assessing the Command Plan, technical requirements, and opportunity details.

  3. Evaluation of the “4 Questions”:

    • Is the Command Plan properly completed?
    • Does the SA have a good understanding of the customer’s current stack, competitive landscape, attendees, use cases, and motivations?
    • Does the SA have sufficient lead time for preparation?
    • Does the SA have relatable experience for this account?

  4. Assignment:

    • Based on the evaluation, the request is assigned to an available SA with the appropriate skills and capacity.
    • Assignment is done collaboratively within the SA Team, prioritizing “two pairs of eyes” principle.

  5. Prioritization:

    • Requests are prioritized based on factors such as deal size, strategic importance, and urgency.
    • Fast-track prioritization is available for time-sensitive requests.

  6. Communication:

    • The assigned SA is responsible for communicating with the Account Executive to notify them they are working on the account, confirm details, set expectations, and discuss possible account strategies.
    • The SA and AE disucss timeline, next steps, agenda for the next meeting and roles they will play in the call
    • Any additional information or clarification needed is requested at this stage.

  7. Preparation and Execution:

    • The assigned SA prepares for the engagement, which may include customizing demos, researching the customer, and collaborating with other team members.
    • The SA executes the requested activities, such as discovery calls, demonstrations, or technical deep dives.

  8. Follow-up and Documentation:

    • Post-engagement, the SA documents the outcomes, next steps, and any relevant information in Salesforce and the Customers & Prospects Google Drive folder.
    • The SA collaborates with the AE on any follow-up actions or additional support needed.

This triage process ensures that SA resources are utilized effectively, customer needs are met promptly, and the sales team receives timely and valuable technical support throughout the sales cycle.

Guidelines for efficient triage process

#1: Triage within One Business Day

It doesn’t need to be within an hour. You can eat lunch first

  • Totally Acceptable Behavior: A new opportunity is created and sits for 3 hours because the Team is busy with demos and life.
  • Totally Acceptable Behavior: A new opportunity is created, and someone in the Team’s Slack channel says “hey there is a new opp and I would like to discuss” and that the Team follow-up discussion doesn’t come for 2, or even 4 hours, because the rest of the Team is busy with other things. This is still okay. The wait period is not a diss to anyone, the Team will get to it when they can, in natural pauses of the day.
  • One Full Business Day Defined: If it comes in at 4pm, the Team has until 4pm the next day to triage.
#2: Encourage a Second Pair of Eyes Without Delaying Assignment

If possible, two team members review a Command Plan before or after initial assignment

  • Whenever possible, a second team member should review the Command Plan to provide additional insights and ensure thorough understanding. This second review can happen after the initial assignment to avoid any delays in responding to the request.
  • Once an opportunity is assigned, the assigned team member is enouraged collaborate with another team member or a reporting manager to review the plan, verify goals, and identify next steps. This ensures that we maintain quality and strategic alignment without compromising our responsiveness.
  • There are cases where a second review may not be feasible or necessary, such as:
    • Fast-track prioritization for demos that were scheduled with less than 24 hours notice
    • Very specific communication language or skill required for the engagement (which means the request can be directly assigned to a specific SA)
The 4 Questions

There are often ‘what-if’ scenarios when an SA evaluates an incoming lead. These 4 questions give us the start to our async Slack conversations. Should this meeting move forward if I don’t know ‘X’? is exacty when the members of The Team will able to add context, and conversation to the Triage Collaboration.

  • #1: Is the Command Plan Properly completed? Read through the Plan. Identify if anything is missing.
    • Goal: Make it acceptable for the AE and the Command Plan not to be perfect. Make it thusly acceptable for the SA Team to ask clarifying questions and request more information before the opportunity is assigned, and before the next proposed meeting can take place.
      • Command Plan clarification questions are a great opportunity for our experienced SA org to lead and guide those folks who are in the sales org who are newer to GitLab and/or DevOps. Having the proper time for a feedback loop serves everyone involved in the lead. If we don’t tells our AEs what more we need, how else will they understand what to ask in the future?
  • #2: Based on the Command Plan, does the SA have a good understanding of the following:
    • Current DevOps stack? (SCM, Plan, CI/CD, Cloud Vendor(s), Deployment technologies)
    • What are the evaluated competitive technologies? (ex: GitHub, ADO, Atlassian)
    • Who will be attending the meeting? Names and titles need to be identified (LinkedIn, here we come).
    • What are the specific use-cases they are looking for GitLab to address?
    • Why Now?
    • It is totally fine if all the answers aren’t known during triage — use this as an opportunity to do discovery, collaborate, and gather information together as the engagement progresses.
  • #3: Does the SA have the lead time to prepare; is the meeting is not scheduled within 12-24 hours of the request
    • Goal: AEs to hold off on scheduling the next customer meetings until the SA Team has enough time to evaluate if all correct information has been collected in Questions 1 & 2.
      • SAs deserve time to clarify on Command Plans with the AEs and prepare demonstration environments. GitLab is a large, and ever changing platform - the product is forever being delivered (every month). The SA team requests proper time to prepare so they can deliver the best results.
      • Sometimes, a lot of runaway is not possible. We will still have a ‘Fast Track’ process that allows the AE to both mark the request record in Salesforce (for future metrics) and notify the Team
  • #4: Does the SA have relatable experience on this type of account.
    • ‘Yes’ could be the “preferred” answer depending on the account and timeline.
    • But ‘No’ is also a ‘Yes’. Solution Architects belong to a learning-focused organization. Less experienced SAs are going to continue to take on accounts where they do not know everything, and will have a chance to learn with the support of the wider team

Expectations when working with an SA

Running Meetings

  • All meetings should be planned with clear desired outcomes available to the SA
    • Why does the prospect want to meet with us?
    • What are our meeting objectives/goals?
    • Agenda and list of attendees should be provided in advance;failure to provide this information could delay in the scheduling or declination of a meeting request.
  • SA activities include:
    • Discovery calls allow for pain to be identified and can be effective way to help build an awareness of the consequences of that pain both for the customer and the GitLab account team.
    • Demonstrations align value to capabilities within the product, aiming to speak to the needs of the customer.
    • Technical Deep Dives are used to show off a very specific function or capability within GitLab’s product.
    • Reverse AMAs where the SAs evaluate the customer environment and provide recommendations on ways to more effectively use GitLab.

Post-Sales Engagement

Customer Success Manager assignment is not available for the majority of Commercial Accounts

As an opportunity enters into either the Negotiating or Awaiting Signature stage, the Solutions Architect and Account Executive ought to begin introducing the customer to a Customer Success Manager following the Commercial CSM Transition Process.

Solutions Architects ought to be primarily engaged with accounts that have active opportunities in Salesforce.  When we work with customers, it’s easy to build a trusted advisor relationship with them that persists past the end of the sale.  In these cases, SAs must use their judgment in determining when to redirect a customer to the proper support channel for follow-up questions.

Below are a few example responses an SA can provide customers that reach out for help after a deal closes. Please leverage your personal connection to them and their company to customize these as you see fit.

Accounts without a Customer Success Manager

Thanks for reaching out!

In order to best direct your question and provide you a timely response, can you submit a support ticket with our support team? Additionally, I have copied your Account Executive as they can help escalate your request if necessary. Below are some links to get started with GitLab support.

I thoroughly enjoyed getting a chance to work with you and role is primarily focused on our customers that are involved in pre-sales engagements; and being a person of one, I don’t want to be a bottleneck to you getting a response.

You can go to support.gitlab.com and submit a new request. Please use your company email address and an account and password will be created for you. There are more details regarding reaching out to support.

Accounts with a Customer Success Manager

Thanks for reaching out!

In order to best direct your question and provide you a timely response, can you submit a support ticket with our support team? Additionally, I have copied your Customer Success Manager and Account Executive, as well, as they can help escalate your request if necessary. Below are some links to get started with GitLab support.

I thoroughly enjoyed getting a chance to work with you and role is primarily focused on our customers that are involved in pre-sales engagements; and being a person of one, I don’t want to be a bottleneck to you getting a response.

You can go to support.gitlab.com and submit a new request. Please use your company email address and an account and password will be created for you. There are more details regarding reaching out to support.

Below are some additional items you can share with the customer.

  • Search GitLab documentation and issues with these pro tips!
  • If you do not find a proposed feature in the GitLab issues list, please contribute an idea to our product team to improve the community’s experience!
  • GitLab Documentation covering How-Tos for Installation and Day-to-Day usage.
  • GitLab is fortunate enough to have a strong community of contributors where you can search for ideas and issues within the GitLab Forum or moderated subreddit.
  • With transparency being a value of ours, we strive to push content daily to both the GitLab Youtube and GitLab Unfiltered Channel. You will find How-Tos and Daily Engineering conversations in these channels.
  • If you need engineering assistance, please create a support ticket. Your team has “Standard Support” which means “Next Day” or 24-hour support Monday thru Friday.

On-site Engagement

Solutions Architects are highly versatile and can be leveraged for on-site engagements that require direct access to valuable stakeholders. This approach allows for Solutions Architects to engage with key decision-makers in real-time, gather critical insights, and provide tailored recommendations based on their expertise.

On-site requests should primarily be driven by the desire of the customer. No on-site will be perfectly executed. As a team, learning how to best leverage through iteration on-sites is a critical capability for us to build.

  • Giving a demo to a large crowd with various personas that otherwise would not have been engaged virtually.
  • Running a workshop where the given customer has requested this to be done in person.
  • Meeting with executives in a room to help discuss their initiatives and cast a vision for GitLab within their organization.
  • Conducting a Day In The Life of A Developer assessment
Pre-Requisites for On-site Engagements

Any customer on-site must have the following:

  • A customer requesting or accepting proposal for the on-site with an agreed-upon agenda
  • A predefined initiative with the budget that aligns with a problem GitLab can solve within a price range that GitLab can be purchased. This budget can either come from net new spend or from reclaiming spend where the existing budget and renewal dates are known.
Budget Approval Process for On-site Engagements

Submit a Request for Approval

Prior to conducting any on-site engagement, approval from the Solutions Architect (SA) Manager and Area Sales Manager (ASM) is required. The intent of this approval process is primarily to catch any budget concerns, provide guidance on building proper justification for the engagement, and create visibility across the team to help build consistency. As the team gains experience with on-site engagements, this may move towards a don't ask, do tell approach. Regardless, SAs are to be trusted to do the right thing when it comes to determining the need for onsites.

To facilitate the review process, the following information should be provided by submitting an issue:

  • Customer SFDC Opportunity Link: The link to the customer opportunity being pursued with updated Help inside of Command Plan listing out Technical Details of what is needed for an on-site.
  • Estimated Cost: The amount expected for travel and lodging (not including meals) for on-site engagement.
  • GitLab Team On-Site Attendees: The team members required to attend the on-site engagement. If a Customer Success Manager is aligned to the account, please make sure there is collaboration.
  • Summary of Customer Engagement To Date: An overview of the ongoing activities with the customer.
  • Customer Stakeholders/Teams: A list of key stakeholders who will be present during the engagement, along with any outstanding or pending activities on-site.
  • On-Site Proposed Date(s): The proposed timeline and agenda for the on-site engagement.
  • On-Site Agenda: The proposed agenda for the on-site on each given day
  • Outstanding Activities Prior to Scheduling: What needs to be completed prior to the event

This review process aims to help ensure on-site engagements have the highest level of professionalism and that they deliver the intended value to the customer.

Commercial SA Processes

Async Slack support

In some cases SA support might be required in early stage or not fully qualified opportunities. Slack can be used for answering narrowlly-scoped technical questions, providing additional customer outreach materials or helping an Account Executive with a narrowly-scoped customer inquiry. These requests can be served asynchronously via Slack:

  • AMER: #cs-commercial-amer-support
  • EMEA: #sa-commercial-emea-support

These Slack channels are considered to be a safe harbor for all Commercial AE <-> SA communication. When asking questions, please ensure you always provide as much context as possible; including the SFDC URL, and type of subscription (SaaS or Self-Managed). Solutions Architecture will monitor and provide best effort support on these requests. Avoid using these Slack channels for cases that require technical discovery and solutioning. These have to be handled via standard SA Request process.

Demo Jam

With the continuous iteration and releases of GitLab, it’s important to stay up to date on the newest capabilities while staying sharp on existing use-cases to best serve customers. The Commercial Demo Jam serves as a safe forum for the Commercial SA team to practice demoing features, discuss potential customer objections, and articulate value through storytelling.

Structure:

  • Demo Jams are hosted twice a quarter as a part of Global Bi-Weekly Meeting as a 15-25 minutes secondary agenda
  • Each session should consistes of a ~5 minutes demo (recorded or live) and ~5 minutes for team feedback/discussion.
  • Recordings are published to the Solutions Architecture playlist on GitLab Unfiltered.

Peer Review

Commercial SA team recognizes Peer Review sessions as a key activity in elevating the quality of pre-sales efforts, fostering collaboration, promoting continuous learning, and ultimately increasing the chances of successful client engagements.

Structure:

  • Peer Reviews are hosted twice a quarter as a part of Global Bi-Weekly Meeting as a 15-25 minutes secondary agenda
  • Duration: 25 minutes (assuming two presenters)
  • Two opportunities are reviewed during the session (10 minutes each)
  • Outcomes are documented and are stored in Commercial SA / Reviews & Retros

Solutions Architect Judgment Indicator

The Solutions Architect Judgment Indicator (SA Judgment) is a metric used to assess the technical perception and feedback regarding current opportunities. It aids in making informed decisions and effectively managing sales pipelines. This indicator enhances the precision of forecasting by providing a means to validate AE judgment based on the technical seller’s assumptions. It also facilitates discussions during deal reviews and pipeline analysis by highlighting potential misalignments more easily.

The key aspects to take into consideration:

  1. Technical statement
    1. Customer knowledge: current state well documented (internal)
    2. Clear use cases. Identified pains.
    3. Product-match. Identified capabilities to close the gap.
  2. Customer implication (customer provides the right resources to scope the project, treats the project with the right priority)
    1. Access to development, information security and operations. Technical/lead developer involved with the right skills
    2. Connection to the technical validator/buyer
    3. Established communication channel and responsiveness

The overall score will be tracked in the existing SA Validated Tech Eval Close Details in SFDC with the following structure: [COLOR] Initials Date: One line qualitative comment with [COLOR] equals to:

  • [RED]: Indicates high risk or significant issues present in the opportunity’s presales forecast. These issues might include technical challenges, unclear requirements, or insufficient resources allocated.
  • [YELLOW]: Suggests moderate risk or some concerns in the opportunity’s presales forecast. This could include minor technical hurdles, scope creep, or potential resource constraints.
  • [GREEN]: Signifies low risk or favorable conditions in the opportunity’s presales forecast. This indicates that the technical aspects are well-understood, resources are adequate, and the forecast is on track.

Example: [RED] VD 17/10: No access to technical buyers, no clear use case.

Solutions Architects are required to fill out in their judgment on all opportunities meeting these criteria:

  • EMEA COMM Business Unit
  • Net ARR >$50K
  • Stage: 3+ (potentially 2+)

Team Meetings

Commercial SA team meetings are held on a regular basis to ensure alignment, share knowledge, and discuss important topics. The following meetings are part of the Commercial SA team’s schedule:

Global Team Meeting

  • Frequency: Bi-Weekly, every other Monday
  • Duration: 50 minutes
  • Purpose: Discuss global initiatives, share best practices, and align on cross-regional topics
  • Second half of the Global Team Meeting is dedicated to specific topics:

Regional Team Meeting (EMEA or AMER)

  • AMER
    • Frequency: Weekly on Monday
    • Duration: 50 minutes
    • Purpose: Connect as a team, discuss any ongoing initiatives, share updates, provide feedack, foster open discussions
  • EMEA
    • Frequency: Bi-Weekly, every other Monday
    • Duration: 50 minutes
    • Purpose: Connect as a team, discuss any ongoing initiatives, regional priorities, share updates, and address any pressing issues

Manager Sync

  • Frequency: Weekly
  • Duration: 25 minutes
  • Purpose: Discuss team performance, address any challenges, and align on priorities for the upcoming weeks, months, quarters

Weekly Standups (EMEA)

  • Frequency: Weekly
  • Duration: 25 minutes
  • Purpose: Quick check-in to discuss workload, ongoing tasks, blockers, priorities for the week, and triage any open SA Requests

All team meetings are facilitated to be asynchronous friendly. Therefore, all meetings are recorded and shared with the team. Team members are expected to attend these meetings regularly, or review and contribute to the discussions and share relevant information asynchronously

Commercial SA team members are strongly encouraged to take time off as part of GitLab’s paid time off policy. Taking off can be intimidating as we may support multiple customers at any given time. To best support our customers, consider the following:

  1. Create a PTO coverage issue A PTO coverage issue may not always be required but here are a couple guiding examples on when to create one:

    • Customers are running an active trial and may need technical guidance.
    • Leaving for more than 2 weeks and need to distribute the workload across the team.

  2. Announce your time off to your team and, share the PTO Coverage issue link, and communicate any expected coverage requirements.

Last modified November 1, 2024: Remove trailing spaces (6f6d0996)
View page source - Edit this page - please contribute. Creative Commons License