Create a process which provides the means of identifying the number of customers who are not able to activate their instance due to overage enforcement?
Problem Statement
Around the GitLab 14.2 milestone, the Fulfillment team implemented additional Seat checks and True-up validation. Subsequent to this we need to track the impact of the rollout and as such require the means to identify how many support tickets we have where customers are not able to activate their GitLab instance due to overage enforcement.
Business requirements
-
Ability to identify any ticket related to a license activation
- Defined as: customer is unable to successfully apply a license/activation code to their instance
-
Ability to identify cause of failure:
- As related to a known bug, such as:
- True-up validation errors due to multiple unique subscriptions (Ramp deal, Billing Entity Change)
- True-up validation errors due to customer transitioning legacy > cloud after manual legacy license created.
- Multi year cloud license was generated with conflicting trueup_from/to and previous_user_count values
- As related to a known bug, such as:
- As a new, not previously identified bug (an issue should be opened).
- Or not a bug (customer misunderstanding, customer unwilling to pay, sales process issue, etc.)
- Ability to track additional ticket attributes for reporting:
- Current/previous license type (Cloud, Legacy, Offline)
- New license type being applied (Cloud, Legacy, Offline)
- Instance version
What is the problem?
Unable to currently use Zendesk to identify and report on these occurrences or customers.
Why is this a problem?
We are unable to measure the impact of the changes and identify if further iterations are required. This is because Zendesk L&R tickets in the current configuration do not provide the granularity required to identify, in particular, this is because.
- The current Zendesk Fields
Transaction Issue Type
andL&R: Licensing Troubleshooting
do not provide the options to identify customers impacted by these introduced features. - We are unable to automatically add a Zendesk tag to a ticket which would provide the necessary granularity upon ticket creation. Therefore tags will have to be done upon ticket closure.
Proposal
- Fulfillment product team review the above listed Business Requirements and identify if there are any gaps?
- L&R Support Engineers review the above listed Business Requirements and identify if there are any gaps?
- Once we have a complete list we map each occurrence to a tag or a set of tags
- We choose a go-forward option from:
- We create a Macro for each tag and document the requirement for using the individual Macros in the L&R Workflows Handbook Section
- We use a list of requirements which are mapped to tags, add these to the L&R Workflows Handbook Section section as a table
- We come up with an alternative approach such as creating new multiple
Transaction Issue Type
andL&R: Licensing Troubleshooting
fields.
DRI
Required Resources
- The Fulfillment product team
- The L&R support management team
- The L&R Support Engineering Team
Potential Roadblocks/Things to consider
- The process will not be completely automated therefore we are relying on SEs to remember to use the macros. We’ll also be relying on them to use the right macro or use the right tag and to want to do so. At times L&R engineers can be extremely busy and may forget to do this,
- Zendesk automatically closes tickets after the customer has not responded for 2 weeks. None of those tickets will have either a macro or a tag applied.
Desired Outcome
We have an easy-to-follow workflow process in place that L&R support engineers can consistently follow and which is documented We are able to accurately report on the above Business Requirements
We can report on the above Business Requirements