Gitlab hero border pattern left svg Gitlab hero border pattern right svg

GitLab Proof of Concept

Proof of Concept (POC) Guidelines

GitLab wants prospects to enjoy a successful Proof of Concept with GitLab Enterprise Edition. A POC is a collaboration between GitLab and the prospective customer for evaluating GitLab Enterprise Edition.

POC's are commonly entered into once an NDA is signed, budget for the project is in place, any competition has been identified and success criteria have been documented.

The target duration for a POC is 2 weeks, extended to a total duration of not more than 8 weeks for highly complex evaluations. A GitLab Customer Success collaborative project (only accessible to GitLab team members) should be utilized as the default method to manage a POC, while a document is available when using a project is not an option. When utilizing the a collaborative project, follow the instructions in closely in order to properly copy the entire project.

GitLab Solutions Architects should set a limit of 3 concurrent POC's as a best practice in order to provide excellent customer service and to enable a target of achieving 24 hour or less response times to inquiries during any POC. If more than 3 concurrent POC's are required, the SA should assess their ability to support the additional requirements and/or discuss viability with other SA's in their region.

Tracking a Proof of Concept in Salesforce

Salesforce Object

In order to track a POC correctly in Salesforce, the Strategic Account Leader should position the opportunity as Stage 3. The Solutions Architect will manually create a POC object within SFDC when the prospect or customer has indicated interest in moving forward with a guided POC.

To track a POC, click the Proof of Concepts tab from the top menu bar in Salesforce. Create a new POC using the New button. Alternately, the Solutions Architect may select the relevant Opportunity, scroll down to the related list labeled Proof of Concepts and click on the "New Proof of Concept" button. This will automatically associate the POC with that Opportunity while all other fields need to be manually completed.

Complete the following fields at minimum:

POC Types include:

Once the POC begins, the Solutions Architech should change the Status field from New to In Progress. When the POC is complete, the Solutions Architect should change the Status to Closed and the Result should be identified as Successful or Unsuccessful.

Proof of Concept Details

POC Key Players


GitLab Role / Responsibilities

Note: in the case of a "lite" POC, the Solutions Architect is expected to be the sole GitLab contact. "Lite" is determined case-by-case by the size of the prospect as well as their ability to engage with GitLab.

POC Meetings and Tasks

POC Kickoff Checklist

Meeting Cadence

Calls may be recorded with customer consent, and recordings may be stored in the Recorded Meetings folder in the project repository for mutual benefit.

Internal Kickoff Meeting - 1 - 1.5 hours, led by the Solutions Architect


External Kickoff Meeting (Remote) - 1 hour, led by the Solutions Architect


Week One Retrospective call, led by the Solutions Architect


POC Wrap Up Meeting - Led by the Strategic Account Leader


POC Calendar

Week one

Week two

POC Template Document

As an alternative (or in addition) to using a collaborative GitLab project, a document is available which helps outline the details of a POC. In the document (only accessible to GitLab team members), provides the framework for a successful POC by addressing current state issues, persistent challenges, business problems, desired state and outcomes.

This document suggests and verifies specific success criteria for any POC, as well as outlining a mutual commitment between GitLab and the identified prospect parties. It also specifies the limited timeframe in which the POC will occur.

Using the POC Template

The template provides a standardized approach to the POC process, but the document requires customization for each and every POC to be executed.

To use the template, begin by making a copy of the master document for each POC.

Edit each area highlighted in yellow within the document to include pertinent information for any particular prospect. This information includes basic data like the prospect name and GitLab team member details, as well as data to be collaboratively identified with the prospect, such as success criteria, trial location, and the client pilot team(s).

After all the highlighted sections have been completely filled in, collaboratively complete the Date and Owner column fields within the Project Plan and Roles and Responsibilities sections.

Finally, ensure both GitLab and the prospect have a copy of the document. Schedule all meetings associated to the POC via calendar invites prior to distributing the GitLab Enterprise Edition license for the POC.