The User on the Invoice

The platform had spent years perfecting the chicken and priced the egg as an optional extra.

The chicken was the order; the egg was knowing who might place one and what they’d buy. On the B2B wholesale platform I worked on, the people doing that work were reps, and their experience came as an add-on to their agency’s account.

I’d spent months on a dashboard the agency managers loved, then started over for reps and worked through eight versions. Some agencies couldn’t see the need. The information was already in the platform; surely a capable rep could find it.

Finding it meant filtering tables, opening records, copying addresses, planning a route somewhere else, and writing things down before each visit. The rep did all that work, but the agency’s name was on the invoice. You can guess whose request was easier to fund.

I could stop, listen, and empathize all day and still end up designing a better dashboard for someone else’s job. We’d named the agency the expert, so its view set the limits of what a rep should need. Research that challenged those limits was now up against the way the company made its money. Try fixing that with a clearer table.

The sales that made those licenses affordable came from the reps. Helping them prepare for a visit still looked like improving an optional feature, while a manager’s reporting request arrived as something a paying customer needed to run the business.

I find it useful to ask three separate questions: who buys access, who does the work, and whose work creates the value that keeps it all going? The product followed the first answer and made the other answers argue for a budget.

In companies where design sits one or two levels below engineering, you may be allowed to improve a requirement without being allowed to change what gets built. A prototype doesn’t get you into the meeting where someone decides to fund it.

A senior design leader has to get the rep’s day into that room, show how the work leads to the next order, and make the business face what its priorities are costing the person in the parking lot. The business still makes the pricing decision.

The new name we chose for the merged company avoided choosing one customer. The product had already chosen, years earlier, and the invoice made it look like nobody had chosen at all.

That’s the short version.

The remaining 3 minutes put dollar amounts to the arrangement and follow what happens when a rep’s needs have to compete for funding.

Keep readingOr skip to the end of the series

---

The business model licensed the platform to agencies and manufacturers. Retailers and reps were add-ons. An agency paying around $10K for five manager seats could pay a couple thousand more for its retailers to get their own experience, and a couple thousand more for up to ten reps to get the iPad app and a restricted version of the platform, scoped to whatever data the agency thought its reps needed. It’s subtle, but the revenue design was driven entirely by the user furthest from the order.

Agencies manage teams, buy software, and need control over their business information. The trouble starts when their place in the commercial relationship becomes a substitute for understanding everyone else’s work.

A manager’s reporting request fit the product’s existing story: a paying customer needed something to run the business. A rep’s need looked like an enhancement to an optional add-on, even when it concerned the activity that made the agency’s business possible. Reps generated the sales that paid for the agency’s licenses, and a request to support them still had to justify itself from inside the category the product had put them in.

Every design decision about reps had to be legitimized with funding, and funding followed the persona on the invoice.

Once I noticed that, it became harder to describe the issue as a dashboard problem. The dashboard was one place a much older decision had become visible. The agency bought the product, so the agency became the authoritative voice on it; the rep used a restricted version, so the rep’s needs were considered within the boundaries of that version. Research that suggested a different boundary had to compete with the business model that had helped make the problem difficult to see.

This is how a product ends up with an answer to “Who matters?” without anyone remembering the meeting where it was chosen.

Someone has to buy the software, and an agency can value and fund an excellent experience for its reps. The question is whether the business has a way to recognize that value when the person describing the problem isn’t the person signing the agreement.

I find it useful to separate three questions. Who buys access? Who does the work? Whose work creates the value that keeps the arrangement viable? Sometimes one person answers all three. On this platform, the answers were spread across several groups, and the product had been built around the answer to the first.

Take preparing for a retailer visit. Treat it as a convenience for an optional user and it’s easy to defer. Treat it as support for the person trying to create the next order and the questions change: how much effort does preparation take, what gets missed, and would the agency see the difference in orders? The existing commercial structure was helping keep those questions off the table.

If orders are the chicken, knowing who will order and what they’ll order is the egg. The platform had spent years perfecting the chicken and priced the egg as an add-on, and the person sitting in the parking lot outside Dallas with a spiral notepad was the one paying for it.

This is where the fix stops being a UX fix. Stop, listen, empathize: obvious stuff, and pointed at the wrong person, it can get you as far as a better dashboard for somebody else’s job. Answering the expertise question early gets you further. Reps knew the work of taking and managing orders, but their expertise hadn’t set the direction of an experience built around orders.

How does that happen? In a lot of companies, product design sits one or two levels below engineering. The person whose job is the user can discover something big enough to change what the business should build and still be sitting at a level of the organization only authorized to change how an existing requirement works.

You can conduct the research, design for reps, build a persuasive prototype, and then go looking for a budget line that doesn’t exist. A better prototype won’t put you in the meeting where that budget is decided.

A senior design leader needs to get the rep’s working day into that room: show what the platform makes them do, explain how that work connects to the next order, and make it hard to dismiss the whole thing as someone struggling with a table. The pricing decision belongs to the business; the design leader brings the evidence and makes its consequences hard to miss.

That can lead to a better product inside the existing commercial arrangement, a different priority for investment, or a conversation about packaging. What matters is that the finding survives the trip from the parking lot to that decision.

The name we chose for the merged company refused to pick a customer. The product had picked one a long time ago, and nobody noticed, because the one it picked was the one paying.