Connected product knowledge with OrelFlow

Explore WhatsApp product catalog AI consistency with OrelFlow: customer journeys, connected records, team handoffs and practical launch steps.

By OrelFlow Editorial

A woman checking her smartphone in an office

A practical guide to keeping WhatsApp product answers aligned with prices, stock, variants and approved product knowledge, with architecture, failure handling. With OrelFlow, product questions, verified order states and customer access can guide a useful commerce conversation. This guide explains how to connect that design to your OrelFlow solution and the work your customers need to complete.

Why catalog consistency is a sales control

A customer may ask, “Is the blue medium available, and can it arrive this week?” That sounds like one question, but the answer depends on several records: the exact variant, its current stock status, a location or fulfillment rule, a delivery estimate and the price applicable to that customer. A product brochure can explain the fabric; it cannot reliably establish today’s inventory.

Inconsistency appears when teams update a storefront but not a PDF, change a variant name without updating the chatbot’s lookup, or let an assistant reuse a price from an earlier conversation. An apparently helpful answer can then send the buyer to an unavailable item or create an expectation the checkout cannot honor.

Treat accuracy as a workflow requirement. The catalog owns sellable identity and approved commercial facts; product knowledge explains what the item is and how to choose it. Neither should silently substitute for the other. This distinction matters most when the buyer moves from exploration to a transaction, where a wrong variant or price becomes an operational problem rather than merely an awkward reply.

Assign an owner to each kind of product fact

Before connecting an AI assistant to product information, document which system can approve each answer. The source of truth might differ by merchant; the decision should be explicit rather than inferred from whichever document the assistant retrieves first.

Buyer-facing fact	Proposed authority	Required identifier or context	Rule before answering
Product and variant identity	Approved product catalog	Product ID, variant or SKU ID	Resolve the exact sellable variant; ask if ambiguous.
Current price and currency	Commerce pricing source	Variant ID, market, customer context	Check the applicable price; do not reuse a document price.
Stock or availability	Inventory or availability service	Variant ID, location or channel	Request a current status; distinguish unknown from unavailable.
Materials, dimensions and care	Approved product content	Product ID, content version	Answer only within the approved scope.
Delivery estimate	Fulfillment rules or human team	Destination, item and service	Qualify an estimate; do not promise an unverified date.
Order or payment status	Order or payment authority	Verified order reference and permitted access	Never infer status from chat text alone.

The table is a design example, not a description of OrelFlow’s existing connectors. An owner should also decide whether prices include tax, how promotions expire and whether inventory is shared across channels. Those choices change the correct response even when the product name stays the same.

Design the answer path around identifiers and freshness

A workable architecture has five parts: an inbound WhatsApp conversation, an identity resolver, catalog and knowledge lookups, an answer policy, and a response log with a route to a person. The resolver maps phrases such as “the blue one” to a product and, when possible, a specific sellable variant. It should retain the customer’s stated size and market without treating them as permanently valid preferences.

For descriptive questions, retrieval can find approved product content tagged with product ID, version, approval status and effective date. For commercial questions, the workflow should query the applicable pricing or availability authority using the variant ID. A retrieved paragraph that says “in stock” is not a substitute for that check. The answer policy then determines whether the evidence is fresh enough to reply, whether it needs clarification, or whether it must escalate.

Define freshness by fact type. A materials description might remain usable until its approved version changes; stock could require a check at answer time. Record when each value was fetched and how long the business permits it to be treated as current. If a conversation continues after a pause, recheck transaction-sensitive facts before repeating them.

Meta describes its WhatsApp Cloud API as a developer interface for business messaging. That supports planning a messaging interface, not assuming a live OrelFlow deployment. Account, messaging, consent and billing requirements should be confirmed against current Meta documentation during implementation.

Specify inputs and retain an evidence-backed output record

A useful input contract separates what the customer said from what the business verified. Consider this illustrative request: “Do you have the blue travel jacket in medium? What does it cost?” A structured interpretation might contain the conversation ID, message timestamp, product phrase, requested color and size, market, language, and any verified customer context. None of those fields proves that a matching variant exists.

The lookup should return candidate product and variant IDs, match confidence for review, authoritative price and stock responses, timestamps, and approved descriptive content IDs. Confidence is a routing aid, not permission to invent a missing fact. If two variants remain plausible, ask the customer which they mean.

An illustrative output record could read:

conversation_id: example-1042
resolved_variant_id: JACKET-BLUE-M
resolution: confirmed
price_evidence: pricing-source / USD 85 / checked 14:02
availability_evidence: inventory-source / available / checked 14:02
knowledge_version: product-copy-v7
response_decision: answer-with-checkout-qualification
customer_message: "The blue travel jacket in medium is listed at USD 85 and shows as available as of 14:02. Please confirm the final total and availability at checkout."

