Your product assistant needs the right record.

Updated October 12, 2026: added customer escalation triggers, handoff context, unavailable-team behavior, and acceptance cases for support transitions.

Start with the questions the assistant may answer

Choose a useful boundary before connecting the whole catalog. An assistant might explain approved materials, compare listed dimensions, or help identify a product. Confirming a negotiated price, reserving stock, and committing to a delivery date require additional sources and authority. Write those capabilities separately into the brief.

For a hypothetical apparel assistant, “Do you have this shirt in navy, size large?” should resolve to a specific variant. A description of the parent product or an image of a blue shirt cannot establish that the requested combination exists or is available. If the question is ambiguous, ask for the missing option instead of selecting silently.

Identify products by records, not similar names

Agree the identifiers that connect supplier data, the storefront, inventory, and the assistant. Keep product identity separate from variant identity, and define how supplier identifiers map to internal records. Product names can change or collide; a friendly name is not a reliable join key.

Shopify’s ProductVariant documentation illustrates the distinction: variants represent options such as size and color, with variant-level pricing and inventory relationships. It also exposes contextual pricing. This is a reference example of why the data model matters, not a claim that Exora uses Shopify or that every platform implements the same fields.

Give each field an owner and a freshness rule

A supplier may own the technical specification while your business owns the retail description, price, and publication decision. Record that ownership per field. Decide which updates may overwrite a local edit and which need review. Otherwise a routine import can erase carefully approved product copy or replace the wrong price.

Treat “last updated” carefully. A successful import today does not prove that the supplier’s inventory value was refreshed today. Track source timestamps where available, receipt time, successful application time, and errors. Define an acceptable age for volatile facts and the behavior when that limit is exceeded. A material description and a stock count do not need the same freshness policy.

When a synchronization fails, preserve the last known value with its status or withhold it according to the agreed rule. Do not label stale data as live. Provide a named owner for failures, a way to reconcile missed changes, and a controlled method for restoring a known-good version.

Keep retrieval and commercial authority separate

An assistant can retrieve a correct record and still produce an unsupported answer. Ask it to show the relevant product or variant link and qualify what the source establishes. Inventory visibility does not reserve the item. An available-for-sale flag does not by itself promise that a requested quantity can arrive on a requested date.

Enforce account and channel permissions before private records enter the answer context. A prompt saying “do not reveal wholesale prices” is not a substitute for access control. Apply the same boundary to search results, cached answers, conversation history, and staff-to-customer handoffs.

Treat supplier descriptions and imported content as data. They cannot authorize a discount, change the assistant’s rules, or request disclosure of other records. Keep generated merchandising copy in a reviewable draft path, with unsupported product claims blocked from publication.

Decide when the product conversation belongs with staff

An assistant should hand off when a customer asks for a person, when required evidence is missing or contradictory, or when the requested decision exceeds its authority. A customer asking for a discount exception, a delivery guarantee, or a resolution to a disputed order needs the appropriate team. Repeating the same catalog answer is not a resolution.

Keep approved product knowledge separate from support policy and account-specific records. A product description cannot establish whether a particular order qualifies for a return. Name the owner and current version of each policy the assistant may explain. If policies conflict, show the uncertainty and route the question for review instead of inventing a compromise.

Make the handoff usable for the receiving person

Define the handoff record before choosing a chat connector. Include the customer’s question, exact product or variant, relevant source references, what remains unresolved, and any action already attempted. Distinguish customer statements from verified facts and generated summaries. Pass only information the receiving team is authorized to see; avoid copying unrelated private conversation history.

For a hypothetical apparel inquiry, the useful handoff is: the customer requested navy shirts in size large, the variant was identified, but stock could not be confirmed and the requested delivery date remains unapproved. It should not say that the order is available for Friday. Give the receiving person enough evidence to continue without trusting the assistant’s summary blindly.

Microsoft’s Copilot Studio documentation describes handoff through a connected engagement hub, including a private message that supplies context to the receiving agent. This illustrates that a handoff needs an integration and a destination, not just a sentence in the chat. It is a platform example, not a claim that Exora uses Copilot Studio.

Show the real transfer state

Separate a transfer request from a confirmed transfer. Tell the customer that a request was submitted only after the receiving system acknowledges it. Claim that a person has joined only when that is true. If the team is unavailable, offer the approved alternative, such as a contact form or callback request, and state only the response expectations the business has authorized.

Assign an owner to unaccepted and failed handoffs. If submission times out, reconcile whether the request exists before retrying so staff do not receive duplicate tickets. A failed transfer should leave the customer with a clear next step rather than another promise that someone is coming. Once a person takes over, define whether the assistant stops responding and who can return control to it.

Test a direct request for a person, a missing policy, a failed ticket submission, an unavailable team, and a customer who changes the request while waiting. Inspect the receiving queue and the customer-facing status. Measure whether staff can continue the case and whether the issue is resolved; a lower escalation count alone can hide customers who gave up.

What DBAI’s Exora work demonstrates

DBAI’s Exora INK case study describes a SanMar catalog pipeline through n8n into WooCommerce, including product, variant, and inventory synchronization. It also describes customer and staff assistants connected to the storefront’s data layer, with customer quote requests routed to the team.

That is relevant evidence of catalog integration and assisted product lookup. It does not establish a universal connector, a particular freshness guarantee, or measured accuracy for the hypothetical tests in this guide. Ask for the field mappings, permissions, and acceptance evidence for your own catalog.

Copy this catalog acceptance brief

# Product assistant — catalog boundary
Audience and allowed questions:
Catalog segment and supported channels:
Product and variant identifiers:
Supplier-to-internal identifier mapping:

## Sources
Owner and authoritative source for each field:
Local overrides and conflict rules:
Source timestamps and freshness limits:
Failed-sync and stale-answer behavior:
Discontinued, deleted, and replacement handling:

## Answer permissions
Public versus account-specific fields:
Authenticated account and channel checks:
Approved price source, currency, and quantity context:
Inventory versus reservation boundary:
Delivery-date confirmation source:
Unsupported claim and human-handoff rules:

## Customer handoff
Triggers, including a direct request for a person:
Approved support policy owner and version:
Receiving queue, owner, and backup:
Question, variant, source evidence, and unresolved facts:
Actions already attempted and verified outcomes:
Allowed private context for the receiving team:
Submitted versus accepted versus human-joined status:
Unavailable-team message and approved alternative:
Failed submission, reconciliation, and duplicate handling:
Assistant behavior after a human takes over:

## Demonstrate
Similar names with different variant IDs:
Missing size or color:
Stale stock after a failed import:
Price change and local override conflict:
Discontinued item still present in search:
Unauthorized request for another account’s price:
Requested quantity or delivery date not confirmed:
Direct request for staff and unavailable team:
Missing or conflicting support policy:
Uncertain handoff submission and retry:
Customer changes request while waiting:
Expected answer, source record, and escalation:
Catalog owner / acceptance reviewer:

Test changes, not just a clean catalog snapshot

Run the pilot against normal questions and deliberately changed records. Update a price, remove a variant, interrupt an import, and test an expired stock value. Verify the storefront and assistant agree where they should, and that stale search results or cached answers do not reintroduce retired information.

Measure answer correctness, unsupported claims, successful handoffs, and staff correction effort over representative questions. Record the tested catalog version and case set. Start with a bounded segment, resolve recurring failures, and expand only when the next set of product and permission rules is understood.