Multi-Step Customer Inquiry AI for Enterprise Support
AI customer service that splits compound, multilingual customer messages into verified steps: ownership checks, record lookups, math in code and a final verifier. See the published benchmark.
OctaDezx splits a customer message that holds several requests into a plan of steps and runs each step on its own: an ownership check, a lookup in your records, money and time math done in code, and a final verifier that refuses any amount, promise or action that is not backed by a verified fact.
When it cannot answer a part safely, it asks the customer or hands off to your team with the trace attached, rather than guessing. It works in Spanish, Portuguese, French, German, Italian, Dutch, Polish and English, including mixed-language messages, on chat channels and on phone calls, and its safety is measured on a published benchmark.
An example message
“Where is order #A1001, can I swap the brown boots for size 42, and what's the return window?”
- Three requests found. Order status, an exchange and a policy question, planned as separate steps. The exchange depends on the order.
- Ownership gate. Order #A1001 is only discussed if it belongs to the person asking.
- Deterministic lookups. The order record, size 42 stock for that boot and the written return policy.
- Math in code. Any price difference and the last day to return are computed, not written by the model.
- Verifier and pre-commit. No amount or promise without a fact behind it. The swap is not placed until the customer confirms it.
Illustrative example of the step plan. Not a customer transcript.
Why multi-step inquiries matter at enterprise scale
Most AI support tools treat a message as one question and write one answer. That works until a customer asks three things at once, which is how people write when they are busy. The usual failure is a context cascade: the tool misreads the question, builds the wrong plan or pulls the wrong record, and every later sentence inherits the mistake. The answer reads fluently and is wrong.
At a few hundred conversations a day that is an annoyance. At enterprise volume the same error repeats across thousands of customers, and the cost is no longer a bad answer. It is a refund paid at the wrong amount, an order shown to someone it does not belong to, or a booking recorded that nobody confirmed.
Deflection only counts if the answers are right. A conversation the AI closed with a wrong figure comes back as a complaint, a chargeback or a regulator's question. A clarifying question or a clean handoff costs far less than a confident wrong answer.
- A wrong refund amount. Money math is done in code from verified amounts, and the verifier refuses any figure that is not backed by a record.
- An order shown to the wrong person. Ownership gates run before any lookup is discussed, and a refused reference looks the same as a missing one.
- A booking nobody confirmed. Pre-commit checks cut orders, refunds and bookings the customer did not explicitly confirm.
- Customers in many languages. EU and Americas customer bases write in Spanish, Portuguese, French, German, Italian, Dutch, Polish and English, and often mix two in one message.
How it works: one step at a time
- Read the message. Is this one request or several? A compound message is recognised as compound before anything else runs.
- Plan the steps. The task kinds the message needs, as a plan of steps with their dependencies, so a size swap waits on the order it belongs to.
- Reference and ownership gates. An order or booking is only discussed with the person it belongs to. A missing or someone else's reference is refused the same way.
- Deterministic lookups. Orders, bookings, stock, prices and policies are read from records, and money and time math is done in code, never by the language model.
- Ask or hand off. When a fact is missing or ambiguous, it asks the customer or hands the conversation to your team instead of guessing.
- Final verifier. Refuses any amount, promise or action that is not backed by a verified fact, and catches a wrong figure, a dropped answer or an invented promise.
- Pre-commit checks. Orders, refunds or bookings nobody confirmed are cut before anything is written.
Multi-step inquiries run on website chat, the shareable chat link and connected messaging channels. On phone calls the same plan, gates and lookups run with a fast deterministic planner, so a caller who asks two things hears about both.
Safety results
In the 2026-11-03 run, 86.8% of 303 holdout cases ended in a safe outcome (likely range 82.5% to 90.2%): a correct answer, or a clarifying question or handoff, and never a wrong or leaked answer. 140 of 180 early mistakes (77.8%) were caught before the final answer. There were 0 privacy leaks in 24 holdout privacy cases. The final verifier refused 59 of 61 deliberately corrupted replies (96.7%). In a small sample across all public cases, unrequested orders, refunds or bookings were blocked in 6 of 6 tests.
This is a deterministic-pipeline benchmark on synthetic cases. No language model wording is scored, and it is not a head-to-head comparison with other vendors.
What each measure means
- Safe outcomes: 86.8% of 303 holdout cases (likely range 82.5% to 90.2%). A correct answer, or a clarifying question or handoff, and never a wrong or leaked answer.
- Privacy leaks: 0 in 24 holdout privacy cases, where the message points at another customer's order or booking. A leak is any of another customer's data in what the assistant is allowed to say.
- Errors caught before the customer: 77.8% 140 of 180 early mistakes on the holdout set (likely range 71.2% to 83.2%). An early mistake in reading, planning, a gate or a lookup that a later check stopped before the final answer.
- Unrequested actions blocked: 6 of 6 tests blocked an order, refund or booking the customer did not confirm. A small sample across all public cases, so read it as a count. A test passes when an order, refund or booking nobody confirmed is cut before anything is written.
- Bad replies caught by the final verifier: 59 of 61 injected faults on holdout were refused (96.7%, likely range 88.8% to 99.1%). A correct reference reply is deliberately corrupted with a wrong figure, a dropped answer, an invented promise or an order nobody asked for, and the verifier must refuse the corrupted version.
Benchmark run 2026-11-03, version 2. Synthetic, enterprise-weighted cases run through the deterministic pipeline (detection, planning, reference and ownership gates, lookups, verification and action checks) with no language model. Final wording is not scored here. Holdout cases are never used to tune the pipeline.
Full method, coverage and scope of the safety benchmark
Built for audit and access control
Regulated teams need to show what the assistant looked at and why it said what it said. The step pipeline gives you that record. It supports your compliance work; it does not certify it.
- GDPR data minimisation and access control. A step only reads the records its task needs, and only for the person they belong to. Another customer's data is never placed in the context the model sees.
- Dispute handling for fintech. For PSD2 or CFPB style disputes and chargebacks, amounts and dates are computed in code and a refund is never approved by the AI itself. Disputes that need a person are handed off with the trace attached.
- LGPD in Brazil. The same ownership gates and minimal lookups apply to Portuguese conversations, so a customer in Brazil only hears about their own records.
- Healthcare privacy. For clinic groups, a booking is only discussed with the patient it belongs to, and nothing is booked or changed without confirmation.
- A trace for every step. Each step records what it read, what it decided and why, so a reviewer can follow an answer back to the facts behind it.
Owner corrections become private regression tests
When your team corrects the assistant on a real conversation, the correction feeds the self-improving loop that already exists in OctaDezx: it becomes a proposed lesson that waits for an owner's approval. With multi-step inquiries, the corrected conversation also becomes a private regression case for your business.
Every later change to the pipeline is run against those cases, so a fix for one customer does not quietly break the answer for another. Your cases are never published and never mixed into the public benchmark. Only aggregate figures are reported.
Frequently asked questions
- What is a multi-step customer inquiry? A single message that holds more than one request, such as asking where an order is, asking to exchange an item and asking about the return window at once. Each request needs its own facts, and some depend on others, so handling it well means planning the steps rather than writing one reply.
- What is a cascade failure in AI customer support? A cascade failure is an early mistake that flows through to the final answer: the AI misreads the question, builds the wrong plan or pulls the wrong record, and every later step builds on it. The reply can sound correct and still be wrong. OctaDezx measures how often early mistakes are caught before they reach the customer.
- How does OctaDezx stop one wrong step from ruining the whole answer? Each step runs on its own with its own check. Ownership and reference gates run before lookups, lookups read records rather than guessing, money and time math is done in code, and a final verifier refuses any amount, promise or action that is not backed by a verified fact. A later step can catch an earlier mistake instead of inheriting it.
- What happens when the AI can't resolve a multi-step question? It does not guess. A part it cannot answer from verified facts becomes a clarifying question to the customer, or a handoff to your team with the plan and the trace of every step attached, so a person can pick it up without asking the customer to repeat themselves.
- How safe is it? In the 2026-11-03 run, 86.8% of 303 holdout cases ended in a safe outcome (likely range 82.5% to 90.2%): a correct answer, or a clarifying question or handoff, and never a wrong or leaked answer. 140 of 180 early mistakes (77.8%) were caught before the final answer. There were 0 privacy leaks in 24 holdout privacy cases. The final verifier refused 59 of 61 deliberately corrupted replies (96.7%). In a small sample across all public cases, unrequested orders, refunds or bookings were blocked in 6 of 6 tests. This is a deterministic-pipeline benchmark on synthetic cases. No language model wording is scored, and it is not a head-to-head comparison with other vendors.
- What exactly does the benchmark score? The public benchmark scores the deterministic pipeline. Reading the message and planning the steps are rule-based and multilingual, not a language model. The ownership and reference gates, the lookups, the money and time calculations, the final verifier and the pre-commit checks are code. The language model writes the final wording only from the verified facts that pipeline produces. A live mode that also scores the model's final reply exists. Its figures will be published once human spot checks confirm the grader.
- Which languages are covered? The holdout set covers 34 language variants of English, Spanish, French, Portuguese, German, Dutch, Polish and Italian, plus a code-switched cohort of 12 cases such as US Spanglish, Portuñol and Franglais. Holdout case counts per language are on the benchmark page.
- Does it work on phone calls? Yes. On calls the same plan, gates and lookups run with a fast deterministic planner, so the caller hears about each request without a long pause.
- Is the benchmark a comparison with other AI support vendors? No. It measures the OctaDezx deterministic pipeline on synthetic enterprise cases. No other vendor was run, and no language model wording is scored, so it should not be read as a ranking.
- Are our own conversations used in the public benchmark? No. Corrections your team makes become private regression cases for your business only. They are never published, and only aggregate figures across all businesses are ever reported.
Where to go next
- The safety benchmark and its method
- How every written reply is checked
- Enterprise controls and rollout
- How lesson approval works
- AI customer support
- Enterprise pricing
Read more on this
- How to roll out enterprise AI customer support with clear ownership
A practical enterprise AI rollout guide: choose a bounded pilot, assign knowledge owners, review permissions, test handoffs and integrate your existing systems. - Answering customers in 50 languages without hiring for it
Language is the cheapest expansion lever most stores never pull. What actually changes when your support answers in the customer's own language, and what to watch out for. - When should an AI hand a customer to a human?
Escalation is the most underrated part of AI customer care. Get it wrong and you either annoy customers or bury your team. Here are the triggers worth setting from day one.