Deflection counts the tickets your AI kept away from a human. Multi-step resolution counts the customer problems it actually finished - identity verified, dispute filed, refund posted, account updated. In complex support those are different numbers, and the infrastructure that closes the gap is what separates a real AI agent from a chatbot with a confident tone.
Multi-step resolution is the ability of an AI support agent to take a customer's issue from start to finish across several dependent actions - look up an account, run a check, call an external system, update a record, confirm the outcome - without handing off to a human partway through. Deflection, by contrast, only measures whether a human was avoided. A ticket can be deflected and unresolved at the same time: the customer gave up, got a partial answer, or was quietly dropped after step one. This guide explains what multi-step resolution means, why deflection metrics hide unresolved problems, and what infrastructure - integrations, workflows, guardrails, and independent QA verification - actually enables resolution rather than avoidance.
Deflection measures avoidance (no human touched the ticket). Multi-step resolution measures completion (every dependent action the issue required was carried out and verified). The two only agree when no deflected ticket is left half-done.
Most real support tickets are not one question and one answer. They are chains: verify identity, then check the transaction, then file the dispute, then update the CRM, then confirm to the customer. Deflection counts the chain as a win the moment a human is avoided, even if it stopped at step two.
Multi-step resolution depends on infrastructure a chatbot does not have: write-capable integrations, workflows that hold state across steps and recover from errors, guardrails that block unsafe actions, and independent QA that verifies the outcome.
A half-completed action chain is often worse than no action: a dispute opened but not finished, an account partially updated, a refund promised but not posted. These look like deflections and behave like incidents.
The defensible 2026 setup: deep integrations for the actions, deterministic plus natural-language workflows for the orchestration, defence-in-depth guardrails for safety, and 100% automated QA to verify resolution actually happened.
Last updated: June 2026
Most AI support vendors lead with a deflection rate because it is the easiest number to inflate and the hardest to disprove. The problem is that deflection was designed for a world of single-turn questions - store hours, password resets, order status - where avoiding a human and solving the problem are the same event. Modern support is not that world. A frozen account, a disputed charge, a failed cross-border transfer, or a benefits change is a sequence of dependent actions, and an agent that can answer a question but cannot complete the sequence has not resolved anything. This is a buyer-neutral explainer: what multi-step resolution actually requires, why deflection metrics systematically hide the tickets that did not get finished, and what infrastructure makes end-to-end resolution real rather than aspirational.
What is multi-step resolution?
Multi-step resolution is the completion of a support issue that requires more than one dependent action, carried out in the correct order, with state preserved between steps and the final outcome verified. The defining feature is dependency: step three cannot run until step two succeeds, and the agent has to know what to do when a step fails. A single retrieval-and-reply is not multi-step resolution, no matter how good the reply is.
Multi-step resolution: an AI agent completing a chain of dependent actions - lookups, external calls, writes, confirmations - end to end, recovering from errors along the way, so the customer's underlying issue is actually solved rather than answered.
Consider what a real ticket looks like. "My card got declined and now my account is locked" is not one task. To resolve it, an agent has to verify the customer's identity, check why the account was locked, confirm there is no active fraud hold, unlock the account if it is safe to do so, update the record, and tell the customer what happened and what to do next. Six dependent steps, two of which write to systems of record, one of which is a risk decision that must respect a guardrail. Answering "your account appears to be locked, please contact support" deflects the ticket and resolves nothing.
The hard part is not any single step - it is the orchestration and the failure handling. What happens when the identity check is ambiguous? When the core banking API returns a 5xx halfway through? When the unlock would violate a fraud threshold? A chatbot does not have answers to these questions because it was never designed to take actions; it was designed to retrieve text. Multi-step resolution is an agentic problem, and it is where the category genuinely splits.
Common multi-step patterns across regulated industries:
Fintech dispute: verify identity, pull the transaction, check eligibility, file the dispute in the system of record, post a provisional credit if policy allows, confirm to the customer with the case number.
Healthtech refill: verify the patient, check the prescription status, confirm there is no clinical hold, coordinate with the pharmacy, and update the patient on timing.
Insurance claim status: authenticate the policyholder, look up the claim, interpret the adjuster's notes, explain the next step, and schedule a follow-up if the claim is stalled.
Gaming/betting account: verify the account, check responsible-gaming flags and KYC status, action a withdrawal or a limit change within policy, and log the decision.
Each of these is several actions, at least one write, and at least one decision that has to respect a rule. None of them are deflectable in any honest sense of the word.
What deflection actually measures - and what it hides
Deflection rate is the percentage of inbound contacts handled without a human agent. If 1,000 tickets arrive and 700 never reach a person, deflection is 70%. It is a containment metric: it records the absence of a handoff, not the presence of a completed outcome. As a capacity-planning input that is useful. As a measure of whether customers were helped, it is silent on the only thing that matters.
Deflection rate: the share of contacts resolved or abandoned without human involvement. It counts the absence of an escalation, which is consistent with both a solved problem and a customer who gave up.
The structural flaw is that deflection collapses two opposite events into one number. The customer whose six-step unlock completed cleanly and the customer who got dropped after step one both show up as "deflected." In single-turn support that ambiguity is small, because most tickets are one step. In multi-step support it is enormous, because there are many places for the chain to stop early and every one of them still counts as a deflection.
Specific ways deflection hides an unresolved multi-step ticket:
Stopping at the answer instead of the action. The agent correctly explains what needs to happen ("you will need to verify your identity to unlock the account") and stops there. The customer understood the problem and still cannot use their account. Deflected; unresolved.
The half-finished chain. The agent verifies identity and pulls the transaction, then the dispute-filing step fails silently. The conversation ends, deflection is recorded, and a regulated action was left incomplete.
The premature close. The agent marks the ticket resolved when the customer stops replying, even though the underlying action never ran. Silence is read as success.
Channel hand-off as deflection. The chat "deflects" by telling the customer to call or email. One issue, counted as deflected once and as new volume once, finished zero times.
A worked example makes the gap concrete. Two AI agents each handle 1,000 multi-step tickets. Agent A deflects 820. On audit, 410 chains completed end to end and 410 stopped partway - identity verified but no dispute filed, account checked but never unlocked. Real end-to-end resolution: 41%. Agent B deflects 640. On audit, 590 chains completed and 50 escalated cleanly to a human after the agent hit a genuine policy edge. Real resolution: 59%. On a deflection scoreboard Agent A wins by 18 points. On finished problems Agent B is far ahead, and Agent A has generated 410 partial actions that will resurface as repeat contacts, complaints, and - because some of those half-finished chains touched money or records - compliance incidents. A team optimizing deflection buys the worse agent and the bigger liability.
This is why a half-completed action chain is often worse than no action at all. A dispute opened but never submitted, a refund promised in chat but never posted, an address updated but a linked record left stale - these are not neutral non-events. They are inconsistencies in systems of record that someone has to find and unwind, and in regulated industries they are the kind of thing that shows up in an audit.
The infrastructure that enables real resolution
Multi-step resolution is not a prompt or a model choice. It is an infrastructure problem, and the gap between a chatbot and an agent that resolves is the gap between retrieving text and safely operating your systems. Four layers do the work.
1. Integrations: the agent has to be able to act, not just read
An action chain only works if the agent can reach into the systems where the actions live - the helpdesk, the CRM, the payments processor, the core banking or claims platform - and write, not just read. "We integrate with Salesforce" can mean anything from reading a contact record to updating a case with the right fields. The distinction that matters for resolution is whether the integration is write-capable, scoped to least privilege, and reliable enough to be part of a chain where a failed call has consequences.
Read-only integrations cap an agent at answering questions about your systems. Write-capable, scoped integrations let it finish the job: post the credit, update the record, lock the card, schedule the callback. The depth of the integration layer is the ceiling on how much of a ticket the agent can actually resolve. Mature platforms reach the systems of record directly with least-privilege scoped tools and webhooks rather than relying on a thin read-only layer or brittle middleware.
2. Workflows: orchestration that holds state and recovers from failure
Chaining actions in the right order, carrying context between steps, and deciding what to do when a step fails is the orchestration problem, and it is where most "agents" reveal themselves as chatbots. A real resolution engine needs to branch (if the identity check is ambiguous, take a different path), hold state (remember the transaction it pulled three steps ago), and recover (retry, take an alternate route, or escalate cleanly rather than dropping the customer) when an external system errors mid-chain.
In practice this calls for two styles of workflow working together. Deterministic, structured workflows give you exact control over high-stakes sequences where the steps must run in a defined order - a regulated dispute filing, a KYC unlock. Natural-language workflows handle the open-ended reasoning a script cannot anticipate. The combination matters: pure decision trees are too rigid for the variety of real tickets, and pure free-form reasoning is too unpredictable for regulated actions. Lorikeet combines deterministic Structured Workflows with natural-language workflows in a single interaction, with all configuration written in plain English, so the rigid parts stay rigid and the flexible parts stay flexible.
3. Guardrails: making the actions safe to take
The moment an agent can take actions, the question stops being "can it answer" and becomes "will it do something it should not." Guardrails are what make a write-capable agent safe to deploy: dollar-threshold blocks, scripted disclosures, jurisdiction-specific rules, PII handling, and escalation triggers when a decision exceeds the agent's authority. Without them, multi-step capability is a liability rather than an asset.
The strongest approach is defence in depth, applied across the lifecycle rather than as a single runtime filter. Lorikeet runs adversarial simulations and red-teaming before launch, inbound message checks at runtime, outbound guardrails on what the agent is allowed to say and do, and 100% post-facto QA after the fact - the principle being that the language model is the engine and the platform is the cockpit. The value of testing the bad paths before go-live is that your compliance and operations teams can sign off on the agent's behavior in advance, rather than discovering an unsafe action after it has run against a real customer. Compliance features here support your obligations; they do not replace your own controls or certify any outcome on their own.
4. QA verification: proving the resolution actually happened
A multi-step chain that the agent believes it completed is not the same as one that actually completed. Verification is the layer that checks, independently, that the actions ran and the outcome meets the resolution definition - and it should not be the same system that did the work, because an agent grading its own resolution has an obvious incentive to report success. That self-grading is the single most common way a resolution number gets inflated.
Independent, automated QA closes that loop. Lorikeet pairs its customer-facing Concierge with Coach, an analytics and quality-assurance agent that performs automated QA, scores ticket quality, runs root-cause analysis, and verifies resolution - the AI evaluating the AI. Coach is deployable standalone at roughly $0.10 per ticket, including over the top of a human team or another vendor's agent, which means the verification layer does not have to come from the system that produced the answer. Reviewing 100% of tickets rather than the traditional 1-3% sample is what catches the rare half-finished chain in a regulated workflow, which is exactly the failure that a thin sample misses and an audit finds.
How channels change the resolution problem
Multi-step resolution gets harder, not easier, when the same issue spans channels. A customer who starts a dispute in chat, calls to add detail, and gets a confirmation by email is running one logical chain across three surfaces. If voice runs on a different stack than chat and they are bolted together with a transcript hand-off, the customer repeats themselves and the chain loses state at every boundary - two agents pretending to be one. Real resolution requires the same agent, with shared memory and the same workflow engine, across chat, email, voice, SMS, and WhatsApp.
Voice raises the bar further because latency is part of the experience: a multi-step action taken mid-call cannot stall the conversation while it waits on an API. Lorikeet runs voice with sub-second latency on the same workflow engine as its other channels, with outbound re-engagement (collections, abandonment) governed by the same guardrails - DNC, call-hour, and consent rules - so an outbound action chain respects the same controls as an inbound one. The point is not the channel count; it is that a resolution chain should not break when the customer switches surfaces.
Where deflection-oriented tools still fit
Deflection-first tools are not a scam; they are built for a different job. FAQ chatbots and self-service deflection layers - and the deflection-rate reporting in platforms like Zendesk AI, Ada, Fin by Intercom, and similar tools - do genuine work on high-volume, single-turn, informational queries. For "what are your hours," "how do I reset my password," or "where is my order," there is no chain to complete: avoiding a human and solving the problem are the same event, and deflection is a reasonable proxy for success.
The fit breaks down precisely where the ticket becomes multi-step. When a contact requires an action (move money, file a dispute, change a beneficiary, action a withdrawal), a sequence of dependent steps, or a regulated decision, "did it avoid a human" stops predicting "did it get finished." That is the band where deep integrations, stateful workflows, defence-in-depth guardrails, and independent QA earn their keep, and where Lorikeet is built to operate - complex and regulated support with the audit trail to back the resolution claim. An honest limitation: this infrastructure is heavier to stand up than dropping a deflection widget on a marketing site, and it is overkill if your volume is mostly simple informational queries. The trade is a number you can defend to a CFO or a regulator instead of one that only looks good on a slide.
A practical checklist for evaluating multi-step resolution
If you are assessing an AI support agent on whether it actually resolves rather than deflects, these questions surface the gap quickly:
Walk me through a real ticket that required five dependent actions end to end. Where did the agent write to a system of record, and where could it have stopped early?
What happens when an external system returns a 5xx mid-chain - retry, alternate path, clean escalation, or silent drop?
Which of your integrations are write-capable versus read-only, and how are they scoped?
How do you keep a high-stakes sequence deterministic while still handling the open-ended parts of the same ticket?
Can my compliance team review the guardrails and the bad-path behavior before go-live, not after?
Who verifies that a chain actually completed - the agent itself, or something independent - and on what share of tickets?
What is your resolution rate on the hardest 20% of multi-step ticket types, not the blended average?
The pattern across all seven: push past "did it avoid a human" to "did it finish the work, safely, provably." A vendor built for resolution will welcome the questions. A vendor selling deflection will steer you back to the headline number.
If you want an agent that finishes multi-step tickets end to end - with deep integrations, stateful workflows, defence-in-depth guardrails, and independent QA on every ticket - see how Lorikeet resolves rather than deflects.
Key takeaways
Deflection measures whether a human was avoided; multi-step resolution measures whether every dependent action a ticket required was completed and verified. They diverge most in complex support, where chains have many places to stop early.
A half-finished action chain - a dispute opened but not filed, a refund promised but not posted - counts as a deflection and behaves like an incident, especially in regulated workflows.
Real resolution depends on infrastructure: write-capable, scoped integrations for the actions; deterministic plus natural-language workflows for orchestration and error recovery; defence-in-depth guardrails for safety; and independent QA for verification.
Verification must be independent and broad - 100% automated QA rather than self-grading or a 1-3% sample - because the rare half-finished chain is the failure a thin sample misses and an audit finds.
Deflection-first tools fit single-turn, low-stakes queries; resolution-first infrastructure fits multi-step, regulated, action-taking support across chat, email, voice, SMS, and WhatsApp.
