[Proposal] Streamline Provisioning Mailers
Background
In reviewing the current state of customer email communications owned by groupprovision, there are areas where we could improve the overall customer experience. Historically, our emails have been inconsistent, lacked context, and are also behind on branding. For example, customers receive the same "welcome to GitLab" email for a renewal, and add-on, or the second year of a multi-year subscription.
This issue will look at provisioning mailers
, specifically these include:
- Mailers including license key/activation code
- Mailers including any confirmation of purchase
This issue does not address:
- Usage data send reminders
- Ramp specific purchases (exploring this as a possibility in gitlab-org&9575)
- Other emails owned by groupprovision / sectionfulfillment
Proposal
End Goal: All provisioning mailers are context specific, with the most relevant links and information for the customer based on the details of their purchase.
What Warrants a Different Mailer?
- Type of purchase (Renewal vs. New vs. Update/Amendment): involves different actions needed from the customer, different persona context of new vs. existing customer (welcome vs. thanks again).
- Product purchased (SaaS subscription vs. SM subscription vs. add-on only): involves different actions needed from the customer, different documentation/resources
- License type - SM only (Cloud License vs. Offline License vs. Legacy License): involves different actions needed from the customer, different documentation/resources
Potential Workflow/Logic
The following diagram highlights the potential end state of customer mailers.
-
☑ indicates mailer already exists - order of logic is not necessarily accurate; workflow is to show an idea of how we arrive at each mailer
Reference: Mermaid editor text
graph TD A[Customer completes purchase] -->B{Purchase Type} B -->|New| J{Product Type} J -->|Self Managed Subscription| D{License Type} D -->|Legacy License| G[fa:fa-check-circle New Legacy License Mailer] D -->|Offline License| H[fa:fa-check-circle New Offline License Mailer] D -->|Cloud License| I[fa:fa-check-circle New Cloud License Mailer] J -->|SaaS Subscription| E[fa:fa-check-circle New SaaS Purchase Mailer] J -->|Add-on| F[Add-on Purchase Mailer] B -->|Renew| K{Product Type} K -->|Self Managed Subscription| L{License Type} L -->|Legacy License| M[Renew Legacy License Mailer] L -->|Offline License| N[Renew Offline License Mailer] L -->|Cloud License| O[fa:fa-check-circle Renew Cloud Confirmation Mailer] K -->|SaaS Subscription| P[Renew SaaS Confirmation Mailer] B -->|Update| Q{Product Type} Q -->|Self Managed Subscription| R{License Type} R -->|Legacy License| S[Update Legacy License Mailer] R -->|Offline License| T[Update Offline License Mailer] R -->|Cloud License| U[fa:fa-check-circle Update Cloud Confirmation Mailer] Q -->|SaaS Subscription| V[Update SaaS Confirmation Mailer]
The end state for these emails is being documented in this Google Sheet. All mailers can be found in this repository.
Proposal Evaluation
Looking at the workflow above, this would result in a total of 13 provisioning mailers
. This number could potentially grow if new products are added (ex. GitLab Dedicated).
Pros
- The customer is extremely clear on what their purchase was and what action needs to be taken to access this purchase.
- Individual emails can be shorter, without the need for statements like
If you purchased XYZ, then..
- The ability to tailor each mailer to the exact situation at hand allows us to:
- Include docs/handbook links, videos or other specific documentation for the scenario and actions needed from the customer
- [Idea] Include a specific
Contact Support
link that opens the correct form based on product type
Cons
- This will increase our overall count of mailers to maintain, leading to potentially more work when there is a brand update or other need to update all mailers.
- This will increase the current mailer send logic, which will increase the risk of the wrong email being sent or a bug occurring
- We will likely need to have voucher copies of all of these mailers, which doubles the total amount
Summary of Work
The following mailers would need to be created to meet the base proposal outlined in the workflow diagram above:
Other Considerations
- Should we create Ramp specific mailers for initial purchase and/or successive ramp intervals? Epic created to track this work separately: gitlab-org&9575
- Where are there opportunities for consolidation by using within-email dynamic text?