2026-09-15

Choosing an AI customer service chatbot: an enterprise comparison guide

How should you choose an AI customer service chatbot? This article covers knowledge base quality, ticket execution, human handoff, deployment pilots, cost accounting, and contract acceptance to help enterprises build a rigorous selection and evaluation method.

1. Establish a selection baseline: define requirements by real inquiry volume and business difficulty

The first step in selection is not scheduling vendor demos but building a reproducible business baseline. Without a baseline, products can only be compared on feature counts and demo polish; with one, you can determine how much human work a chatbot actually removes and whether it genuinely resolves issues.

We recommend sampling from recent online chats, call summaries, and customer service tickets. The sample should span weekdays and holidays, peak and off-peak periods, new and existing customers, and different channels, rather than drawing on a single day or a single team. After sampling, don't just classify by department; stratify by handling difficulty:

For each tier, measure inquiry volume, current first-contact resolution rate, average handling time, and the corresponding labor cost. Labor cost cannot be calculated simply as agent salary divided by working hours; it must also include review, escalation, cross-department communication, and supervisor involvement. For issues that require multiple back-and-forth exchanges, record the full lifecycle rather than only the duration of the first conversation.

The first round of validation doesn't need to load all knowledge materials; you can build a minimal knowledge set from high-frequency questions. But the test set must be kept separate from the configuration materials and should deliberately include paraphrases, colloquial expressions, typos, missing key information, mixed intents, and rule exceptions. Standard phrasings only prove that a system can repeat preset answers, not that it can handle real customer input. You should also hold back a set of blind-test conversations the vendor has not seen in advance, to prevent tuning to the test questions during the demo phase.

All candidate solutions must be measured against the same acceptance criteria:

• AI independent resolution rate: The share of conversations in which the customer's goal was achieved without any human input.
• Human handoff rate: The share of conversations that enter the human queue, broken down into proactive escalation, recognition failure, and process limitations.
• First response time: The time from when a customer starts an inquiry to when they receive a useful response, excluding greeting messages.
• Wrong answer rate: The share of factual errors, misapplied rules, unsupported inferences, and incorrect operations.
• Ticket closure rate: The share of tickets that have been fully processed with results returned, not merely created successfully.
• Agent hours saved: The actual reduction in working hours after deducting knowledge maintenance, exception review, and handoff handling.
• Customer satisfaction: Compare changes before and after the pilot by scenario, cross-checked against complaints and repeat inquiries.

Response rate and AI participation rate are no substitute for resolution rate. A chatbot sending a message, or generating a suggestion during a conversation, does not mean the customer's problem has been solved. Acceptance should work backward from business outcomes: Was the order successfully modified? Was the refund completed? Was the ticket closed? Did the customer need to get in touch again?

Targets should also be set separately by difficulty. For high-frequency issues with stable rules, clear paths, and complete system interfaces, you can require automated execution through to closure. For complaints, exception approvals, and inquiries with insufficient information, a more reasonable goal is to support human judgment, organize the context, and hand off safely. Any solution that promises full automation without distinguishing between scenarios should be required to explain its failure boundaries, risk liability, and the cost of human fallback. The resulting baseline table should serve simultaneously as the pilot dataset, the scoring basis, and a contract acceptance appendix, so that the same criteria apply before and after procurement.

2. Comparing knowledge bases: not how many documents are imported, but whether answers stay usable

Knowledge base selection is where demos are most misleading. Document import speed, supported file formats, and page counts only show that materials can get into the system; they do not prove that answers will be reliable in customer service scenarios. What really needs comparing is whether, faced with the varied ways real users phrase things, the system can find the right knowledge, give a constrained answer, and promptly stop using old versions after content changes.

Blind-test with the same set of historical questions

Extract high-frequency questions, complaint-related questions, and error-prone questions from past customer service conversations, strip out the original answers, and hand them to each candidate system for testing. Don't let vendors tune to the questions in advance, and don't test only standard phrasings. For each business intent, prepare at least a direct question, a colloquial version, a version with typos, and a version with the subject omitted, and add follow-up questions and cross-turn references. For example, first ask about the refund policy, then follow up with "What about orders that have already shipped?"

Record test results separately. Hitting the right material does not mean the answer is correct, and a fluent answer does not mean the citations are sufficient. For information that cannot be confirmed, the right behavior is to state what conditions are missing, ask for more information, or hand off to a human, not to stitch together a conclusion that merely looks complete.

