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

Selling Professional Services

Selling Professional Services

You can also watch the sales enablement session about how to sell services.

Selling services workflow

There are two different ways that services can be sold:

  1. Through the use of a SKU which come with a boilerplate description and fixed cost (no SOW involved).
  2. Through a Statement of Work which is created by the Services Calculator and approved following the process below:

Statement of Work Process

Generally, this process involves the creation of the baseline SoW and issue by the Solutions Architect. The SA then engages with the Professional Services team to get scoping questions defined and answered. After that, the SoW is finalized by the Profession Services team and approved by the VP of Customer Success.


  1. SA: Create baseline SoW from Services Calculator
  2. SA: Add details to issue around customer requirements
  3. SA & PSE: Conduct detailed scoping call with the customer
  4. PSE: Develop Custom SoW and pricing for customer
  5. Account team: Deliver SoW to the customer, add to the Salesforce (SFDC) opportunity
  6. Send for signature (just like software terms)

Detailed Process

  1. Sales and account team to introduce early in discussions.
  2. The SA can do basic scoping and use the calculator for an estimate.
    • This should be a good estimate to secure budget.
  3. Customer should execute Subscription Agreement AND Consulting Services Agreement.
  4. The SA can use the custom SoW scoping details page to help drive the conversation and uncover required capabilities for the custom SoW.
  5. The SA will create the SoW from the calculator, scoping the project and estimating both schedule and cost for the SoW.
    • This deck, accessible by GitLab employees only, provides detailed guidance on SoW creation.
  6. The calculator automatically creates an issue on the SoW Proposal Approval board.
  7. SA: Check and add any more details to the issue created on the SoW Proposal Approval board.
  8. SA: Fill out any additional scoping details. Ensure the issue is assigned to a Solutions Manager for review, and move it to the proposal::Scoping step.
  9. SA & PSE: Conduct more detailed scoping call (only when needed) to prepare SoW.
  10. If there are additional scoping questions needed to scope the engagement, Professional Services Engineering will inform the account team within three (3) business days of this call.
  11. Once all scoping questions are complete, move the SoW to the proposal::Writing step.
  12. Once written, move the SoW to the proposal::Cost Estimate step where a Manager of Professional Services will provide a cost estimate used to calculate the expected margin for the project. It will be completed and ready for the account team review within one (1) business week.
  13. Move the SoW to the proposal::ReadyForApproval step.
  14. The SoW is approved by the Senior Director of Professional Services or VP of Customer Success.
  15. Move the SoW to the proposal::Approved step. Assign the issue to the SA for delivery to the customer via the account team.
  16. SoW will be assigned and typically started within 4 weeks lead time.
  17. SoW delivered and executed
  18. Services fulfilled


Do we have set SKUs I can use?

Yes - for off the shelf items, we have SKUs.

What are our daily or hourly rates?

We do not currently have an hourly or daily rate. Nor do we plan to have an hourly rate. Just as with GitLab support, the mission of our Professional Service group is not to bill hours, but to achieve success for our Customers. So just as we don't offer support by the call or by the hour, we do not offer Professional Services by the day or the hour.

In the future, we may have a daily rate or a daily rate for on-site support. However, we currently do not for the same reasons listed above.

What if the customer only wants training?

If the customer is an EE customer, we can offer training. However, training will need to be scoped out by the Customer Success department before quoting a price. The account executive will also be required to provide the use case for the need for just training.

Example use case might be:

Customer is under license utilization and we need to prevent churn, help expand usage into additional groups and other business units.

What options exist for CE Customers?

GitLab CE is ideal for personal projects or small groups with minimal user management and workflow control needs. Because these groups don't typically need a lot of focus on scaled implementation or training, we currently do not offer implementation, integration or training services to our CE customers. Many of our partners offer such services. However, we find that many customers who have been running a CE instance and are looking to transition to a scaled implementation of GitLab may require a Discovery Engagement to determine the customer's long-term needs.

If a customer is upgrading from CE to EE, Professional Services should be engaged to scope out the requirements for the transition if the customer will need services in the transition.