AI chatbot for e-commerce: approved product comparisons

An AI chatbot for ecommerce can help shoppers compare product attributes from approved information. Build the comparison around exact variant identifiers and cited source passages, with unanswered attributes sent to staff instead of filled by a model.

The proposed task here is a product-comparison draft in AI Flowi Workflow. It covers supplied descriptions and shopper questions; checkout, payment, live inventory and private order lookup need separate verified systems.

Create a comparison matrix before a chatbot

Write the product facts in a consistent matrix before connecting retrieval. Each variant needs a stable reference and its own approved attributes. A family-level description may cover several variants, while a size, material or accessory list applies to only one. Putting them in the same paragraph without identifiers makes a comparison difficult to check.

These are your dataset fields, not built-in store connector fields. Keep volatile stock and customer-specific order data out of the static comparison base. A source-backed material comparison is useful even when the assistant cannot answer whether a particular variant is available today.

Prepare the catalogue and provider access

Use an AI Flowi Workflow account, approved product text, synthetic shopper questions and a reviewer who can correct the catalogue. A searchable knowledge base needs an embedding model and its provider credentials where required. The answer-generation model requires your own account and API key with its provider, paid separately from the workflow plan.

Follow the knowledge-base guide for ingestion and chunk inspection. Keep variant identifiers near their attributes when preparing the source. Check that a retrieved passage preserves the identifier; finding the right product family is insufficient for a variant comparison.

Configure an evidence-first comparison

example configuration, not a recorded test

This product-comparison path is documented in the catalogue; not production-tested by Ai Flowi.

1. Chat Input: follow the chat input procedure for a question naming the variants and requested attributes.
2. Knowledge Base: use the knowledge-base procedure for approved variant descriptions.
3. Parser: follow the shared Parser configuration.
4. OpenAI: use the model connection instructions for the variant-comparison draft.
5. Structured Output: supply the reviewed product passages through input_value and the configured OpenAI LanguageModel through model. Set schema_name = approved_product_comparison. Use its table-based output_schema for variant references, comparison attributes, evidence, unresolved facts and staff question. Put the original synthetic shopper question in system_prompt alongside rules to use only supplied evidence. This first exercise sets the question manually; dynamic question composition needs its own verification.
6. Chat Output: use the JSON display setup for the variant comparison.

Define the comparison and handoff output

The draft should identify both variants, list each requested attribute and place the supporting passage beside every comparison claim. If an attribute appears for only one variant, the other cell stays explicitly unknown. Do not turn an absent statement into “does not support,” “not included” or another negative assertion.

A staff handoff here is a field for a person to review, not an automated assignment. It should say which fact needs checking and which source caused the uncertainty. A request about stock or an existing order should produce an out-of-scope note without exposing customer records or inventing availability.

Compare an attribute without borrowing a sibling’s facts

Use a synthetic shopper question about whether two variants include a carrying case. The approved source explicitly lists a case for variant A; variant B’s passage describes its material but says nothing about accessories. The comparison should state the supported inclusion for A and leave B’s case status unknown. Silence in B’s description cannot support an exclusion claim.

Before generation, preserve the variant reference, attribute wording, accessory scope, source section and content revision together through the evidence preparation step. A row saying only carrying case included is unusable if its variant identifier was lost. Reject evidence that contains the right words but refers only to the product family.

The staff question is whether the current approved description for B confirms accessory inclusion. If staff supply a corrected source, rebuild that comparison from the revised evidence. Keep the shopper’s criterion separate: wanting a carrying case explains the comparison request, but does not justify inventing an overall recommendation from unrelated attributes.

Test product-specific failures

• Compare two variants with the same family name but different specifications. Check that their attributes remain separate.
• Remove one attribute from one source. The model should preserve the gap rather than borrow a value from its sibling variant.
• Supply conflicting approved descriptions. The draft should flag the conflict and request catalogue review.
• Ask for an unsupported “which should I buy” conclusion. Check that the answer ties any comparison to stated shopper criteria and source facts.
• Ask about an order or today’s stock. Confirm that the draft identifies the missing live system instead of suggesting it performed a lookup.

When should I use a simpler option than an ecommerce chatbot?

A retrieval count does not establish coverage, and structured formatting does not establish truth. Parser’s formatting rules and the schema editor’s complete field semantics are not supplied by the export. Verify these boundaries with the actual configured nodes before presenting a continuous chat experience.

If your entire comparison fits a small public table, publish that table first. Use the assistant when varied questions justify retrieval and you can maintain approved sources. For deployment mechanics, link to website chat publishing; its separate app setup need not be repeated here.

Usage and further reading

Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.

Measure retrieval, generation and repeated attempts with your selected providers. Review the catalogue contracts and existing use cases. Compare the information boundaries in education enquiries and use conversational commerce to distinguish product discovery from transaction handling: comparing approved attributes does not authorise a checkout or confirm an order.

By Ai Flowi, operated by AI FLOWI SDN. BHD. · Published 10 October 2026 · Evidence and corrections policy · Report an error