Verify that knowledge updates are genuinely operable

A knowledge base keeps changing after launch, so have business staff complete an addition, review, publication, retirement, and rollback on the spot. Pay close attention to whether these operations depend on the vendor or a technical team, and whether the system records content sources, editors, version diffs, effective dates, and approval records. If a policy can be published but its expiry scope cannot be set, old answers will sooner or later make their way back into retrieval results.

Maintenance hours should also be factored into procurement costs. Record how much time the business team spends each week organizing materials, resolving conflicts, reviewing answers, and publishing updates, and convert it at actual labor cost. A system with good initial results that requires manually splitting documents and repeated tuning for every change may cost more per year than a solution with higher license fees but a complete maintenance process.

Distinguish knowledge answers from business data queries

Document knowledge is suited to answering relatively stable rules, such as service scope, documentation requirements, and return and exchange conditions. Order status, contract entitlements, membership tiers, account balances, and transaction progress, by contrast, depend on the current user's identity and real-time business data. Such questions cannot be solved by a knowledge base alone; you must verify that the system can read context from order, CRM, ticketing, or transaction systems within its authorized scope.

During evaluation, separate "explained the rule correctly" from "solved the problem." Even if a chatbot accurately explains delivery times, it cannot say why a package is stuck if it can't see that customer's order milestones. The selection sheet should specify which questions are covered by static knowledge, which must call business data, and how the system degrades when data is missing, interfaces time out, or permissions are insufficient.

Judge long-term performance by how fast knowledge gaps are closed

A single blind test only establishes a launch baseline; it does not represent ongoing performance. After launch, review the questions most often handed off to humans each week and determine whether the cause is missing material, retrieval failure, incomplete answer rules, or a need for business system execution. Review low-rated and erroneous conversations monthly, recording the full cycle of issue discovery, owner confirmation, knowledge revision, retesting, and official release.

• Require candidates to provide exportable erroneous conversations, hit sources, and version records, rather than only aggregate scores.
• Assign each knowledge gap an owner, a deadline, and retest samples; after revision, run regression tests with the original question and its variants.
• Ultimately compare not just initial accuracy, but also how efficiently issues are located, how long content updates take, and whether similar errors recur.

The selection conclusion on knowledge base capability should rest on verifiable operational results: whether real-world phrasings consistently hit the right knowledge, whether answers are traceable to sources, whether expired material is retired promptly, and whether the business team can keep making corrections at an acceptable maintenance cost. Only when these conditions hold can the high-quality answers seen in a demo carry over into production.

3. Comparing ticketing and business execution: verify that the chatbot can get things done

Fluent answers in a demo do not mean less human work after launch. When selecting, change the unit of testing from "single-turn Q&A" to "complete business task": after a customer makes a request, the chatbot needs to verify identity, read business data, determine the applicable handling rules, create or modify a ticket, call backend interfaces, and feed a clear result back to the customer. Merely generating suggested actions, or turning the issue into more polite wording, is still assisted response and does not count as independent resolution.

Pilot tasks should be drawn from recent real inquiries and retain the missing information, abnormal states, and permission restrictions of normal business. For example, when testing a refund request, don't just observe whether the chatbot can explain the policy; verify whether it identifies the customer and the order, checks refund eligibility, submits the request, fills in the reason field, updates the ticket status, and notifies the customer once processing succeeds or fails. For issues that are processed asynchronously, keep tracking subsequent status; acceptance cannot stop at "Your request has been submitted."

These metrics must use a common denominator and distinguish business failures from technical failures. Unavailable interfaces, expired authentication, and failed field validation should not be dressed up as "handed off to a human." Likewise, successfully creating a ticket does not mean the issue has been resolved. Only when the customer receives a resolution, or a verifiable business state has actually changed, can a case count as independent resolution; tasks still waiting for humans to continue data entry, review, or reply should be classified as collaborative handling.

Also check whether tickets stay continuous across channels. Testers can have the same customer inquire via the web first and then follow up by phone, email, or social channels, observing whether the system can merge identities, carry over context, sync processing status, and record every action taken by the chatbot and by humans. If switching channels generates duplicate tickets, or agents still have to copy customer details and chat summaries, the value of automation will be offset by back-office data entry. Operation trails should also include call time, input parameters, returned results, status changes, and failure reasons for audit and troubleshooting.

