SA Practices

Business Value Services is a practice and approach that allows the GitLab deal team (AEs and SAs as well as the extended team) to:

• Focus on customer challenges and required GitLab DevSecOps capabilities to address these challenges
• Quantify value of the GitLab solution with performance improvements and measurable business outcomes

The practice starts from the first conversation at the discovery and scoping stages. The output of the business value discussion can be a Return on Investment (ROI) and Total Cost of Ownership (TCO) document, also known as a Business Value Assessment. This allows the team to:

Every company is developing software. Whether it is external facing applications, or internal applications, or both. Every company wants to be more efficient at developing software, as it has a direct correlation with the company’s success. GitLab is positioned to help every company create better applications by providing capabilities throughout the application delivery process including development, operations and security. In the past, there was not one solution to help companies develop software from idea to deployment. Companies relied on purchasing specific products for specific capabilities, and/or used manual methods such as email, spreadsheets, and documents to keep track of their development.

They say that practice makes perfect. While it’s true that practice is important to hone one’s skills, it’s how you actually do that practice that matters. Deliberate Practice is a particular way of practicing that is persistant and intense. When one practices deliberately, they are stretching beyond their normal comfort level and they are focusing on a particular piece of their routine or demonstration to work on with a specific goal of improving performance.

Effective Objection handling skill is critical to becoming a trusted advisor in our respective sales/customer success roles. Objection handling means responding to the customer in a way that changes their mind or alleviate their concerns. Objections typically fall into these categories.

Objection Handling Process

The Objection Handling Process can be broken down into the following steps:

• Listen
  • Active listening is a key part of effective objection handling. Use methods like nodding and physically showing interest.
  • This is our chance to do more discovery & learn as much as about the customer as possible.
• Question
  • Ask questions if it makes sense, generally we find open ended questions are the best way to retrieve information. This not only shows you are interested in them, but it also gives you more information with which to make the sale.
  • As you question them, watch carefully for body language that gives you more information about what they are thinking and feeling.
  • You might also use the “tip the bucket technique” to see if there are more objections that can be answered.
• Think
  • Take a pause to think & figure out which technique is the best for their objection. You will see that these techniques will become second nature with practice.
• Handle
  • Handle the objection in an appropriate time frame using the techniques above or however way you like.
  • You are under no obligation to try and force-fit a method where it is unlikely to work.
• Check
  • Finally, check to find out whether your objection-handling worked! Ask if you have answered their question. Ask if there are any more concerns. As necessary, handle outstanding objections.

Then go for the close using any of these closing techniques.

The purpose of this page is to hopefully help an SA onboards when they onboard a new Dedicated Customer, what are the considerations and preparation material during the onboarding/discovery phase. Based on past interactions with existing GitLab Dedicated customers and due to the usually longer nature of onboarding customers, a collaboration project is recommended to keep all stakeholders aware and engaged.

A collaboration template specifically for dedicated customers is available as a template here (https://gitlab.com/gitlab-com/account-management/templates/dedicated-collaboration-project).

This is a practice guide for a Solutions Architect (SA) to position Professional Services to a customer during the sales cycle and gather the appropriate information to provide to the Professional Services Engagement Management Team for custom scoping, if necessary. The overall workflow for selling Professional Services is defined in the Professional Services Handbook - Selling Professional Services page.

• See the Positioning Professional Services Class on LevelUp for an overview.

Types of Services

GitLab provides a wide array of Professional Services offerings to accelerate the customer’s time to value in GitLab platform adoption and maturing DevOps practices. Service offerings range from standard instructor-led training to custom services packages that address a specific customer need. Generally, Professional Services are sold in one of two ways:

The worldwide Solution Architecture team, as a learning organization believes that we can be more successful by receiving feedback. Feedback is a two-way street. It is important that SA management takes the time to provide feedback on a regular basis to their individual team members, but simoultanously GitLab team members should share their feedback with management and peers. During this two-way feedback exchange, it provides SAs insights into their activities working with customers and internal processes as well as the SA management insights into their leadership skills.

The Subject Matter Experts (SME) Program is an initiative designed to help solutions architects (SAs) provide better support to customers. The program will identify and onboard subject matter experts in key areas, such as AI, security, and agile planning.

SMEs are Solutions Architects who will help SAs in their region to answer more-in-depths questions, provide deep technical expertise, and assist with customer demos and presentations when needed.

Goals

The goals of the SME Program are:

This is a practice guide for a Solutions Architect (SA) to engage enterprises for driving a strategic solution during discovery and scoping stage, which can lead into the technical evaluation.

A strategic solution is aimed to provide a customer the DevOps capabilities for delivering software better and faster with an organizational wide impact and aligned with the enterprise transformational intiatitives. The SA will assess and provide the solutioning as the right fit for the enterprise from the business and technical perspectives. The solution should aligne with the business outcomes that can be realized based on the DevOps roadmap vision. Further the solution can accelerate the customer’s DevOps transformation at scale.

When working with GitLab, many prospects and customers have software delivery performance improvements as critical business outcomes. Unfortunately, due to the inherent and increasing complexity in the software delivery process, an organization’s software delivery value streams often consist of dozens, if not hundreds, of manual configuration touch points and handoffs. Typically, there is a lack of visibility and understanding into the current process, making it challenging to identify and measure software delivery improvements. Without understanding the current software development value streams, organizations risk putting time, effort, and money into areas that will not improve their software delivery capability in any meaningful way.