You can also watch the sales enablement session about how to sell services.
Please remember to follow the Rules of Engagment for Selling Professional Services with the following highlights:
There are 4 main steps for selling GitLab Professional Services:
The SAL/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 SAL/ISR can pull the SA/CSM in for help selecting services needed based on customer requirements.
The SAL/ISR creates a Professional Services Only opportunity.
If the customer only needs standard services from the service catalog, the SAL/ISR can generate the quote from within the newly created SFDC PS opportunity by:
Add Add on Products.
Select Planto see the current SKU offerings that can be added to the opportunity.
After following the above process steps, click
Generate PDF to obtain an Order Form to share with the customer for signature. The SAL/ISR 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 SA for assistance if needed.
If the account team (SAL/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.
Deal Desk with require a quote for either Service option above. How to create a quote can be found here.
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.
Once the services have been rendered and the project is closed, the SAL/ISR should obtain signatures from the customer. The SAL/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.
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.
Yes - for off the shelf items, we have SKUs.
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.
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.
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.
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.