Finally, business fit should outweigh the length of the feature list. E-commerce teams should focus on verifying order detail retrieval, logistics tracking, return and exchange eligibility checks, and after-sales ticket creation; teams built around a CRM system should test contact identification, deal stage lookups, links to past communications, and updates to existing tickets. A solution with many interfaces that cannot correctly understand your company's data structures is usually inferior to one that covers the key processes with clear field mappings.

• Require candidates to complete testing with the same set of de-identified data, the same permissions, and a fixed time limit.
• Include normal tasks as well as tasks with missing information, duplicate submissions, interface timeouts, and insufficient permissions.
• Have business staff verify outcomes, technical staff inspect call logs, and customer service supervisors confirm that routing and escalation are reasonable.
• Keep evidence for each task in the acceptance report, and do not accept demos that only show preset success paths.

The final judgment at this stage is straightforward: did the chatbot bring about the correct change in the business object, and did the customer receive a traceable result? If the answer is no, then however natural the conversation feels, it can only be considered a response tool, not a business execution system capable of running customer service processes.

4. Comparing human handoff: judge by handoff loss, not by "supports transfer to a human"

Almost every customer service system offers a way to reach a human. What really sets them apart is when the handoff triggers, whether the handoff information is complete, and how much extra work the human has to do after taking over. When selecting, don't just check whether there is a "Talk to a human" button on the page; break a handoff down into its stages: triggering, queuing, context transfer, human handling, and audit trail.

First verify that it hands off immediately when it should

The pilot should trigger handoffs with real business language, not by following the vendor's prepared demo script. At a minimum, cover the following situations:

• The customer explicitly asks for a human, including colloquial, emotional, or multi-turn requests;
• The model has low confidence and cannot confirm the customer's intent or the basis for its answer;
• Content that requires careful handling appears, such as complaints, refund disputes, or privacy requests;
• External interfaces for orders, payments, logistics, and the like return errors, so the business action cannot proceed;
• The conversation exceeds the set time or number of turns without producing a useful result.

The focus of acceptance is whether these rules take effect reliably. Once a mandatory handoff condition is met, the chatbot should not keep reciting boilerplate, asking for clarification again, or trying to retain the customer. Enterprises should also confirm whether different strategies can be configured for different queues, business hours, customer tiers, and risk categories. When no agents are online, the system should clearly tell the customer what happens next and keep a pending item, rather than marking the conversation as resolved.

Check whether agents receive a "task package" or just a chat log

A complete handoff cannot simply push the last few messages to a human. At a minimum, the agent interface should show the customer's identity and permission status, the full conversation, the current intent assessment, business data already retrieved, actions the chatbot has performed, and any unfinished steps with their corresponding errors. For actions such as refunds or rebookings, it should also indicate which operations have already been submitted, so the human does not repeat them.

A direct test is to observe the first questions the agent asks after taking over. If the human still has to ask again for the order number, issue type, customer request, or earlier handling results, then although context was passed along, the information did not become an actionable state. The more repeated questions there are, the worse the customer experience, and the more easily the hours saved by AI are offset by follow-up communication.

Measure real benefits by the workload after handoff

Evaluation data cannot stop at the "human handoff rate." Fewer handoffs are not necessarily better; they may also mean the chatbot failed to step aside in time. We recommend recording the following metrics together:

• Human escalation rate: Of the conversations that enter the chatbot, the share ultimately taken over by an agent, broken down by trigger reason;
• Handoff wait time: The time from triggering escalation to the agent's actual response;
• Information repetition rate: The share of conversations in which, after transfer, the human asks again for information the chatbot already obtained;
• Remaining human handling time: The handling time from when the agent takes over until the issue is closed;
• Reassignment rate: The share of conversations that, after entering the human queue, are transferred to someone else again because of a wrong skill group or insufficient information.

The agent hours actually saved by AI should be calculated as the purely human baseline handling time for the same type of issue, minus the human handling time after AI involvement, less the time consumed by review, error correction, queue switching, and repeated communication. This result should be calculated separately by issue type. The handoff cost of a logistics inquiry is clearly different from that of a complaint dispute, and blending them into one average masks the extra burden in high-risk scenarios.

Include audit capability in handoff acceptance

Every escalation should leave a queryable chain of events: which knowledge content the chatbot cited, which business systems it read from or wrote to, what rule it used to decide on a handoff, what the interfaces returned, and whether the agent modified or overrode the machine's suggestion. Logs should also include time, operator, version, and key inputs and outputs, and support replay by conversation.

