The SMB Account Executive is a grade 6.
- Experience managing an inbound request queue and assisting prospects and customers with online chat, email, and phone correspondence.
- Familiarity with the needs of software development and IT operations teams.
- Basic understanding of application lifecycle management including the technology commonly used in application lifecycle management.
- Basic understanding of DevOps practices, including the cultural shift it represents and the benefits to building and shipping software upon adopting those practices.
- Experience in a role that puts customer needs above all else.
- Product demo experience.
- Working knowledge of software development methodologies such as Waterfall, Agile, and Conversational Development.
- Comfortable with frequent client phone calls to explain hard-to-understand concepts and deployment options.
- Excellent spoken and written English
- You are obsessed with making customers happy. You know that the slightest trouble in getting started with a product can ruin customer happiness.
- Affinity with software and the software development process
- Passionate about technology and learning more about GitLab
- 3+ years experience in sales, marketing, or customer service
- Experience with CRM and email automation software is highly preferred
- An understanding of B2B software, Open Source software, and the developer product space is preferred
- Be ready to learn how to use GitLab and Git
- You share our values, and work in accordance with those values
- Ability to use GitLab
As with all roles in the Sales Department the SMB Customer Advocate participates in the Sales KPIs.
Renewal/account intake involves responding to customers that contact GitLab through the following channels:
- Salesforce Cases (where our firstname.lastname@example.org live)
- Direct email (customers, partners)
The instructions below describe the basic process for properly handling inquiries from each of these channels.
Salesforce Cases (proactively monitor, check at least three times daily):
- Navigate to the "Cases" tab in Salesforce.
- Create custom view for managing all cases assigned to your alias specifically. (Instructions for creating new view coming soon.)
- Review this view of unassigned cases and reassign to yourself any within your territory.
- Navigate to your cases view in SFDC, filter for most recent cases. With any open cases, please work according to the following steps:
- Open case > Open account.
- If the account has an owner that is not you or is Sales Admin and not within your territory, navigate back to case, reassign it to the proper account owner based on territory, and chatter them.
- If the account is owned by you or Sales Admin and is within your territory, check for activity history on the case, account, and contact.
- If a colleague has responded to the case or is in touch with the contact, reassign the case to them.
- If there is no activity history, respond to case and continue communication with customer via email.
- After responding, update case status from "New" to "Closed". This ensures only untouched cases will remain in your queue.
Zendesk (proactively monitor, check at least three times daily):
- Navigate to Zendesk.
- Click "Views" and choose "Upgrades, Renewals & AR (refunds)".
- Tickets are automatically sorted from greatest urgency to least, start from tickets at the top of the list.
- Open ticket, then review the activity log. If a sales colleague has already been in touch and this customer is awaiting another reply, ping your colleague on Slack with a link to this ticket if an SLA breach is imminent.
- If there is no activity history on the ticket, use the contact's email address from Zendesk and check SFDC to see who ticket should be routed to.
- When the account is in your territory, reassign the ticket to yourself (if not already in your name), and respond and/or update the ticket status accordingly.
Ticket status can be updated in the following ways:
- "Submit as Pending" if you have written a response to a prospect and are expecting their response.
- "Submit as Solved" if the ticket has been resolved and can be closed (i.e. no response is expected from the prospect).
- "Submit as Open" if the account is outside of SMB segmentation; make sure to cc the appropriate account owner within the ticket. Ping the account manager on Slack notifying them of the active ticket that requires their response.
- If the account is requesting a refund or billing support, disposition the ticket to the Accounts/Receivable Refunds form on the left panel and "Submit as Open".
Direct email (proactively monitor, check at least three times daily):
- If a Customer or Partner emails you directly, check SFDC for account ownership and introduce the correct colleague.
- If the account is in your territory, continue correspondence via email.
Pitch and Negotiation
Here are some basic resources for pitching Gitlab and our different product offerings:
Pitching GitLab on the SMB team:
Normally we do not use a “pitch deck” given the nature of why SMB customers are coming to us at this time. The vast majority of customers that are wanting to speak with us have already done their research on GitLab and are familiar with the product. Therefore, it is not currently necessary to present company details and product vision at the SMB level for the bulk of our customer conversations. It is our job to validate their decision to go with GitLab and create as much value as possible.
The “pitch” is mainly dependent on listening to the customers needs and figuring out which product is right for them.
Use discovery to help build a story and collect relevant information in order to map out the features and value to focus on:
- Which tools are they looking to replace with GitLab?
- What is their primary driver for looking at GitLab in the first place?
A little bit on Creating Value
- Size and Scope
Scope- Find out how many components of GitLab they want to use
Size- The larger the organization, the more value GitLab provides
A single application sets up a small or medium sized business for a scalable situation as their organization grows
After the initial round of questioning, summarize your findings to the customer and prescribe how GitLab can solve their problem and what product tier they require
- Are they interested in Epics? Yes → Ultimate
- Do they have a need for security? Yes → Ultimate
Pitching for the upgrade:
When dealing with a potential upgrade, it is again important to listen to the customers needs. If no need to upgrade currently exists, it is possible to uncover one.
Drivers for each product edition:
Below are some common drivers the SMB team has seen for a customer to gravitate towards a certain product edition. It is important to be aware of these drivers when determining and suggesting the right product tier for both new and current customers.
- All of the developer features
- Maven Repository - more info
- Security Features
Occasionally they are looking for more advanced project management features
- CI/CD for external repositories
- May have their repository in BitBucket or GitHub and need to upgrade in order to support that
- GitLab CI for GitHub
Additional CI/CD minutes (Silver only)
- This decreased when we saw CI minutes on demand get introduced - more info here
- Need to provide the value of a single application for their SDLC (SCM, CI, Project Management, Security)
- Reduces tool chain cost and friction
- Project Management
- Direct competition with Jira
- Determine the importance of security
- More regulated industries tend to be more interested in Ultimate because of their security needs
- Why Ultimate?
Some resources for negotiation:
Premium edition - we typically do not negotiate, but we can sometimes make exceptions in special cases such as multi-year agreements and high volume deals
For customers who are coming up on renewal and are on early adopter pricing, there is an increase to our current Ultimate price
- In these cases, refer to the pricing approval matrix to reference how you can assist them
Always bring up multi-year deals and more users added in advance
It’s important to identify the customer’s needs around Ultimate to see how they will be using it. This is why proving the value of Ultimate prior to negotiating is crucial.
The next step in the SMB Account Executive job family is to move to the Mid Market Accout Executive job family or the Sales Managment Job Family.
Avoid the confidence gap; you do not have to match all the listed requirements exactly to apply. Our hiring process is described in more detail in our hiring handbook.
Candidates for this position can expect the hiring process to follow the order below. Please keep in mind that candidates can be declined from the position at any stage of the process. To learn more about someone who may be conducting the interview, find their job title on our team page.
- Selected candidates will be invited to the following:
- A phone or video conference screen with the recruiter. This takes 30 minutes and helps our recruiting team align your interests and qualifications with the right opening on the sales team.
- A video conversation with a potential colleague. This takes 45 minutes and helps us understand your sales experience, style, and skills.
- A video conversation with the hiring manager. This takes 30 minutes and helps the sales manager understand what you want to do next in your career and how that might intersect with GitLab and the Commercial sales team.
- A video conversation reviewing your professional experience chronologically. This takes from 45 min to an hour and allows your hiring manager to understand the similarities and differences of past roles you’ve had to the role we are considering for you
- A mock GitLab customer call. The mock call itself is limited to 15 minutes. You are given a few minutes to ask any final questions before going into the mock call. After the mock call, we use the remainder of the half hour to understand feedback, how it felt to sell GitLab, and ask any questions we have remaining about your candidacy.
Additional details about our process can be found on our hiring page.
GitLab Inc. is a company based on the GitLab open-source project. GitLab is
a community project to which over 2,200 people worldwide have contributed.
We are an active participant in this community, trying to serve its needs
and lead by example. We have one vision: everyone can
contribute to all digital content, and our mission is to change all creative
work from read-only to read-write so that everyone can contribute.
We value results, transparency, sharing, freedom,
efficiency, self-learning, frugality, collaboration, directness, kindness, diversity, inclusion and belonging,
boring solutions, and quirkiness. If these values match your personality,
work ethic, and personal goals, we encourage you to visit our
primer to learn more. Open source is our culture, our way of
life, our story, and what makes us truly unique.
Top 10 reasons to work for GitLab:
- Work with helpful, kind, motivated, and talented people.
- Work remote so you have no commute and are free to travel and move.
- Have flexible work hours so you are there for other people and free to plan
the day how you like.
- Everyone works remote, but you don't feel remote. We don't have a head
office, so you're not in a satellite office.
- Work on open source software so you can interact with a large community and
can show your work.
- Work on a product you use every day: we drink our own wine.
- Work on a product used by lots of people that care about what you do.
- As a company we contribute more than we take, most of our work is released
as the open source GitLab CE.
- Focused on results, not on long hours, so that you can have a life and
don't burn out.
- Open internal processes: know what you're getting in to and be assured
we're thoughtful and effective.
See our culture page for more!
Work remotely from anywhere in the world. Curious to see what that looks
like? Check out our remote manifesto and guides.