AI suggests.The seller decides.

AI in the Back Office was a strategic question nobody had evidence for. The company wanted to move fast, and the real risk was building the wrong AI: over-automating in ways sellers would not trust, or under-building and missing the moment. There was no data on what sellers actually wanted AI to do, or how much autonomy they would accept.

I took the ambiguity on directly, as a product designer rather than a researcher by title. That is the point of this story: a contested, politically loaded question turned into an evidence question, and the answer turned into the company’s adopted AI posture.

A designer’s survey alone would not carry a decision this contested, however clean the data. So the validation was two-phase by design: sellers first, then the people who hear them complain. The survey closed at 118 responses, and the findings held across both phases.

Sellers were not afraid of AI. They were unwilling to be automated over. Two in three keep the final say for themselves, and the smallest group of all is the one that wants no AI at all. The posture almost named itself.

The cross-validation round said the same thing in its own words.

The report recommended suggest and confirm: AI proposes, the seller approves. Not a limitation to outgrow but the product itself, which sets the real design bar: an accept step fast enough that autonomy stops being the thing sellers ask for. With the posture came a recommended roadmap, and two lines of it got struck out.

The no-go list is the part I’d defend hardest: a designer saying no, with evidence, while the roadmap pressure ran the other way.

In practice the report broke a stalled prioritisation, moved three features to the front of the queue, and wrote the prototype’s scenarios into the chatbot’s plan. That is decision-impact, and I claim it as exactly that — whether the posture drives adoption as the features ship is the test still ahead.

The posture then had to become product, and the design side of that is mine. The working artefact is a coded prototype — code over Figma for speed: scenarios could be reworked directly, and a working link lands harder than a clickthrough. Concept one is where we are: a reactive Q&A assistant. Concept two is where we want to be: proactive, grounded in the seller’s actual data.

Six proactive scenarios make up the concept set. The consistency is the argument: suggest and confirm as a system, not case by case.

A pilot that proved demand and was not built to last: a hackathon build I worked on, taken live with about 200 UK sellers in January — answers pulled from support articles, not filtered by country, and no way to know whether a seller got what they needed. I co-wrote the spec that makes it a real product, owning the seller-facing layer: answer feedback, three-rule escalation to a human, and answers filtered to the seller’s country.

The industrialized chatbot ships under a new name, the Seller Assistant, as a hard commitment on the current roadmap, and discovery for the proactive iteration is already open. The proof so far lives in decisions and citations rather than usage numbers, which is the right kind of impact for research-to-strategy work, and the honest version of this case study says so: the posture is adopted, the prototype exists, and the adoption test is ahead.

Each step up that path is gated. The evaluation framework fixes the numbers the assistant must hit before it advises on live seller data, and raises them again before it may act on a seller’s behalf.