Responsibility boundaries also need to be spelled out at the procurement stage. When a chatbot gives a wrong suggestion, a business interface fails during execution, or a dispute arises after an agent uses a machine-generated draft, who reviews it, who handles it, and who keeps the evidence cannot be left for discussion after launch. The final judgment is simple: prioritize systems that step aside promptly when risk arises, hand the complete task state to a human, and leave a record of every step, rather than simply chasing a lower handoff number.

5. Comparing deployment: turn vendor promises into a time-boxed, data-scoped pilot acceptance

Deployment speed cannot be judged from a product demo. Registering an account, importing a few documents, and generating a conversation only prove that the system runs. Being production-ready also requires identity and permission setup, historical data processing, ticket rule configuration, integration testing with business systems, compliance checks, exception rollback, and staff training. In selection, replace "how long until it's activated" with "how long until it runs stably within a defined business scope."

All candidate products should work from the same pilot brief. The enterprise provides the same knowledge materials, historical inquiry samples, interface specifications, and target processes; vendors may not narrow the scope on their own, nor should they use pre-processed demo data. The pilot is best limited by channel, business line, and data volume, which both controls investment and makes side-by-side comparison easier.

SMBs without dedicated IT staff should run an additional "vendor-independence test": business staff independently add knowledge, adjust Q&A rules, modify routing nodes, and review failure records, while the vendor only observes and does not operate on their behalf. If routine changes still require submitting an implementation ticket, ongoing costs go beyond the subscription fee to include waiting time, external service fees, and lost business responsiveness. When basic deployment clearly exceeds the enterprise's planned window, break down whether the delay comes from data quality, internal approvals, system interfaces, or product limitations before deciding whether additional implementation investment is justified.

Acceptance also cannot look only at whether the system returns answers. The enterprise should agree in advance on test samples, pass conditions, and failure categories: for example, whether permissions are correct, whether ticket fields are complete, whether the system can recover from interface exceptions, whether human handoff carries context, and whether sensitive data is handled according to the rules. Results corrected manually during testing must be flagged separately; otherwise, the implementation team's ability to patch things up is easily mistaken for product capability.

The contract should turn pilot conclusions into enforceable clauses covering at least the following:

• Clearly define the acceptance scope, test methods, pass thresholds, and re-test rules;
• Agree on import and export formats for historical data and knowledge assets, and on migration responsibilities;
• Specify who is responsible for knowledge maintenance, runtime monitoring, and business reviews after launch;
• Define severity levels, response times, recovery requirements, and escalation contacts;
• Distinguish responsibility boundaries for model adjustments, prompt strategy optimization, process redesign, and new development;
• Spell out the remediation deadline, cost allocation, data return, and termination and exit mechanism if targets are not met.

Ultimately, the comparison is not about whose demo is fastest, but about which vendor, given the same inputs and constraints, completes production delivery with less human intervention in a way the enterprise can continue to maintain on its own. Only when deployment is broken down into tasks that can be timed, reproduced, and held accountable does the delivery timeline carry any weight in selection.

6. Comparing costs: normalize to the true cost per resolution and annual total cost of ownership

Unit prices on a quote cannot be compared directly. Different vendors may charge per conversation, per successful resolution, per seat, or by tiered usage. For the same inquiry, some platforms bill as soon as the chatbot replies, while others charge only when the issue is independently resolved. Enterprises should first normalize the cost basis and then compare quotes.

First calculate the true cost per resolution

For example, if a solution charges P per conversation and its independent resolution rate during the pilot is R, the true cost per resolution is P÷R. When the resolution rate drops, cost rises nonlinearly: the enterprise not only pays the chatbot conversation fees but also bears the cost of subsequent human handling. Therefore, vendor demo data or industry averages can only be used for initial screening; the final calculation must use the actual resolution rate from the enterprise's own pilot.

Here, "independent resolution" should be defined by the enterprise rather than taken at face value from the billing system's status. A chatbot running a process and then handing off to a human, a customer who stops replying, or a conversation that closes on timeout does not necessarily mean the issue has been resolved. The contract appendix should specify the criteria, the observation window, the rules for merging repeat inquiries, and whether an existing resolution record is revoked when the customer follows up. Otherwise, what looks like pay-for-results may still bill for completed processes or closed conversations.

Then calculate annual total cost of ownership

An annual budget cannot simply multiply the AI unit price by inquiry volume. At a minimum, the following items should go into the same cost sheet:

