Tephlo answers from your knowledge base and your catalog, and from nothing else. That makes this the single highest-leverage thing you maintain: the quality of the answers is the quality of what is in here.
Open Knowledge base in the console and upload a file, or paste text directly for something short like a returns policy or a price list caveat.
Upload: .pdf .docx .xlsx .txt .md — up to 5 MB per file · or paste raw text
Each source moves through PENDING and PROCESSING while it is parsed, split into passages and indexed, then becomes READY and starts answering. The page polls while anything is in flight, so you can watch it happen rather than guessing.
When a source fails, the reason is stated plainly rather than hidden:
No readable text foundA scanned or image-only document has no text layer to extract. Re-export it as a text PDF, or paste the content in.
Unsupported document typeThe file is not one of the formats above.
Processing service unavailableThe indexing service could not be reached. Nothing was half-indexed — re-upload to try again.
Re-uploading a source does not leave the old version half-live. A new revision is indexed alongside the current one and switched over in a single step, so a customer never gets an answer stitched from two versions of the same document.
How an answer is found
A customer’s question is not matched against your documents by keyword alone. Four things happen, and each exists to fix a specific way the naive version fails:
The question is made standalone. A short follow-up like “and the 2kg?” means nothing on its own, so it is rewritten using the conversation so far before anything is searched. Only short follow-ups pay this cost, and if the rewrite fails the search falls back rather than stalling.
Three searches run and are fused. Semantic similarity finds passages that mean the same thing, full-text search finds the ones that use the same words, and exact matching finds identifiers — an SKU, an order reference, a model number — that semantic search is famously bad at. The three ranked lists are combined into one.
The shortlist is re-ranked. On a large knowledge base a wider pool is pulled and reordered by true relevance before the top passages are handed to the answer. If the re-ranker is unavailable, the fused order is used — a degraded ranking, never a failed answer.
The answer is bound to what came back. Citations can only point at sources that were actually retrieved for that reply. A citation to a source the search never returned is not a formatting slip — it is the beginning of a fabricated answer, and it is refused.
An empty result is an honest “I don’t know”, not an invitation to improvise. If nothing relevant comes back, the question is treated as unanswerable and the conversation escalates. A retrieval outage is recorded as a different reason from a genuine gap in your material, so your analytics never blame your knowledge base for an infrastructure problem.
Validity, staleness and conflicts
A price list from 2023 is worse than no price list. Every source can carry a validity window and a human verification stamp, and the assistant treats them as a trust contract rather than as metadata.
Verified · currentSomeone marked it verified, its start date has passed, and its end date is still in the future. This is the only state that counts as trusted freshness.
ExpiredThe end date has passed. An end date of exactly now is already expired — the bar does not round in your favour.
Not yet validThe start date is in the future. Next season’s prices, not this season’s.
UnverifiedIt has a window, but nobody has confirmed the content is right.
No validity windowNo dates set. This is the correct state for timeless material — how your warranty works, what your service includes — and it is not a defect.
Three rules follow from that, and they are the reason to bother setting dates at all:
Trusted freshness is demanded only when the question needs it. An undated policy page answers “what is your returns window?” perfectly well. A question about what is true today — a current price, this week’s availability — requires a source that is verified and current.
A stale source loses to a usable one. Where both exist, the current source wins.
Two current sources that disagree both reach the answer. Nothing in code can break that tie honestly, so the disagreement is surfaced instead of one side being silently dropped. Quietly picking a winner between two live, contradictory prices is deciding a customer’s money on their behalf.
What makes a good knowledge base
The failure mode is not usually a missing document. It is a document that a human could interpret and a retrieval system cannot.
Write answers, not brochures“Delivery in Ouagadougou is 2–3 working days; outside the city, 5–7” is retrievable. “We pride ourselves on fast, reliable delivery” answers nothing and will be quoted back at a customer asking how long they must wait.
One fact in one placeThe same price in four documents is four documents to update, and the day one is missed the assistant has two current sources that disagree — which it will show the customer rather than guess between.
Put the question in the textPassages are matched against how customers phrase things. A heading that reads “Returns and exchanges” retrieves better than one that reads “Policy 4.2”.
Date anything that changesPrices, promotions, opening hours, shipping times. Leave genuinely timeless material undated — a validity window on something that never expires just creates an expiry you have to remember.
Write down what you do not do“We do not ship outside the country” is a real answer. Without it the assistant has no grounded reply and escalates a question your team then answers by hand every week.
Keep identifiers exactOrder references, SKUs and model numbers are matched exactly, and are repeated verbatim in replies even when the conversation is happening in another language.
Let the escalation queue tell you what is missingEscalations with the reason no supporting knowledge are a list of the documents you have not written yet. See analytics.
The product catalog
Prose retrieval cannot answer “the cheapest one under 50,000 that is in stock”. A structured catalog can. Upload a spreadsheet of your products and Tephlo extracts typed rows from it — SKU, name, category, subcategory, brand, price, currency, stock — while keeping every original column alongside them, so nothing you had is lost.
Header names vary between businesses, so common alternatives are recognised automatically: SKU, Product ID or Item ID; Product name, Name or Title; Final price, Sale price or Price; Stock quantity, Qty or Availability. The customer-facing price is preferred over the list price where a sheet carries both.
Catalog answers are exact rather than paraphrased. The assistant filters and sorts by price, stock, category and brand against the real rows, so a price it quotes is a price you uploaded.
Catalog stock is a snapshot, and the assistant says so. It reflects your last catalog update, not a live inventory system — there is no live stock lookup anywhere in the platform. A reply claiming to check current, real-time or live stock is treated as a fabricated capability and replaced. Keep the sheet current, and treat stock in a chat as indicative.
Only products belonging to the active, fully-indexed version of a catalog are visible to a customer. A half-imported spreadsheet cannot leak into an answer.
Customer memory
With customer memory on, durable facts about a customer — their preferences, context they have already given you — are carried into future conversations, so they are not asked the same thing every time they write.
This is deliberately separate from the short-lived working memory that runs inside a single conversation. The quantity someone wants today is scratch for today; their preferred language or their usual delivery area is a fact about a person. Sensitive fields — card numbers, PINs, one-time codes — are refused outright and cannot be stored by either mechanism, whatever a configuration asks for. See working memory for the in-conversation half, and consent and retention for the controls.