## Problem to solve SaaS customers are being surprised and taken off-guard by Quarterly Subscription reconciliations. Because self-service SaaS customers have not historically been charged true-ups, the QSR process and the fact that they have to pay for overages is totally new. See tickets from customers [here](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/337). ## Intended users ### What customers does this affect? This Epic only addresses SaaS customers who are enrolled in Quarterly Reconciliation (use cases 1.2 and 2.2.1 on the list of all SaaS customers affected by overages below). I believe that both would have `Subscription.TurnOnSeatReconciliation__c = Yes` in Zuora (but need to double check). <p> <details> <summary>Full scope of SaaS customers that are affected by overages</summary> 1. Self-Service SaaS customers 1. Subscriptions purchased/renewed **prior** to August 2, 2021: overage has never been enforced (via Annual True-ups). 1. Subscriptions purchased/renewed **after** to August 2, 2021: overage is being enforced via Quarterly Reconciliation. 1. Sales-Assisted SaaS customers 1. Subscriptions purchased/renewed **prior** to August 2, 2021: Sales Reps have been "enforcing" the overage manually (via Annual True-ups). 1. Subscriptions purchased/renewed **after** to August 2, 2021: overage is being enforced via Quarterly Reconciliation. 1. This is only applicable to customers paying with a credit card, or another payment method (that isn't a PO). 1. This is not yet the case for customers that require a Purchase Order or transact via a Channel, these customers would still be subject to Annual True-ups. </details> </p> ### What users does this affect? There are two main types of users that need additional communication around this topic: * Group Owner who is buying the subscription * **Group Owner or project Owner / Maintainer who adds additional members to the subscription, increasing the seat count** This Epic will focus on the **Group Owner or project Owner / Maintainer who adds additional members to the subscription, increasing the seat count**. See https://gitlab.com/gitlab-org/gitlab/-/issues/347267 for communication at the time of purchase. In smaller organizations, these two types of users are likely to be the same person, but in larger organizations it's more likely that they are different people. ## Proposal Users who are adding additional members should be aware that their actions will incur costs if they are adding users above the subscription's seat count. Group Owners should notified when the group is approaching and has exceeded its seat count. ### :white_check_mark: 1. Alert to group Owners when group is approaching seat count When a group is approaching its seat count, alert the admin. Communicate how many seats they have left and that they can go over their seat count with the overages appearing on their next bill. [See more details in the issue](https://gitlab.com/gitlab-org/gitlab/-/issues/348481) ### :white_check_mark: 2a. Modal that informs users of additional charges before adding a member Let a user know when they are about to add a Member that would result in additional charges for the group. [See more details in the epic](https://gitlab.com/groups/gitlab-org/-/epics/7804) ### :hourglass_flowing_sand: 2b. Modal that informs users of additional charges when a Guest user in an Ultimate group is promoted to a higher role Trigger the modal that informs users of additional charges when a Guest user in an Ultimate group is promoted to a higher role. [See more details in the issue](https://gitlab.com/gitlab-org/gitlab/-/issues/199893) ### 3. Email group Owners to notify them of overages #### :white_check_mark: 3a. Email to group Owners the first time a user is added that will result in additional charges When a group exceeds its seat count for the first time, notify the group Owners of the overage and the fact that they will be billed for this and any future overages. [See more details in the issue](https://gitlab.com/gitlab-org/gitlab/-/issues/348487) #### 3b. Continue to update group Owners on seat usage and any overages via user digest The ~"group::utilization" team has an issue open for a [user digest email](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1344) to regularly update group owners on the utilization of seats in their group. This will keep group Owners updated on an ongoing basis about the status of any overages and will prevent surprises.