Recommending without selling, the trust versus revenue trade-off held by design in the back office AI assistant

Trust already exists, and it is human

A merchant looking for a module does not lack options, they have too many. Merchant research is unambiguous: finding the right module is the first pain expressed. Choice overload, filters that do not speak the language of the need, module sheets that are hard to compare, and the recurring fear of breaking the store by installing the wrong module.

The decisive signal was not the pain, it was the workaround. Facing that wall, the merchant leaves the back office: Google, their community, or the few modules their agency recommends. A trusted recommendation already exists in their life. It is human, established for years, and forgiven when it is wrong. The assistant is not fighting a void: it is fighting that recommendation, with near-zero tolerance for error.

Two readings of the same subject

The PrestaShop Addons marketplace is an economic pillar of the ecosystem: every module sold sustains a publisher and the platform. The natural reading of the subject followed that slope: an assistant that recommends modules is one more promotion channel.

The research said otherwise. The external studies compiled, still to be consolidated, converge: hidden commercial promotion creates a feeling of manipulation; the same promotion, owned and labeled, strengthens trust without killing interest. The real risk was not missing sales. It was that a single suggestion perceived as sold switches off trust in the entire assistant, including everything it already does well.

Relevance caps revenue, never the reverse

Three options were on the table. Follow the commercial slope, revenue first: profitable short term, untenable from the first suggestion perceived as sold. Refuse any commercial dimension: unrealistic, the ecosystem funds the product. Or invert the hierarchy: relevance first, revenue as a side effect, transparency owned.

The third option was confirmed in a duo with product and documented in the decision log: the assistant helps the merchant find the right module for a need they express. Never a module recommended above another that is significantly better suited, and the nature of each suggestion stays visible. The guiding thread for every decision that followed fits in one sentence: behave like a trusted agency, not like a salesperson.

That decision was not made once and for all. The commercial slope came back in conversations along the way; the documented frame served as the anchor to restate it. A pivot of this kind is a frame held over time, not a done deal.

Verifiable rules rather than an intention

A principle that stays an intention gives way at the first pressure. The pivot was therefore translated into rules, each verifiable in the interface. The recommendation comes after the answer to the need, never instead of it. Two recommendations per conversation at most, three modules displayed at most. Already installed or incompatible modules do not appear. The nature of each suggestion is displayed. And when nothing reliable matches, the assistant says so: an honest empty state rather than a mediocre suggestion. The market benchmark set the bar: no product observed combines these three gestures, naming the nature of the recommendation, giving the decisive reason, knowing how to say no.

That left protecting the frame from its own erosion. A threshold metric guardrail completes the rules: if the negative feedback rate on messages with a recommendation crosses its threshold, action is triggered, even if business indicators are green. An anti-illusion measure comes with it: modules still active thirty days after installation. A module installed then uninstalled is a commercial success and a user failure; counting it as a win would mean measuring drift as progress.

A Figma page left blank

A frame of this kind cannot be proven in a mockup. A conversational product is judged in motion: the model’s thinking states, latency, a flow error mid-answer, an installation failing halfway. These are the moments that decide trust, and no still image accounts for them. The journeys were therefore designed directly in code, in a playable playground wired to the product’s real components; the project’s Figma page stayed blank.

The playground replays a dozen typed scenarios, from explicit need to business goal, with their success, error and recovery states. The recommendation card exists in three variants, from compact to expanded, and a configurator varies the content and exports the source of each variant. Every rule of the frame thus becomes verifiable state by state, by clicking, not by assuming.

This delivery mode changed the conversation with the development team. The flow review happened in the browser, hands on. In the end, the developers picked up components and an explicit data contract, not mockups to interpret, with a caveat stated as is: the components are ready, nothing is plug-and-play, the integration remains to be wired. Claude Code served as a build partner throughout; the speed of iterating in code made feasible what would have taken weeks of mockup back-and-forth.

The frame filtered every compromise

The value of a frame shows in the compromises it imposes. Four are documented.

The installation progress bar is simulated, for lack of real data. Rather than inventing a percentage, the animation shows the real steps, download then installation, without a precision we do not have.

The purchase does not happen in the assistant. For a paid module, the journey points to the marketplace product page: pricing cases are too numerous to handle cleanly in a conversation panel, and a mishandled purchase would cost more trust than an owned redirect.

The model partly chooses what it displays. The sorting and filtering rules live partly in the instructions given to the LLM, not in the code: nothing there is guaranteed by default, every guardrail has to be verified in real conditions.

Finally, the first version leverages the existing catalog search in a conversational context, without building a recommendation engine. Aligning that expectation with the stakeholders is as much design work as the screens.

Work in progress, written as such

This case is not a retrospective. At the time of writing, the work is in progress on PrestaShop’s side: no usage metric exists, and the collective end-of-discovery go is not signed.

Three critical hypotheses await their verdict, each instrumented with its measurement signals. The first: by displaying the nature of the recommendation, the decisive reason and the trust signals, the merchant installs instead of going back to their agency. The second, the riskiest: the catalog search works on keywords and the model does the filtering; if relevance falls short, a single off-topic suggestion is enough to destroy trust. The third, the bet of the pivot itself: transparency builds repeat usage without collapsing conversion.

In six months, these three lines will have an answer. The question that will matter then is not whether the journeys were good: it is whether the frame held when the numbers came in.

The mandate ended in August 2026, before the collective go. The discovery was handed over with its instruments: the replayable playground, the documented recommendation frame, the metric guardrail, the instrumented hypotheses. This is precisely the kind of handover a principle gets translated into verifiable rules for, rather than staying an oral conviction.