Original issue: Fulfillment UX Research: GitLab Cloud Activation & Sync
What’s this issue all about?
Please review as additional context: &1735 (closed)
Problem Statement
Renewals and true-ups are a complicated, time-consuming manual task for both sales folks and customers. Here are some examples of why:
- Our license server only shows the total license count at the time of purchase/distribution and GitLab has to rely on the customer to tell us their up to date active user count at the time of renewal in order to complete the renewal (and true-up or true-down if necessary).
- Renewal license key application can be problematic if there is a large enough delay between distribution and application of the key - for example: If a customer purchases a 100 user license, and doesn't apply their key before adding more users, their key will not work. This is exacerbated if the renewal included a tier upgrade as they will not have access to new features until the correct key is applied.
- For SMB customers, the volume of renewals is much higher and the same problem applies as it does for mid-market and large customers, which results in a lot of manual work for GitLab.
- Self-managed trial license are vulnerable to issues where customers can infinitely take out trials or hack the key.
The proposal is that we deprecate license keys, in favour of a bi-directional instance ID containing hashed, dynamic license information about their active/inactive user count, dates for last synced and expiry, whether or not this instance ID has ever had a trial and Plan that can be synced automatically with our license server (or manually if the customer instance is air-gapped). Instead of GitLab providing a key, the customer would provide their instance ID either by a manual copy/paste into their customer account or by allowing automatic license synchronisation with our license server. Please check out this step by step flow example.
This would ensure that our license server is always up to date with the latest instance information, making true-ups and renewals clearer and easier and reducing risk of repeat trials.
I'd like to schedule calls with five or six different self-managed customers in SMB, MM and Large segments who have run into issues with license and user management with GitLab to understand what direction we need to take the Cloud Licensing Concept.
Who is the target user of the feature?
- System Administrators - People who administrate servers and the applications that run on them
- Billing Administrators - People who may need to handle billing and licensing (i.e. have access to the customer portal, but do not have access to the GitLab instance at the admin level).
- IT Administrators - People who handle application license management at scale across the organisation.
- Sales Reps and Account Executives who are helping customers with renewals and true-ups
In some cases, the same person could perform some or all of these roles rather than just one.
What questions are you trying to answer?
- Are our personas correct? Are they the right people we should be talking to?
- What are the main pain points that people have when applying and renewing self-managed licenses
- What are the best and worst licensing (cloud or otherwise) experiences that they've had with other organisations?
Current issues with licensing at GitLab:
- Inconvenient
- Confusing
- Error-prone
- Seat management is not clear
- Our true-up model is frustrating and unclear
Core questions
Is the vision for licensing accurate and solving the right problem(s) for our customers?
Additional questions
- Would there be any problem with them sharing the version number automatically as part of the license check?
"Why do we need to know the version number and Plan as part of the license sync?"
- It's extremely helpful for our support team to know what version a self-managed customer is running so they can help them faster
- Similarly, the Plan is important so that the customer receives the correct support SLA's
- We can provide security update notifications so customer instances are not vulnerable
- We know if customers have not upgraded to a recent version or applied their purchased Plan, meaning we can proactively work with them to provide assistance and help if they are struggling to handle this on their own.
What hypotheses and/or assumptions do you have?
- Customers don't feel comfortable or confident in how much they should really be paying at the time of renewal
- Customers are delayed from adoption and onboarding due to difficulties with applying a new license
- GitLab is potentially not billing customers properly due to inaccurate representations of active/inactive users as we have to rely on customers showing/telling us their active user count.
- Customers can block users so they are not counted as an active user at the time of renewal, meaning GitLab potentially loses money
- Customers can take out repeated trial license keys
- Sales folks struggle with completing renewals on time due to the above reasons, meaning we may not hit sales targets
- Support folks have to handle the follow-up problems that occur due to licensing issues, increasing ticket frequency and a potentially lower CSAT score
What decisions will you make based on the research findings?
The external customer research will hopefully help to further solidify the assumptions we have an ensure we're on the right track, as well as providing us with more recent and up to date feedback, since this is a legacy problem we're trying to solve.
For internal customer interviews, they will inform us of some of the pain points on the other side of the coin (workflow) and give us an opportunity to demonstrate a very first iteration of the visual workflow. It's helpful to have a basic screenshot click through guide of what we're thinking so that 1. we can demonstrate active progress we're making and 2. provide a visual flow for those who are more visual learners than text/spoken word based learners. We want to make it as easy as possible for sales folks to digest the early stage idea so we can get clear feedback and iterate quickly.
What's the latest milestone that the research will still be useful to you?
Progress Checklist
Luca
-
Schedule users for interviews -
User 1 - Friday, 13 Sep 2019 at 11am CT -
User 2 - Thursday, 3 Oct 2019 at 9:30am CT
-
Eileen
-
Write research plan [Deadline: 2019-09-06] -
Write user interview guide draft [Deadline: 2019-09-06] -
Get feedback on user interview guide [Deadline: 2019-09-11] -
Schedule 5-6 sales/support internal stakeholders for interviews/feedback on cloud licensing concept [Deadline: 2019-09-16] -
Rashad Bartholomew, Account Executive - Thursday, Sep 19 @ 11:30am CT -
David Astor, SA - Monday, Sep 23 @ 11:30am CT -
Mark Rogge - Tuesday, Sep 24 @ 11:30am CT -
Mike Miranda, SMB Sales - Wednesday, Sep 25 @ 10am CT -
Kelly Hair - Thursday, Sep 26 @ 11:30am CT -
Simon Williams - Friday, Sep 27 @ 10am CT -
Adam Olson, SAL - Friday, Sep 27 @ 11am CT
-
-
Write internal stakeholder interview guide draft [Deadline: 2019-09-17] -
Finalize internal interview script [Deadline: 2019-09-18] -
Conduct internal stakeholder interviews [Deadline: 2019-09-27] -
Conduct customer interviews [Deadline: TBD] -
Collect and analyze licensing-specific customer feedback [Deadline: Oct 16] -
Analyze interviews and summarize findings [Deadline: Oct 16] -
Document insights as issues in the Insights Repository [Deadline: Oct 18]
Links
- &1963 (closed) - Interview notes and recordings
- Research plan
- Interview guide
- License Sync Flow MURAL