You have qualified a lead and now you need to turn it into a sale. This phase is called Facilitate the Opportunity. The goal of this phase is to achieve a technical commit followed by an economic commit from the customer. A Commit is a verbal acknowledgement from the buyer that they want to proceed with the deal. In this phase there are 4 high level tasks you need to complete to get a technical and economic commit:
Again the four tasks above are demonstrable outputs of correctly applying MEDDPPICC and Command of the Message (CoM) within each of the tasks. This also supports your transition from appearing as a common software sales person into a trusted consultant that brings business solutions instead of multiple invoices and a smile.
Traditional sales typically bypasses understanding the customer. Traditional sales relies heavily on getting a foot in the door with a customer by overwhelming them with product information in the hopes that a buzz word or some random product feature will catch the customer’s attention and build urgency in the customer. GitLab doesn’t operate that way. GitLab uses Discovery Questioning.
Discovery Questions help to uncover existing customer needs, problems, pain points, goals etc. Regardless of the opportunity being handed off from an SDR or qualified by you, you should always create discovery questions based on the following research process and criteria.
A buyer persona is a fictional representation of your key buyers. This helps you pre-identify obstacles, objections, initiatives, and metrics that are important to your buyer. This step will give you an edge in understanding your customers better than your competition. There are typically 5 buyer personas you may encounter.
Buyer Process Maps (BPMs) highlight and explain the mental pathways buyers’ travel to make decisions and help to guide selling activity based on where the buyer is in their process. Your goals in this step include differentiation, reduction in resistance, avoid wasting cycles, and facilitating better meetings and creating. See a breakdown of the Buyer Process Map and the common buyer actions that indicate what stages of the buyer process the prospect is in.
This step includes a number of sub-tasks necessary to obtain additional buyer insights:
Leverage MEDDPPICC to gather the information necessary to qualify the opportunity.
This step helps to ensure you gather more pertinent information from the buyer. More specifically, it will help you identify information gaps, set specific objectives, and ultimately increase your buyer’s confidence in you. Use the two job aids below to prepare for your discovery calls.
Discovery doesn’t take place in just one call. It takes place over a series of meetings. It’s important to take the time to get to understand the customer’s organization on an intimate level in order to propose the best product solution possible. Below are the tasks and assets you’ll need to facilitate successful discovery call meetings.
The goal of developing and presenting a good pitch is to obtain a verbal commit from the customer. Again, traditional sales representatives tend to overwhelm customers with a long overview of the company and its product features in the hopes that one of the features will resonate with the customer and create a sense of urgency to buy.
Always avoid making a pitch more about us than the customer. At GitLab the approach is more consultative. This is the reason that insight into the customer based on individual research and discovery calls is so important. It gives you an intimate understanding of what the customer’s problems are and their long term goals. Your responsibility in developing and presenting a GitLab sales pitch is to align the customer’s problem to a particular GitLab product based solution. You have worked with the customer to this point to do the heavy lifting and understand what they need. Now as a consultant you are presenting a solid solution to meet their immediate needs but also providing a solution roadmap of their long term goals and needs.
As a rule, a GitLab Sales Pitch deck should be no more than 10-15 slides. You can use the GitLab Customer Template and reduce it to the recommended number of slides.
For Enterprise Strategic Account Leaders, you can also use this GitLab ENT SAE Proposal Template to give you a headstart on a custom proposal for your customer.
It is also recommended that the presentation be more visual rather than text heavy. A GitLab customer deck should contain the following components:
As a GitLab sales representative you should know from your discovery calls and research your customers pain points well enough to match them to one if not all of the GitLab Value Drivers. GitLab has the following three value drivers:
Your job is to call out the specific key pain points and show the customer how their pain aligns with GitLab’s value drivers.
The next component of the pitch deck is showing how GitLab can help. This will require you to understand the customer’s specific use case. You discovery calls should have provided much of the data to define the problem, but going further you must do the following:
This part of the customer deck will help orient your customer to what GitLab is and how we can help them.
The data gathered from the discovery calls is analyzed by AE/SAE to make the determination of whether to qualify the lead in terms of GitLab value to their organization. Upon determination of qualifying, the AE/SAE then should engage a Solution Architect to begin the transition to the scoping phase of the sales process.
Scoping represents an opportunity to discuss customer requirements in more detail. This step is the primary responsibility of a Solution Architect (SA). The SA will do a deep-dive technical requirements review based on the documents provided by the AE/SAE. The SAs main goal in scoping is to understand all the necessary elements that need to be brought into the project scope and identify the pieces that need to be brought together in order to produce a successful outcome for all stakeholders. The tasks necessary to accomplish proper scoping are the following:
Technical evaluation is where the prospective customer evaluates the fit of GitLab to their organization and their specific business outcomes. This may be driven by a Lite POV, a free trial, real time or asynchronous Q&A, a workshop and/or other approach requiring technical guidance from an SA. If Discovery did not include the SA, the AE should follow the triage process to engage an SA for the opportunity, filling out the issue template and providing MEDDPPICC information as well as the known required capabilities in Salesforce. The following are tasks the SA must review and manage during technical evaluation.
Hold a strategy meeting: Once the SA has completed the solution design blueprint and/or the Proof of Value, the sales representative will need to hold a strategy meeting with the SA to discuss the highpoints of the solution in order to prepare and present a pitch deck to the customer. If the sales representative does not have deep technical product depth, it will be even more important to debrief the solution blueprint with the SA.
Command of the Message is defined as "being audible ready to define solutions to customers’ problems in a way that differentiates you from your competitors & allows you to charge a premium for your products & services.” This means you must in many ways understand the customers pain points and goals better than they do and speak to real solutions. The solution is presented to the customer through a pitch deck.
At this point, it may also be beneficial to egage the Risk and Field Security Team to provide security assurance support. Prior to making a financial commit, many customers will require security due diligence. The AE, SAE or SA may utilize the Customer Assurance Package for self-service resources or request assistance through the Customer Assurance Activities Procedure.
Should you include the demonstration within the same meeting as the sales pitch? Typically 50% of the time the demonstration is presented in the same meeting with the pitch deck being delivered first.
However, this is an audible-ready moment where the AE/SAE and SA need to meet as a team and discuss if the customer is ready for the demonstration. This should be an agenda item at the regular account management meetings and each team needs to set the criteria of whether to combine a pitch deck meeting with a demonstration on a customer by customer basis. The demonstration should be tailored to the customers specific pain points and business goals. Again, traditional sales representatives tend to overwhelm customers with a long overview of the company and its product features in the hopes that one of the features will resonate with the customer and create a sense of urgency to buy.
A Technical Commit takes place within the Technical Evaluation POV through a series of working sessions where GitLab capabilities are mapped to business and technical requirements within the Customer Requirements Document. When the technical champion has socialized within the organization that GitLab’s capabilities meet or exceed their technical needs in dealing with their business drivers and want to move forward, this is a verbal Technical Commit.
A Champion is the person within your client's organization that will sell on your behalf when you're not there. They will guide you through the decision making process, introduce you to key players and decision makers, and alert you when things go wrong. For medium to high engagement deals, try to obtain a minimum both a technical champion and a business champion. The technical champion can guide you through the Technical Evaluation steps and hopefully help get the Technical Commit. The business champion if he or she is not one in the same as the technical champion will provide you with insight into the paper process, decision makers, and internal organizations that have influence on whether the opportunity moves forward or not. The criteria for a champion are as follows:
If the person does not meet the above criteria, they should be deemed an advocate. An advocate speaks well on your behalf, socializes your solutions, and helps you understand the landscape within the organization. However,they cannot remove barriers to a deal.
As you facilitate the deal, you must constantly test your points of contact as possible champions or advocates. For this reason, it is best to have multiple advocates and multiple champions to create a point of contact safety net for changing positions and changing initiatives.
To get an economic commitment you have to help a customer organization understand their common pain points and goals and assist them to plan to address those pain points and goals without being overtly involved in the decision making process. It creates urgency by showing the customer that the pain associated with not partnering with GitLab is greater than any pain associated with moving forward (3 Whys: Why Gitlab, Why Now, Why Do Anything At All).
When you can do this properly, you will have made a consultative based case that compels the customer to make a decision to buy. This is done on the same side of the table with your identified champions/advocates. Below are the steps that need to be taken to engage and get a commitment from an economic buyer.
To engage the economic buyer you need a customer focused deck that aligns high level business needs with GitLabs Value Drivers. The customer deck should be created with the idea that your champion can present it to the economic buyer. To do this you will need to work side-by-side with your advocates and champions to update the customer deck you created earlier to provide the following components to an economic buyer:
Align the customer needs to an existing GitLab case study. To locate a good case study go to Customer Reference Documents. You'll need to build a few slides that distill the main points of the case study to align it to the customer you are pitching.
A justification is defined as the action of showing something to be right or reasonable. You’ll need to work with your champion be clearly show the business justification for choosing GitLab by creating a graphic representation of one or all of the following points:
Preliminary pricing is usually based on the Proof of Value designed by the Solution Architect. Work with your champion(s) to further align preliminary pricing with the justification and ROI that you should have already created in the customer deck.
Additionally, test your champion during the late stage of the Technical Evaluation process to get an idea of the pricing and budget implications that may present themselves and incorporate that information into the preliminary pricing proposal.
At this point the opportunity now moves the Deal Closure phase, phase three of the GitLab sales cycle.
