Solutions Architects (SA) who work with the Public Sector provide subject matter expertise and industry experience throughout the sales process to Public Sector customers within the United States.
Because specific requirements and common engagement practices differ from Enterprise or Commercial customers, the guidance below exists to assist Solutions Architects who work with customers in the Public Sector specifically.
The GitLab Support Team provides U.S.-based support for those customers that require U.S. citizens to work their support tickets.
Technical Close Plans provide insight and transparency to the sales process by highlighting the technical ecosystem, competitive landscape, evaluation goals and technical steps required in order to achieve a technical win (Salesforce Stage 3). These plans are templated and only required for opportunities exceeding $100K in revenue.
To create a technical close plan:
When the opportunity progresses to stage 4, the technical close plan is complete. A brief retrospective on the information helps the team identify trends in customer needs as well as clear paths to opportunity wins. In case of opportunity loss, a brief retrospective on the information can help populate the Closed Lost reason in Salesforce.
During each greenfield (new customer) sale, customers will move from the presales technical evaluation into procurement. During the presales period, the account sales team will introduce the Customer Success Management Program to eligible customers. This call will be led by the Solutions Architect.The introduction provides guidance on accessing GitLab Support, available CSM programs and GitLab Professional Services.
The goals of this introduction are many:
Prior to introducing the program, the SA should ensure that all sales stage data is recorded and available to kick off the Success Management Program. The required workflow within each sales stage is as follows:
A customer-distributable Success Management data sheet as well as an accompanying slide presentation are available for use to guide the customer discussion. These resources are only available to GitLab team members.
FAQ for customer engagements when customers are using OpenShift
Q: How will the customer use GitLab with OpenShift?
A: When working with a potential prospect its important to understand how that customer wishes to use GitLab and OpenShift together. Will the customer just deploy projects from GitLab to OpenShift? Does the customer wish to run a GitLab Runner within OpenShift? Or, does the customer need to run the GitLab Server within OpenShift? Knowing the answer to this is key before continuing the architecture conversation because GitLab currently can deploy to OpenShift, can run runners within OpenShift and run the GitLab server within OpenShift.
Q: What is the planned release date for OpenShift integration?
A: The GitLab Server Operator (the ability to run a GitLab instance on openShift) was released with GitLab v14.3. The GitLab Runner Operator was already released previous to v14.3.
Q: What features currently do not work when running GitLab with OpenShift?
A: SAST, DAST, AutoDevops. These are on the roadmap with no designated date as of yet.
Q: What OpenShift versions will the integration work with?
A: OpenShift versions 4.5 through 4.8 are currently supported. Version 4.9 support is in the works. Versions 3.x and below will not be supported.
Q: How can I (or my customer) track the integration status?
The GitLab for Campuses program introduced flat rate pricing for universities based on size. In order for these campuses to evaluate GitLab's fit for their schools, labs, and students, a campus technical evaluation playbook was created. The playbook covers personas, meeting types, options and outcomes associated with an ideal 4 to 8 week evaluation of GitLab for campuses with minimal to moderate knowledge of GitLab.
Solutions Architects can use this playbook to guide campuses through an evaluation of GitLab's broad technical capabilities. The playbook is accessibly by GitLab team members only.