Choose between an AI chatbot and live chat by the job the visitor needs completed. Explaining a published policy, checking a person's account, changing a booking and talking to a human require different information, permissions and ownership. A public-content assistant may suit the first job. A staffed conversation or a separately verified support workflow may be essential for the others. Choose the responsible path before choosing the chat window.
Author: Achla AI, Organization. Reviewed 14 October 2026. Prepared with AI assistance from official service guidance, support-product documentation and Achla product sources. The decision tools and scenarios are original and hypothetical. No measured ticket reduction, customer outcome or completed support test is claimed.
AI chatbot versus live chat starts with the visitor task
The UK Government Digital Service defines webchat, also called live chat, as a conversation between a user and a human adviser. It distinguishes a chatbot that helps users without a human adviser and notes the trained staffing needed for webchat. This is a useful functional distinction even when vendors combine both interfaces in one product. Chatbots and webchat guidance.
The first buying question is therefore not “Which technology is better?” It is “Who or what is responsible for completing this visitor's task?” A polished automated reply is not evidence that a person is available. A person in a chat window still needs the right information and authority.
Write the desired completion in plain language: understand, check, change or speak. These verbs help reveal whether the proposed channel can actually finish the job.
Separate public questions from private cases and actions
Consider four hypothetical requests from the same business website.
“What is your cancellation policy?” needs the organization's public wording. “Has my cancellation been processed?” needs the correct customer's record. “Cancel it for me” asks for an action. “I want to discuss what happened with someone” asks for human conversation. The topic is similar; the required service is not.
Classify by the required result, not by the words used. A policy answer can explain a process and link to its source without knowing the visitor's identity. An individual status requires a verified way to determine whose record is involved. An action requires permission to change something. A conversation requires an available person or an honest alternative route.
Do not let the presence of AI collapse these distinctions. Text generation alone does not demonstrate account access, authorized transactions or human staffing. Ask for separate documentation for each required capability.
Also distinguish a human preference from an exception. A visitor may want a person even when the public answer exists. Another may need judgement because published rules do not settle their circumstances. In both cases, record the desired human path rather than assuming that another automated explanation completes the request.
These are purchasing categories, not a formula for removing support staff. The decision tool below assigns responsibility; it does not estimate how many requests will disappear.
Use the support-path decision matrix
Fill this matrix with your own visitor tasks. The entries below are illustrative and have not been tested on any product.
| Visitor task | Information and action needed | Human requirement | Channel to investigate | Owner and availability evidence |
|---|---|---|---|---|
| Understand a public policy | Approved policy; explain and link | Optional contact for unresolved interpretation | Public-content answer assistant | Policy owner approves source; site owner checks documented product availability |
| Check a personal account status | Verified identity and account record; retrieve | Human or verified account-aware workflow | Authenticated account service or support channel | Account-service owner confirms authorization and support path |
| Change a booking | Booking record, identity and write permission | Authorized staff or verified transactional process | Booking service or support workflow | Operations owner confirms who can execute changes and when |
| Discuss an exception | Circumstances and responsible judgement | A person able to make or escalate a decision | Staffed support channel | Named team, authority and published availability or response expectation |
| Request a human immediately | Conversation with a person | Explicit | Live chat with staffing, or clearly stated alternative | Staffing owner confirms whether someone is actually reachable now |
| Find a manual outside staffed hours | Approved public manual; explain or locate | Alternative for unresolved task | Public-information assistant plus separate contact route | Documentation owner and contact-route owner remain identifiable |
A channel is not accepted merely because a widget can display a reply. For each required row, ask the supplier or operating team to provide evidence of the missing parts. Mark unknown availability unknown; do not turn it into “24/7 support” because the launcher remains visible overnight.
Keep the data owner and channel owner separate when necessary. The product team may maintain policy content while a service team handles exceptions. The card should tell you who resolves incorrect information and who receives the visitor when information is insufficient.
What makes a real human handoff different from a contact link?
A contact link points to another route: an email address, form, phone number or support page. It may be entirely appropriate, but it does not establish that the current conversation has been assigned to a person. The visitor may need to start a new request, and the original conversation may not travel with them.
A native handoff is a documented product workflow with configured routing and a change in responder responsibility. Zendesk's handoff and handback documentation describes moving the first-responder role between an AI agent and a live agent; the live-agent notification follows the account's routing flow. This is Zendesk-specific behavior, not a capability shared automatically by every chatbot. Zendesk handoff and handback.
Intercom likewise documents escalation guidance, rules and workflows for Fin. Its current guidance distinguishes offering escalation from escalating immediately, and describes a different outcome when no human routing target is configured. A buyer must inspect the configured destination, not just the bot's sentence saying it can help. Intercom escalation guidance.
For any claimed handoff, ask: where does the request arrive, who becomes responsible, what does the person receive, and what happens if nobody is available? Do not infer preserved context, a response deadline or completion of an action without evidence for that exact product and configuration.
Achla's evidenced public-answer widget is not presented here as staffed live chat or a native agent-transfer system. If continuity within the same conversation is essential, evaluate a separately verified product that supplies it.
Write the ownership and expectation card
Create one card for each channel you intend to offer. The example below is for a hypothetical small service business choosing a public-information assistant alongside an existing support email route. It is a proposal, not a result.
| Card field | Illustrative decision |
|---|---|
| Channel purpose | Explain approved public service and policy information |
| Content owner | Service manager reviews the public source wording |
| Channel owner | Website maintainer owns widget configuration and checks |
| Human route owner | Existing support team monitors the separate email channel |
| Staffed hours | Use only the hours the support team has actually confirmed |
| Response expectation | Publish an agreed expectation if one exists; otherwise do not invent a deadline |
| Unsupported task route | Show the independently available support page or contact route |
| Private data boundary | Do not ask for passwords, account records or sensitive details in public-answer chat |
| Handoff description | Contact route only; no promise of native transfer or conversation continuity |
| Acceptance decision | Eligible for public-answer evaluation; account actions remain outside this product requirement |
The important work is completing the empty responsibility fields. A product can answer from content, but the organization still needs a person who owns that content. A contact form can collect a message, but somebody must monitor it. An availability notice needs an owner who can keep it accurate.
Use different cards if you also propose live chat or account servicing. Those cards should name the staffing or authenticated workflow owner. Do not copy “support team” into every field and leave the actual destination unclear.
Design the closed or unavailable route before choosing software
Specify the visitor's next step when the preferred path cannot complete the job. The Government Digital Service recommends alternative options when chat or webchat cannot provide the needed support, and planning for conversational dead ends. Its assisted-digital guidance also describes support via phone, webchat or in person according to users' needs. Assisted digital support guidance.
An unavailable route is not a failure that software copy can hide. If the visitor requests a human after hours, the interface should not imply that an operator is joining unless that is true. If the only alternative is an asynchronous route, describe it accurately. If an urgent request needs a different established channel, keep that channel visible rather than relying on the assistant to invent one.
Avoid using an automated chat box as an unapproved place to collect account details. Direct a private case to the organization's verified process. Record the link, owner and honest expectation in the card.
Zendesk's workflow-design guidance treats the route from automated assistance to live support as a design decision. Use that as an example of why the operating route needs planning; do not copy Zendesk's features into another supplier's capability description. Zendesk conversational workflow design.
Make a bounded product decision with the completed card
Choose a public-content assistant when the essential job is to explain or find approved public information and the separate contact route is sufficient for the remaining needs. Choose a staffed channel when human conversation is essential. Investigate a verified authenticated or transactional workflow when the job needs personal records or actions.
A combined product may be appropriate when native transfer is a required part of the service. Evaluate the transfer destination, operating availability and evidence for the particular configuration. “Includes AI” is not an answer to those questions.
Use three possible buying outcomes: fits the required public task, needs another verified capability, or cannot yet be decided because evidence is missing. The third is useful. It stops a supplier demonstration from silently filling gaps in your responsibility card.
If the requirements change later, reopen the decision. A public-information assistant selected today does not become an account-service tool when somebody adds a new question to the welcome text. Keep any claimed new capability subject to documentation and owner review.
For a broader category shortlist, consult the existing AI site-search overview. The card remains the more specific tool for deciding which channel should own each visitor task.
Where to evaluate Achla for public answers
Achla is a candidate for source-linked answers about public website information. Review its current installation documentation, including generic script and documented CMS paths. Drupal owners can also inspect the Drupal connector page. Placement does not add account access, live agents, lead capture or transactions.
Read troubleshooting guidance for later installation checks and current pricing for terms. If the completed card fits the public-answer scope, begin onboarding; sign-in may be required. Evaluate that bounded job on your site. Keep the public-answer evaluation separate from the staffing and account-service decisions on your card.