[UX & Design] Communicating prorated charges for seats added to a paid group
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.
Customers should pay a pro-rated amount (by credit card or ACH) for new users as/before they add them to their group. We would need to prevent customers from adding more users to a group than they've purchased and provide clear messaging to explain what to do to add more users. We could also make some UX improvements to the portal here as well to accommodate this change.
Update based on the team's Nov 5th design review
We felt that forcing pre-pay before being allowed to add users was too restrictive and not very scalable to larger organizations. It put the billing group owner in the position of being a bottleneck for other group owners and subgroup owners who want to add users. We are now exploring a flow where owners are allowed to add users over their subscription seat count, and they will be invoiced/charged a prorated amount for those users monthly.
Update based on the team's Nov 11th design review
As we talked through the proposal, we realized that we were trying to solve too many problems at once. With that in mind, we more narrowly defined scope for our MVC. What's now out of scope (but we will likely explore in iterative approaches): user management permissions, automatic credit card charges, invoicing, subscription seat count decreases. What's in scope: communication to users when they add a group member over their seat count, prorated charges for users added above seat count, log of subscription seat changes over a time and the billing impact of those changes.
With that in mind, we are exploring a solution that (1) prorates charges for seats added to a paid group, (2) communicates those charges to a user when they are adding a member to a group with no available seats, (3) sends the billing owner a regular monthly summary of charges incurred that month.
@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.
- @esybrant create v1 design mockups by 1st Nov
- @esybrant, @tipyn, @eileenux, & @timnoah to review mockups together on 5th Nov
- @esybrant to iterate towards v2 mockups based on feedback by 11th Nov
- @esybrant, @tipyn, @eileenux, & @timnoah to review mockups together on 11th Nov
- Group review with engineering on 14th Nov
- @esybrant iterate towards v3 (final designs) ready for 18th Nov (12.6).
- @rdickenson update handbook: https://about.gitlab.com/handbook/ceo/pricing/#true-up-pricing
- @rdickenson update customer documentation
- @williamchia @mkarampalas @esybrant work on internal and customer facing messaging plan
Understand how we can help customers pre-pay for users via invoice. See: &1898