English (US)Español (LA)Português (BR)

Three cases, one decision map

The same steps run each time. The code decides where the turn goes. Select a case to light its route.

Message Starts the turn Masking Code decides C Intent router Model labels M Charge lookup Code decides C Policy engine Code decides C Confirm box Code decides C Case opened Code decides C Which charge? Code decides C Nothing opens Code decides C Handoff Code decides C Advisor view Person decides P

Normal case

A México account with one matching charge: Cafe Central, 320 MXN.

“Vi en mi estado de cuenta un cargo de 320 pesos mexicanos de Cafe Central del 12 de junio y no lo reconozco.”es-MX line, shown in Spanish (LA)
  1. Masking. The code masks personal identifiers in the text before any model call.
  2. Intent router. The model labels the intent as a charge inquiry. It decides nothing else.
  3. Charge lookup. The code reads the charges of the session account and finds one match.
  4. Policy engine. The code checks the dispute window, the status and the amount. The policy allows the dispute.
  5. Confirm box. The customer confirms the charge. The system opens nothing before that.
  6. Case opened. The code opens the case, reads it back and shows the case number.

Result. A verified case. The system says that the case exists only after it reads it back.

Ambiguous case

A Colombia account with several charges that could match.

“não reconheço uma cobrança”pt-BR, then: não reconheço, pode revisar?
  1. Masking. The code masks personal identifiers in the text.
  2. Intent router. The model labels the intent as a charge inquiry.
  3. Charge lookup. The code finds more than one candidate charge.
  4. Policy engine. The text does not name one charge. The code does not guess.
  5. Which charge? The page shows the candidate charges as chips. The customer picks one.
  6. Nothing opens. No dispute opens and no case exists until the customer picks and confirms.

Result. A question, not an action. Nothing opens on the second unclear message either.

A person is needed

An Argentina account. The customer asks for an advisor.

“Quiero hablar con un asesor.”es line. In pt-BR: quero falar com um atendente
  1. Masking. The code masks personal identifiers in the text.
  2. Intent router. The model labels the intent as a request for a person.
  3. Policy engine. The first request offers help. A second request files a handoff. The code decides, not the model.
  4. Handoff. The code builds the package for the advisor from its own records.
  5. Advisor view. The advisor reads the package in a read-only view, with the trace of each step.

Result. A handoff with the verified facts, so the customer does not repeat the story.

The handoff package

This is the shape of what the advisor receives. It holds no customer identifier and no raw transcript. The values come from the conversation, so this page shows the fields only.

request
The intent that the system understood. A code, not the customer's words.
summary
A fixed summary of the conversation, built from the turns.
conversation
Each turn as codes and references. No raw transcript.
verified_facts
The charge facts that the code read from the data.
actions_taken
Every step the system tried, with its turn and outcome. Failed steps too.
evidence
References that support the facts.
open_questions
What the advisor still needs to ask.
language, country, phase
Where the case is and in which language.

Source: HandoffPackage and the advisor mock.

The lines are the demo lines of the demo replay. The data behind the demo is synthetic and the Gold store is a labelled mock. See what is real.