These IDs, values and timestamps are fictional. In production, the record also needs access controls and retention rules. Its purpose is to make an answer traceable: a reviewer can identify which variant was discussed, which sources supplied the claim and whether the information had expired.

Construct answers without blending incompatible evidence

The assistant should build its reply in a deliberate order: identify the item, state verified facts with appropriate qualifications, answer descriptive questions from approved content, and offer the next action. If it has a verified price but no stock result, it can give the price while explicitly withholding an availability claim. If it has a product description but cannot resolve the size, it should ask a narrow clarification question.

Use links as navigation, not as proof. A team could evaluate whether its shop has an appropriate product or checkout destination, but should verify the live customer path before placing it in an answer. The checkout remains the authority for the final payable total when taxes, shipping, discounts or customer-specific terms can change it.

Keep promotional copy outside the evidence layer. An assistant can say a product has a specified material if approved content supports it; it should not turn that fact into an unsupported guarantee about durability. For cross-sells, define which recommendations are approved and when missing inventory or compatibility data should suppress them. These limits prevent conversational fluency from becoming a source of misleading sales claims.

Illustrative scenario: a variant changes mid-conversation

Illustrative scenario—not a customer case study: A buyer asks about a medium blue jacket. The resolver identifies a candidate variant, and the catalog reports a price and available stock. The assistant explains the material from approved content and gives a qualified availability answer. Ten minutes later, the buyer asks to buy two. In the meantime, the stock source has changed.

The assistant should not rely on its earlier answer. It requests availability for quantity two, checks whether the prior price is still applicable, and either directs the buyer to a verified purchase step or explains that it cannot confirm the requested quantity. If the inventory service is unreachable, “I can’t confirm two are available right now” is more useful than restating the old status.

The transition from product advice to purchase also changes the workflow. The cart and eventual order need their own authoritative states; a chat message saying “I’ve paid” cannot establish payment. The related guide to WhatsApp commerce orders and payment states covers that boundary. For teams implementing payment notifications, payment webhooks and idempotent delivery addresses why duplicate or delayed events must not trigger duplicate fulfillment.

Plan failure paths before inviting customers to rely on answers

A dependable design specifies what happens when evidence is absent, conflicting or late:

No exact variant match: Ask about size, color or model; do not pick the closest item without telling the customer.
Stale product document: Withhold unsupported descriptive claims and send the content to its owner for review. A current stock check does not make an old specification correct.
Price conflict: Suppress the quote, retain both source references for investigation and direct the buyer to a verified purchase path or agent.
Inventory timeout: Mark availability unknown, not out of stock. Offer a retry or human check without promising either will resolve immediately.
Unavailable item: State the confirmed status and offer an approved alternative only if its identity and availability can also be checked.
Changed context: Recalculate for a different market, quantity or variant instead of carrying an earlier answer forward.

Give the handoff a compact evidence packet: question, resolved or candidate IDs, checks attempted, timestamps, uncertainty and the message already sent. That prevents an agent from repeating a failed lookup or accidentally treating the assistant’s tentative interpretation as fact. Set an owner for unresolved conversations and a process for correcting any customer-facing error discovered after an answer.

Put versioning and operations controls around the catalog

Assign business owners for product identity, pricing, inventory and approved copy. Record a stable product ID and variant ID even if display names change. When an item is retired or merged, maintain an explicit mapping or stop answering from its old identifier; otherwise older documents and conversation history can keep reviving it.

Version content when specifications change, and define who approves publication. Monitor failed lookups, conflicting facts and the age of evidence used in replies. A daily review of exceptions can reveal whether a feed is late, a promotion lacks market rules or a newly added variant has no approved description. The review should lead to a corrected source, not just a prompt adjustment.

Protect operational data as carefully as answer quality. Limit access to price rules and customer context, define retention for conversation and evidence logs, and test what the assistant reveals when a buyer asks about another person’s order. Access to order details should require an appropriate verification process. These are implementation controls to design and validate, not assertions about currently available OrelFlow features.

Implementation checklist and acceptance criteria

Start with a narrow product set and a documented set of questions. Agree on the relevant markets, languages and permitted claims before expanding coverage. The following checklist is suitable for a pilot review:

[ ] Name an owner and authoritative system for each fact in the mapping table; document tax, currency, promotions and stock-location rules.
[ ] Map every pilot product and sellable variant to stable identifiers; reject unmapped or duplicate IDs before answering.
[ ] Tag approved product documents by identifier, version, approver and effective date; remove or quarantine superseded content.
[ ] Define refresh and expiry rules by fact type, including when a paused conversation must trigger another check.
[ ] Test exact matches, ambiguous names, missing variants, conflicting prices, stale content and inventory timeouts.
[ ] Verify that the assistant never states an unconfirmed price, stock position, delivery date or payment state as fact in those tests.
[ ] Confirm that human escalation includes the evidence packet and has a named receiving team and review process.
[ ] Test the actual destination for any product or checkout link and confirm how final totals are presented.
[ ] Review access, consent, messaging requirements, log retention and error correction with the appropriate business owners.
[ ] Have product, sales and operations reviewers approve sample answers before broader use.

