Initiate pro-rated charges when a .com customer exceeds the users in their subscription
Problem
- We do not allow customers to pay a prorated charge for new users on .com. Since we don't typically do a true-up for .com at renewal and do not have any automated way to do this, we are losing significant revenue.
Proposal
- Alert customers to the prorated amount that will be charged at the time of adding users over their subscription amount
- Charge the default payment method on file at the time of going over their subscription
- In the case where the payment fails, block the add of the user and ask them to update their payment method on file (link to the customers portal where they can do this)
- Create a breakdown of those charges in the customers portal for historic purposes
- For customers without a credit card on file (who pay via sales-assisted ACH), ask the user to verify the prorated amount when they are adding a user that would put them over their subscription. Add additional charges to breakdown in the customer portal and in SFDC, so that a rep could to manually true them up.
Business Requirements:
- Automatically open opportunities in SFDC and move their stage to closed won so we are tracking the rev in SFDC also * The important fields would be:
- type = add-on
- iACV = cost of users added
- close date = invoice date
- stage = closed won
- opp owner = assigned to appropriate account owner ( @james_harrison )
- a notification to the rep so they can assist with any growth plans for clients
- adjust the renewal iACV on the renewal opp that is open with future close date
Result
Increased revenue for Gitlab, an easier to understand and fair billing model for customers.
Designs:
- Wireframes
- Designs in design tab
- Prototype
- Specs in Sketch Measure
Next steps (if any)
- Finalize high fidelity designs
- Technical conversations
How will we measure success?
- Additional revenue generated by these charges
- Positive customer sentiment to a more transparent and standard billing policy
Open Questions
-
Can we do the charge at the time of the warning/monthly/at the renewal? Yes -
Are we comfortable with telling people we will charge them at the end of their term and then not? Not really, we'd rather charge them at the time of the message -
How do we handle cases where many people are added in a day - can we do a daily charge? - better to charge for each one -
Can we use this for self-managed? (we would not pro-rate in that case) - this would be a build on the mvc warning - TBD, likely needs license sync first but may be able to leverage the work that the acquisition team is doing around initial payment
Next Steps
-
@esybrant to update designs based on coversation with @jameslopez on 1/16/20
To-dos coming out of sync meeting on 1/30/20:
-
Determine if we can identify folks paying via ACH/Sales assisted orders that don't have a payment on file @jameslopez -
Handle case where credit card owner is no longer a member of the group @esybrant, @mkarampalas, @amandarueda - Emily to craft error message for this case
-
Handle case for Azure auto-provisioning - do we need it for the MVC? Do we know how many people are using auto-provisioning? - @amandarueda @mkarampalas - Plan is to handle the same as ACH - will allow them to add and will explore an option for a regular email notification on their usage.
-
Handle case for customers that are already over - do we just wait to get the extra users at renewal? @amandarueda @mkarampalas - we will not charge for their current overage, only any new overage and will get the full amount at their next renewal for their subscription going forward. -
Can we add to the column in the customers portal the person who "purchased"? @jameslopez -
Can we pass prorated charges for ACH customers to Salesforce and pass activities to Salesforce so Sales can see what's owned at the time of the renewal? @jameslopez -
Design for the case where a guest
member is changed to a higher role (gitlab#199893 (closed)) @esybrant @amandarueda @mkarampalas- Emily to update messaging
-
Determine if we should start charging for pending invites and the approach to handle it - @amandarueda @mkarampalas - Yes, we should also update the messaging when an invite is sent to inform the customer.
-
Coordinate with Product Marketing on announcement/blog - @amandarueda @mkarampalas -
Determine the approach for the case when there are multiple cards/contacts on the Zuora record - Use the one that has the
Order
object associated
- Use the one that has the
Edited by Donique Smit