The Sales team call is every Monday 9:00am to 9:30am Pacific Time.
We cover several areas: where we are at with revenue, sales operation updates to help productivity, how the BDR and SDR team are contributing to our pipleine, product marketing sharing how they are enabling sales productivity and scrum.
We use Zoom for the call since Hangouts is capped at 15 people, link is in the calendar invite, and also listed at the top of the Sales Team Agenda.
The call is recorded automatically, and all calls are transferred every hour to a Google Drive folder called "GitLab Videos". There is a subfolder called "Sales Team Meeting", which is accessible to all users with a GitLab.com e-mail account.
We start on time and will not wait for people.
Person who has first item on the agenda starts the call.
If you are unable to attend just add your name to the Sales Team Agenda as 'Not attending'.
We start by discussing the subjects that are on the agenda for today.
Everyone is free to add subjects. Please start with your name and be sure to link to an issue, merge request or commit if that is relevant.
When done with a point mention the subject of the next item and hand over to the next person.
When someone passes the call to you, no need to say, “Can you hear me?” Just begin talking. If we can’t hear you, we’ll let you know.
Even if you cannot join the call, consider reviewing the recorded call or at minimum read through the sales team agenda and the links from there.
GitLab is an integrated product for the entire software development life-cycle. It contains not only issue management, version control and code review but also CI, CD, and monitoring. 2/3 of the organizations that self-host git use GitLab, that are more than 100,000 organizations and millions of users.
Is it similar to GitHub?
GitLab started as an open source alternative to GitHub. Instead of focusing on hosting open source projects we focused on the needs of the enterprise, for example we have 5 authorization levels vs. 2 in GitHub. Now we've expanded the feature set with continuous integration, continuous delivery, and monitoring.
What is the benefit?
We help organizations reduce the cycle time between having an idea and seeing it in production. Before GitLab you needed 7 tools, it took a lot of effort to integrate them, and you end up with have different setups for different teams. With GitLab you get data on how long each part of the software development life-cycle is taking and how you can improve it.
Quotas may be adjusted based on geographic region.
GitLab Version Check
Before prospecting and engaging with a prospect, check to see if they are using CE. To do this, use GitLab Version Check. Everything about GitLab Version Check.
Parent and Child Accounts
A Parent Account is the business/organization which owns another business/organization. Example: The Walt Disney Company is the parent account of Disney-ABC Television Group and Disney.com.
A Child Account is the organization you may have an opportunity with but is owned by the Parent Account. A Child Account can be a business unit, subsidiary, or a satellite office of the Parent Account.
You may have a opportunity with the Parent account and a Child Account. Example: Disney and ESPN may both be customers and have opportunities. However, the very first deal with a Parent Account, whether it is with the Parent Account or Child Account, should be marked as "New Business". All other deals under the Parent Account will fall under Add-On Business, Existing Account - Cross-Sell, or Renewal Business (see Opportunity Types section).
If the Parent and Child accounts have the same company name, either add the division, department, business unit, or location to the end of the account name. For example, Disney would be the name of the Parent Account, but the Child Account would be called The Walt Disney Company Latin America or The Walt Disney Company, Ltd Japan.
When selling into a new division (which has their own budget, different mailing address, and decision process) create a new account. This is the Child Account. For every child account, you must select the parent account by using the parent account field on the account page. If done properly, the Parent/Child relationship will be displayed in the Account Hierarchy section of the account page.
Remember that a child account can also be a parent account for another account. For example, Disney-ABC Television Group is the child for The Walt Disney Company, but is the parent for ABC Entertainment Group.
We want to do this as we can keep each opportunity with each child account separate and easily find all accounts and opportunities tied to a parent account, as well as roll-up all Closed Won business against a Parent Account.
When to create an Opportunity
Before a lead is converted or an opportunity is created the following must occur:
Authority
What role does this person play in the decision process? (i.e. decision maker, influencer, etc.) OR is this someone that has a pain and a clear path to the decision maker
Need *Identified problem GitLab can solve
Required Information
Number of potential EE users
Current technologies and when the contract is up
Current business initiatives
Handoff
The prospect is willing to schedule another meeting with the salesperson to uncover more information and uncover technical requirements and decision criteria
Interest by GitLab salesperson to pursue the opportunity. Are you interested in investing time in pursuing this opportunity.
Reseller Opportunities
Opportunities utilizing a reseller require slightly different data:
Opportunity Name: If the partner is an authorized reseller, rename the opportunity with the partner’s nick-name in front, then a dash. For instance; if it is a Perforce deal, the opportunity name should start with P4 - (whatever your opportunity name is) This is important for the workflow that solicits updates from the reseller.
Account Name: It is important that opportunities using a reseller are created on the END CUSTOMER’s account, and not the reseller’s account. The account name on an opportunity is never a reseller. Resellers do not buy licenses; they purchase them on the behalf of an end customer. For instance, the account name field on an opportunity should never be SHI.
Opportunity Owner: Should be the name of the AE who is working the deal with the reseller
Associating Contact Roles: After creating the opportunity, click “New” in the contact section to associate contacts with the opportunity.
The primary contact should always be a contact at the end user’s account and not a contact at the reseller. This is important as resellers come and go, and if we do not capture the contact at the end user account, we will not be able to sell to this account if the reseller ends their relationship with us or with the end account.
A reseller contact (say, the sales rep at ReleaseTEAM) can, and should be added to the opportunity with the role of Influencer. NOTE: A contact that works for a reseller should never be added to an end user account. For instance an employee of SoftwareOne should be a contact of the SoftwareOne account only, and not the Boeing account.
Associating Partners to an Opportunity: After creating the opportunity, click “New” in the Partners section to associate the reseller with the opportunity.
You can associate multiple partners with an opportunity if there is more than one reseller involved in the opportunity. This is not uncommon for government opportunities, or opportunities where the customer is asking multiple fulfillment houses (like SHI and SoftwareOne) to fulfill the order.
Opportunity Naming Convention
Opportunities for subscriptions will use the following guidelines:
New Business/Existing Customer - Cross-Sell:
[Name of Company]- [Quantity] [Abbreviations of Product]
Example: Acme, Inc- 50 EES
Example: Acme, Inc- 50 EES/Geo
Add-On Business (seats only):
[Name of Company]- Add [Quantity] [Abbreviations of Product]
Example: Acme, Inc- Add 25 EES
Example: Acme, Inc- Add 25 EE/Geo
Add-On Business (new products):
[Name of Company]- Add [Quantity] [Abbreviations of Product]
Example: Acme, Inc- Add 25 PS
Add-On Business (Upgrade from Starter to Premium):
[Name of Company]- Upgrade to EEP
Example: Acme, Inc- Upgrade to EEP
Add-On Business (Downgrade from Premium to Starter):
[Name of Company]- Downgrade to EES
Example: Acme, Inc- Downgrade to EES
Renewal Business (no changes):
[Name of Company]- [Quantity] [Abbreviations of Product] Renewal [MM/YY]
Example: Acme, Inc- 50 EES Renewal 01/17
Example: Acme, Inc- 50 EES/Geo Renewal 01/17
Renewal Business + Add On Business (seats):
[Name of Company]- [Quantity] [Abbreviations of Product] Renewal [MM/YY]+ Add [Quantity]
Example: Acme, Inc- 50 EE Renewal 01/17 + Add 25
Renewal Business + Add On Business (new products):
[Name of Company]- [Quantity] [Abbreviations of Product] Renewal [MM/YY]+ Add [Abbreviation of Product]
Example: Acme, Inc- 50 EE Renewal 01/17 + Add Geo
Renewal Business + Upgrade:
[Name of Company]- [Quantity] Upgrade to EEP + Renewal [MM/YY]
Example: Acme, Inc- 50 Upgrade to EEP + Renewal 01/17
Once all active customers are converted to either EE Starter or EE Premium, these products will no longer be available to sell a la carte.
Opportunities for Customer Training will use the following guidelines:
Training
[Name of company]- [Type of training]
Example: Acme Inc- User Training.
Note to set up the actual training, click here, choose the template "Customer Training", and fill in the details under the Sales Heading. Support will handle the rest.
Types of Training:
See GitLab.com for the most up to date trainings offered.
Gitorious Opportunities:
Any deal coming from Gitorious has “(Gitorious)” added.
Example Acme, Inc-Gitorious- 50 EE
Opportunity Types
New Business - This type should be used for any new account (business) who signs up either through the sales team or via the web portal. Paid training also falls under this type if the organization does not have an enterprise license.
Existing Account - New Division- This type should be used for new business sold into an existing account but a new division, a new purchasing group.
Add-on Business- This type should be used for any incremental/upsell business sold into an existing account and division mid term, meaning not at renewal.
Renewal - This type should be used for an existing account renewing their license with GitLab. Renewals can have their value increased, decreased, or stay the same. We capture growth/loss as a field in Salesforce.com
New Business vs. Existing Account - New Division:
The primary difference between these two opportunity types is based on whether the prospect will sign a new subscription agreement versus using an existing subscription agreement. If the prospect would like to sign their own Subscription Agreement as the basis for their agreement with GitLab, then the custoemr is considered "New Business". If the customer would like to piggy back off an existing service agreement previously signed by the parent account or another business unit under the parent account, then it is considered an Existing Account - New Division type.
Opportunity Stages
To help move opportunities through the buying process, here is a guide based on the MEDDIC sales process
Discovery - research, fact finding, identify contacts, current situation,
Developing - isolate the opportunities, assess needs, qualify the opportunities, build rapport, access decision makers, understand decision process and criteria, Collaborate on solutions, define the business case, assess competition
Present Solution - Tailor the presentation, coordinate the team, present recommendations, present pricing, isolate value proposition, gain feedback
Negotiating - negotiate business terms resolve objections, set close plan (sequence of events), gain commitment
Verbal Commitment - how a company approves s business teams desire to purchase, how the company vets purchases from a legal, info security, risk, compliance, and vendor management perspective
Won - Deal won and booked
Lost - Opportunity not won at this time
Unqualified - This should only be used when an opportunity is passed from the BDR team, but does not meet our standard qualification criteria. Once you've moved the opportunity to Discovery or later, the opportunity can no longer be marked as Unqualified.
Escalation to Support
Customers that require technical assistance or have questions that are not within the scope of sales can have their queries escalated to the GitLab support team via the following channels.
Create a new ticket on behalf of the customer in the support web form
For quick questions, see the internal support section of the support handbook.
Forward a customer question via email to the support email address. - It's important the email is forwarded and not CC'd to avoid additional changes required once the support request is lodged.
Contributing to EE Direction
Being in a customer facing role, salespeople are expected to contribute to GitLab Direction. Each day we talk to customers and prospects we have the opportunity to hear of a feature they find valuable or to give feedback (positive and constructive) to an EE feature that there is an issue for. When you hear of feedback or you personally have feedback, we encourage you to comment within the issue, if one exists, or create your own issue on our EE Issue Tracker. Checking the GitLab Direction page and the EE Issue Tracker should happen throughout the week.
Export Control Classification, and Countries We Do Not Do Business In
GitLab's Export Control Classification (or ECCN) is 5D002.c.1 with CCATS number G163509. This means that GitLab source code can be exported and re-exported under the authority of license exception TSU of section 740.13(e) of the export administration regulations (EAR).
