As the sales of GitLab increase, the demand for professional services will follow suit. To meet this demand we need to have an elastic and on-demand bench of delivery resources. Partner collaboration will also help to prevent PSE Burnout by allowing PSEs to take lead roles (e.g.architect, technical oversight, etc.). Finally, building relationships with partners allows the delivery team to add Subject Matter Experts as needed.
From a sales perspective, channel partners can help facilitate the initial licence deal and up-selling opportunities with customers whom they have an ongoing relationship.
There are different types of relationships we can have with partners and its important to outline the distinctions :point_down:. Direct vs indirect is a reference to the way the services are sold - Direct means the partner sells direct to the customer, Indirect means GitLab sells services and the partner helps with execution.
|Partner Indirect (Staff Augmentation)||Partner Indirect (Project Based)||Partner Direct|
|Subcontracted to GitLab?||Yes||Yes||No|
|Access||Slack, www-gitlab-com, GDrive||Slack, www-gitlab-com, GDrive||Partner Portal|
|Communication w. GitLab PS||Organic (see above row)||Organic (see above row)||Partner Help Desk|
|Allowed to know of other Customers of GitLab PS?||Yes||No||No|
|Can contribute back to practice automation?||Yes||Yes||TBD|
GitLab PS can and should help our partners be successful in delivering services for their (and by extension, our) customers. We can provide guidance, examples and strategic advice, including references to public documentation or blog posts that could help "un-stick" a partner in an engagement. If the partner needs hands-on help, however, we will need to engage with the partner via an SOW to ensure we have appropriate liability protections in place.
Note: GitLab professional services is building out a means to field and respond to help desk questions from the channel partners who are not subcontracted with us (Jan/Feb 2021). More details to come as this process gets created.
If the project requirements exceed the current capacity of the available resources then the professional services team may employ a subcontractor to help deliver the project. The following provides a checklist of items to process before and during the use of a subcontracted resource:
Confirm that the terms and conditions agreed to with the customer enable the use of a subcontractor. In some cases, GitLab must first obtain written approval from the customer in order to employ a subcontractor.
Review the list of potential Partners and subcontractors. GitLab has established relationships and signed Master Service Agreements with a collection of partners. Review the list of partners and select ones that have resources with the correct set of skills and certifications.
Contact the selected partner through an introduction by the GitLab PS Partner Manager. GitLab should then submit the requirements to the partner and request resumes and rates for any resources the partner deems available and suitable for the project. Interview proposed resources. GitLab will meet with the proposed resources to determine if the person is a fit technically as well as from the perspective of fitting in with the project team that includes both GitLab and customer personnel.
Share Statement of Work between GitLab and the selected partner. The Statement of Work should be based on the latest released template to ensure that up to date legal language is included.
Send GitLab signed and stamped Statement of Work to the Partner.
Onboard the subcontractor using the onboarding process.
Track time. As described on the PS Operations page, GitLab must account for all time logged against a project.
Offboard the resource. At the conclusion of the project, remove access to Slack channel, internal tools, as needed.