Streamline gratis support requests
Problem Statement
What is the problem?
See https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/4645+ for a full discussion.
Briefly: the priority prospect process as it stands today only serves one specific set of needs when it comes to offering support at no-cost.
Why is this a problem?
There are several situations where it make sense, as a business, to provide support coverage at no-cost:
- client is migrating from SM to SaaS and has SaaS specific questions while their SM subscription is valid.
- client has a temporary license to provide coverage during a negotiation period
- former customer, or a business unit within a former customer, is evaluating GitLab.
Proposal
- Expand priority prospects into a new gratis support offering that will cover more use cases.
- Remove "for whom evaluation of support is part of their decision criteria" as a requirement for access
- Create a single intake form that will cover these use cases.
- Have a single team (ops) handle these requests (regardless of type) end-to-end.
Specific materials to review:
- Documentation - Support Ops workflow: https://handbook.gitlab.com/handbook/support/readiness/operations/docs/policies/gratis_support/
- Documentation - Requesting Gratis Support (Using the intake form): TBD
- Intake form: https://gitlab-com.gitlab.io/support/support-ops/forms/gratis-support-request-form/
DRI
@lyle will act as the DRI for this issue.
RACI Matrix
Responsible: who is responsible for doing the work this change request represents?
The Ops team will be responsible for:
- creating appropriate documentation and workflows for making sure requests for gratis support can be fulfilled.
- tracking requests and their outcomes, as we do for priority prospects now
- removing access to support once the gratis support period is over
Accountable: who is accountable for the results represented by this change request?
@lyle is accountable for the results of this change request.
@lyle will be the person to get involved if:
- requests are not able to filled in a timely manner
- there are situations that aren't covered
- a request is delayed because of capacity
- something horrible goes wrong that was unforeseen
Consulted: who should be consulted on this proposal?
- Support Managers: are there specific areas that we've seen that aren't covered by the form as presented here?
- Support Readiness Specialists: are there any concerns with processing a wider scope of requests?
Informed: who needs to be informed if this change request is accepted?
- Field team
Required Resources
- Buy-in from Ops
- Feedback from Support Managers on areas of concern
- Documentation that will facilitate the servicing of requests
Potential Roadblocks/Things to consider
-
Future iterations may need to be made to the process: currently there's a cap of 30. If we open this up to cover more cases than prospects we may hit our number of slots. This will trigger some discussion about our capacity to serve in these cases or how we should prioritize.
-
This isn't a final state: end-to-end ownership of this process is interim and hopefully can be transitioned out of support (see comment: https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/4645#note_1568051800
Desired Outcome
Non-outcomes
This change should not affect:
- Most of the literals of the priority prospect offering: SLA times, number of slots will remain the same.
What does success look like?
- Single place for gratis support requests to be filed.
- Single team to service them.
- More situations covered.
How do we measure success?
- Requests completed within SLO
Where would future feedback go?
RFC in support-team-meta
Related Issues/MRs/Epics/Tickets
https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/4645