Update .com paid signup process
Problem
As a user, when I signup for a paid package, the process is convoluted, complex and confusing. I don't understand why I have to create 2 accounts in order to signup and pay. I would rather try to figure out how to use the product for free rather than invest my time trying to figure out how to pay.
Data
While the MRR growth rate for larger packages on .com have been increasing, smaller package MRR has been decreasing.
While we see a decrease in associated MRR growth at smaller packages and an increase in month over month MRR growth for the largest dollar packages, the month over month paid account growth count is decreasing for both Gold and Bronze.
Data Interpretation
What we believe this data tells us is that paid account acquisition at high dollar amounts is very efficient. Sales does and amazing job of pushing high dollar users through the funnel, and are extracting more dollars from fewer accounts. At lower levels, we do not see this efficiency. If sales is not involved on the paid conversion process, the user is significantly less likely to convert to a paid customer.
Hypothesis
The convoluted and difficult nature of paying for your package on GitLab.com is causing many lower dollar users away. Improving the paid signup process will drive up both month over month paid account growth and the month over month MRR growth rate (will update to ARR when we have those metrics).
Solution
Move paid signup into gitlab.com.
Idea
Proposal
- See designs in design tab
- Prototype link
Goals
- At signup the user should never know that a second application exists that manages their payments
- The user should not have to create a password or profile for customers.gitlab.com
- The user should be able to log into customers.gitlab.com using a code that is texted to their phone (rather than password)
- The user should be able to log into customers.gitlab.com using a code that is emailed to their address (rather than password)
- If the user is a part of this test, when linked to customers.gitlab.com from their instance, they should be taken to a signup page that does not prompt them for a password
- The user should never have to manage a trial license key
Risks
- Allowing users to directly signup for a paid plan could decrease sales leads
- Measure: We will monitor decreases in the total number of sales leads during this test
- Mitigation: We could limit the number of seats or the package (or both) a user can self serve and direct any over a certain amount to sales
- Allowing users to directly signup for a paid plan will decrease trial registrations and there fore sales leads
- Measure: We will monitor for decreases in the total number of trial registrations in during this test
- Mitigate: If this is the case, we should run this experiment before making any further investment as making it easier to signup for a trial should balance the scales
Rollout
Date | % traffic |
---|---|
Jan 13 | 10% |
Jan 20 | 25% |
Jan 27 | 50% |
Feb 10 | 100% |
How do we measure success?
- SAAS paid signup revenue vs control
- SAAS paid signup account count by package vs control
- SAAS trial signup count by package vs control
- Account creation conversion - accounts_created/Sign_ups_started