When users are instructed to access customers.gitlab.com to renew their subscription via the renewal email, they are required to log in and are taken to the plans page. This is a confusing experience because they then need to navigate to "Manage Purchases" and find the "renew" button for the corresponding subscription.
We want to simplify that flow for users by enabling deep linking to the renewal flow for the corresponding plan.
Acceptance Criteria:
We can take a user directly to the renewal flow for their plan that requires renewal
If we cannot go directly to the renewal flow for the subscription, we should at least take the user to the manage purchases page
Renewal emails are updated to leverage the new mechanism
Banner links to renew are updated
G/W/T
PERSONA: Gitlab .com group owner
GIVEN: My subscription is coming close to renewal
AND: I am logged in and see the renewal banner
WHEN: I click the renewal banner link
THEN: I am logged into the customer portal and taken to the /subscriptions page automatically
WHEN: I click on a link in the renewal email
THEN: I am brought to the Customer Portal signin page and log in
THEN: I am taken to the /subscription page automatically
PERSONA: Gitlab billing admin (self-managed)
GIVEN: My subscription is coming close to renewal
AND: I am logged in and see the renewal banner
WHEN: I click the renewal banner link
THEN: I am logged into the customer portal and taken to the renew page for the corresponding subscription automatically
WHEN: I click on a link in the renewal email
THEN: I am brought to the Customer Portal signin page and log in
THEN: I am logged into the customer portal and taken to the /subscription page automatically
@mkarampalas - we could link users to the /subscriptions page, but AFAIK theres no "Detailed" view for subscriptions, they all just live on one page.
Is the desired behavior just taking them to /subscriptions, or is the desired behavior building out a separate view where only 1 subscription is shown?
@jayswain I was thinking we'd link to the URL that clicking Renew goes to. It's structured like this: customers.gitlab.com/subscriptions/[subscription ID]/renew
@jayswain Since there isn't an option for a .com account to manually renew, the /subscriptions page makes sense. We'll need to include some language specific to them, like "to enable auto-renew, click here". I'll update the issue so it's clear.
@mkarampalas some thoughts as I dig into this more:
Magic Link:
The magic link is great, but given it's a security concern, we'd have to propose it and debate about it, we couldn't just implement it immediately. There's a growing favor for passwordless logins, but by using both methods (passwords and magic links) we broaden the area for attack.
Emails:
Do you have an example of the "renewal email" that either a self-hosted or .com customer receives? I've never seen it before. I believe this email is coming from Zuora, which would make this more difficult to implement. It's possible we'd have to move away from Zuora sending this email, and do it from the customer app, which I'm a fan of. For .com I know we have the billing_rate_increased mailer, but outside of that one, I think we lean on Zuora for sending emails around renewal time. If you have an example I'd love to see it.
Complete Solution:
Magic Link, as well as moving zuora mailers to the customer app and linking customers directly to the renewal.
MVC:
I'm still thinking about what would be the "cheapest and best" solution.
What does work currently, is if you're logged out, and click a link that takes you to a specific renew page, you have to login, and then you get redirected to the original link.
I'm thinking of possibly a path like /my_renewal which would make its best guess at which subscription you probably want to renew, and would redirect you there. For self-hosted customers with 1 subscription, that'd be pretty easy. For self-hosted customers with 19 subscriptions where they renewed half-way through they year and did a true-up and bought extra minutes, I imagine it'd be a little more difficult, and maybe we'd just take them to/subscriptions And of course for .com customers, they'd just get /subscriptions
We'd be able to update the Zuora email message to use the /my_renewal url.
I like and fully support your recommendation for MVC. Lining up this change and the email updates may not be possible at this time - I had hoped we'd be done with that project but it is still in progress.
If we get the /my_renewal link working as part of this effort then we can update the other issues that are for updating the emails to leverage that link as well.
My 2c on the MVC... this looks like two new issues - one for Engineering, one for Zuora (not sure who handles that change?)
Create deep linking path in the customers portal to the Renewal Flow for self-managed subscriptions
TBD: the parameters required to link to the renewal flow for this customer and plan - these need to be available in Zuora (as the link will be included in a Zuora generated email)
e.g.
/my_renewal - redirects to 'best guess' subscription for the logged in customer
/my_renewal/:subscription_id/ - redirects to specific subscription for customer (assuming this is valid)
If if user is not logged in they need to then are redirected to this page (existing functionality).
Update renewal email in Zuora to use /my_renewal path
Uses /my_renewal, or /my_renewal/:subscription_id/ if known
Out of scope for %12.8, potentially 2 new issues for the %Backlog
Good point, it's highly likely Zuora has the subscription_id, or an identifier we can use.
The unfortunate part of this is theres no templates, and no "workflow" that I'm aware of for updating the zuora mailers. I'm assuming someone with access can just go in and change at any time.
The other disjointed thing there is, The mailers and app code change at different times. They aren't one system.
The other disjointed thing there is, The mailers and app code change at different times. They aren't one system.
Yes but with this approach, you can deploy the new path to customers, we can manually test/verify, and then we ask to get the Zuora mailer updated. Should be fine as long as it's done in that order.
Given the code I've seen in the callbacks section of our app, its possible that sometimes theres no subscription_id, so we find by subscription_name as a backup. I find everything weird about that. but moving on ;)
We should be able to leverage those params. I still think some sort of redirect url makes sense, given that we're not certain if we'll always have the correct attributes. Nor do we know if an ID has changed, or whatever disconnect may exist from the 2 systems.
Agree. The new url should handle the params given to it and make a decision as to where to redirect the user, even if that is to the default '/subscriptions' or '/renew' path.
Thank you @csotomango ! Are we able to include hyperlinks on text or do we have to list out the full URL? If we have to list out the full URL, can we update it to this? If not, I'll want to take a cleaner pass.
Dear <BillToContact.FirstName>,This is a friendly reminder that your GitLab subscription (<Subscription.SubscriptionName>) will expire on <Subscription.TermEndDate>.Start your renewal here: http://customers.gitlab.com/subscriptions/my_renewal Need help? See our Licensing FAQ here: https://about.gitlab.com/pricing/licensing-faq or just reply to this email. Thank you again for partnering with GitLab to deliver better software, faster. We look forward to working with you again!Warm regards,The GitLab Teamwww.gitlab.comLeaving us? We’re sad to see you go! To cancel your subscription, simply email renewals@gitlab.com and we’ll be happy to assist you.