Design member counts in GitLab.com billing areas
Problem to solve
When a customer signs up for a GitLab.com plan they'd like to use on a group, they pay for the year and assign their subscription to the group. If they'd like to add additional members, they're free to invite them to the group - we'll automatically bill for the user.
We simply let the customer add members to the group, without notifying the user that it might result in an additional charge. Furthermore, we don't offer a section in Billing that explains the charge, or informs the customer of how many members they've paid for (and how many members they're able to add to the group before they experience an overage).
We'd also like to eventually add the ability to pay for additional runner minutes and repo storage, and the Billing section should eventually evolve to support all in-product activity that may result in charges.
Solution
Similar to the license page for self-hosted (#7054 (closed)) instances, we will display the subscription usage data in a table. A detailed view of how the seat count has evolved through time will be available below.
Subscription table
The title for the table will be the name of the active subscription.
On the right side of the header there will be a button labeled Manage
, which will open the customers portal when clicked.
The table will have two rows, Usage and Billing.
The Usage row displays how many seats there are in the subscription and how many have actually been used. The columns in this row are:
- Seats in subscription: Number of seats that have been paid for.
- Seats currently in use: Number of active seats.
- Max seats used: Max number of members there have been in the group at the same time.
- Seats owed: The difference between Max seats used and Seats in subscription.
The Billing row displays information relating to the subscription's validity in time, as well as when payments are due:
- Subscription start date.
- Subscription end date.
- Last invoice: The date the last time the GitLab team (or automatic system) contacted the customer to settle up any outstanding balances.
- Next invoice: The upcoming date when the GitLab team (or automatic system) is scheduled to contact the customer to settle any outstanding balances.
Seat purchase history
The seat purchase history will give information on how many new seats were set up per month, as well as when the payment for each batch of seats was made.
The columns in the table will be:
- Month: Each row will group all the seats that were added during a certain month.
- Seats added: Number of seats added during that month.
- Price per seat: The price of a seat will change depending on the month when it was created, diminishing as the end of the subscription nears.
- Paid on: Date on which the batch of seats was paid.
There will be one extra row for the original purchase of the subscription, which will be indicated in the Month column.
Each row will have an Expand
button, which will unfold a nested table detailing which users created the need for new seats.
The columns in the nested table will be:
-
User: Profile picture, user name and
@username
- Joined on: Date on which the user became a member of the group. This attribute will make it possible to determine when the seat was created.
- Last activity: The last time the user had any activity in the group, displayed in timeago format. This will be helpful to determine which users can be removed from the group
- Member of: Members of subgroups count towards billing, so this is an important attribute to help determine where seats are being used.
Since we do not retain information on users once they leave a group, we cannot provide information on which users generated some seats. These will be displayed in a unique row using the following string:
+X user/users who has/have left the group
When there is a large number of seats, the table will serve them in batches of 10 rows. At the bottom of the table there will be a row reading 'Load more users', which will load 10 more rows on click.
Sorting
Optionally, a sorting dropdown can be included in the nested table. The options would be:
- Join date: Order seats by descending join date.
- Last activity: Order seats by ascending timeago value.
- Member of: Order seats alphabetically by group of membership.
Informational popovers
Seats in use | Max seats used | Seats owed | Last invoice | Next invoice |
---|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
![]() |
We will add information icons to some of the cells, which will open popovers when clicked. The copy for each one is as follows:
- Seats currently in use:
Users with a Guest role don’t count towards seats in use.
- Max seats used:
This is the maximum number of users that have existed at the same time since this subscription started. This is the minimun number of seats you will need to buy when you renew your subscription.
Learn more about renewals (Link TBD)
- Seats owed:
GitLab allows you to continue using your subscription even if you exceed the number of seats you purchased. You will be required to pay for these seats on your next usage review.
Learn more about invoices (Link TBD)
- Last usage invoice:
This is the last time the GitLab.com team was in contact with you to settle any outstanding balances.
Learn more about invoices (Link TBD)
- Next invoice:
This is the next date when the GitLab.com team is scheduled to get in contact with you to settle any outstanding balances.
Learn more about invoices (Link TBD)
Trial
When a group is on a trial, this will be reflected in the header of the subscription table. The content of the subscription table will behave slightly differently from a normal subscription:
- Seats in subscription: Since a trial is free, this count should increase automatically as users are added to the group. It will always equal Max seats used.
-
Seats owed: For the same reason, this count will always be
0
for trials. - Last invoice and Next invoice: Since a trial is free, there are no invoice dates.
The seat usage table will also behave slightly differently:
- The Original subscription row will be renamed Trial start.
- The price per seat will always be $0.
- The Paid on column will never have a value.
Free
If a group is using the free version of GitLab.com, the header for the table will read:
GitLab.com Free
In this case, the subscription table will also show some specific behavior:
- Seats in subscription and Seats owed will behave the same way as they do in a trial.
- The Subscription end date slot will be empty.
- Free subscriptions do not have invoice dates.
The seat purchase history has two peculiarities:
- The price per seat will always be
$0
. - The Paid on column will always be empty.
Unavailable automatic management
We currently show a message stating that some groups cannot automatically upgrade or downgrade their subscription. We will restyle this message as an alert block placed between the two tables and change the copy to:
Automatic downgrade and upgrade is currently not available for some plans. Please contact Customer Support if you wish to make a change.
Future
In the future, we want to add more information about billing, including pipeline minutes usage. We can do this by adding a new row to the subscription table.
Since we do not allow customers to buy more minutes at the moment, we could start by having the following columns in the Pipeline minutes row:
- Monthly minutes: Number of minutes included in the license.
- Minutes used this month: Number of minutes used in the current month.
- Minutes left this month: Number of minutes left this month.
- Average monthly minutes: Average amount of minutes used each month (excludes the current month).
In order to include a detailed view of how many minutes are used each month, we can divide the bottom section using tabs.
The minute usage tab would have the following columns:
- Month
- Minutes used
- Minutes unusued
Specs and measures
The tables have some particular sizing rules that are detailed in these specs:
- Subscription table
- Seat history table
-
Expanded seat history table. The nested table is offset from its parent by
16px
. - Full interactive spec previews
- Sketch file
What does success look like, and how can we measure that?
- We should be able to clearly explain any overage with the Billing section for the group.
- We should consider a Free group on GitLab.com and make sure we're offering them a valuable experience as well.