An answer grounded in your own material, an honest limit where there is no answer, and a person the moment one is needed. This page explains each of those, including the ones Tephlo enforces whether the language model cooperates or not.
Every reply about your business is built from passages retrieved out of your knowledge base and rows from your catalog. That evidence is the answer’s entire basis. Where there is no evidence there is no answer: the assistant says it is not sure and hands the conversation to a person rather than filling the gap.
This is stricter than it sounds. It applies to prices, stock, opening hours, delivery times, warranty terms, eligibility and policy — the facts a customer will act on. A confident sentence about your returns policy with nothing behind it is a failure even when it happens to be true, because nothing distinguished it from the time it was not.
General conversation is still conversation. Greetings, small talk, and explaining what the assistant can help with do not require a citation. The grounding rule binds claims about your business.
What it cannot do
This is the section worth reading twice. The assistant has a fixed set of abilities, decided by a registry in the platform from real runtime state — never inferred by a language model. Some of those abilities depend on your workspace. Others do not exist for anyone, ever, and no setting, plan or configuration creates them.
Never possible, in any workspace
Place, change or cancel an orderThere is no ordering system in this platform.
Add anything to a cart, basket or bagNo cart exists.
Take payment or check outThere is no checkout, and no online store to send a customer to. It will not invent one either — see the guard below.
Book, reschedule or cancel an appointment, or look up availabilityNothing in this platform holds, reserves or arranges a slot.
Check live stockCatalog stock is a snapshot from your last catalog update, and the assistant is required to describe it that way.
Sign someone up to a list, waitlist or newsletterNo subscription is created anywhere.
Deliver a course, run a quiz, grade work, enrol anyone or issue a certificateIt can teach a concept in conversation. It cannot register a student, mark a paper or certify anything, and it will not claim to.
Available only when your workspace supports it
These are resolved per conversation, from the real state of your workspace at that moment. If the check fails — or cannot be run because a database or cache is unreachable — the ability is treated as unavailable. An offer that was never made is recoverable; an invented one is not.
Answer from your materialRequires at least one indexed knowledge source.
Look up your catalogRequires an active, fully-indexed product catalog.
Check the status of an order already placedRequires an enabled order-lookup connector, and the customer supplying the reference and the verification detail you asked for. Strictly read-only — an enabled connector never unlocks creating, changing or cancelling an order.
Note a request for your teamA callback, a complaint or a refund request, written down for someone to action. Requires request capture to be switched on.
Bring in a personRequires at least one confirmed escalation recipient. With nobody to alert, the assistant will not say a team member will take over, call back or follow up — because nobody would.
Look something up on the public web Off by defaultRequires a configured search provider for the deployment.
How the limit is actually enforced
Two mechanisms, in order:
Before the reply is written, the assistant is given the resolved list of what it may offer and an explicit list of what it must say is impossible, with purchase and checkout named first.
After the reply is written and before it is sent, the text is checked against that same registry. A reply promising an unavailable action never reaches the customer: it is replaced with a message that names the limit plainly and offers a real next step instead.
The guard reads the reply itself, in the customer’s language, and it is built to distinguish a claim from ordinary speech. Stating an inability is not a claim — “I cannot book an appointment from this chat, but I can note the request for the team” is exactly the reply the rules ask for and survives untouched. Neither is your own material: “check-out is at 11am” is a hotel’s honest answer, and “to book an appointment, walk in before 4pm” is a real next step, not a promise about the chat.
Why this exists. An earlier version, asked how to buy a product, repeated the price and then offered “you can place your order through our website or contact our sales team.” There was no website, no checkout and no sales desk. The registry exists so that the failure is structurally impossible rather than merely discouraged — a goal you type cannot create a capability, and a capability the platform does not have cannot be promised.
Conversation goals
Answering a question is not the same as helping someone. In Assistant → Goals you describe your organization, and the platform selects a strategy for how a conversation should move.
You choose the kind of organization you are:
CommerceNarrow a shopper to a specific item using what they have already said, give the details that settle a decision, and never invent stock, scarcity, discounts, delivery times or a payment path.
EducationTeach one small step at a time with a concrete example, hint before giving the worked answer, and respond to the answer the learner actually gave. Never claim to enrol, grade, mark or certify.
ServiceEstablish the outcome wanted, then scope, price and timing — all from your material. Never say a slot is free, held or arranged.
SupportFix the problem rather than the sentence. One diagnostic step at a time, tracking what has already been tried, with no selling of any kind.
NonprofitExplain the work concretely and point to a real way to take part. Every impact figure comes from your material, and no contribution is ever described as received.
GenericAnswer what was asked, then help with the natural next step. Ask only what you need.
The strategy also depends on where the conversation has got to. A shop at “what do you sell?” needs different advice from the same shop at “I’ll take the blue one”: the first is narrowing, the second is holding the choice exactly as given and moving to the real supported step. When a customer declines, the pursuit stops immediately — no second attempt, no new offer, no reason to reconsider.
On the same screen you can add:
What your organization wants from these conversations, in your own words.
What a good outcome looks like for the customer.
What your team handles off-chat, so people are guided toward it and never told it has been done.
What your team needs collected before it can act, as a short checklist.
Tone, and teaching style for education workspaces.
Situations where you would rather a person took over.
A goal is not a capability. Everything on that screen describes what your team does. It grants the assistant nothing. Writing “we take payment on delivery” states a fact about your operation that the assistant may relay; it does not let the assistant take a payment. The same screen shows, right there, the live list of what your assistant can do now, what is not connected yet, and what can never be done in any workspace.
Working memory and action honesty
Tephlo carries the state of a conversation from turn to turn: what the customer is trying to do, the option they settled on, the details they have already supplied, and the question it last asked. That is why a bare “2” is read as the answer to the question actually asked, why “two of them” lands on the right item, and why nobody is asked for the same detail twice.
This memory is short-lived and deliberately kept apart from long-term customer memory. A quantity or a delivery slot is scratch for one conversation, not a fact about a person. Sensitive fields such as card numbers are refused outright, whatever a configuration asks for.
The same mechanism is what keeps the assistant honest about actions, and it is worth stating exactly:
An offer is not an outcome. A customer saying yes records the action as under way, never as done.
Only a step that genuinely completed can be reported as complete. The conversation cannot be moved to “finished” by agreement — only by a real result.
A failure is stated plainly. If writing down a request fails, the customer is told, and the conversation goes to a person. It is never smoothed over with “I have logged that for you.”
Phrases it must never say
Add exact phrases to the Never say list on the conversation-goals screen and they are enforced rather than requested. A reply containing one is withheld from the customer and the conversation is handed to a person instead.
Matching is a plain, case-insensitive substring test — blunt on purpose. You write the phrases, so a false positive costs one escalation, while a miss costs you the exact promise you banned. Very short entries are ignored, because a three-letter phrase would match inside ordinary words and silence legitimate answers.
Human handoff
An escalated conversation lands in your escalation queue with its full history and the reason it escalated. An agent takes it in one tap and replies to the customer over the same channel — the customer never repeats themselves — and when it is resolved the conversation returns to the assistant.
The reasons are recorded, and they are not all the same kind of thing:
Customer asked for a personThe clearest signal there is, and it is always honoured.
No supporting knowledgeYour material had no answer. These are the most useful escalations you will read — they are a list of the documents you have not written.
Low confidenceThere was evidence, but not enough to answer safely.
High riskA consequential medical, legal, financial or safety question that could not be grounded safely.
Customer frustrationThe customer is clearly and strongly upset and the turn did not resolve it, so a person takes over before the relationship does.
Loop detectedThe conversation is going in circles. Repeating a fourth time helps nobody.
System errorA supported action could not be completed. The conversation is handed over rather than confirming a success that did not happen.
Service unavailableThe language model, the retrieval service or web search was down. Recorded separately from a genuine knowledge gap, so an outage never shows up in your analytics as a hole in your knowledge base.
The customer is told the truth about the wait. They are told a person is being brought in and why. With business hours configured on Assistant → Behavior and your team offline, they are told when you are back rather than left in silence. A handoff notice is never re-sent verbatim to fill a gap — repeating “someone will be with you shortly” with no new information is treated as a defect, not as reassurance.
Languages
Tephlo detects the language each customer writes in and replies in it. That covers the generated answers and the platform’s own fixed messages alike — fallbacks, clarifications, handoff notices, request confirmations and follow-ups. There is nothing to configure.
Your knowledge base can stay in one language. The facts are translated faithfully, and identifiers — order references, SKUs, model numbers — are repeated verbatim rather than translated.
French is a first-class language here, not an afterthought: francophone West Africa is this platform’s first market, so the fixed messages are written in French as well as English, and the guard that catches invented capabilities carries a French rule table of its own. English rules always run as a baseline underneath, because a French reply can still contain an English phrase like “checkout”. A language with no translation table falls back to English rather than breaking a reply.
Money questions
Financial questions are treated as consequential by default, and rightly: answering “should I put my savings into this?” badly costs somebody real money. Those go to a person.
But the same caution, applied bluntly, breaks an accounting tutor: refusing to explain what a debit is leaves a customer who can neither get an answer nor get a person. So there is one narrow exception, and its narrowness is the whole safety argument. Three independent judgements must all agree that a question is conceptual education:
The classifier that reads the incoming message.
The safety guard, which classifies independently and cannot see the first one’s output.
A deterministic check in code that reads only the customer’s own words — never any model output — looking for conceptual framing and for the absence of anything personal, transactional or regulatory.
Any one of the three dissenting leaves the question high-risk. Because the third reads no model output at all, an instruction planted in a message cannot talk its way past it.
The line in practice: “what is compound interest?” is a lesson. “Explain bonds, then tell me whether I should buy this one” is guidance that happens to open with a lesson, and goes to a person. So does anything about current tax rates or filing obligations, because those change and must come from evidence rather than from a model’s memory.
How any of this is checked
Claims about assistant quality are easy to make, so here is what is actually measured and what it does not prove.
The floor is tested against a hostile model. Scripted conversations make the model invent a checkout, promise a callback nobody will make, or utter a banned phrase, and assert that the code catches it — in the outgoing text and in the carried state. This proves the guards hold. It proves nothing about whether a reply reads well, because the prose is scripted.
Reply quality is graded against a fixed rubric across a versioned corpus in English and French, covering all five business domains. Thirteen defects are hard failures that no amount of good writing can offset — fabricating a capability, inventing a route to transact, reporting an action as done when it was not, unsafe financial advice, ungrounded business claims, privacy violations, leaking another workspace’s material.
Four of those are decided in code before any grader is asked. They read only code-owned signals and the customer’s own words, never the model’s claim about what it did, which is what lets them outrank a good grade.
Over-caution is a failure too. Escalating a plainly conceptual money question is graded as a defect in its own right, so the rubric cannot be satisfied by an assistant that simply refuses everything.
What that does not prove. The corpora are authored, not sampled from real traffic; they are a probe. A score is comparable only against another run of the same rubric on the same corpus with the same grader. And a model grading model prose rewards fluency, so the dimensions most sensitive to that are flagged for a human to grade instead. Numbers travel further than the paragraph that qualified them, which is why the qualification is stated everywhere the number is.
Commercial questions — plans, limits, what a conversation costs — are answered on the Tephlo FAQ.