[UX & Design] Communicating prorated charges for seats added to a paid group

Problem

We currently do not charge customers when they add users to a group on GitLab.com. This means we are hosting users for free, missing out on revenue and some customers are confused as to how they pay us for those users, whilst other customers are not paying for them at all and abusing the system by removing users prior to their renewal date. If customers add a user and don't pay for the user, we are hosting those users for free, which costs GitLab money (in addition to the loss in revenue of them not paying for their user). Customers do not currently get billed fairly in their yearly true-up and are charged at 100% for their users even though they may have only added them for one day prior to their renewal date.

Billing for users after they add they are added to a group for GitLab.com is problematic from a user experience perspective (as we have to bill them each time we make an amendment to their subscription in Zuora), which means each time they add a user they get a new invoice to pay.

Proposal

Iteration 1 (MVC): Better communication to users

Here are the issues for the implementation of the MVC:

What problem are we solving? Proposed solution
Subscription seat information is only accessible to group owners/admins, but other user roles can also add users to paid seats, impacting billing. Add subscription seat information on the members page for the instance/group and its subgroups, visible to all users who can add members to paid groups.
SaaS___Group_members_page__at_seat_count
When a user is added to a paid group/instance that would put the group/instance over its seat count, it is not clear that adding that user will incur charges. When a user is being added and it would increase the subscription's Seats owed/Users over license number, show a modal and ask the user to confirm that they would like to add a seat to their subscription.
SaaS___Group_members_page__add_seat_modal

See the full flow documented in Mural.

Iteration 2: Proration

Here is the issue for iteration 2:

What problem are we solving? Proposed solution
When a seat is added with only a few months left on the subscription term, customers are not thrilled about having to pay for that seat for the entire year. When a customer adds a seat above their subscription seat count, ask them to approve a prorated amount for that seat based on the amount of time left in the subscription. They will be billed for all seats added at the end of their subscription term.
Screen_Shot_2019-12-16_at_12.22.30_PM
Since users other than admins/owners can add paid users to groups/instances, the admin/owner is not always aware that additional users have been added beyond the subscription seat count. Send a monthly email to owners/admins detailing the subscription changes that month.
Screen_Shot_2019-12-16_at_12.23.24_PM
When admins/owners receive a true-up bill for additional seats added over the subscription term, they do not have visibility into when those seats were added and what charges were incurred. In the customer portal, add a detailed cost breakdown of additional charges incurred over the course of the subscription term.
Screen_Shot_2019-12-16_at_12.23.15_PM
GitLab is missing out on revenue by not charging for users added above the subscription seat count. At the end of the customer's subscription term, manually generate an invoice for the prorated charges incurred over the course of the year. (We will automate this process in a later iteration.)

See the full flow documented in Mural.

Designs

Next steps

@esybrant does the plan/schedule below work for you? The dates aren't rigid, but I'd like to keep some sort of momentum going on this and have this ready for engineering for 12.6 if possible.

Other tasks:

Later iteration

Understand how we can help customers pre-pay for users via invoice. See: &1898 (closed)

Edited by Emily Sybrant