It offers help with fit, unavailable products, relevant offers, and return policies. The customer chooses what to do next; the merchant sets the limits.
Four ways to remove friction, protect trust, and create value on both sides of a purchase. Designed around four platforms: Shopify, Bloomreach, Databricks, and Google Cloud with Gemini.
Concept + local prototype · 28 September 2026. All scenarios use synthetic data. Gemini has run live on Vertex AI inside the loop; Shopify, Bloomreach and Databricks use mock adapters with their contracts ready. Benefits below are hypotheses to evaluate, not measured business results. Merchant agendas, scheduled reports, and advocacy journeys are roadmap ideas.
Watch the concept film
A six-minute walkthrough of how Clercom decides what to do, and when to do nothing.
Concept film. The scenario images are illustrative, and the connectors to Shopify, Bloomreach and Databricks are simulated; only one Gemini call on Vertex AI has run live. No business result is claimed.
Observed outcomes inform the next decision → return to Understand
Serving the customerFind a suitable product, understand the facts, receive proportionate help, and retain the freedom to decline.
Serving the merchantEarn qualified demand, respect contribution limits, reduce avoidable friction, and learn which assistance is useful.
The agent analyzes catalog facts, stock, consent, interaction history, merchant policies, and later outcomes. A page view is a signal to investigate—not proof of a shopper’s thoughts. Choosing no action can be the best result.
Four customer and merchant situations
Each situation starts with its original storyboard, then what the customer sees and can do next. Open the technical section under each one to see how the agent handles it.
These images describe a proposed experience. Retailer names, policies, product details, order confirmations, and result figures in them are illustrative—not verified partnerships or outcomes.
1. Marco compares bikes and needs help with fit
Marco compares gravel bikes, then opens the geometry and size guide. He needs a way to check fit before choosing.
Original concept storyboard · Bike fit and compatibility need verified evidence. Browsing alone does not establish why Marco hesitates.
What the customer seesA small offer to open the sizing guide, compare published measurements, or ask a specialist.
What the customer can do nextMarco supplies the missing measurements, compares the guidance, and decides whether to buy, book help, or keep looking.
How the agent handles it
Signal
Size-guide views or a direct fit question.
Understand
Published dimensions, compatibility information, and the requirements Marco chooses to provide.
Decide
Offer grounded guidance. Ask for missing information. Refer unresolved fit questions to a person.
Act
Present the permitted assistance, record whether it was delivered, and leave the choice with the customer.
Learn
Help accepted, question resolved, purchase, and later fit-related returns. Record these as separate events; sending help is not a purchase.
Customer value to testA clearer way to judge whether the bike suits him.
Merchant value to testA chance to earn an appropriate purchase and reduce avoidable fit questions or returns.
Prototype connection: Scenario 1 maps to the fit fixture. The local demo uses synthetic bags and deterministic rules; the pictured storefront experience is proposed.
Laura finds a helmet she likes and selects size M. It is out of stock. Without help, she must restart her search or contact support.
Original concept storyboard · The image’s fit, shipping, and exchange claims are illustrative. They require verified merchant and manufacturer information before use.
What the customer seesAn explanation of what is unavailable, followed by available candidates with their verified differences and a route to fit advice.
What the customer can do nextLaura compares the candidates, asks about fit, checks another location where supported, or declines the alternatives.
How the agent handles it
Signal
The selected variant is unavailable.
Understand
Variant stock, manufacturer sizing information, product features, and the customer’s stated requirements.
Decide
Filter out unavailable or unsuitable candidates. Explain differences; do not assume that “M” means equivalent fit across models.
Act
Present the permitted assistance, record whether it was delivered, and leave the choice with the customer.
Learn
Alternative viewed, help requested, accepted candidate, paid order, and later returns. Record these as separate events; sending help is not a purchase.
Customer value to testA next step that preserves the work she already put into choosing.
Merchant value to testA chance to retain suitable demand without recommending the wrong product.
Prototype connection: Scenario 2 maps to the substitution fixture. The local demo uses synthetic bags and deterministic rules; the pictured storefront experience is proposed.
The merchant sees products sitting in inventory. A broad discount could move units but reduce the money left after costs.
Original concept storyboard · The original image’s customer counts and percentage improvements are concept placeholders, not measured results. Campaign orchestration is a future capability.
What the customer seesAn eligible customer sees a product relevant to their stated need, with a small benefit only if the merchant has allowed it. Other customers receive no offer.
What the customer can do nextThe customer can inspect the product, use the offer, ask a question, or decline. The merchant reviews whether the intervention was worthwhile.
How the agent handles it
Signal
Stock age and sell-through trigger a merchant-side review.
Understand
Stock, price, cost, shipping, product relevance, consent, and previous contacts or offers.
Decide
Choose an eligible audience and a permitted response. Reject offers that fail relevance, contact limits, or contribution requirements.
Act
Present the permitted assistance, record whether it was delivered, and leave the choice with the customer.
Learn
Eligible customers, accepted offers, stock sold, contribution after costs, opt-outs, and a comparison group where feasible. Record these as separate events; sending help is not a purchase.
Customer value to testA relevant option with clear terms, without a blanket promotional push.
Merchant value to testA way to test stock movement while limiting benefit costs and protecting contribution.
Prototype connection: Scenario 3 maps to the inventory fixture. The local demo uses synthetic bags and deterministic rules; the pictured storefront experience is proposed.
4. Giulia wants to understand returns before paying
Giulia builds a high-value cart and opens returns and support information. A discount may leave her actual question unanswered.
Original concept storyboard · The storyboard’s 60-day extension is not an implemented or approved policy. Policy-page visits do not prove that price is irrelevant.
What the customer seesA concise explanation of the verified return terms, with a link to the full policy and an option to ask support about exceptions.
What the customer can do nextGiulia checks the terms, asks for clarification, proceeds to checkout, or decides the purchase is not right for her.
How the agent handles it
Signal
A policy question or interaction with returns information.
Understand
The merchant’s current return, exchange, shipping, and warranty terms, including exclusions.
Decide
Answer from the policy. Escalate exceptions. Do not extend return terms or introduce a discount without authorization.
Act
Present the permitted assistance, record whether it was delivered, and leave the choice with the customer.
Learn
Question resolved, escalation, purchase, and later policy-related complaints or returns. Record these as separate events; sending help is not a purchase.
Customer value to testClear expectations before committing to the purchase.
Merchant value to testA chance to resolve questions while preserving price and avoiding unsupported promises.
Prototype connection: Scenario 4 maps to the reassurance fixture. The local demo uses synthetic bags and deterministic rules; the pictured storefront experience is proposed.
The central question is simple: when Laura’s selected size is unavailable, can Clercom help her take a useful next step?
Laura selects a variant.The storefront reports that it is unavailable. This is an observed event, not a guess about her feelings.
Clercom checks the evidence.It retrieves stock and product facts, identifies what is missing, and checks whether assistance is allowed.
Laura sees an offer of help.For example: “This size is unavailable. Would you like to compare available options?” The exact message is proposed UX copy.
Laura chooses a next step.She can compare, ask a fit question, or dismiss the suggestion. The agent must not treat silence as acceptance.
The system records what actually happened.An offer delivered, an option selected, an order paid, and a later return are separate events. A purchase is possible, not guaranteed.
The local demo tests this pattern with bags. It does not currently deliver the helmet storefront experience shown in the image.
Design the agent from the experience
Each design step produces something that can be inspected or tested.
Step
Question it answers
What gets built
1 · Need
What is the customer trying to do?
A scenario with a clear choice and an acceptable outcome, including deciding not to buy.
2 · Signal
What can the system observe?
An event such as variant unavailable or a direct policy question.
3 · Evidence
Which facts are needed, and are they current?
A small evidence record: product, stock, policy, consent, and relevant history. A later step selects only the evidence each decision needs.
4 · Decision
Which response could help?
A structured proposal: explain, compare, offer a permitted benefit, ask a person, or take no action.
5 · Permission
Is that response allowed?
Code that checks product facts, stock reserve, contact limits, and money left after costs. A model cannot override it. Customer-facing text is rendered from approved templates, never from the model’s free text.
6 · Interaction
What will the customer see and control?
A clear offer of assistance with a way to decline; a separate record of execution success or failure.
7 · Feedback
Did it help, and what should change?
Outcome events, scenario evaluations, and a merchant report. Learning initially means using recorded history; it does not mean automatic model retraining.
Signal → Understand → Decide → Act → Learn remains the runtime loop. These seven steps explain how that loop is designed and verified.
Test the decision and the outcome separately
Before a real customer sees itReplay the four scenarios. Check missing facts, stale evidence, unavailable stock, incorrect sizes, excessive benefits, contact limits, and invented policies. Verify that the agent declines or escalates when it should.
After a permitted interactionMeasure help accepted, questions resolved, orders, returns, contribution, and complaints. Compare with a suitable baseline or holdout before claiming the agent caused improvement.
The last recorded local run passed 21 tests and 20 evaluation cases, including invented products, fabricated policies and invented marketing claims that code must stop. Those results cover synthetic behavior, not live integration or business impact.
The merchant sets the agenda. The agent reports against it.
Roadmap idea: make the agent accountable to a business request, not just a stream of actions.
Example merchant brief
“Help customers find suitable weekend bags and improve aged-stock sell-through, while protecting contribution and keeping outreach useful.”
Before activation: agree the audience, product set, baseline, target, time window, attribution window, allowed actions, benefit budget, minimum contribution, consent rules, contact limits, and escalation owner.
Cadence: weekly for active experiments; every two weeks for slower journeys. Merchant approval is required before expanding the agreed scope.
Set agenda
Approve scope
Run & observe
Review report
Adjust agenda
Performance report · proposed template
No results populated: this is a report design, not evidence of live performance.
Goal and scope
The exact request, agreed target, eligible audience, and reporting dates.
Customer assistance
Eligible sessions → help offered → help accepted → question resolved; breakdown by all four scenarios.
Commerce outcomes
Product selection → cart → paid order → cancellations/returns. Show counts, denominators, and observation windows.
Merchant economics
Net contribution, benefit cost, stock movement, and support workload where these data are available.
Quality and restraint
Unsupported claims, policy violations, failed actions, escalations, dismissals, and reasons for no action.
Evidence of impact
Observed assisted conversions are descriptive. Estimate incremental impact only with an appropriate holdout or experiment; disclose sample size and uncertainty.
Next decision
Continue, narrow, pause, or revise—plus a short explanation and merchant approval for changes.
How a merchant review would work
Each review starts from the agreed agenda. It walks through one customer interaction and the evidence behind it, shows the customer’s next observed step, the merchant outcome and any unknowns, covers all four scenario groups, exceptions and guardrails, and ends with one explicit decision for the next reporting period.
Earn trust beyond checkout
After the order, the customer still needs delivery, a product that meets expectations, and help if something goes wrong. Reviews and advocacy are optional later steps.
Discover a suitable productUnderstand the need, compare facts, and remove a real obstacle. A helpful “not suitable” answer can also build trust.
Buy with confidenceSupport an informed purchase within policy. Record the order separately from a successfully delivered recommendation.
Experience the productCheck delivery, product experience, and unresolved issues through consented channels. Support continues after conversion.
Offer honest feedbackInvite an honest review where appropriate, including a Google review when the merchant has an eligible presence. Keep invitations neutral: no reward for positive sentiment, no filtering out unhappy customers.
Reward regulars, within limitsAn established customer (repeat orders, items kept, opted in) can receive a generous personal offer within a cap the merchant sets. Code checks eligibility and margin; the decision uses observed purchases, never inferred feelings. Built in the prototype as the fifth scenario. Whether rewarded customers go on to recommend the store is a hypothesis to measure, not assume.
Choose to advocateOffer a separate, opt-in referral or ambassador journey with clear terms and disclosures. Never infer advocacy from a purchase or tie rewards to a positive review.
Future measures: resolved post-purchase issues, repeat purchase, voluntary reviews, referral participation, referred orders, and opt-outs. Customer experience and business value must both remain visible.
Build evidence before expanding autonomy
1 · Local baseline
Exists in prototype. Five synthetic scenarios (including the earned personal offer), mock adapters, a rules baseline and a live Gemini path, policy checks, templated messages, and outcome history.
Next proof: retain scenario-specific traces and distinguish proposed assistance from implemented actions.
2 · Real platform loop
Next. Verify scoped reads, connect real data, and test bounded sandbox actions. Gemini 2.5 Flash on Vertex AI has completed a live call inside the loop; Shopify, Bloomreach and Databricks runtime connections come next.
Exit: observable evidence of each required platform’s runtime contribution, with no silent mock fallback.
3 · Merchant agenda
Proposed. Store an approved objective, policy version, audience, budget, and reporting cadence.
Exit: the agenda constrains decisions; the merchant can pause it and review changes.
4 · Reporting & growth
Proposed. Produce weekly or biweekly reports, run controlled experiments, then add consented post-purchase journeys.
Catalog, variants, inventory, orders, and permitted commerce actions.
Bloomreach
Consented engagement context, event signals, and bounded customer interactions.
Google / Gemini
Reason over selected evidence and propose structured assistance; deterministic policy remains authoritative.
Databricks
Analytical evidence, outcome aggregation, cohort comparisons, and merchant reporting.
These are intended adapter responsibilities. Current local runtime uses mocks; account or console access alone does not prove integration.
What works today
Local prototype: five synthetic scenarios, policy checks, templated customer messages, recorded outcomes and suppression after a dismissal. Live: one Gemini 2.5 Flash call on Vertex AI ran inside the loop. Shopify, Bloomreach and Databricks use mock adapters.
Access: sandbox accounts for Bloomreach, Shopify, Databricks and Google Cloud were set up during the Composable AI Hackathon. Connecting their runtime data and actions is the next step.
To build: the pictured customer interface, Gemini in the web app, the platform connections, merchant agendas, scheduled reports, and post-purchase journeys.
In short
“Clercom helps customers make a good choice while respecting the merchant’s economics and policies. It can clarify fit, find a relevant alternative, match suitable demand to inventory, or explain a return policy. The merchant sets the agenda; the agent shows what it did, what customers experienced, and what outcomes followed. Over time, useful assistance can earn repeat business and voluntary advocacy.”
