When Should Repayment Emails Be Sent? - ProductFTW #90

I’m currently preparing for my DevCon presentation, The Hidden Cost of “Instant”: Timing Decisions in Card Payments and Rewards. As I’ve been working through the presentation, I’ve found myself revisiting a lot of the product decisions I’ve had to make over the years around repayment and rewards.

There were far more topics than I could possibly fit into a 45-minute session. One that stood out because it ended up being much more complicated than I expected was repayment emails.

At first, it sounds like a simple requirement: “Send a reminder before the payment is due.”

The deeper you get into implementation, though, the more questions you uncover. Before long, that single requirement turns into dozens of product decisions that affect engineering, customer experience, support, compliance, and operations. 

Once you start thinking about reminders, confirmations, and other transactional communications, the questions multiply quickly. Once a payment becomes delinquent, you’re entering the world of collections, which is a whole different can of worms that deserves its own article. That’s where product teams have to decide not only when to communicate, but also whether a communication should be sent at all.

The first question every product team has to answer is the same one that inspired this article.

When should a repayment email be sent?

Should it be seven days before the due date? Three days? The morning it’s due? All three?

There isn’t a universally correct answer because every product, customer base, and servicing strategy is different. What matters is that you make the decision intentionally.

Of course, deciding when to send a reminder is only the beginning. Consider just a few common scenarios:

• The customer already made a manual payment.
• The customer only paid the minimum payment.
• The customer made a partial payment.
• The customer scheduled a payment that hasn’t processed yet.
• AutoPay is enabled.
• The payment ultimately fails.

None of those scenarios showed up in the original requirement, but they all influence whether a reminder should be sent and what it should say.

As I worked through these scenarios, I realized repayment reminder emails shouldn’t be driven by dates alone. They should be driven by the customer’s current state. Before sending any communication, I’d want to know:

• Has the customer already made a payment?
• Was the payment successful?
• Is a payment already scheduled?
• Is AutoPay enabled?
• Has the payment failed?
• Is there still an action the customer needs to take?

The answers determine both whether an email should be sent and what information it should contain.

That leads to another product decision: What information should you actually include in the email?

Personally, I lean toward giving customers as much useful information as possible. If I’m opening a payment reminder, I’d rather immediately see my due date, minimum payment, statement balance, and anything else I need instead of being told to log into the application. Some issuers allow consumers to opt in or out of this information via email. Often missed is the requirement to make it clear what card is being referenced: larger issuers may frequently have users with more than one card.

The challenge is that more information also creates more opportunities for inconsistency. If the customer makes a payment after the email is generated but before it’s opened, or if the wrong balance is referenced, the email immediately becomes a source of confusion. That’s one reason many issuers intentionally keep repayment emails relatively lightweight and direct customers back to the application for the most current information.

At this point, I stopped thinking about repayment emails as individual notifications and started thinking about them as a communication strategy. The question was no longer, “When should we send a reminder?” It became, “What communications should exist, and what rules determine whether each one is sent?”

The first thing I’d do as a product manager is work with compliance to identify the communications we actually want to support. Depending on your product, that list could include something like:

• Statement available
• Payment reminders
• Payment confirmations
• Payment issues (failed, reversed, returned, etc.)
• Payment overdue notifications

Once you know which communications you want to support, each one needs a clear set of product requirements. Some of the questions I use:

• What business event triggers the communication?
• When should it be sent?
• When should it not be sent?
• Does the messaging change based on the customer’s account state?
• What information should be included?
• How do you ensure the information is accurate when the customer reads it?
• How do you prevent duplicate communications?
• Should this also be delivered through other channels like push notifications or SMS?

By the time I finished making that list, I realized the original requirement, “Send a repayment reminder email,” wasn’t really a requirement at all. It was the title of an entire feature.

That’s one of the things I enjoy most about product management. Features almost always look simple at first. The real work is uncovering all of the decisions hiding underneath them.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.