New York, NY
Suggested date
A quick test to predict payment dates and encourage AutoPay setup can significantly benefit fintechs. By anticipating payment schedules, fintechs can prompt users to automate payments, reducing late fees and improving on-time rates. This fosters trust, boosts retention, and enhances cash flow predictability, strengthening user engagement and overall financial health.
Scroll ↓
Problem statement
WE ARE GETTING FAILED NSF RETRIES FOR 24.7% OF THE TOTAL POPULATION EVEN THOUGH THEY HAVE AUTOPAY SET UP.
Data shows that most payment returns stem from incorrect AutoPay setups, where members schedule payments on dates with insufficient funds. While we aim to reduce payment returns for existing members, this test will also help us understand its impact on new member behavior and delinquency rates.
Hypothesis
WE WILL REDUCE DELINQUENCY RATES THROUGH AN EXPERIMENT FOCUSED ON AUTOPAY ENROLLMENT USING PLAID PAYCHECK DATA.
We aim to create a targeted UX experiment for 10k users, encouraging 50% with existing AutoPay and 50% without it to schedule payments on the suggested date.
How: In collaboration with the Product, Engineering, Credit and Legal team, we'll use Plaid data to predict paycheck dates and tailor AutoPay suggestions. This approach enhances the current UI, guiding users to adjust or set up payment dates, boosting engagement while minimizing development complexity for rapid iteration and data-driven insights.
Use research
BEFORE STARTING ON DESIGN I DECIDED TO SEND A SURVEY TO 500 USERS AND ASKED THEM HOW DID THEY CHOOSE THEIR AUTOPAY DATE
These were some of the TOP, most popular responses.
“I just clicked through and set it up on the date that I clicked set up”
“Hmm not sure what day I have it setup for. I though it was automatic”
“I chose a random day that I though would make sense to pay bills”
“I put my autopay date near the date my bill is due”
“A couple days after my pay day but I have inconsistent paychecks”
“I set it up for the due date on the 26th of every month, duh!”
Wireframe +
usability testing
A MID FIDELITY WIREFRAME WAS NECESSARY SINCE WE NEEDED TO USE PRE EXISTING COMPONENTS FOR EFFICIENCY + WE WANTED TO USE IT FOR USABILITY TESTING
This was the wireframe using common payment patterns and components in our app. This is the feedback we got from 100 users.
Final design
WITH ALL THE FEEDBACK I WAS ABLE TO INCORPORATE A DESIGN THAT REQUIRED A LOW LEVEL OF EFFORT BY REUSING LIBRARY COMPONENTS AND USING INTUITIVE COMMON PAYMENT PATHS ON THE APP
Launch
TO IMPLEMENT THIS CAMPAIGN WITH MINIMAL DISRUPTION TO OUR ENTIRE MEMBER BASE, WE OPTED TO LAUNCH IT THROUGH LIFECYCLE MARKETING, A MORE TARGETED AND DIRECT ENTRY POINT FOR ENGAGEMENT.
This approach leverages our past successes, as we typically see strong results with approximately 40% open rates when introducing new in-app features, allowing us to reach users effectively while maintaining a seamless experience.
Results
AutoPay adoption:
We noted that the population that had AutoPay setup was more apprehensive to change their selected date than new users that hadn’t.
Approximately 30% of users adopted the suggested AutoPay date, leading to a notable improvement in payment processing accuracy for users that had previously set up AutoPay. While 70% was the adoption rate for users who hadn't previously set it up.
This also proves that a suggestion upon onboarding might be the best way moving forward since adoption rate is higher. By creating a customized setup upon account creation we expect better account health longterm.
Returned payment fee:
Although this might not be your typical revenue stream result, Petal is a mission driven company and the results provided on this test perfectly align with the goal to ‘improve peoples financial well being’. Petal finds returned payment fees not to be at par with industry standard and at times it proves to be predatory. Petal will be getting rid of this fee altogether after this test was held since this mistake might be a lack of financial literacy (to no ones fault).