DISCUSSION: Direction of the Customers Portal and Fulfillment process
Overview
Note: We will keep this open through %13.4, and then consolidate into an action plan.
This is an open discussion on the direction of Customer's Portal and Fulfillment process. This is parallel to the team responsibility discussion that @amandarueda opened here: https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/100.
It is difficult to make decisions on team responsibilities and potential effort without having a shared (for lack of a better term) vision about the future of Fulfillment at GitLab.
Where we are
Note: this could use input from those who have been at GitLab longer or know the history better
If we consider the historical context, the Customer's Portal makes a lot of sense. Our customers were installing Self-managed instances and they needed a way to manage their paid services. Hence a "Customer's Portal" as a project separate from GitLab was created.
But as time has gone by the requirements of the Customer's Portal have increased. It needs to support more products including SaaS Plans, CI Minutes, Seat Purchase, etc. It wasn't until 2019 that the requirements of fulfilling our Customer's purchase became a significant engineering effort with both the formation for Fulfillment Frontend and Backend teams and partners in Growth.
In order to better support business partners and improve the system integrations from the Customer's Portal, the Business Integration team was formed.
Over time, the Customer's Portal is becoming middle-ware between GitLab and third-party systems like Zuora. This is becoming more apparent as we move UI completely out of the portal and into GitLab.com.
Problems
- Disjointed UX experience
The purchase experience is disjointed. Even if the customer remains in the portal for all their entire purchase experience, the internal experience still isn't unified. We've made progress in this area, but there is still more work to do there. Likewise some flows can be completed directly from GitLab.com, but most require interfacing the Customer's Portal.
- Separate Logins
There isn't a single sign-on for both GitLab.com and the Customer's Portal. This is for historical reasons stated above, but I don't think there is any technical limitations preventing us from using SSO.
It probably isn't possible to unify the credentials with out some input for the user, but it should possible to devise a UI where when the user logs in to Customer Portal, they are asked to either create or link an account with GitLab.com.
- Fragility
Critical fulfillment functional frequently fails leaving either customer with errors or unfulfilled purchases. This can also result in data errors where the data between the projects is out of sync.
To resolve some of these issues, the support team resorts to using the console directly to modify customer data.
- Low Delivery Rate
The engineering teams aren't delivering on as many changes and feature requests as required by the business demands.
There are potentially 3 reasons for this:
- Change in direction to implement and during implementations of high-priority features
- Long term acquired complexity in the code base
- Difficult to maintain test suites
- Features are limited by 3rd party tools
Occasionally we can't implement requested features because of limitations in Zuora or other 3rd party tools.
- Fundamental functionality is sometimes missing
Goals
- Achieve the lovable level of maturity
- Move all UI to GitLab.com
- Unify logins with GitLab.com
- Better Monitoring (proactive response to issues)
- Reliable data
- Support more Growth Experiments (maybe through better APIs like GraphQL)
- Reduce need for Support to require console access (or improve support UI)
- Combine License App and Customer Portal
Action Plan
As an outcome of this issue, we've broken down the topics raised into buckets based on level of effort and created issues/epics to further discuss and prioritize.
Small
Achievable in 1 milestone
- Adding missing indexes for DB tables
- Mentioned by @shreyasagarwal.
- Issue for Customers Portal
- Issue for License App
- Confidence: High
- View Customers Portal logs in Kibana
- Issue
- Confidence: High
- Complete the pajamas update to reduce legacy code
- Epic
- Mentioned by @vitallium
- This is under "Small" because most of the effort has already been completed, but let me know if you think the remaining work is considerable effort.
- Confidence: High
Medium
Achievable in 2-3 milestones
- Improve the admin interface of the Customer Portal
- Mentioned by @chris_baus.
- Epic
- Confidence: Medium
- Improve the state of the Order model
- Outlined by @jejacks0n
- Issue
- This seems to fall under the data integrity topic (also listed below) so I've created this issue in that epic.
- Confidence: High
- Reduce the noise in Sentry
- Issue
- I'm not quite sure how much effort is required to resolve every error, but we could make a significant improvement in a few milestones.
- Confidence: High
- Re-architect the contact/account architecture
- Issue
- Related Business Ops Epic
- Mentioned by @chris_baus
- Confidence: Medium
Large
Multiple milestones; Coordination between multiple teams.
- Move UI to GL.com
- Epic
- Confidence: Low
- Creating a (better) API
- Epic for transitioning to GraphQL
- In my opinion, this epic is strongly related to "Move UI to GL.com". In order to effectively move the Portal UI elements to GL, we must have a better API.
- Confidence: Medium
- Integrate the Customers Portal with GitLab.com
- Raised in the Engineering weekly and mentioned here by @chris_baus
- Spike Issue
- UX Research Issue
- Past issues that relate to this discussion:
- Confidence: Low
- Merge the License application into the Customers portal application
- Epic
- Confidence: Medium
- Assessment of integration architecture
- Issue
- Confidence: High
- Single Sign On between Customers and GL.com
- Deprecate Customers Portal logins. Require a GL.com account to login to the Customers Portal.
- Issue
- Confidence: Medium
- Improve data integrity
- Epic
- Confidence: High
- EntApp Architecture
- Epic
- Confidence: Medium
- Improvement GL-Marketo integration
- Issue: Improve GitLab<> MKTO API Integration
- Confidence: Medium
Many of the items above are related to the topic of how to improve the Fulfillment-related tasks (purchasing, subscription management, etc) from a customer perspective and an engineering perspective. There are a variety of options outlined here that live on a spectrum from "Proceed as-is" -> "Move everything into GL". This is an important discussion that will need to involve perspectives from across the company. I'll open a follow-up issue to continue this larger architecture conversation.
Miscellaneous
Not related to effort
- Incorporate an embedded SRE for Fulfillment/Growth
- Work more technical debt issues
- Either increase percentage per milestone or have milestones dedicated to tech debt.
- Mentioned by @jameslopez