Acceptance should be based on observable behavior, not whether replies sound polished. For a pilot, specify a review set with correct answers and known failure cases. A passing result means each tested answer identifies the right variant, uses permitted evidence and either qualifies or withholds uncertain claims. Record any exception, fix its source or policy, and rerun the affected test before widening the catalog.

Measure correctness, coverage and handoff quality

Define metrics before launch so a higher reply rate does not conceal worse advice. Variant resolution accuracy is correctly identified sellable variants divided by reviewed conversations where a variant could be identified. Evidence compliance is reviewed commercial claims backed by a permitted source and valid check divided by all reviewed commercial claims. Unsafe-answer rate is replies that assert an unverified or contradicted commercial fact divided by reviewed replies; track it separately, not as the inverse of customer satisfaction.

Measure clarification rate as requests for more item detail divided by product inquiries, and handoff completeness as escalations containing all required context divided by escalations reviewed. Pair these with source failure rate—required lookups that time out or return unusable data divided by attempted required lookups. Segment findings by product family, variant, language and market to locate specific data problems.

Review a sample of both answered and escalated conversations. An increased handoff rate can be appropriate if it replaces unsupported promises; falling handoffs are not automatically an improvement. Set acceptable thresholds with the business team and report the observation window and sample size. No conversion or revenue outcome should be assumed from these quality measures.

Evaluate OrelFlow against the workflow you actually need

Use OrelFlow’s commerce solution and broader business-messaging focus as a basis for a requirements conversation, not as evidence that every catalog, inventory, pricing or checkout connection is already supported. Bring the field mapping, proposed authorities, sample failure cases and acceptance checklist to a demo discussion. Ask the team to confirm available integrations, onboarding work, pricing, messaging constraints, escalation options and which parts require custom implementation.

Request a demonstration using your own approved test data, including an ambiguous variant, a price change and an unavailable inventory source. Ask to see what the customer receives, what an agent receives and what evidence is retained for review. This is a stronger evaluation than judging a single successful product answer: it tests the boundaries that determine whether the workflow can be trusted in daily operations.

FAQ

Can an AI assistant answer from a PDF product catalog alone?

It can use an approved, current document for stable descriptive details if the content is tied to the right product and version. A PDF should not be assumed authoritative for changing prices, inventory, promotions or delivery commitments. If those facts are not available from an approved current source, the assistant should qualify what it knows and offer another way to confirm. A useful people-first resource should make such limits clear rather than hide them; see Google’s helpful content guidance for the editorial principle, not as evidence of product functionality.

What if a customer uses a nickname rather than a product name?

Map the phrase to candidate products, then use the available context—such as a previously discussed color or an explicitly shared product link—to narrow the set. Do not treat an old conversation preference as confirmation of a new purchase choice. If candidates remain, ask a specific question or show clearly identified options. Only quote variant-level facts after the sellable variant is resolved and the relevant commercial checks succeed.

How often should catalog knowledge and stock be updated?

Set separate rules for each fact rather than one universal refresh schedule. Approved specifications can be revised when product content changes; price and stock may need a check when the customer asks and another before a transaction step. The right frequency depends on the merchant’s update process and the consequence of an outdated answer. Document the rule, log the age of each source response, and test what happens when a feed is delayed. If freshness cannot be established, say so and escalate or offer a verified alternative.

Continue your implementation journey

Continue with WhatsApp and ERP Integration: A Blueprint for Operational Workflows. A practical blueprint for connecting WhatsApp conversations to ERP workflows, with identity checks, permission-scoped reads, invoice states, reconciliation, a Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.

Continue with Logistics WhatsApp Notifications: Events, Exceptions and Delivery Evidence. A practical guide to designing logistics WhatsApp tracking notifications around carrier events, consent, duplicate updates, delivery disputes and human hand‑( Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.

Continue with Travel Booking Workflows: Agentic Briefs and Consultant-Led Availability. Design a travel WhatsApp booking workflow that captures a useful brief, verifies supplier availability and quote terms, and keeps a consultant accountable for Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.

Build this journey around your business

Start your OrelFlow setup with one specific customer request. Bring the current conversation, the records the team checks and the action that should follow. Define what the assistant can answer, what a connected workflow can change and which decisions stay with your people. Product questions, verified order states and customer access can guide a useful commerce conversation.

Use the steps in this guide as acceptance criteria for your own configuration. Walk through a successful request, missing information, an unavailable connected system and a request that needs a person. Agree how your team will measure completion and review exceptions before expanding to another customer journey.

Explore the relevant OrelFlow workflow, browse ready-to-customize templates, or plan the setup with our team. Template purchases and any separately scoped setup work should match the actual requirements of your business.

Sources and further reading

More insights