Customers creating a new group and buying a new subscription, instead of upgrading or renewing their existing group
-
This ticket they bought new on a new group instead of renewing, and I’m not sure about the root cause, but it also looks like there was a different purchaser, so perhaps there was some issue with visibility/access to the namespace
🤔 It looks like the purchaser had permissions, so I struggle a bit to understand how they missed the renewal flow and got into a new purchase flow instead. -
This subscription is the one that they got the email about auto-renewal not being possible and to contact sales: https://customers.gitlab.com/admin/reconciliation?query=A-S00073023 - but now I realise it’s probably because of EoA that QSR is disabled? They happened to have 1 seat owed and I advised that they add the seat before renewal (this is pretty hard to explain) and self-serve the renewal since previous orders looked web direct and they weren’t getting response from sales.
^The sense I get from this example is that they expect to pay for only the users that were active in the namespace and only pay for the time they were active. Comparing quarter, annual, and pro-rata charging is just a little hard to lay out for a customer sometimes. I’m asking the customer to buy an additional seat to pay for an overage, but they don’t want another seat.
2b. In this ticket the customer got a QSR charge in 1st quarter and then asked billing to cancel the seats increase and the invoice because they don’t want a seats increase
- This customer purchased new subscription on new group instead of upgrading on their existing namespace (they didn’t have permissions on the existing namespace, but they followed through with the purchase and created a new group anyway even though it was strange to them that they couldn’t see their existing namespace). I made the mistake of helping move the 1 seat sub to their namespace, which immediately give them 4 seats owed. ^ Feedback about this customer is that I had two calls with them and they really struggled to understand our billing model. They ultimately wanted to have 6 users in their namespace, instead of 5, so somehow they got the idea that if they purchased 1 seat, they could apply that to a project and add as many people as they want. I think this is a bit of an edge case in customer thinking, so I wouldn’t rely on this example too much, however, I can see how it would be confusing going from a 5 user limit to a seats-based charge for all billable members in the namespace. The threshold for switching to paid subscription is minimum 5 seats upfront for this conversion, which may not seem intuitive to people.