AI customer support agents differ most in what happens after they understand a request. Explaining a refund policy is an answer; verifying the customer, checking the order, applying the policy, issuing the refund, recording the change, and escalating an exception is a resolution workflow. For teams comparing these systems, the useful dividing lines are resolution depth, action permissions, handoff quality, channel coverage, and the unit that determines cost.
Customer expectations now reflect that distinction. A 2026 Gartner survey of 3,566 B2B and B2C customers found that 58% of people who use generative AI had used it to complete a task on their behalf, rising to 74% in B2B settings. The same research found that 87% considered access to a human agent essential when a company uses generative AI for customer service. [Customer research]
This category therefore extends beyond general-purpose AI chatbot alternatives. A support agent must work with company knowledge, customer-specific data, business systems, permissions, escalation rules, and operational state. An assistant that can discuss an order is not automatically able to modify that order.
Table of Contents
The Resolution Ladder: How Far Can the Agent Actually Go?
“AI customer support” covers systems with very different operating limits. A practical comparison starts by identifying the highest level of work the agent can complete reliably, rather than counting how many AI features appear on a product page.
Level 1 — Knowledge Answer
The agent searches approved knowledge and explains a policy, troubleshooting step, product feature, return rule, or account process. It does not need customer-specific system access. This can reduce repetitive questions, but the customer may still have to complete the actual task elsewhere.
Level 2 — Contextual Resolution
The agent can read account, order, subscription, entitlement, delivery, or ticket data and tailor its answer to the individual customer. It may determine that an order has not shipped or that a plan lacks a requested feature, yet remain unable to change anything in the source system.
Level 3 — Single-System Action
The agent can perform a bounded write operation such as changing a shipping address, pausing a subscription, updating a customer record, creating a case, cancelling an eligible order, or beginning a refund. This is where permissions and confirmation rules start to matter as much as language quality.
Level 4 — Multi-Step Resolution
The agent coordinates several reads, decisions, and write operations in the required order. A damaged-order flow might verify identity, retrieve the order, check delivery status, collect the reason, evaluate policy, choose replacement or refund, execute the transaction, and update the support record.
Level 5 — Exception-Aware Resolution
The agent knows when autonomous processing should stop. It can recognize an approval threshold, unavailable tool, identity problem, failed transaction, policy exception, sensitive issue, or explicit request for a person and move the case to the right human queue without discarding work already completed.
A low handoff rate is not automatically a better result. An agent that autonomously handles routine requests but escalates ambiguous, high-value, or sensitive cases correctly can be safer and more useful than one that tries to contain every conversation.
AI Support Agents Compared by Resolution, Actions, and Handoffs
The products below overlap, but their natural operating environments differ. Some are closely tied to a support suite or CRM. Others are designed as an AI layer that connects to an existing helpdesk. Gorgias is unusually commerce-centered, while Salesforce Agentforce ties actions closely to Salesforce records, flows, and usage metering.
| Platform | Natural Fit | Resolution Model | Action Depth | Human Handoff | Billing Driver |
|---|---|---|---|---|---|
| Intercom Fin | Support teams wanting configurable AI across Intercom or another helpdesk | Answers plus Procedures for structured end-to-end work | Read/write connectors and multi-step Procedures | Configured handoffs plus default escalation behavior | Outcome-based |
| Zendesk AI Agents | Zendesk-centered support operations | Automated resolutions inside the Zendesk service environment | Actions in authorized systems | Escalation into human service workflows | Automated-resolution tiers |
| Ada | Enterprise CX needing configurable tools, Playbooks, and handoffs | Conversational reasoning combined with structured multi-step flows | API tools, code tools, and ordered processes | Configurable handoffs to several support systems | Commercial quote |
| Salesforce Agentforce | Organizations already centered on Salesforce data and automation | Agent actions grounded in CRM, knowledge, flows, and business logic | Record, prompt, flow, custom, and voice actions | Omni-Channel escalation paths | Flex Credits or other eligible usage models |
| Gorgias AI Agent | Shopify-focused ecommerce support | Support and shopping flows tied to commerce data | Multi-app actions with conditions and confirmations | Built-in and configurable handover rules | Resolved interactions plus helpdesk plan costs |
| Forethought Solve | Teams adding a resolution layer across existing support systems | Autoflows, actions, and omnichannel automation | API actions plus Browser Agent for systems without APIs | Human escalation within support operations | Quote-based plans |
| Decagon | Enterprise teams with complex service procedures and system integrations | Agent flows capable of transactional service work | Multi-step system actions and operational procedures | Context-rich handoff design | Per conversation or per resolution options |
| Sierra | Enterprise brands deploying customer-facing agents across channels | Agent OS with goals, business systems, controls, and monitoring | Business-system workflows configured around desired outcomes | Human transfer can remain part of the customer journey | Outcome-based |
Where the Eight Platforms Differ in Real Support Work
Intercom Fin: Procedures Push Beyond Answer Automation
Fin is a close match for teams that want knowledge answers and operational workflows managed through the same customer-service agent. Its Procedures system combines natural-language instructions with controlled steps, branching, rules, data access, and actions. Intercom describes Procedures as a way to resolve complex requests end to end rather than stopping after an answer. [Product documentation]
Data Connectors are the important operational layer. They can retrieve information from external systems and perform write operations; Intercom’s documentation uses examples such as sending a POST request to cancel a subscription. That makes the distinction between “Fin can see the account” and “Fin can change the account” explicit. [Data connector documentation]
Fin also supports configured handoffs inside Procedures and default escalation behavior. The latter can respond to cases such as an explicit request for a person, strong frustration, or a repetitive loop. This makes Fin worth examining when the purchase decision depends on both autonomous resolution and controlled exit paths rather than containment alone. [Handoff documentation]
Zendesk AI Agents: Resolution Is Tied Closely to the Service Suite
Zendesk AI Agents make the most immediate sense when Zendesk already holds the tickets, knowledge, routing rules, and human-agent workspace. Zendesk states that its AI agents can perform actions in authorized systems rather than functioning only as answer bots. Messaging and email are supported surfaces, while voice AI agent capabilities are separately managed in the product. [AI agent documentation]
One deployment detail deserves attention before assuming channel parity: each Zendesk AI agent is created for one channel type. Zendesk’s current setup documentation states that a single AI agent cannot, for example, interact with customers on both messaging and email. A team operating several channels should therefore examine configuration and reporting across multiple agents, not merely confirm that the product supports those channels somewhere in the suite. [Channel setup]
Ada: API Tools, Playbooks, and Handoffs Are Separate Control Layers
Ada is structured around distinct pieces for system access and conversational procedure. Its documented Actions model uses API calls to retrieve or process information, while Processes link multiple actions in an ordered workflow and Playbooks guide multi-step customer interactions. This separation is useful when support operations need a clear distinction between a tool call and the larger procedure in which that call is allowed. [Product concepts]
Ada’s terminology has also moved recently. In August 2026 it renamed Actions to API tools and added a Tools API covering API and code tools. Code tools can call an endpoint and run sandboxed Python on the result before the agent uses it. This matters for teams comparing current implementations against older documentation that still refers to “Actions.” [Release notes]
Handoffs are treated as explicit destinations rather than an afterthought. Ada documents connections to systems including Salesforce, Zendesk, Amazon Connect, ServiceNow, Genesys, Gorgias, Help Scout, Kustomer, Twilio Flex, and Gladly, with configuration varying by destination. [Handoff documentation]
Salesforce Agentforce: Action Metering Is Part of the Product Decision
Agentforce is especially relevant when customer records, cases, entitlements, service data, automation, and approvals already live in Salesforce. The product can meter individual actions such as a record update, case summary, product inquiry, custom prompt, or flow execution. That creates a different economic model from platforms that charge only when an entire conversation is considered resolved.
Salesforce currently lists Flex Credits at $500 per 100,000 credits. Standard Agentforce actions consume 20 Flex Credits, while Agentforce Voice actions consume 30; Salesforce also lists conversation-based and resolution-based options for eligible use cases. Because one customer request can invoke several actions, the number of actions per completed case belongs in any cost model. [Official pricing]
Salesforce also supports escalation through service routing rather than treating human transfer as an unrelated channel. Organizations already using Omni-Channel should examine which agent configurations can transfer to representatives or queues and what happens when no eligible human destination is available. [Escalation documentation]
Gorgias AI Agent: Commerce Actions Are the Main Differentiator
Gorgias has the clearest specialization in this group. Its AI Agent is designed around ecommerce service rather than a broad collection of enterprise processes. Actions can cover tasks such as cancelling an order, pausing a subscription, or changing a shipping address. A single action can also span more than one connected application and execute steps in sequence. [Action documentation]
Confirmation controls are particularly relevant for transactional work. Gorgias allows customer confirmation to be enabled for actions and automatically requires confirmation for certain irreversible operations. That makes it easier to separate a low-risk lookup from a state-changing action that should not happen silently.
The commerce focus also creates a scope limitation worth checking early. Gorgias documents AI Agent on Chat as requiring Shopify and states that this Chat setup is not supported for BigCommerce, Magento, or WooCommerce. A retailer outside Shopify should verify the exact channel and integration combination before treating the product as a platform-neutral choice. [Platform support]
Forethought Solve: API Actions and Browser Automation Cover Different Back Ends
Forethought Solve combines conversational support with Autoflows and Custom Actions, making it suitable for teams that want AI to execute service procedures without replacing the surrounding helpdesk. The less common capability is Browser Agent, which Forethought says can log into systems, click, type, and complete tasks in internal tools that do not expose suitable APIs.
That browser-based option can matter when a company has older portals or internal systems that cannot easily be connected through an API. It also makes testing more demanding: a browser workflow can fail because of changed page state, authentication, interface changes, or unexpected intermediate screens, so success should be judged on completed business state rather than the agent merely reaching the correct page.
Forethought currently presents Team, Professional, and Enterprise packages through a quote process rather than a simple public per-agent price. Channel availability and capabilities differ among those packages, so an evaluation should match the intended deployment rather than treating “Solve” as one identical configuration. [Official pricing]
Decagon: Transactional Work and Handoff Context Belong Together
Decagon targets customer-facing agents that can move beyond retrieval into transactions. Its own product material describes service actions such as refunds, returns, subscription changes, account changes, and appointment scheduling, with operational procedures governing how those tasks are handled. [Product capabilities]
Its handoff model also illustrates what buyers should ask every vendor to preserve. Decagon describes a handoff package containing information such as a summary, intent, customer account data, and actions already taken. That is much more useful than a transfer event that simply moves the transcript to another queue. [Handoff documentation]
Sierra: Outcome Pricing Puts the Definition of Success in the Contract
Sierra’s Agent OS is aimed at enterprise customer-facing agents, with business-system integrations, goals, controls, testing, monitoring, and cross-channel deployment forming part of the product. Sierra lists chat, SMS, WhatsApp, email, voice, and ChatGPT among customer interaction surfaces. [Channel information]
Sierra uses outcome-based pricing and states that customers pay when the software achieves agreed valuable outcomes. That can align spending with completed work, but it makes the contractual definition of an outcome especially important. A password-reset outcome, completed payment, appointment change, resolved billing question, and human-assisted case may have different business value even if each begins as one conversation.
A published R1 customer case also shows why voice resolution should be examined separately from chat. The deployment includes voice interactions, payment-related work, and transfer to human staff when needed rather than treating voice as a text bot with speech added. [Customer deployment]
Human Handoff Is Part of the Resolution Design
A support agent should not be evaluated by autonomous resolution alone. Some conversations should reach a person, and the quality of that transfer determines whether the AI saved work or merely inserted another step before the human agent.
Useful Handoff Triggers Go Beyond “Customer Asked for a Human”
- Explicit human request: the customer directly asks for a representative.
- Repeated failed attempts: the conversation loops or the agent cannot make progress.
- Low-confidence or unsupported request: the agent lacks enough knowledge or system access to finish safely.
- Transaction failure: an API, browser action, payment operation, or downstream update does not complete as expected.
- Approval threshold: the requested refund, credit, cancellation, or account change exceeds autonomous authority.
- Identity or authorization issue: the agent cannot establish that the requester is allowed to perform the action.
- Sensitive or specialist case: suspected fraud, legal disputes, unusual billing disagreements, or other queues that require trained human handling.
- Customer frustration: the interaction has become unproductive even though the original issue might normally be automated.
Gorgias, for example, documents handover behavior for anger or frustration, explicit human requests, sensitive topics, configured handover topics, and cases where a reliable answer cannot be produced. Its behavior also varies by channel; chat may seek confirmation before handing over in some cases, while email and SMS follow different interaction patterns. [Handover documentation]
A Warm Handoff Should Carry the Work Already Done
Cold Handoff
The AI says the customer will be transferred. The human agent receives little more than the transcript, then asks the customer to explain the problem again and repeats lookups the AI already performed.
Warm Handoff
The human receives the customer’s intent, verified identity state, relevant account or order data, a concise summary, actions already attempted, actions completed, the reason automation stopped, and what remains unresolved.
What the Handoff Packet Should Preserve
- Customer identity and verification state
- Detected intent and requested outcome
- Conversation summary and accessible transcript
- Relevant account, order, subscription, or service context
- Policy or eligibility checks already performed
- Actions attempted and actions successfully completed
- Failed tool calls or incomplete transactions
- Reason for escalation
- Any approval or specialist decision still required
The handoff should also avoid making a human undo AI work simply to understand state. If the AI already cancelled a shipment but failed while issuing a refund, “refund failed after cancellation” is operationally different from “customer wants to cancel.” That distinction must survive the transfer.
Read Access, Write Access, and Transaction Control Are Different Capabilities
Integration counts are a weak proxy for resolution capability. A vendor may connect to a billing, commerce, CRM, or subscription system while exposing only a small set of read operations. Buyers need to know what the agent can do through each connection.
| Access Level | Typical Operations | Customer Outcome | Control Needed |
|---|---|---|---|
| Read | Retrieve order, account, delivery, subscription, entitlement, or ticket data | Agent can personalize an answer | Identity, data scope, privacy |
| Write | Update address, create case, pause plan, cancel order, alter record | Agent changes business state | Authorization, validation, confirmation |
| Transactional workflow | Coordinate several reads, rules, writes, and downstream systems | Agent can finish a multi-step request | Ordering, retries, rollback handling, approval boundaries, final verification |
The Duplicate-Action Problem Appears After a Tool Call Times Out
Suppose a customer asks to cancel an order. The AI sends the cancellation request, but the API response times out. The agent cannot tell whether the remote system rejected the request or accepted it and merely failed to return the confirmation. Retrying blindly can create duplicate side effects in systems where the operation is not safely repeatable.
A production evaluation should therefore ask what happens when a state-changing call returns an ambiguous result. Depending on the operation, the system may need an idempotency mechanism, a follow-up status read, a transaction identifier, or a rule that stops automation and escalates rather than retrying.
“The tool call succeeded” is not the final test. The support agent should verify the resulting business state before telling the customer that a cancellation, refund, payment, booking, or account update is complete.
Confirmation Should Depend on Action Risk
Requiring confirmation before every tool call creates unnecessary friction. Never requiring it creates a different problem. A useful action policy distinguishes low-risk reads from reversible edits and from actions with financial or account consequences.
| Request | Typical Control | Why |
|---|---|---|
| Check delivery status | Authenticated read | No business state changes |
| Update contact preference | Validation, then write | Usually reversible |
| Change shipping address | Eligibility check and customer confirmation | Can affect fulfillment |
| Pause subscription | Policy check and confirmation | Changes billing or service state |
| Issue routine refund under an approved threshold | Identity, policy, transaction verification | Financial action |
| High-value refund or disputed ownership | Human approval or specialist handoff | Higher financial or authorization risk |
Resolution Metrics and Pricing Can Describe Different Things
A reported “resolution rate” is not useful until its denominator and success rule are known. One platform may calculate resolutions only among conversations where the AI meaningfully participated. Another may report automation across all incoming support contacts. A third may wait for a no-reply period or run a verification step before assigning a resolution status.
Do Not Treat Conversation Closure as Proof of Resolution
Zendesk’s 2026 automated-resolution model shows how nuanced this can become. Its documentation separates assisted escalation, contained resolution, and verified resolution. It also describes a 72-hour no-follow-up window followed by an LLM-based verification process for contained and verified outcomes. Assisted escalations do not count against the resolution allowance because a human ultimately resolves the issue. [Resolution methodology]
A buyer comparing vendor percentages should ask for the operational definition behind each number. Otherwise, an 80% result from one platform may describe something materially different from an 80% result from another.
| Metric | What It Tests | Failure It Can Reveal |
|---|---|---|
| AI involvement rate | How much incoming work reaches the AI | A high resolution percentage on only a narrow slice of contacts |
| Autonomous resolution rate | How many eligible conversations finish without human completion | Low containment despite broad AI deployment |
| Action success rate | Whether requested system operations finish correctly | Good conversation quality hiding failed transactions |
| Handoff rate | How often humans take over | Automation boundaries that are too narrow or too broad |
| Reopen rate | Whether supposedly resolved cases return | False resolution |
| Repeat contact rate | Whether the customer contacts support again about the same outcome | Silent dissatisfaction or incomplete work |
| Human override rate | How often staff reverse or correct AI work | Poor action decisions even when technical execution succeeds |
| Handoff rework | How much information the human has to recollect or redo | Cold transfers that inflate agent workload |
Billing Has Moved Closer to Resolutions, Outcomes, and Actions
The billing unit can change which platform is cheaper even when two agents automate the same number of support contacts. A long conversation with one completed outcome behaves differently under per-conversation pricing than a short request that triggers five individually metered actions.
| Billing Unit | What Drives Spend | What to Verify |
|---|---|---|
| Resolved interaction | Number of conversations the AI completes | Exactly what qualifies as resolved |
| Outcome | Number and type of agreed completed outcomes | Which outcome classes are chargeable |
| Action | Tool or business operations executed | Actions per typical customer request |
| Conversation | Customer interactions handled | Conversation boundaries, resets, and handoffs |
| Platform plus usage | Base service plus AI volume | Included allowances and overage rates |
| Commercial quote | Negotiated scope and usage assumptions | Volume commitments, channels, deployment, and outcome definitions |
Intercom currently charges eligible Fin outcomes rather than simply billing every message. Its documented outcome model lists $0.99 for a resolution and $0.99 for a Procedure handoff in supported chat and email scenarios when Fin is used with Intercom; other outcome types and deployment arrangements can differ. [Official pricing]
Gorgias also prices AI Agent around resolved interactions. Its published pricing material states that most plans are $0.90 per resolved interaction, with Starter plans beginning at $1, while included volume and overage rates depend on tier and billing arrangement. [Official pricing]
Decagon says it supports both per-conversation and per-resolution pricing and notes that customer contracts can use different models. Sierra takes an outcome-based approach. These models should be compared using the same real ticket distribution rather than a headline unit price alone. [Pricing model]
Which Requests Should the AI Resolve Without a Human?
Automation suitability depends on more than how common a request is. Structured inputs, reliable system access, reversible actions, clear policy rules, and low ambiguity generally make autonomous resolution easier. Financial exposure, disputed identity, policy exceptions, and specialist judgment move the boundary in the other direction.
| Support Request | Autonomous Fit | Main Requirement | Typical Escape Condition |
|---|---|---|---|
| Order status | High | Reliable authenticated read access | Missing or conflicting shipment data |
| Standard account lookup | High | Identity and account retrieval | Ownership cannot be verified |
| Shipping address change | High when eligible | Fulfillment-state check plus write permission | Order already locked or shipped |
| Subscription pause | High when policy is explicit | Plan rules and customer confirmation | Unsupported subscription state |
| Routine refund | Medium to high | Eligibility, amount threshold, transaction verification | Policy exception or amount exceeds authority |
| Damaged-order claim | Medium | Evidence collection and clear remedy rules | Evidence or policy is ambiguous |
| Complex technical incident | Variable | Diagnostic access and bounded remediation | Root cause remains uncertain |
| Billing dispute | Lower | Transaction history and dispute policy | Customer contests liability or amount |
| Suspected fraud or account takeover | Low | Specialist controls | Route to protected human process |
| Legal or regulatory complaint | Low | Specialist handling rules | Human review |
The same request can also move between categories. A $20 refund for an unopened item inside a clear return window may be deterministic. A $2,000 refund involving disputed delivery and several prior credits is not the same automation problem even though both tickets contain the word “refund.”
Run Failure Tests, Not Just Happy-Path Demos
A vendor demonstration that answers “Where is my order?” proves little about action safety, state recovery, or handoff quality. A useful pilot sends each shortlisted platform through the same controlled cases and records the resulting system state.
- Knowledge-only request: confirm that the agent answers from approved information and does not invent account state.
- Authenticated lookup: check whether it retrieves the correct customer-specific record.
- Single write action: update a reversible field and verify the final value in the source system.
- Multi-step resolution: require several reads, a policy decision, and one or more write actions.
- Customer changes direction: change the requested outcome midway through the workflow and check whether stale actions are avoided.
- Tool returns an error: determine whether the agent retries, checks state, asks for help, or incorrectly claims success.
- Ambiguous timeout: test whether a possibly successful write is duplicated.
- Human request: ask for a person at different stages and measure how quickly the exit path works.
- Policy boundary: exceed a refund, credit, or permission threshold and confirm that the agent does not bypass it.
- Warm handoff: inspect exactly what the receiving human sees and whether any lookup or explanation has to be repeated.
Teams building a formal test program can use AI evaluation platforms to inspect tool selection, arguments, retries, traces, and final outcomes. For customer-support agents, the most useful test result is usually not a language score. It is whether the intended business state was reached without an unauthorized or duplicated action.
Channel Parity Needs Its Own Test
“Omnichannel” does not guarantee identical automation on chat, email, voice, SMS, or messaging apps. Authentication methods can differ. A confirmation step that works naturally in chat may require another design over voice. Human availability, transcript transfer, attachments, session state, and action support can also vary by channel.
Run the same high-value workflow on every channel that will enter production. If address changes work on chat but voice can only answer questions and transfer, the product still supports both channels, but it does not provide the same resolution depth on both.
Choose by Support Architecture and the Work You Want Automated
There is no useful universal ranking for this category because the surrounding support stack changes the answer. A platform that fits a Salesforce-heavy service organization may add unnecessary complexity to a smaller Shopify store, while a commerce-specialized agent may be too narrow for an enterprise with several internal account systems.
| If Your Priority Is… | Start by Examining… | Verify Before Buying |
|---|---|---|
| Configurable support automation across Intercom or another helpdesk | Intercom Fin | Procedure coverage, connector permissions, handoff behavior, chargeable outcomes |
| AI inside an established Zendesk operation | Zendesk AI Agents | Channel-specific agent setup, resolution tiers, action integrations |
| Enterprise Playbooks with configurable external tools and handoffs | Ada | Tool permissions, Playbook design, destination-specific handoff behavior |
| CRM-native service actions and Salesforce automation | Salesforce Agentforce | Actions per use case, Flex Credit consumption, Omni-Channel escalation |
| Shopify commerce actions such as order and subscription changes | Gorgias AI Agent | Store/platform eligibility, irreversible-action controls, interaction volume |
| Existing support stack plus workflows in systems with weak API coverage | Forethought Solve | Custom Action coverage, Browser Agent reliability, package-level channel support |
| Complex enterprise service flows and transactional customer work | Decagon | Procedure design, integration effort, handoff packet, pricing unit |
| Enterprise customer agent deployment with outcome-based commercial terms | Sierra | Outcome definitions, channel-specific workflows, human transfer, system integrations |
The strongest shortlist starts with the support request, not the model. Identify which requests should be answered, which should read account data, which should change business state, which require several systems, and which must reach a person. Then compare how each platform handles those exact boundaries.
For a knowledge-heavy support operation, answer quality and retrieval may carry most of the value. Once the goal includes refunds, cancellations, subscription changes, bookings, payments, entitlement changes, or account updates, the selection criteria shift toward permissions, transaction verification, action ordering, auditability, and recovery from partial failure.
Human support remains part of that design. A useful agent should complete the requests it is authorized to complete, stop when it reaches a real boundary, and transfer enough context that the next agent—human or automated—can continue from the current state rather than starting the case again.