> [!caution] Status: 🚧 In Progress > > [Iteration 1](https://gitlab.com/groups/gitlab-org/-/epics/13445) out of 3 has been completed. See [iteration plan](https://gitlab.com/groups/gitlab-org/-/epics/9303#iteration-plan). ## Table of contents [[_TOC_]] ## Problem The current implementation of Zuora's "upcoming renewal" email notifications presents significant limitations. We cannot tailor these communications to address specific customer situations, as all emails follow the same template regardless of subscription type (one-time charge Compute Minutes, multi-year ramp, or subscriptions purchased through a reseller). This lack of flexibility creates two key problems: 1. We cannot customize messaging for different subscription scenarios where more precise wording would be beneficial. 2. We cannot suppress notifications entirely for situations where emails are inappropriate or unnecessary. Zuora's platform does not provide the level of customization required to effectively manage these varied communication needs, resulting in a suboptimal customer experience. ### Additional problems 1. **Emails are logged in Zuora only**, which makes it challenging for any Sales rep to know what was sent to their customers. Reps end up sending their own Renewal emails, so the customer ends up with many more of them. 2. **Emails are only sent to SoldTo Contact in Zuora**, but there might be multiple billing managers. 3. **We send emails for non-renewable subscriptions:** TBD 1. `Subscriptions with one-time charges only` (CI Minutes, Professional Services, etc) will never renew, yet we send them a renewal email. * subscriptions with one-time charges only expiring by month: *  2. `Customers with multi-year subscriptions` (with separate subscriptions per term) should not be receiving renewal emails if they already have a future-dated subscription. ([issue](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/914 "Cancellation Notification Email for MY Ramp Orders")) 4. **Emails have generic text.** The same email copy is sent to every subscription, without accounting for nuances of those subscriptions: 1. `Community Programs subscriptions` are receiving confusing renewal emails, and don't know what to do to process their renewal. Community Programs have a specific application/verification process that must be followed. ([example issue](https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/gitlab-for-open-source/-/issues/46), [customer ticket](https://gitlab.zendesk.com/agent/tickets/345691), [issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/181)) 2. Customers with `subscriptions that are on auto-renew` are getting a generic email that lacks clarity on what will happen. This makes it hard for our Finance team to handle disputes, and for customers to know that their subscription will renew automatically. ([related issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/766)) 3. As we iterate on https://gitlab.com/groups/gitlab-org/-/epics/5619+, we are sending more specific "upcoming auto-renewal" emails. However, the customer is now getting two "15 day" renewal emails - one that is correct, and one that is ambiguous. Approximate number of [subscriptions](https://docs.google.com/spreadsheets/d/1wmmc35TqZvkqyr4UgCQDMOu7DBDk3wb4_KZKjUscxbE/edit#gid=0) that will receive auto-renewal emails: - August 2022: 517 - September 2022: 794 - October 2022: 870 4. Combining the use cases from above for some rough math, **we can expect this many opportunities for confusion**: - **August 2022: 1,009** - **September 2022: 1,483** - **October 2022: 1,417** 5. **We are not aware of which emails users receive** We currently have a way to BCC the emails we send from CDot to SFDC - they show up under the Contact’s activity history, and the reps can easily see them there. We do this already for “upcoming auto-renewal” emails and QSR emails. ### Inventory of Renewal Emails https://gitlab.com/gitlab-org/fulfillment/meta/-/issues/1019+ ## Proposal Move all "Upcoming Renewal" emails out of Zuora and into CustomersDot, so that we can send the right emails on the right cadence. ### Iteration plan <table> <tr> <th> :hash: </th> <th>Epic</th> <th>Scope of work</th> <th>Status</th> </tr> <tr> <td> :one: </td> <td> [Iteration 1: Set up integration and logging in CustomersDot to track all upcoming renewal events from Zuora](https://gitlab.com/groups/gitlab-org/-/epics/13445) </td> <td> **Goal: Set up integration and collect data.** Integrate Zuora with CDot for upcoming renewal events: 1. Set up callouts to send upcoming renewal event details to CDot alongside the renewal email from Zuora. 2. Log these event details with additional subscription data. 3. Enable data export for analysis to better understand the types of renewal emails being sent. </td> <td> :white_check_mark: Completed on 2025-04-16 </td> </tr> <tr> <td> :two: </td> <td> [Iteration 2: Send Upcoming Renewal emails from CustomersDot](https://gitlab.com/groups/gitlab-org/-/epics/13446) </td> <td> **Goal: Stop sending irrelevant emails, send emails from CDot, and log emails in SFDC.** All renewal emails will go through CDot and we will: 1. Stop sending emails for subscriptions with only One Time Charges (Compute, Professional Services, etc). 2. Stop sending emails for subscriptions that are "old ramps" 3. Only send 1 relevant 15-day email for subscriptions on auto-renew (we currently send it twice - once from Zuora). 4. Send a default email for all other subscriptions (same content as we send from Zuora today), keeping the 90/60/45/30/1 day cadence. 5. Log email in SFDC. </td> <td> :construction: In progress. Scheduled for FY26-Q2. </td> </tr> <tr> <td> :three: </td> <td> [Iteration 3: Customize Upcoming Renewal email templates](https://gitlab.com/groups/gitlab-org/-/epics/13447) </td> <td> **Goal: Send more relevant emails.** Set up specific emails for: 1. Subscriptions purchased through a Reseller 2. Community Programs subscriptions. 3. Subscriptions that are not on auto-renew. 4. Subscriptions that are on auto-renew. </td> <td>Not started.</td> </tr> </table> ### Follow-up opportunities 1. Work with the Billing team on email copy edits, get approval from them before we go live. 2. https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/11164+s --- **Support Priority Score:** 2 <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> > [!important] > This page may contain information related to upcoming products, features and functionality. > It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. > Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->