Clarify SLA and Support expectation for sales-assisted trials/prospects
Problem:
GitLab Support provides technical Support to sales-assited trials and prospects without a Service Level Agreement and it's not clear what trials/prospects can reasonably expect in terms of "paid" Support.
Support Service Level Agreement depends on clicking the "I Accept" box in the purchase flow, as defined in GitLab Subscribtion Terms section 1 (particularly 1.2).
Proposal:
Set "prospect SLA" expectations to clarify
- SLA times are only binding for customers
- sales-assisted trial/prospect SLA performance should not be counted towards customer FRT/NRT KPIs
Why?
From a legal perspective, an SLA requires Agreement from two parties. As Trials/prospects have not agreed to our GitLab Subscribtion Terms of Service, there is no agreement between the two parties.
From a team performance perspective: In situations where there are multiple tickets in danger of breaching, tickets from paying customers who've accepted ToS should be given priority as these count toward KPIs
Context
Related Issues
Related MRs
Results
Expected/intended results
Sales-assisted trials and prospects have clear expectations set regarding their support options and expected/targeted response times.
How to measure results
- Reduction in Sales/SAs asking questions about if we provide support for trials/prospects
- Reduction in tickets from non-sales-assisted trials
- Ticket deflection for free trials without sales assistance (link to handbook saying "only available to sales-assisted trials. if you're interested in trialing support, reach out to sales").
What would success look like?
- Sales and SAs don't have to ask in #support-managers about trial/prospect support.
- Support can link trials/prospects to SSoT to set expectations and provide details on the Support available to them.
- Ability to link to SSoT for Support details for sales-assisted trials/prospects
Closed by: gitlab-com/www-gitlab-com!56693 (merged)