< Return to AGDATA Portal Overview
- Part One: Rebate Estimator
- Part Two: Payments & Customer Insights
Part 1: Rebate Estimator
Problem Statement:
Ag rebate programs are remarkably complex. They frequently factor in dozens of product SKUs, multiple years’ worth of sales data, hundreds of retail locations, per-acre application rates and more. As a result, estimating one’s rebate is a heavily manual process.
Problem Context:
Historically, the process of estimating rebates has been done by a (manufacturer) sales rep on a per-customer basis using an Excel spreadsheet. These spreadsheets often have multiple pages of sales data, earning rates and pricing; from there, complex formulas are built to calculate the program. Sales Reps would enter what they anticipate their account would purchase, and the formulas would yield an approximate earnings.
This process functioned well enough, but it was a very manual process with lots of copying and pasting, and was, as you might expect, very error prone. The spreadsheet’s calculation often did not match the actual program’s calculation. As a result, their customers received a smaller check than they expected – not a recipe for happy customers.
AGDATA has a the industry’s best-in-class program calculation engine, and many manufacturers use us to run these calculations and fulfill the rebate payments. By tapping into the actual program calculation, we could simplify the experience and eliminate the manual spreadsheet wrangling. All while guaranteeing that the math would line up.
The Process:
This was functionally a custom, pilot project: our product team may have had a vague vision for it, but we worked very tightly with one particular client and built it heavily to their specifications. While I worked closely with the Product Manager to execute the vision, I had very little access to users and leaned heavily on the PM’s domain expertise and client requests.
Building exactly what the client requested was predictably messy. I started with a very simple solution but was quickly overruled as the customer insisted data points be added.
Iteration:
As we progressed, our ideas started to come together: what if instead of simply providing numbers, we could visualize the program? For example, if a program required you to purchase $100,000 of product, we could show – visually – how close you were to to that threshold.
We iterated on that concept, worked hard to gain client buy-in, and were finally able to get some user input on the concepts. Ultimately, we put together an updated design:
Feedback:
The feedback we received was significant. The Manufacturer Sales Reps raved about how much time it saved – several relayed it saved upwards of 3 hours of work per account. (Some Sales Reps have dozens or even hundreds of accounts!) Their retail contacts loved about how much easier it was to understand the program. As a result, they were spending more, which benefited everyone: Retailers were able to maximize efficiency by purchasing the right products, and Sales Reps were able to sell more, easier.
Progression and Evolution:
In an attempt to bring this tool to additional users, I worked hand-in-hand with the PM & POs to evolve the tool. Countless discussions, whiteboard sessions and sketches covered more ideas than we could build.
The most obvious opportunity was to introduce multiple programs into a holistic Account Plan: manufacturers often have many programs that a customer can earn on, and some products can double-dip. By allowing users to add multiple programs to a single plan, we could reduce the work while given improved clarity on how much would be earned.
In some ways, the progression was really significant. But I think in other ways, we shifted too far away from what made the initial version a success. We had not yet “productized” the tool yet, so rather than building what the product needed through proper UX research, the company leaned heavily into customer-funded work. This allowed us to build out the product with minimal investment (good for a small company), but this led to changes based on client request rather than user need (bad for a SaaS Product).
Being able to see all of an account’s earnings in one place was a huge win. But we traded off a significant amount of visibility into the program metrics. These visuals are there, but they require extra clicks to see and ultimately have been deprioritized. AGDATA has been able to add extra clients and gain users, but it’s lacked some of the “oomph” that the original release had in spades.
Ultimately, this project was a huge learning opportunity for me. At its most basic level, I spent a ton of time balancing the ideals of simplicity – less data on the page makes the page easier to understand for all users – with the complexity necessary to allow users to complete the work. The second learning was far more significant: clients compulsively add; they always want more: more data, more complications. Learning to absorb their requests and create meaningful designs – while reining in their demands that would result in a subpar experience – is a never-ending endeavor. Being client-funded but product-minded is a very difficult line to walk.
< Return to Project Overview Continue to Part 2: Payments & Customer Insights >>