Skip to content
Guides

Products a customer can act on

The structured catalog gives Tephlo exact product facts. Saved carts turn those facts into a reviewable request for your workspace — not a placed order, checkout or payment.

Catalogs are not articles

Both live in the Content group, but they solve different problems. An article explains a returns policy, sizing guide or product story in prose. A catalog row carries typed fields the platform can validate and use deterministically: an SKU, name, price and currency, stock facts, categories, brand and bounded attributes.

Knowledge articlesRetrieved as passages and cited in an answer. They can describe a product, but prose never becomes a durable product identity or authorizes a cart change.
Structured catalogQueried as validated product rows. Only these rows can supply the exact SKU and money snapshot used by a saved cart.
Putting a price in an article does not make it cart-actionable. This separation prevents a paragraph, an old brochure or model-generated text from quietly becoming an item a customer appears to have selected.

Actionable products

A row may still be useful for an answer when it is incomplete. To enter a cart, however, it must belong to the active catalog generation and carry the server-validated identity and commercial facts the action requires. The console marks rows that are not actionable.

  • SKU and product name identify the item. The customer or model never supplies an internal database id.
  • Price and currency travel together. A partial money value is rejected rather than interpreted.
  • Stock is a catalog snapshot. It reflects your last update, not a warehouse hold or a real-time inventory reservation. Nothing counts a figure down as items sell, so the assistant states how old the catalog is once the figure is more than a week past its upload, and stops presenting it as certain after a month.
  • Attributes are bounded scalar facts. They can describe colour, size or material; they cannot contain code, a tool definition or a new permission.

Managing the catalog

Members whose role includes catalog management use Content → Catalog to add, edit and remove managed products. Each change checks the catalog version, so a stale browser cannot silently overwrite somebody else’s newer edit. The product mutation and catalog-version advance commit in one database transaction, so customers never read a half-written managed edit.

Products imported through a supported Knowledge catalog remain read-only on this screen. Edit their source and re-import them instead. The console labels managed and imported rows so the source of truth is not ambiguous.

Ordinary documents still belong on the Knowledge page. Do not duplicate the same live price in an article and a catalog row: the structured row is the commercial source of truth.

Saved carts

Where the active workspace profile permits cart management, a customer can ask the assistant to save or remove an exact catalog item. The operation is deterministic and bound to that customer, channel and tenant. The model can express the request, but it cannot choose a different SKU, price, quantity or workspace behind the action.

  1. The assistant identifies an actionable row from the current catalog.
  2. The customer confirms the intended action where confirmation is required.
  3. The server re-authorizes the exact tool and revalidates the product before changing the cart.
  4. The line snapshots the product name, SKU, price, currency and catalog generation so later review has an honest record of what the customer saw.
  5. The reply that confirms an added line also asks whether to send the saved cart to your team as a potential order for review (“Reply yes to confirm”). A plain yes sends it; anything else, such as adding another item, withdraws that question and the assistant answers what was said. A decided customer’s order request is therefore on record in three replies: the add offer, the confirmation with the send question, and the receipt.

An active cart expires after its retention window and duplicate delivery is idempotent: a provider retry does not add the same line twice merely because the message was delivered again.

Potential-order review

Submitting a cart creates a potential order in Business → Orders to approve. Members who can view orders can open it and review the price snapshot; contacting the customer and recording one of the declared states needs order approval:

AWAITING_REVIEW → CONTACTING_CUSTOMER / CONFIRMED / REJECTED / CANCELLED / EXPIRED
CONTACTING_CUSTOMER → CONFIRMED / REJECTED / CANCELLED / EXPIRED

A confirmed, rejected or cancelled decision is sent to the customer automatically on their channel, in their language, as soon as the messaging window allows (a re-engagement template goes first when it is closed). The confirmation tells them that payment is handled manually for now and that the team will contact them to arrange payment and delivery; nothing is charged in the chat. The request shows whether the customer has been told.

“Confirmed” means the workspace confirmed the request in this internal workflow. It is not proof of payment, inventory reservation, shipment or fulfilment. Keep the external payment and delivery outcome in the system that actually performs it.

What this does not do

No order is placedA saved or submitted cart is an internal request, not a commerce order.
No card is charged and no checkout existsCommerce records contain no card fields. The assistant refuses to ask for, repeat or treat card, CVV, PIN, password or one-time-code data as a workflow input.
No inventory is reservedA quantity in a cart is not a hold against your stock.
No shipment or fulfilment is startedThe workspace still contacts the customer and completes the sale off-platform.

Authorization and privacy

A profile declaration is not enough by itself. The tool is authorized again at execution time against the immutable workspace policy and current tenant state. A suspended workspace, missing policy, revoked capability, cross-tenant identity or stale product fails closed before the write.

Customer ownership uses a purpose-separated subject digest rather than a raw phone number or email in the commerce tables. Cart and potential-order data is included in the workspace privacy export and erasure lifecycle; lifecycle events retain only closed status codes and timestamps needed for content-free audit evidence. Members can view only their own workspace’s records.

External systems are a future adapter, not a hidden feature

The shipped workflow is intentionally internal. It does not synchronize with Shopify, WooCommerce, an ERP, a payment processor, delivery service or warehouse. A future adapter may connect one of those systems through a server-owned tool and the same authorization boundary; a URL or instruction in Knowledge cannot create that integration today.

Use it now for assisted salesLet the assistant collect exact products into a reviewable cart, then let your workspace contact the customer to confirm and arrange payment and delivery.