Materially improve purchasing and licensing workflows to improve sales efficiency through fixing 16 of 16 Fulfillment pain points => 56%
Fulfillment needs to deliver on the rest of the pain points from FY21-Q4 OKR.
Why is this OKR important?
These pain points were identified at the end of 2020 as causing inefficiencies in our sales process and suboptimal experiences for our customers, so are a priority to fix.
How do I achieve this?
Work with your product counterparts to prioritise and drive progress on the below issues.
How will this be measured?
We are unlikely to deliver each of these to completion (and don't have good definitions for completion at this stage). I'd like to mark each of these points as completed if we can get to a launch stage with minimal functionality, understanding that each project may require ongoing iteration.
| PAIN POINT | PAIN POINT THEME | DESCRIPTION | OPPORTUNITY | LINK | DRI | Status | % complete |
|---|---|---|---|---|---|---|---|
| 1 | Data integrity | Data can become out of sync because you can adjust account variables in multiple places which do not sync back to the other systems. Ex. Manual adjustment of CI minutes performed directly in GitLab.com, this now puts the amount of subscription CI minutes out of sync with what is in GitLab.com. | In a first iteration, let's establish a top list of key data points that are critical to the business. Using those, we should trace availability of actions which cause the data to be out of sync between systems. | gitlab-org&4307 (closed) | @jameslopez | Backlog | 54% |
| 2 | Sales efficiency | When a new license is loaded, an error will be thrown if the instance has more users than what they’ve purchased. This happens frequently with sales-assisted purchases because of the time lag between negotiations, quote generation, signature and provisioning. | We should introduce an overage threshold to allow prevent this abrasion during the sales and onboarding processes. | https://gitlab.com/gitlab-org/license-gitlab-com/-/issues/184 | @jameslopez |
|
100% |
| 3 | Sales efficiency | When additional users are purchased with sales, the sales person must figure out which subscription to apply the add-on to. In some cases, GitLab.com customers may have multiple subscriptions | Pass GitLab.com namespace to SFDC and append to Closed Won Opportunity record. | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1989 | @jameslopez | WIP %13.11 | 100% |
| 4 | Sales efficiency - Cloud license management system | When a self-managed subscription is modified (additional users, tier upgrade), the prior license is not deactivated and therefore could be used in another instance exposing us to revenue loss. Aim is deliver the MVC for Cloud Licensing as per #10409 (comment 510629180). | Implement Cloud License Sync which will allow for deactivation of licenses. | https://gitlab.com/groups/gitlab-org/-/epics/1878 progress tracked in https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/185 | @jameslopez @rhardarson | WIP %13.11+ | 54% |
| 5 | Sales efficiency & Customer tools | The Max User logic of only referring to the last 12 months from the end date has caused repeated pain for non-standard contract lengths. For example, a subscription term less than 12 months picks up values from the prior contract period and subscription terms greater than 12 months doesn’t consider time in the beginning of the subscription period which could leave money on the table. | gitlab-org/gitlab#7008 (closed) | @csouthard |
|
100% | |
| 6 | Data integrity | For CI minute provisioning, we are sending the diff and not the total value. This causes data integrity and transaction processing hurdles. | Update CI Minutes provisioning API so transactions can be retried | gitlab-org&4331 | @csouthard | Scheduled %14.0+ | 0% |
| 7 | Data integrity | Our current architecture stores subscription information against a user-level Customer record in the Customers database. As a result, we suffer many issues when contacts at companies change. A common example is when a new contact doesn’t know about the Web Store account and creates a new account which then breaks associations to prior subscription. | Simplify and create the relationship between a subscription and a namespace and leverage the GitLab.com flow to bring clarity to the subscription and namespace relationship. | gitlab-org&4421 (closed) | @chris_baus | Backlog | 0% |
| 8 | Data integrity | When a subscription contact’s permissions change within the GitLab.com group, they they lose access to the subscription and the link between GitLab.com and the Web Store Customers breaks, causing data and purchasing issues. | By simplifying the database architecture and utilizing GitLab.com group member permissions to allow access to purchasing and subscription management activities, we can prevent the orphaned subscriptions created in this use case. | gitlab-org&4421 (closed) | @chris_baus | Backlog | 0% |
| 9 | Purchase & provisioning flow improvement | Customer experience suffers from having a separate portal with a separate login. While we have SSO connected via GitLab.com, it’s not always obvious to users and the look and feel of the system makes it clear that you’re in another system. | Move all purchasing flows for GitLab.com purchases to the GitLab.com frontend interface and eliminate the need for a separate Web Store login. | gitlab-org&1888 (closed) | @chris_baus @rhardarson | WIP %13.10+ | 75% |
| 10 | Purchase & provisioning flow improvement | During the CI minutes purchase process, depending on how the user entered the purchase flow, they may be asked which namespace the CI minutes should be applied to. This is an over complication as a result of disparate systems. | Simplify and create a lower touch process by moving the CI minutes purchase flow into GitLab.com | gitlab-org&5391 (closed) | @rhardarson | WIP %13.10+ | 70% |
| 11 | Purchase & provisioning flow improvement | When a new subscriber enters the purchase flow from our pricing page or from the Web Store, if they do not already have a group created, they are blocked from continuing their purchase. | Move all new subscription purchase flows to the GitLab.com flow so a group is created when one is not available during purchase. | gitlab-org/customers-gitlab-com#1986 (closed) | @rhardarson |
|
100% |
| 12 | Purchase & provisioning flow improvement | There are a number of steps a GitLab.com customer with a sales-assisted order must take to complete provisioning of their subscription. | Simplify and create a lower touch process by moving the purchase (UI and transactions processing) and subscription management activities within GitLab.com. | gitlab-org&5012 | @chris_baus @rhardarson | Scheduled %14.0 | ~5% |
| 13 | Purchase & provisioning flow improvement | If coming from a trial, the address details are not filled out and the user is taken to other pages to complete the address after receiving a purchasing error. | gitlab-org&4465 (closed) | @rhardarson | Backlog | 15% | |
| 14 | Sales efficiency, Revenue & Customer tools | GitLab.com subscriptions are not prompted to enter a number of seats they would like to purchase during the new subscription purchase flow. Instead, we read the number of seats active at the time of purchase and charge them accordingly. This limits growth and doesn’t give purchasing control to the user. | Allow GitLab.com subscribers to add more seats than what is currently active during the purchase process for expected growth. | gitlab-org/customers-gitlab-com#1987 (closed) | @chris_baus @rhardarson |
|
100% |
| 15 | Sales efficiency & Revenue | Renewals processed in the Web Store are currently being booked at Effective price instead of List. | Book renewals at list price to stop leaving revenue on the table. | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/790 | @chris_baus |
|
100% |
| 16 | Eliminate personal namespaces | We currently allow GitLab.com paid plans to be applied to two different objects: personal namespaces and group namespaces This leads to several problems including user confusion and frustration when group level features are not available for personal subscriptions. | Eliminate subscriptions for personal namespaces. They are frequently elected by accident and cause a loss of revenue since we don’t charge for contributor users within those paid subscriptions. MVC to eliminate the ability to purchase new subscriptions for personal namespaces | gitlab-org/gitlab#300345 (closed) | @rhardarson | Scheduled %13.12 | ~10% |
OKR scoring
Pertinent excerpts from: #10680 (closed)
Good
- We made great progress on the this OKR
Bad
- This OKR was (in hindsight) poorly written as it was not clear how to measure progress nor what was considered success.
- EMs were generally not working to update the status of OKRs every two weeks per our process
Try
- All future OKRS should be measurable
- EMs should update OKR status every two weeks. We should put it in the weekly EM meeting and/or set up an automated reminder in slack.
Edited by Wayne Haber