Tier-1 service deflection

A tier-1 deflection is done when the customer has an allow-listed answer that cites a live core or servicing record, or when they have a clean handoff to a human with the transcript, the intent, and the reason the bot stopped. A guessed figure, a vague promise to look into it, or another pass through the menu is not a resolution.

Assistants in the class of Erica or Cora are a pattern for this work, not a ranking. They sit in front of core and servicing stacks of the class that includes Salesforce and Temenos. The assistant earns the deflection only when the intent is on the allow-list and the fields spoken are read, not inferred. If the query is off the list, the quality outcome is the handoff.

Measure quality, not containment. Count answers with a cite. Count structured handoffs. Do not count chats that kept the customer in-bot while stating a number you cannot defend from core.

Build the list from intents your centre already treats as scriptable, then cut anything that needs judgment, investigation, or a write you cannot confirm. In retail banking service, the usual allow-listed reads are:

• Available and ledger balance, only when both can be read live and labelled with an as-of time
• Status of an existing dispute or claim, keyed by case number in the servicing system
• Card state as stored (active, blocked, replacement in flight) and the next customer-safe step
• Direct debit inventory: payee name, mandate reference, next collection date as held on the mandate record

Keep new dispute capture on dispute pre-triage automation. Keep multi-system journeys on agentic end-to-end case resolution. If an agent is already in the contact, use agent assist copilot rather than stretching the customer-facing bot.

Each allow-listed intent is a contract: systems of record, fields that may be spoken, fields that must never be inferred, the authentication bar, and the exact conditions that force a handoff. A balance is not allow-listed until the session meets the same assurance you would require in authenticated IVR. Unauthenticated callers get public guidance and a path to authenticate or to a person. They do not get a rounded figure "to be helpful."

If a product, channel, or customer segment cannot be read live, it is not on the list for that session.

The bot answers only from live reads. If core, cards, or the mandate store is down, timed out, or returning a snapshot you cannot timestamp, the bot does not speak a figure. It says the source is unavailable and offers a retry or a handoff. Stating a stale balance from last night's batch as if it were current available funds is a quality failure even when no agent is involved.

Cite the source in the sentence the customer hears. "Available balance on the current account ending 4321 is [amount], as of 14:03 from core" is a cite. "You have enough for that payment" is not. If the product has both available and ledger, return both and do not collapse them. If core and the channel cache disagree, do not pick a winner in the chat. Hand off with both values attached.

The same rule covers dispute status and card state. Status is the field on the case or card record, not a rewrite of the last SMS.

Illustrative example: the customer says, "What's my balance, and can you stop the gym direct debit that went out yesterday?" After authentication the bot reads live available and ledger from core and cites both with times. It lists mandates from the mandate store. The gym mandate is still active; yesterday's collection has posted. The bot does not invent a pending refund and does not cancel anything in this turn. It states the posted collection as completed, shows the mandate, and asks a single question: whether to cancel future collections for that payee. If the balance read fails, it does not backfill from a warehouse file. It stops on the balance intent and retries or hands off. A successful mandate list does not license a guessed cash position.

Reads can finish after auth. Writes cannot. Card block, unblock, replacement, direct debit cancel, payee change, and any other mandate or card mutation need a restatement plus a confirm that matches that restatement.

The restatement is specific: last four of the card, payee name, mandate reference, and the action in one clause ("cancel future collections for [payee]; this will not reverse the collection that already posted"). Then wait. A bare "yes" after a compound question is not consent. Completing a direct debit cancel because the customer said yes to "Is that the gym one, and shall I cancel it?" is a known failure: the yes may have identified the mandate, not authorised the cancel. Split identification and action into two turns.

Card block is the same class of error. The bot may propose a block when the customer reports a missing wallet. It must not complete the block until they confirm that card, that action, and that recurring merchants may fail. If they only asked whether a transaction was theirs, do not block. If they go silent after the proposal, do not treat silence as confirm. Do not complete a card-block the customer did not confirm. Time out to a human or leave a draft the agent can finish.

Unblock and replacement are not the inverse of block. Each mutation has its own allow-list entry and its own confirm. Do not chain them because the first write succeeded.

Fraud, scams, and "this debit is not mine" when there is no existing case leave immediately. Refusing to hand off a fraud claim in order to keep the contact in self-serve is a quality failure. Transfer with the transcript, amounts labelled as customer-stated (not as core-confirmed), and a fraud or claims queue, not a generic help article.

Vulnerable-customer signals must not be trapped by deflection. Mentions of financial difficulty, a third party controlling the account, bereavement, or language or capacity barriers stop self-serve. Follow vulnerable customer detection. Do not keep the person in the allow-list loop until they pick a menu item. Do not make a hostile re-auth the price of reaching a human.

Also hand off: identity that fails after allowed retries; conflicting core and servicing data; a request to reverse a posted payment the mandate store cannot reverse; complaint or ombudsman language; any intent not on the allow-list, even if it sounds simple.

A clean handoff is a packet: intent, auth level, what was read from which system, what the customer was told, what was not done, and why the bot stopped. If the remaining work is a case, not a single answer, park it for case handling instead of stretching the chatbot.

Status of an existing dispute can be read here. Assembling evidence and routing a new dispute cannot. The digital-service lead tests four gates: allow-list membership, live cite or no answer, explicit confirm on every mutation, and mandatory handoff on fraud, vulnerability, conflict, and unlisted intent. Fail closed. Never invent a balance. Never block a vulnerable-customer path. Never complete a card-block the customer did not confirm.