- An online store with a huge range can make it harder for customers to decide, because nobody helps them narrow it down to a few items.
- A good sales assistant asks about budget, intended use and constraints, then offers two or three products with the reasons, instead of piling the whole range in front of the customer.
- It only works with accurate, complete product data. If prices or stock in the system are wrong, the recommendations will be wrong too.
Where old websites and apps stop
When a customer walks into a real store, a good salesperson asks a few questions and brings out two or three items to choose from. Online, we throw a hundred products at the customer along with a search box. The more there is to choose from, the less able customers are to decide, and they close the page.
A bigger catalog does not make the decision any easier. Traditional filters force people to know the product jargon and do the comparing themselves, while price, stock, reviews and terms are scattered across different places.
Traditional search and filters work well when buyers know the product name and understand the specifications. Many customers, though, start from the outcome they want: they want to open a small shop, the product has to work with their existing system, or they have limited space. So they pick the wrong filters, compare on the wrong points, and may buy something that looks good but doesn't fit their real conditions.
A new-generation AI commerce app should turn the customer's own words into requirements and constraints before it searches for products. Its job is to rule out options that won't work, explain the trade-offs, and carry the context of the decision across pages and devices or hand it on to a salesperson, rather than simply pushing the highest-margin product.
| The old way | The new AI product approach |
|---|---|
| Recommendations based on click history, a display of popular products, and a chat that answers FAQs | A personal shopper that takes a brief in plain language, builds a shortlist, explains the trade-offs, checks stock and delivery area, and prepares a basket for the customer to confirm |
A responsible recommendation system combines AI with catalog rules and live data. AI helps the system understand how people talk, a constraint engine removes options that won't work, and APIs confirm price, stock and terms once more before anything goes into the basket.
New capabilities a business can put to work
So a good shopping assistant behaves more like a person than a smarter search box. It asks what the product is for, what the budget is and what constraints apply, then narrows the field to a few items and explains why each one was picked.
What the project looks like
A personal shopper is a buying experience that starts from the customer's problem instead of an SKU. The user might chat, upload a photo of the space, pick a budget, and then see a shortlist on a comparison screen. The system should let customers change their constraints and see straight away why the options changed, instead of hiding the logic behind the recommendation.
Key features
Features might include guided questions, a compatibility check, a bundle builder, an alternative finder, comparison and explanation, along with stock, price, promotions, delivery and return policy drawn from current data. If a product is out of stock, the system should offer a substitute and say which specifications are equivalent and what the customer has to give up.
Technology and data
The foundation that matters more than the model is Product Information Management, with product codes, attributes, units of measure and relationships kept consistent. On top of that, hybrid search, a constraint engine and a ranking model work together, connected to inventory, pricing, promotions and the cart through APIs, with consent for any preferences the system needs to remember.
Business benefits
Customers spend less time searching and feel more confident because they can see the reasoning. The business gets fewer orders for the wrong type of product and fewer repeat questions, and the know-how of its best salespeople becomes available around the clock. The constraints customers state also reveal product gaps and demand that traditional search keywords never show.
- Compare from structured data and never invent specifications
- Remember preferences only with consent, and let customers edit them
- Build bundles around budget and use, instead of just pushing the expensive items
- Look after customers after the sale: manuals, claims and reorders of the correct model
Hypothetical case
What it looks like in practice
An office supplies store lets customers enter their headcount, space, budget and purchasing policy. The agent proposes three packages with the reasoning, checks stock and creates a list for approval, but it does not pay until someone with authority confirms.
In another hypothetical case, a coffee shop needs to choose an espresso machine within limits on electrical power, cups per hour, counter space and budget. The system asks only for information that changes the result, rules out models the power supply can't support, and puts together a bundle with a grinder, filters and a maintenance schedule.
When the best-fit model is out of stock, the system doesn't jump to a pricier model for no reason. It compares the new options, states which specifications are lower, and lets the customer choose whether to wait, take a substitute or talk to a member of staff. All the decision data travels with the customer.
Explainable Shortlist
Every recommended product has to answer three questions: why it fits, when it doesn't, and where the data came from.
If the system can't explain a pick, it should ask another question instead of guessing.
Scope, risks and how to measure results
Metrics should include recommendation acceptance, returns caused by incompatibility, staff corrections to recommendations, and complaints, alongside conversion. A system that speeds up sales but drives up returns and destroys trust has failed. Recommendations influenced by sponsorship or margin must be disclosed and must never override the compatibility rules.
Ranking can be skewed by incomplete data or sales targets. Keep genuinely helpful recommendations separate from promotions, and let customers edit their preferences.
For the development team · Technical metrics
Metrics to track: Shortlist-to-Cart, Return Rate, Assisted Conversion, Margin Guardrail and Recommendation Override
- Discover: follow the real work and collect examples of normal cases and exceptions
- Assist: let AI draft or recommend while people stay in control
- Act: switch on tools one at a time after the test set passes
- Scale: expand once monitoring, fallback, cost and an owner are in place
Slow the rollout if recommendations bring more clicks while returns, overrides or complaints rise, or if the team still can't explain which rule removed a particular model. Those are signs that ranking is running ahead of the accuracy of the product data.
BUSINESS & PRODUCT READINESS
How ready does product data need to be before AI recommends in place of a salesperson?
For the development team · Technical detail
A personal shopper becomes trustworthy only when all product data follows one structure. Names, models, prices, units, stock, compatibility and constraints each need an ID and an owner. If the website says one thing, the marketplace says another and a PDF still carries an old price, the agent will be choosing from contradictory data. That is why a business should start with product data readiness before tuning the model.
For the development team · Technical detail
The other issue is the system's incentives. If the only target is conversion, it may push expensive items or hide drawbacks. Add return rate, complaints and recommendation override as guardrails, keep normal recommendations separate from promotions, and let customers see the reasoning, compare options and change their preferences.
Start by building an attribute dictionary for a single product category, defining units, meanings, allowed values and owners. A phrase such as “handles heavy use” has to become a condition that can be checked. Products with incomplete data should be flagged, instead of letting AI fill in specifications by guessing.
Split the logic clearly into hard constraints and preferences. Compatibility, safety and regulations are rules the AI must never break, while color, style and order of preference can use a model to help with ranking. Separating these two layers is what lets the team explain recommendations and actually test them.
Which SKUs have complete enough data to start a pilot?
Who owns the compatibility rules?
How do promotions affect ranking?
What does a wrong recommendation cost?
Turning your salespeople's know-how into a product-selection experience that scales
DNA Maker helps product, merchandising, sales and service teams capture how their best people choose products and turn it into a Product Decision Map. We ask which specifications matter to whom, which options can't be used together, and which cases call for a warning to the customer, so the AI works from real product logic instead of copying sales language.
The product design team then builds the experience of asking about needs, the shortlist, comparison, bundles and explain-why, and puts it in front of customers to try. We measure whether the questions are short enough, whether customers can change their constraints, and whether the explanations really help them decide or simply add more text.
DNA Maker helps design screens that make the reasoning behind a recommendation visible, from the requirement summary, shortlist, side-by-side comparison and bundle through to the cart and handoff. We set up the architecture so that product data, rules and content stay separate from the prompt, which lets the client's team change attributes or conditions without tearing down the conversation system.
A trial can start in shadow mode, with the system building shortlists to compare against staff without showing them to customers, and then go live in one small product category. We help build evaluation cases from real questions and measure compatibility, reasoning, returns and decision time before anyone decides to expand into more complex categories.
On the engineering side, we can build the commerce website or app, a product information layer, the AI personal shopper, inventory and pricing APIs, cart and approval, and a post-purchase assistant, with logs of the data each recommendation used. Admins can change rules and review risky recommendations.
If your products come in many options and staff have to ask customers several questions before suggesting a model, try starting with one category. We help assess the data, build a shortlist prototype and test it on real conversations before connecting it to checkout.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
These terms run from product data and ranking through to approvals. Use them to ask where the system learns the constraints, how it explains its recommendations, and who is responsible when catalog data is incomplete.
| Term | What it is | A simple example | What to ask the development team |
|---|---|---|---|
| Product Feed | The product data supplied for a system to use. A good feed has codes, attributes, units, prices, stock and regular update times, so every channel refers to the same data. | Price, stock, specifications and product codes | Who keeps the data up to date? |
| Recommendation | Ranking options to suit the context. Recommendations need rules that remove options that won't work and reasons for the order, and should not rely on language similarity alone. | Choosing a machine by number of users and budget | Does this criterion serve the customer or the sales figures? |
| Preference | A user's likes or limits. Preferences change with the situation and should not be treated as hard rules, so the system has to let users review, edit and clear what it remembers. | No products that need permanent installation | Can customers see and delete their preferences? |
| Structured Output | AI output in a fixed data format. A fixed format lets software check for missing fields and pass the data on, which reduces the risk of pulling facts out of unstructured prose. | Returning a list of SKUs with the reasons as separate fields | What does the system do when data is incomplete? |
| Approval Flow | The route for getting approval before a transaction. The flow has to name approvers by value, risk or exception, and record the reasons and time of each decision for later review. | A manager confirms the company's basket | Which amounts need whose approval? |
Further reading from the original documents: https://ai.google.dev/gemini-api/docs/function-calling