Categorizing type of work by Fulfillment group
Summary
We have defined the work which each of the backend Fulfillment groups will be responsible for here. However, there are a number of areas of workflow, issues and bugs which don't neatly fit into the existing definitions.
Below I will catalogue examples of grey-area issues so we can align as a team on which team will own these sorts of issues moving forward.
Examples
This is a WIP list which I will continue to add and update.
# | Type of issue | Example issue | Team | AR Notes |
---|---|---|---|---|
1 | Trials - SaaS | example | Utilization | Since the most common entry into SaaS trials is w/in the product, I'm leaning towards Utilization |
2 | Trials - SM | License | I lean towards whichever team takes SaaS trials for consistency in UX. | |
3 | Provisioning/Deprovisioning of SaaS plans | Utilization | I lean towards a single team (License?) owning all provisioning/deprovisioning regardless of it being a subscription or add-on service but I can see a world where Utilization owns the consumable add-on services since the code lives in GitLab.com | |
4 | Provisioning/Deprovisioning of SM plans (future via Cloud Sync) | License | See 3 | |
5 | Provisioning/Deprovisioning of CI minutes | Utilization | See 3 | |
6 | Provisioning/Deprovisioning of Storage | Utilization | See 3 | |
7 | Autorenewal changes (backend) | Purchase | I lean towards Purchase since although it's an automated purchase, it is still a purchase and interaction with Zuora | |
8 | Modifying Sentry error logging | example | assign based on context | Would be nice for one team to own all error logging (Sentry, Kibana, etc) and I'd lean towards License for this. |
9 | Creating skus | example | Purchase | IMO Purchase makes the most sense since skus are used for purchases or display of subscription information. Plus, the Zuora tie-in. |
10 | Customers portal admin tools | example | License | Would be nice for one group to own all internal admin tools, whether they are on CustomersDot, LicenseDot, GitLab.com or APIs because there would be oversight and a cohesive plan for the feature set. I recommend License for this. |
11 | Billable users, max users calculations in SM/SaaS | example | Utilization | Since the values are displayed in the product, I'd recommend Utilization to take the lead on these. |
12 | Subscription management features in GitLab.com (invoices, subscription cards, credit cards) | example | Purchase | I'm on the fence here, I think either Utilization or Purchase can own subscription management once it is in GitLab.com. |
13 | Purchase flows once moved to GitLab.com | Purchase | Although the code base will be GitLab.com, I think it makes sense for the Purchase team to own the purchase flows. | |
14 | Emails/In-app notification related to subscription management | example | Purchase | Recommend Purchase |
15 | Emails/In-app notification related to consumption (users/CI/storage) | Utilization | Recommend Utilization | |
16 | Emails/In-app notification related to cloud license | License | ||
17 | Work related to integrations with SFDC and Marketo | License | ||
18 | Work related to integrations with Zuora | Purchase |
Edited by Amanda Rueda