Commercial SA Engagement Model

Commercial Solutions Architecture Engagement Model

The Commercial SA Engagement Model (SA Circles) intends to foster collaboration amongst 3-6 Solutions Architects and 20-25 Account Executives.

The SA team’s engagement is segmented by the AE role, so that the SA engagement model is aligned with the AE team structures.

Solutions architects are responsible for owning their engagement on opportunities. The “engagement model” is a general recommendation, not a rule, and will be left to the discretion of the solutions architect.

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.

SA Request Triage Process

Solutions Architects operate within Circles (small teams of SAs). Each Circle is responsible for managing their triaging process. When scheduling conflicts arise, SA Circles may distribute opportunity workload to other Circles. When taking PTO, or out on a sick day, an SA’s Circle is their first stop for backup.

  • Goals of Circle Triage:
    • Create a mechanism to pragmatically assign opportunities to members of our SA team who are available and ready - in time and skill set.
    • Enable SAs with a process that allows the majority of their time to be focused on current deals and projects that contribute to the greater Customer Success org - not Salesforce report refreshes.

SA Circle Triage Guidelines

#1: No Circle Team Member Self-assigns an Opportunity

Self-assignment does not happen without first discussing the opportunity and the “4 Questions” in the Circle-slack channel

  • This is the #1 immutable rule. All others build off of it. We must Collaborate, prioritizing The Circle and The Process over “just this once”.
    • We will have a Fast-track prioritization route for those demos that were scheduled with less than 24 hours. We will still collaborate in Slack circle-region channels when this situation occurs.
#2: Triage within One Business Day

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

  • Totally Acceptable Circle Behavior: A new opportunity is created and sits for 3 hours because the Circle is busy with demos and life.
  • Totally Acceptable Circle Behavior: A new opportunity is created, and someone in the Circle-slack channel says “hey there is a new opp and I would like to discuss” and that Circle follow-up discussion doesn’t come for 2, or even 4 hours, because the rest of the Circle is busy with other things. This is still okay. The wait period is not a diss to anyone, the Circle 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 Circle has 4pm the next day to Triage.
#3: Better Triage Happens with a Second Review

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

  • Some days, this may not be possible. If 1/2 the team is on PTO and the other 1/2 is slammed, then perhaps in the Slack circle-region channel we might to eachother, after a request for a Circle review, “don’t have time for 2eyes, if you have the capacity and feel fully comfortable with the 4 questions being fulfilled, then assign it to yourself”. The key is, to get here, as a Circle, we communicated on Triage.
    • The Circle’s Reporting Managers are considered a very valued 2nd person to review, when directly requested.
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 Circle 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 Circle 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?
  • #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 Circle 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 Circle in the Slack circle-region-aeasm channel (because the SAs will be doing other work than always watching incoming opportunities. See Point #2 in Triage Guidelines!)
  • #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 hopefully do even better with their small accessible Circle to constantly collaborate with.
    • An additional benefit of the Circle structure is we now have a dedicated small-group who are there for a main-assist.

Segment-Specific Engagement Models

See which region an AE is located within or leverage the Account Sales Territory in the Circle Slack Channel to determine an Account Executive’s segment.

SA Engagement for 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 Engagement for SMB

  1. SMB First Order (FO): Late-stage 2-Scoping and 3-Technical Evaluation 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. SMB Named (Key): Late-stage 2-Scoping and 3-Technical Evaluation 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 within 15 days of the Close Date.
  3. SMB First Year Expand (Exp): AEs should rely on the CSM and CSEs as much as possible for First Year Expand opportunities given that the focus of a customer’s first year is to adopt as much of what they have purchased as possible. If a customer has demonstrable adoption of GitLab and is looking for more of GitLab’s offering to use, then AEs ought to have the opportunity reviewed by their ASM prior to getting an SA engaged.
  4. SMB Pooled (Pool): Requests ought to be brought forth by the AE and approved by the ASM and SA Manager to ensure that the need for an SA is justified.

Expectations when working with an SA

Meeting Expectations

  • 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.

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: #cs-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.

Post-Sales Engagement

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.

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.

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.

Other Considerations

Team meetings
  • Team meetings are held on Mondays (Americas) at 10:30am PST for 25 minutes.
  • Try to be respectful of our scheduled 1:1’s meetings, though they can be more easily rescheduled in favor of customer engagement.
Meeting Follow up/Research

Live Optimization Sessions

Live Optimization sessions are one-time post-sales activities session conducted 1-2 months after a closed deal by a Commercial Solutions Architect in order to support and ‘fine tune’ net new SMB customers’ adoption of GitLab. Read more on the process in the SMB Sales Handbook.

SA Circles