• Base customer service platform, accounts, and seat licenses;
• Model calls, chatbot conversation fees, or resolution fees;
• Ticket management, voice calls, outbound calling, and advanced analytics modules;
• Audit, security, data residency, and industry compliance add-ons;
• Interface development, identity authentication, data migration, and system maintenance;
• Knowledge curation, content review, performance evaluation, and ongoing operations;
• Costs of human handling, review, and escalation for unresolved inquiries.

Of these, platform and seat add-on fees are often higher than expected. Publicly available industry pricing generally indicates that for a 10-person customer service team, software licenses alone can amount to a fixed monthly expense of several hundred to over a thousand dollars. However, this varies considerably by edition, region, and contract term, so rely on the formal quote the enterprise actually receives.

We recommend producing two metrics side by side. The first is the chatbot's true cost per resolution, for comparing automation efficiency. The second is the end-to-end cost per resolution, that is, annual total cost of ownership divided by the total number of final resolutions for the year, for judging overall business value. The latter should include the cost incurred after handoff to humans; otherwise, it will reward solutions that fail frequently but have a low chatbot unit price on paper.

Write cost risks into procurement terms

• Require vendors to provide an itemized billing list, including the conditions for overage, tier jumps, and module activation;
• Set a hard monthly spending cap; once it is reached, pause the AI or route to the human queue to avoid an open-ended bill;
• Agree that bills are auditable and that the enterprise can sample and verify each "resolution" record;
• Model costs separately for normal months, business peaks, and periods when the resolution rate drops, rather than looking only at the average scenario;
• Write the pilot resolution rate, human handoff rate, and repeat contact rate into the final cost model.

For businesses with complex processes, fast-changing knowledge, or historically low automated resolution rates, prioritize contract structures that "charge only for genuine resolutions, with no fee for failures." Only when a pilot proves that the resolution rate is stable over the long term can the low sticker price of per-conversation billing translate into a real cost advantage. The final choice should not be the lowest unit price, but the solution whose annual total cost remains predictable, auditable, and under control under conservative business assumptions.

7. Reaching a final selection decision: scoring, risk control, and contract execution

When closing out selection, first eliminate unacceptable solutions, then score the remaining candidates. Don't convert feature lists directly into scores: the number of features is not business value, and "supported" in a demo environment does not mean it will run stably in production. The scoring basis should come from the same set of pilot data, with a unified inquiry scope, knowledge version, interface conditions, and staffing configuration, so that different vendors cannot each pick the criteria that favor them.

Build the scorecard around business outcomes

Weights are not a fixed template. High-risk sectors such as finance and healthcare can raise the weight of compliance and audit; businesses with heavy after-sales ticket volume should increase the weight of closed-loop execution; and enterprises with markedly fluctuating inquiry volume should give more weight to cost predictability. Weight adjustments should be finalized before viewing final quotes, to prevent the procurement team from reverse-engineering the rules to favor a preferred solution.

Set veto criteria first, then discuss the total score

The following issues should not be offset by other strengths: audit records cannot be fully exported; core interfaces are persistently unstable under pilot load; context is missing on handoff to humans; answer sources, knowledge versions, or handling criteria cannot be traced; billing is usage-based but no monthly fee cap can be agreed; or terms on data use, retention, deletion, or cross-border transfer do not meet enterprise requirements. If any one of these applies, the candidate should be suspended from the shortlist, rather than accepting the risk in exchange for a price cut.

Veto criteria must be written as testable conditions. For example, don't just write "stable interfaces"; specify the test period, request volume, success rate definition, timeout definition, and failure recovery requirements. "Complete logs" likewise needs a defined field scope, export format, retention period, and access rights.

Decision materials should compile pilot, cost, and risk information

• Pilot metrics sheet: Record the sample scope, baseline values, measured results, measurement definitions, and items that did not pass.
• Annual cost model: Cover base licenses, call or conversation fees, implementation and integration, model consumption, and operations staffing, as well as components that may be billed separately, such as ticketing, analytics, voice, and compliance modules.
• Risk register: For each item, specify the triggering conditions, business impact, responsible party, mitigation measures, and contractual constraints.

Vendors' published resolution rates can only serve as supplementary information and cannot replace the enterprise's own pilot. Different vendors' definitions of "resolved" may include conversations where the user did not reply, that closed automatically, or where only a reply was given, so side-by-side comparisons are easily distorted. That said, whether a vendor publishes its metric definitions, calculation periods, and how they map to billing does reflect whether its usage-based bills meet basic auditability requirements. A solution that cannot explain "how a single resolution is billed" also cannot support a reliable calculation of cost per resolution.

