Messaging: New Billing Emails in Customer.io

[joethreepwood]

Messaging

Context

RFC: https://github.com/PostHog/product-internal/pull/636 Art: https://github.com/PostHog/posthog.com/issues/9198

Starting to get ahead of this by building it all into Customer.io to discover where we need work. For now, I'll just build it into one campaign that splits by properties -- but in the future we'll likely want to set up multiple campaigns.

[joethreepwood]

Quick look at how some of these are shaping up in first draft.

[zlwaterfield]

These looks awesome - thank you for putting these together so quickly :)

Few notes:

• The startup one should never trigger. I think we've moved everyone off that, but it's good to have it just in case.
• I need to review all these triggers and ensure we align on the event parameters so they are all triggered correctly. I will work on that later this week.
• Let's make sure the invoice totals are formatted nicely. We've had some issues with that in the past.
• For the allowance reset email - I think there's room to improve and add clarification why now. It's based on their subscription billing dates and the email doesn't explain that well, it can come off as a bit random. I realize this could be said for all emails but it popped out at me for this one.
• Thought: we don't have emails for removing addons, we should probably add them.

[raquelmsmith]

These are great!

• 80% limit one - sentence "Which know we'd prefer you to do" reads weird. Maybe "Which we would obviously prefer you to do ;)"
• 100% free allowance one - "you can set billing limits" (not bill limits) (I realize now this is grammatically incorrect I think but it's what we say everywhere?)
• Updated limits one - should we list what the limits are?
• Startup plan ending one - we should add what their forecasted bill is and don't so strongly suggest billing limits. Limits aren't great for customers in a lot of situations - they lose data. It's better for them to tune their usage so they get everything they need but don't collect the things they don't.
• You've sub'd to posthog - the vast majority of people who sub don't ever pay us money. I'd focus this on having unlimited usage (that you pay for) and better features. And maybe promote the Teams plan 👀
• First bill - link to controlling usage first, then billing limits

[joethreepwood]

Will roll with those amendments and add more polish shortly, thanks both!

For now, two new previews.

[joethreepwood]

I've made all the suggested amends, with a couple of further discussions below...

• The startup one should never trigger. I think we've moved everyone off that, but it's good to have it just in case.

• Startup plan ending one - we should add what their forecasted bill is and don't so strongly suggest billing limits. Limits aren't great for customers in a lot of situations - they lose data. It's better for them to tune their usage so they get everything they need but don't collect the things they don't.

I've replicated the new art and message into the dedicated startups flow, but keeping this just in case as you say and have made the other changes.

• Let's make sure the invoice totals are formatted nicely. We've had some issues with that in the past.

Yep, I can't mock these up just yet because I need to have that data sent on the event so I can grab it - which I can't do until we start getting the integration moved across. What sort of issues have you had in the past?

• For the allowance reset email - I think there's room to improve and add clarification why now. It's based on their subscription billing dates and the email doesn't explain that well, it can come off as a bit random. I realize this could be said for all emails but it popped out at me for this one.

How's this? Little confused if this is for free users, paid users, or both. Free users don't have a billing subscription date, do they?

We've reset your free allowance, giving you more free usage for every tool. We do this every 30 days from your subscription date.

Last month we began dropping data because you hit 100% of your free allowance. Now, we've resumed ingestion as normal for you.

In the future you can that by [upgrading your plan](https://us.posthog.com/organization/billing), which also lets you add custom billing limits to help you control your costs too.

• Thought: we don't have emails for removing addons, we should probably add them.

I need to know an event for these, but we could easily do something like this and adapt it for each one (or include the add-on name if it's set as an event property).

• 80% limit one - sentence "Which know we'd prefer you to do" reads weird. Maybe "Which we would obviously prefer you to do ;)"

Changed to: Your limit resets each month, but you can increase the limit to give yourself more breathing room (and maybe give us more money).

• Updated limits one - should we list what the limits are?

I can do this, I just need the limits to be set on the event as a property so I can read it in Customer.io - then it's an easy add.

[zlwaterfield]

@joethreepwood how do you handle links to EU and US. Are they dynamic based on a property on the customer?

Few other points

• for the failed payments, we send it for every failed payment, so maybe we can update the copy to say the attempt number? Or how many attempts are left? I can make these properties in the event.
• for the billing limit email, can we display the product and total like we do in the current emails?

[joethreepwood]

@joethreepwood how do you handle links to EU and US. Are they dynamic based on a property on the customer?

From what I know, we route people to the correct domain, yes. I'm actually not sure how it works though. Usual pattern in all our emails is to send people to either us.posthog.com or app.posthog.com and they'll be switched to EU if needed.

• for the failed payments, we send it for every failed payment, so maybe we can update the copy to say the attempt number? Or how many attempts are left? I can make these properties in the event.

• for the billing limit email, can we display the product and total like we do in the current emails?

For these I think we can do this as long as we're updating the property on the event. It's not something we've done before for repeated emails, but we should be able to use a bit of Liquid to pull in the variable off the event property.