Product paths checked October 29, 2026. Originally published February 26, 2026.
A chatbot can answer a question from approved content. Live chat puts a person in the conversation. A support ticket records an issue for later follow-up. Choose the path by what the visitor needs to finish, then check what happens when the first answer fails. A ticket confirmation is not a promise that an agent is joining the chat.
For a published answer about hours or a return policy, a chatbot may be a good first stop. A disputed charge, account-specific investigation or request for an exception needs a person who can check the record and make a decision. If that person is not available now, offer a truthful follow-up route rather than calling it live chat.
Compare the actual customer experience
| Decision | Content-backed chatbot | Staffed live chat | Chatbot with ticket follow-up |
|---|---|---|---|
| Who replies now? | The bot, using its configured sources and instructions | A person once they accept the conversation | The bot now; a person later through the support team's follow-up channel |
| What can finish in the conversation? | Questions covered by approved content, plus actions you have connected and tested | Cases the agent has access and authority to resolve | The request is recorded; resolution happens after the team reviews it |
| What must you provide? | Current sources, answer checks and a fallback | An inbox, staff coverage and access to the needed records | Current sources, a working destination, contact details and a team that owns follow-up |
| Main failure to test | A confident answer from missing or outdated content | A queue with no available agent | The bot says “someone is joining” when it only created a ticket, or claims success after creation failed |
Zendesk describes live chat as a real-time conversation with an agent. Its messaging channel lets people resume a conversation later. Ask any vendor which experience its “human handoff” actually starts. The name alone does not tell you whether the visitor stays in a live session, receives a ticket number or must wait for email.
Start with the cases a person must own
Write down your real incoming questions before choosing software. Mark each one according to the information and authority it needs:
- Known public answer. The answer is in an approved help page and does not depend on the visitor's private account. Try a chatbot, then check its reply against the page.
- Personal record or action. The answer requires an order, account, payment or booking state. Use a person unless the bot has a connected, authorized action that you have tested against the system of record. A plausible answer is not proof that an action succeeded.
- Dispute or exception. The visitor contests a charge, reports a security issue or asks for a policy exception. Route to the team with decision authority. Do not make the visitor repeat the same request until the bot gives up.
- Request for a person. Offer the human route you can actually deliver. State whether that is a live conversation during staffed hours or a record for later follow-up.
A mixed queue does not automatically justify a “bot first for everyone” policy. If most questions require private records or judgment, staff the human path first. If approved public answers make up a meaningful share, test the bot on those questions and keep the human route easy to reach.
Know what Agentkit's handoff creates
Agentkit is a website chatbot service, not a staffed live-chat inbox. Its paid Escalate to Human action creates a ticket, case or conversation in a connected support tool such as Zendesk, Freshdesk, Help Scout, Intercom, HubSpot or Salesforce. The action needs a valid visitor email and sends a summary with recent conversation context. Plan how the bot will ask for an email when it does not have one. Creating that record does not mean a person has read it or joined the widget. Assign an owner and a follow-up channel in the receiving team before enabling it.
Agentkit has a separate paid Salesforce live chat action for a configured Salesforce Enhanced Chat deployment. That route starts a chat session with the configured Salesforce Enhanced Chat deployment; a successful request still does not establish that an agent has joined. It needs the Salesforce deployment, routing and signing setup described in that guide. If you need live agents working in one shared inbox, compare products that include that workflow. Our website chatbot comparison maps several options by handoff and billing unit.
For an Agentkit ticket path, open Actions > Integrations and connect the support tool. Add Escalate to human, choose the connected destination and review its When to use instructions. Test with an address you control. Confirm the record appears in the receiving tool with a useful summary, then verify that a team member can follow up. The handoff guide gives a longer set of failure cases. A playground preview or the bot's reassurance alone cannot prove delivery.
Compare cost with your own queue
Per-conversation shortcut figures hide the real bill. Bot plans count messages, credits or outcomes differently. Live chat also needs seats, staff time and coverage. A handoff may use both.
Use the same recent support sample for each option. For a normal week and a busy week, record:
| Input to collect | What to check |
|---|---|
| Visitor questions by type | Which have an approved answer, which need a record or decision, and which ask for a person? |
| Bot usage | Count the vendor's billable unit for a tested conversation, including follow-up messages and failed attempts. |
| Human work | Count cases accepted by staff, handling time, coverage hours and repeat contacts after a poor answer. |
| Handoff outcome | Did a live agent join, did a ticket appear, and did the customer receive the promised follow-up? |
| Busy-period behavior | Check plan limits, overages, queues and who owns requests outside staffed hours. |
Then calculate monthly platform charges + usage charges + staffed hours + setup and source upkeep for each path. Use Agentkit's current pricing for its plan limits and the other vendor's current quote for its own units. The pricing-model guide helps compare units. Do not assume a bot “deflects” a case because the visitor stopped replying; check whether the issue was resolved or came back through another channel.
Run a small acceptance trial
Use ten recent, anonymized questions that represent your queue, including at least one outdated-source case, one private-account case and one request for a person. Ten cases are a setup check, not a performance benchmark. Write the correct answer or required routing decision before you test. For each case, record the reply, source used, whether the visitor could reach the promised channel, and what the receiving team actually saw.
Test once during staffed hours and once outside them. If you have a non-production setup, test a failed ticket creation and confirm that the bot does not claim it created a record. Otherwise, mark that failure path untested. If you offer live chat, verify that a person can accept the session and reply. Keep the result that matters to the visitor separate from the message the bot generated.
If the public-answer cases pass and Agentkit fits your website, create a chatbot with a small approved source set and test the ticket path before publishing the widget. If live human conversation is the main requirement, trial the staffed inbox first and make its queue and after-hours behavior your acceptance check.
