## Summary Customer experience suffers from having a separate system 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. ## Proposal SaaS customers should not be forced to switch to a different website when they want to do business with GitLab. We should allow them to stay contained inside a product they are familiar with and make it really easy for them to handle their billing with minimal disruption. As a first iteration, we will move the purchasing flows related to GitLab.com to the GitLab.com UI and eliminate the current authentication process to the Web Store for GitLab.com customers. ## Timeline / Project sequencing ### Phase 1: Purchase flows | Status | Epic/Issue | Notes | | ------ | ------ | ------ | | :white_check_mark: | [Main subscription purchase flow](https://gitlab.com/gitlab-org/growth/product/-/issues/87) | MVC without filling in any existing customer information. Even if customer has an existing CDot account, information will not autofill.<br><br>_Note: Work was completed by the Growth team when Growth owned the purchase flows_ | | :construction: | - [CI minute purchase flow](https://gitlab.com/groups/gitlab-org/-/epics/6574)<br>- [Storage purchase flow](https://gitlab.com/groups/gitlab-org/-/epics/5789) | MVC without filling in any existing customer information.<br> Componentize the main subscription purchase flow to work as a template for the purchase of different products. | | | Make GitLab.com aware of subscription owner | Up to this point, the purchase flows we've worked on are ones that can be completed by any group Owner. The flows that come next require amendments to the existing subscription, so they can only be done by the subscription owner. | ### Phase 2a (can be worked on simultaneously with 2b): Subscription management flows, only visible to the subscription owner | Status | Epic/Issue | Notes | | ------ | ------ | ------ | | | [Subscription and purchases page](https://gitlab.com/groups/gitlab-org/-/epics/6543) `Only visible to subscription owner` | Since the subscription owner is the only one that can amend the subscription, we will only show the new subscription & purchases page to the subscription owner. Other group owners will continue to see the existing Billing page. | | | Subscription and purchases page `For non-subscription owners` | We will only show a modified, read-only version of the subscription & purchases page to non-subscription owners. We'll hide or disable actions that can only be done by the subscription owner. We'll also add information to the page about who the subscription owner is. | | | [Account info page](https://gitlab.com/groups/gitlab-org/-/epics/6937) `Only visible to subscription owner`| This will be the account information associated with the subscription owner's CDot account. | | | [Add ability for account information to be pre-filled into purchase & subscription management flows](https://gitlab.com/gitlab-org/gitlab/-/issues/343580) `Only visible to subscription owner` | This will prefill purchase flows with saved account information (credit cards, addresses) to make the flows more user-friendly and more frictionless. | | | Subscription management flows (can be completed in any order) `Only visible to subscription owner`<br>- [Upgrade](https://gitlab.com/groups/gitlab-org/-/epics/6542)<br> - [Add seats](https://gitlab.com/groups/gitlab-org/-/epics/6544)<br>- [Manual renewal](https://gitlab.com/groups/gitlab-org/-/epics/6969)<br>- Cancellation | | | | [Manage autorenewal flow](https://gitlab.com/groups/gitlab-org/-/epics/6970) `Only visible to subscription owner` | This should be the final subscription management flow we work on, because it is the most complicated and, unlike the others, is a brand new flow (does not exist in CDot). | ### Phase 2b (can be worked on simultaneously with 2a): Add customer entity and make subscription management flows visible to all group Owners | Status | Epic/Issue | Notes | | ------ | ------ | ------ | | :construction: | [Add customer entity](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1874) | This will allow subscriptions to map to a company/organization object and not a single user account. This is the key to allowing multiple users to manage a single subscription. | | | Create transition plan for moving sensitive information from individual CDot accounts to the customer entity | We need to be sensitive about displaying information that was previously attached to an individual CDot account to other group Owners. For example, a subscription may have a credit card associated for the purposes of autorenewal. That credit card is currently attached to an individual user account in CDot and is only visible to that user. How do we transition that subscription and its associated credit card/address to the company entity, which will be visible to all group Owners? | | | Give all group owners visibility into account and subscription management info/actions<br>- Account info page<br>- Subscription & purchases page<br>- Upgrade<br> - Add seats<br>- Manual renewal<br>- Cancellation | As these flows are finished as part of phase 2a, make them available to all group Owners. | ## Future Iterations 1. Create a subscription management area within GitLab.com 1. Move subscription management services to GitLab.com (Invoices, contact info, payment methods) 1. Consider whether Self-Management purchase flows and subscription management should live in GitLab.com subscription management, in the self-managed instance, or in the Web Store.