Question First, Design Second
The brief said design incentives. The data said fix the product. AI helped me find that out in two weeks instead of six.
the setup
The brief was specific: design AI-targeted incentives to lift auto pay adoption from 34% to 37%. It was a reasonable ask on the surface - more customers on auto pay means more predictable revenue and fewer collections issues. But it arrived as a solution before anyone had validated whether incentives were actually the right lever.
Before designing anything, I wanted to understand why customers weren't on auto pay in the first place - and why the ones who were kept turning it off.
what i found
I started by mapping every auto pay touchpoint across the entire customer journey in FigJam - from the moment a customer first enrolls in service and sees the auto pay option, through every subsequent interaction where they might enable, disable, or encounter messaging about it. That mapping exercise surfaced issues that no data source would have caught on its own.
The bill tile was showing red - signalling urgency and potential alarm - when customers still had plenty of time before their due date. It should only turn red after a payment is overdue. Further along the journey, the auto pay enrollment messaging told customers they would be charged within 24 hours of enabling it, regardless of when their bill was due. That logic was incorrect - the 24-hour charge only applies if a payment is already due within that window. I discovered this one as a customer of my own product. I had avoided enabling auto pay on my own account because that message made it sound like I'd be charged immediately. If it stopped me, it was stopping others.
Beyond the journey mapping, I pulled every data source available across the organization. Churn propensity models from data science, demographic and geographic segmentation, payment standing data from claims and collections, and results from a past auto pay incentives contest. That last dataset was the most clarifying - the contest had produced only marginal lift, which was direct evidence that financial incentives alone weren't moving the needle. I brought a junior designer in to help tag-team the cross-functional data gathering across five teams, correlating datasets that had never been connected before.
The data told us what customers were doing. It didn't tell us why. UX interviews were scheduled with another designer to go deeper on the behavioural side, but those take time to set up and the project needed to keep moving in parallel.
what i did about it
The quick wins went to our site PO immediately - the bill tile state fix and the auto pay messaging correction were straightforward enough to prioritize without a full sprint. Getting those in front of the right person with clear context was enough to get them moving.
The bigger reframe was shifting the project from "design incentives" to "understand why customers leave auto pay." To bridge the gap between the quantitative picture we had and the qualitative insight the interviews would eventually provide, I built a real-time exit survey that triggered whenever a customer hit the disable auto pay button anywhere across the online account management system.
There was no dev resource available - it wasn't their priority, and pulling a sprint slot would have meant a 4 to 6 week wait. Instead I used AI-generated JavaScript to build the survey modal and a separate script to pipe responses directly into a Google Sheet in real time, then implemented both through Optimizely's custom code injection. The whole build took one day.
what it took
None of this was in my job description. Mapping datasets across five teams, correlating data that had never been connected before, and shipping production code without dev support were all self-initiated calls made because the project needed them, not because anyone asked.
The Optimizely implementation required understanding how the disable button was being triggered across different payment journeys, ensuring the modal fired correctly without disrupting the existing flow, and validating that the Google Sheets pipeline was capturing responses accurately in real time. Once the survey was live, I processed the incoming data using AI to generate visualizations and surface key findings as responses came in.
what it became
The survey ran for two weeks across an audience of 2,200 users and returned 130 responses, and the data pointed clearly to two design directions.
46% of respondents had disabled auto pay because they changed their payment method - not because they wanted to leave, but because the product wasn't making the update path visible. The disable button was functioning as a de facto payment method swap. That finding is now directly shaping a product priority to surface the payment method update flow more clearly, addressing nearly half of all auto pay exits without a single incentive being offered.
The next 42% - customers who preferred manual payment, wanted more control over timing, or worried about incorrect charges - shared the same underlying barrier. Cross-referencing with earlier segmentation research confirmed these are the bill-reviewers: customers who want to understand every charge before handing over payment control. That informed a second design direction currently in progress - surfacing bill due dates, upcoming charge dates, and last payment amounts clearly through UI. If the transparency earns their confidence, auto pay becomes a genuine option for a segment that was never going to respond to a discount.
Between them, those two directions addressed 88% of the exit reasons the survey surfaced - and neither required a single incentive. The evidence let us avoid a planned $20,000 incentive campaign.
The approach travelled further than the project itself. Using AI to ship research infrastructure without dev support was broadcast across all NRG regions, opening cross-regional conversations that hadn't existed before. What started as a knowledge share became a two-way exchange with design teams across Texas and East regions.
What started as an execution brief ended up redirecting product priorities, shipping research infrastructure faster than the dev queue would have allowed, and opening cross-portfolio conversations that hadn't existed before.
