Website AI agent: conversations and ticket handoff

Distinguish the live agent from the guided example

The website-agent experience is intended to bring visitor questions into a configured AI conversation and, where connected, into Tickets for follow-up. The shared agent service supports opening a conversation, sending messages, reading its history and cancelling a run. It also distinguishes guest conversations from authenticated access.

The EleonEcho marketing site includes clearly labeled scripted examples. Those examples do not send messages or create tickets. A production embed requires its actual deployment settings and acceptance checks; a floating chat illustration or a working internal chat component is not sufficient evidence that a public embed is connected.

Choose the audience and the agent’s job

Decide whether the visitor needs product guidance, support intake or a sales conversation. Give the agent a narrow initial purpose and knowledge sources appropriate for that audience. Explain what the visitor can ask and identify the experience as AI.

For an authenticated experience, confirm the required identity and permissions. For guest access, confirm the published agent’s public access policy and allowed site configuration. Do not expose internal operating instructions, private tickets or customer documents simply to make the assistant more informative.

Prepare the deployment connection

Your deployment owner needs the supported embed mechanism, public agent identity, HTTPS address, approved site or origin settings and an appropriate privacy notice. Those are environment-specific values. This guide intentionally does not provide a guessed script URL or an example containing credentials.

Verify the embedded experience on the real website, including opening, closing, sending, loading history where offered and displaying an unavailable or failed state. Session behavior belongs to the deployed conversation service; reopening a marketing dialog does not by itself establish whether earlier messages will be restored.

Verify ticket handoff with usable context

A visitor asking for help is not yet a ticket. The configured intake path must confirm the result of the actual Ticket operation and preserve the conversation context needed for follow-up. Check the requester, Department, access rules and which information becomes visible to staff.

Use a controlled request to confirm that one intended case appears in the correct place. Verify a retry or interruption without assuming that a second click should create a second case. The Tickets guide explains the case workflow after successful intake.

Show accurate staff availability and failure states

Optional live takeover requires a separately configured staff connection. Test an available staff member, unavailable staff and a failed transfer. The visitor should understand whether they are still speaking with AI, whether staff have joined, or whether a case has been recorded for later follow-up.

Do not use an iframe load event, a typing animation or an AI-generated acknowledgement as proof of human availability. If the configured service is unavailable, present a truthful retry or contact option supported by the deployment rather than a successful-looking confirmation.

Check the complete visitor journey

Before enabling the experience publicly, verify a real conversation, a correctly answered knowledge question, an out-of-scope question, ticket creation with context, and both staff-availability states. Check mobile layout, keyboard operation, focus on open and close, and the clarity of error messages.

Keep the public documentation and claims aligned with those verified outcomes. See AI tools and autonomy for the boundary between a helpful answer and permission to take action.

Walk through a support request from visitor to staff

Use a controlled request, such as a visitor asking how to change a booking, to test the complete workflow. Avoid real customer details during this check.

1. Start with an approved answer. Ask a question covered by the agent’s configured knowledge. Confirm that the reply uses the intended guidance and does not expose internal information.
2. Ask for help beyond that answer. Request a change that needs staff review. Check that the agent explains its limits and offers the configured escalation path instead of claiming it completed an action it cannot perform.
3. Confirm the case in Tickets. An authorized staff member should find the request in the intended Department, with the requester and usable conversation context. Follow Department and routing setup if the case reaches the wrong team.
4. Check follow-up visibility. Confirm which reply route is available to the visitor. Ticket creation does not automatically establish a customer portal session or mean that a staff member has joined the website chat. Keep internal notes separate from customer replies.
5. Repeat with staff unavailable. The visitor should see the actual outcome: a recorded case for follow-up, a failed attempt or an available retry. Only report live takeover when staff have actually joined.

Troubleshoot missing answers and incomplete handoffs

• The agent opens but cannot answer: check the published agent, the intended knowledge binding and retrieval access. A loaded widget only proves that its interface opened.
• The agent says it created a ticket, but staff cannot find it: verify the Ticket operation result and Department routing. An AI acknowledgement is not a durable case record. Check the original result before retrying to avoid duplicate requests.
• A ticket exists, but no person joins the chat: verify the separate live-staff connection and availability. A support case and live takeover are distinct capabilities.
• A returning visitor sees no earlier messages: check the deployed service’s guest or authenticated session behavior and supported history access. Do not infer conversation persistence from a marketing demo.

Record the visible failure, the affected workflow and the approximate time for your deployment owner. Keep credentials and private conversation content out of public reports. Review the security and AI access controls before widening access as a workaround.