The Commercial Solutions Architecture team leverages SA Circles for two primary reasons:

  • Circles accelerate our learning, as pre-sales professionals, with increased exposure and understanding of deals as they are in an active pre-sales cycle. This acceleration helps us get more immediate feedback to change direction, or ideas to enhance the positioning that has already occurred.
  • Circles normalize opportunity distribution. Ensure that some team members are not getting overloaded and burnt out, with the potential for other team members to sit with an empty queue, and perhaps under pressure to just ‘grab anything that comes’

Guiding Principles

The guiding principles of circles

Diversity, Inclusion, Belonging drives Collaboration

  • No one member is ‘in charge’ of a circle, as they will still report to regional managers. SA Circles are meant to be working groups of peers.
  • Circles reflect a diversity of seniority levels. The key benefit of a circle is receiving different points of views, and giving everyone opportunities for new learning experiences.
  • Circles support a combination of SMB, MM and Strategic AEs

Focus is on Efficiency and Collective Results

  • Strategically important opportunities that have been identified within an SA Circle ought to have increased awareness and focus from the more senior-level SAs. Segment-Specific Engagement Alignment will be a primary tool to indicate what is strategic but may deviate.
  • Success of an SA Circle is viewed from a team success perspective, not individual SA success
  • SA Circles have autonomy to manage their individual triage process, while being encouraged to share their learnings to the other SA Circles

Results-Focused and Collaboration fuels Iteration and Transparency

  • Experimentation within a cirlce is encouraged!
  • SA Circles will focus on being open about how work is triaged and performed.
  • Iteration will help ensure that we find ways to be proactive in a function that can stagnate when it is only reactive

SA Circle Experimentation

When a team decides to run an experiment for a given circle, it should be done in a way that is FAST:

That is to say, every experiment should have:

  • Frequent Discussions that help keep the experiment top of mind for the circle. Discussions should happen as much as possible within its respective issue.
  • Ambitious Scope with all-circle buy-in. Every team member within the circle should commit to putting serious effort into measuring an experiment’s success.
  • Specific Milestones that timebox the experiment and help keep it on track. Experiments should not be tested within a single quarter.
  • Transparency across all circles so that others can watch the experiment in action. This can be done in the form of an issue.

SA Initiatives

5-Minute Demo Framework

The 5-Minute Demo Framework is a method to quickly produce technical content that is easy to consume for the customer. The intent of the framework is to rapidly develop tutorials while also generating value-packed content for the customer to consume. This content can range from videos, blog posts, or tutorials. As a result of building and sharing out bit-sized videos, the Commercial SA team can scale out our reach to a broader technical audience. Moreover, as the content compounds, the Account Executive teams will have a bank of content to share asynchronously to customers used to deliver value to customers efficiently.

Topics Delivered Upon and Available to Customers

  • How to provision dynamic review environments using merge requests and Argo CD - Blog Post
  • How to automate testing for a React application with GitLab - Blog Post
  • CI/CD Modernization with GitLab - YouTube Link or Highspot Pitch Link
  • Build, Test, and Deploy to Google Cloud with GitLab CI/CD - YouTube Link
  • DRY Development: A cheatsheet on reusability throughout GitLab - Blog Post
  • Simple Kubernetes management with GitLab - Blog Post
  • GitLab GitOps Workflow - Youtube Link

Topic Curation

  • A demo wishlist (internal) has been made to help the team generate and prioritize one-off topics based off of field demand and interest.
  • A framework tutorial issue tracker has been created to organize tech and language framework tutorials. These tutorials will align to specific GitLab stages with end-to-end guides.
Tips for searchability
Practice and review
  • If you produce a video and are requesting feedback, feel free to add it to the Demo Jam agenda. An alternative is to record it and share it asynchronously in #cs_mm_sa slack channel for feedback.

Commercial 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 every two weeks and the Wheel of Names is used to randomly select a team member.
  • This is a 25 minute meeting with two presenters.
  • Each presentation has ~5 minutes to present and ~5 minutes for feedback/discussion.
  • List of all previous sessions (including links to recordings) can be found in Commercial Demo Jam document
  • Recordings are published to the Solutions Architecture playlist on GitLab Unfiltered.

Commercial SA Win/Lost Retro

Quarterly review of wins and losses to identify patterns and things we can do to keep winning, prevent losses, and improve GitLab as a product. Encourage everyone to try to add at least one thing.

Structure

  • Win/Lost Retros are hosted the first week of each quarter
  • This is a 50 minute meeting with the entire Commercial SA team
  • Outcomes are documented and are stored in Commercial SA / Reviews & Retros

Process

Commercial SA Peer Review

Commercial SA team holds Peer Review sessions every two weeks 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 every two weeks
  • 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

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. Communicate your time off within your circle in case of coverage.
  2. 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.
Last modified March 28, 2024: Resolve "Move Solutions Architecture outside of Customer Success" (1b1a8189)
View page source - Edit this page - please contribute. Creative Commons License