Write the pilot results into the contract

The contract should not only describe feature delivery; it should also turn the baseline confirmed during the pilot into post-launch service metrics. We recommend reviewing the effective resolution rate, wrong answer rate, additional workload after human handoff, and actual fees monthly, and specifying the data extraction method, the review process for disputed samples, and the remediation, fee adjustment, or exit mechanism if targets are missed repeatedly.

Fee clauses should cap both the annual budget and monthly peaks, and spell out overage alerts, what happens once the cap is reached, and the approval process for new modules. Otherwise, a solution with a lower base quote may expand spending after launch through additional components, growth in calls, or human workload flowing back as performance declines. The winning solution should be the one that passes every hard risk requirement, delivers verifiable business outcome scores, has predictable full-year costs, and allows its key commitments to be enforced through the contract.

8. FAQ: common questions when enterprises buy AI customer service chatbots

How long should an AI customer service chatbot pilot run before you can make a selection decision?

Don't decide when a pilot ends based on calendar days alone. A more reliable stopping condition is that testing has covered the main inquiry types, peak and off-peak periods, missing knowledge, consecutive follow-up questions, identity verification, failed business transactions, and human handoffs, with enough historical conversation samples for each type of scenario.

The pilot should replay the enterprise's own de-identified historical conversations, then add a small amount of real traffic for validation. Before starting, freeze the knowledge base version, test set, and scoring rules; afterward, count independent resolutions, wrong answers, no-answers, human handoffs, and business execution failures separately. If prompts or knowledge content are modified continuously during the pilot, keep a change log and rerun the same test set; otherwise, the before and after results cannot be compared.

Enterprises without a dedicated technical team should also include integration workload in acceptance. Even if answer quality passes, if day-to-day updates depend on the vendor's engineers, ongoing maintenance costs may exceed what is acceptable.

A vendor claims a 70% resolution rate. Can we use that directly in our cost model?

No. "Resolved" in demo data may mean the user stopped asking, the chatbot gave an answer, a preset flow was completed, or even that a flow was executed and then handed off to a human. None of these is the same as what the enterprise actually cares about: "the issue has been fully handled and requires no human work."

Cost calculations should be based on test results from the enterprise's own historical conversations. First define in the contract and pilot rules whether the denominator includes small talk, repeat inquiries, spam, and out-of-scope questions; then define whether the numerator excludes human handoffs, users contacting you again, human remediation, and incorrect completions. We recommend keeping metrics such as automated closure rate, human handoff rate, and false resolution rate side by side. A single composite resolution rate masks high-risk errors.

The contract should also allow the enterprise to spot-check raw conversations and specify the measurement period, deduplication method, handling of abnormal traffic, and dispute review process. A resolution rate that cannot be traced back to conversation records should not go into the budget model.

Do we need to finish organizing all our knowledge before launch?

No, and it usually isn't feasible anyway. A more workable approach is to rank recent real inquiries by frequency and business risk, and prioritize questions that are high-frequency, have stable rules, and have clear answers. High-risk content such as refunds, account security, and compliance commitments should have accurate answers, permission boundaries, and human fallback set up in advance, even if inquiry volume is low.

Knowledge base acceptance should not look at the number of imported files, but at whether answers have sources, applicable conditions, owners, and expiration dates. After launch, keep reviewing conversations with frequent handoffs, low ratings, and wrong answers, then decide whether to add knowledge, adjust the process, or bar the chatbot from answering. If no one owns knowledge maintenance, however many documents are imported at the start will quickly go stale.

Per-conversation vs. per-resolution pricing: which one is always cheaper?

Neither pricing model is inherently cheaper. With per-conversation pricing, the true cost per resolution can be estimated as "price per conversation ÷ auditable resolution rate," because unresolved conversations may incur charges as well. Per-resolution pricing looks more intuitive, but you must check whether "resolved" includes flows that were executed and then handed off to a human, users going silent, or subsequent repeat inquiries.

When comparing quotes, recalculate each option against the same set of historical conversations, including base subscription fees, channel integration fees, model or call fees, implementation fees, knowledge maintenance, overage usage, and the cost of human remediation. The contract should also specify how conversations are segmented, whether repeat contacts are billed again, how failed requests are handled, and whether the enterprise can export billing details. Ultimately, compare both the annual total cost of ownership and the true cost per closed-loop resolution, not just the sticker price.