Selling GitLab Professional Services

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

A Note on Partner Professional Services

Please remember to follow the Rules of Engagement for Selling Professional Services with the following highlights:

• Always start by finding out if your customer/prospect has a qualified and preferred professional services partner and start by engaging with that partner to explore a solution for your customer/prospect
• SMB clients are welcome to purchase SKU offerings. Please route all custom SMB needs through professional services Channel Partners as outlined in the ROE. Please see additional detail in the FAQ below.
• Remember to update the SFDC Professional Services Opportunity to “closed lost” if for any reason after you have created a GitLab Professional Services Opportunity in SFDC the work is transitioned to being sold and delivered by a partner. Then make sure that any Services Attach Registration that the partner registers for that work is attached to the relevant Licensing Opportunity in SFDC. Please work with the Channel Account Manager for the partner (found in SFDC account for the partner) if you have any questions about this process.

Workflow for GitLab selling Professional Services

There are 4 main steps for selling GitLab Professional Services:

1. Identify the right services needed.
2. Create the GitLab Professional Services opportunity in SFDC.
3. Generate the SOW / Service Description Docs
4. Close the opportunity

graph LR;
  a["1. Identify services needed "]-->b["Create the PS opportunity in SFDC"];
  b--custom-->c["Services Calculator"];
  b--standard-->d["SKU Catalog in Zuora/SFDC"];
  c-->e["3. Generate SOW or Service Desc. Docs"];
  d-->e;
  e-->f["4. Close the opportunity"];

Step 1: Identify the right service

The SAE/ISR can find the general services the PS team offers on the services page or for more details specific SKU offerings, on the full catalog. The SAE/ISR can pull the SA/CSM in for help selecting services needed based on customer requirements.

Step 2: Create the opportunity in SFDC

The SAE/ISR creates a Professional Services Only opportunity.

Standard Services Only

If the customer only needs standard services from the service catalog, the SAE/ISR can generate the quote from within the newly created SFDC PS opportunity by:

1. Click New Quote.
2. Choose the proper billing account. In the Quote Type section Select New Subscription. Click Next.
3. On the Create New Subscription Quote screen, update required fields (e.g. Start Date) as needed. Click Next.
4. On the New Quote Flow screen, click the drop down box next to the New Quote Flow and select Add Add on Products.
5. In the Professional Services and Training Row, click the drop down that says Select Plan to see the current SKU offerings that can be added to the opportunity. Click Next.

After following the above process steps, click Generate PDF to obtain an Order Form to share with the customer for signature. The AE should meet with the customer to review the service deliverables, duration, and pricing and should confirm no customizations are needed. Again, they can pull in the EM for assistance if needed.

Custom-Scoped Services

If the account team (SAE/ISR/SA/CSM) determines that the customer requires additional services outside of those listed in the full catalog, they should initiate a scoping engagement with the PS team by opening the Services Calculator and submitting with the information required (customer name, GitLab username and email address). If you don’t know the specifics, you can submit with the defaults. This will add an issue to the PS Engagement Manager’s queue to follow up with you on next steps. Check out the detailed steps below for custom-scoped engagements for more details.

Instructions for creating a Professional Services Quote

Deal Desk with require a quote for either Service option above. How to create a quote can be found here.

Step 3: Create and add the SOW

For standard SKUs, the Order Form is generated directly from SFDC via the quote object here. Upload the signed version of this document when you receive it from the customer.

For custom scoped SOWs, once you receive the SOW from the Sr. Engagement Manager and have gotten it back from the customer with signature, attach it to the SOW doc to the SFDC PS opportunity.

Step 4: Close the opportunity

Closed Won

Once the services have been rendered and the project is closed, the SAE/ISR should obtain signatures from the customer. The SAE/ISR should move the opportunity to Closed Won status

As the agreement approaches Closed Won, make sure to request @ps-scheduling to identify a potential start date in the professional services slack channel given the typical lead times for starting a PS engagement.

Transitioned to a Partner - Closed Lost

Remember to update the SFDC Professional Services Opportunity to “closed lost” if for any reason after you have created a GitLab Professional Services Opportunity in SFDC the work is transitioned to being sold and delivered by a partner. Then make sure that any Services Attach Registration that the partner registers for that work is attached to the relevant Licensing Opportunity in SFDC. Please work with the Channel Account Manager for the partner (found in SFDC account for the partner) if you have any questions about this process.

Custom-Scoped Services Detailed Workflow

1. Account team: Create scoping issue from Services Calculator
2. SA/CSM: Add initial scoping details to the issue around customer requirements
3. SA/CSM & PS Engagement Manager: Conduct detailed scoping call with the customer
4. PSEM: 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)
7. When Closed Won, the PS team will handle staffing. Average lead times are updated weekly - please check with the EM to set expectations with the client

FAQ

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.

What options exist for SMB Customers?

SMB customers often do not have sufficient budget for our professional services offerings, and we traditionally try to meet their needs through channel partners. If your client had budget for one or more of our SKUs, you are welcome to attach the SKU and do not need to create a scoping issue with the professional services team.

Please note: Migrations to GitLab SaaS currently require the use of an admin token, which is unavailable to partners. Therefore, these migrations must run through our GitLab professional services team currently.