To automate customer support well, give the AI a narrow job, current answers, and a clear route to a person. Start with one topic, one channel, and one named handoff owner. Let the AI answer routine questions. Have your team handle failed fixes, exceptions, and requests for human help.
Use recent support conversations as your input. Aim for two useful results: a customer can finish a routine task, or a teammate can continue the conversation without asking them to start again. A person should review both kinds of result during the pilot.
The human touch comes from what happens when the customer needs more help:
- Choice: They can ask for a person without completing another troubleshooting round.
- Memory: The next reply takes account of what they already tried.
- Honesty: They know whether they are talking to AI, waiting in a queue, or speaking to a teammate.
- Ownership: Someone is responsible for following up.
A warm message cannot make up for a lost ticket. Build the handoff before polishing the tone.
This guide uses Intercom Fin, Tidio Lyro, and Gorgias AI Agent as provider examples. We checked the linked instructions on 5 October 2026. The pilot, messages, and sample results below are illustrative. They are not customer case studies or results from our own deployments.
1. Choose the first job carefully
Look at questions your team receives often. Choose one with an agreed answer, a maintained source, and a result you can check. “Explain how to export a report” is a clearer first job than “handle customer support.”
Keep these levels of automation separate:
Scroll sideways to see all columns.
| Type of request | Suitable first approach | What it needs |
|---|---|---|
| “How do I export a report?” | Answer from approved instructions | Current help content and access to a person |
| “Where is my order?” | Retrieve current order information | Customer verification, a working connection, and a failure route |
| “The export failed again” | Pass the known details to support | Conversation history and someone to receive it |
| “Cancel and refund my order” | Prepare a request for human review | Later automation would need authority, eligibility rules, and confirmed results |
A helpful answer, an account lookup, and a refund are different jobs. Test them separately rather than adding all three to the first pilot.
Start with human-reviewed drafts if policies change often, sources disagree, or most requests need exceptions. A person can check the suggested reply before sending it. Use those reviews to find a smaller set of questions suitable for automatic answers.
For the worked example, imagine a small software company with website chat. Its first pilot answers report-export questions. Failed exports and missing data go to Technical Support. The AI cannot diagnose account problems or promise a repair date.
2. Turn that job into a pilot brief
Write down what the AI may do and what your team will do next. This keeps a tool setting from becoming an accidental customer promise.
Scroll sideways to see all columns.
| Field | Illustrative report-export pilot |
|---|---|
| Channel and scope | Website chat; documented report-export instructions |
| Knowledge owner | Support lead maintains the approved help article |
| AI may do | Explain the steps and ask for details needed to answer an in-scope question |
| Handoff triggers | Failed export, missing data, unclear instructions, or any request for a person |
| AI may not do | Change account data, offer compensation, or promise a fix time |
| Receiving queue | Technical Support |
| Human owner | A named teammate covers each shift; the support lead covers gaps |
| Coverage | Monday–Friday, 09:00–17:00 Europe/Warsaw |
| After-hours route | Collect a reply email if missing and create a follow-up ticket |
| Failure route | Show the team's verified support email if ticket creation fails |
| Review and pause | Support lead reviews each pilot conversation; pause the affected flow after a failed required handoff or unsupported promise |
Replace the example hours, queue, roles, and contact route with your own. Name the actual person on duty. “The support team” is too vague when a queue has no owner.
Give the agent one current answer for each covered question
Each source should include the steps, relevant account or plan limits, known exceptions, and what to do when the steps fail. Remove old versions from the material the agent can use.
Keep general instructions separate from private account facts. A help article can explain how to find an order. It cannot establish the current status of a particular customer's order.
Before adding more content, check whether the current content answers the pilot questions. A large collection of conflicting pages gives you more material to maintain.
After a policy change, confirm that the agent has the new version and rerun the affected questions. Give this work an owner alongside the handoff queue.
3. Design the handoff from request to human reply
An escalation has several stages. Check each one in the helpdesk rather than trusting the AI's message.
Scroll sideways to see all columns.
| Stage | Evidence to check | What the customer may be told |
|---|---|---|
| Customer asks for help | The request is recognized | The assistant will try to pass the conversation to support |
| Transfer or ticket succeeds | The conversation appears in the correct queue | The request is in that queue |
| A person takes ownership | A teammate accepts or is assigned the conversation | Who will handle it, if that is confirmed |
| A person replies | A customer-facing human reply is sent | The conversation can continue with that person |
A queued ticket is not a human reply. Measure the wait from the customer's request, including time spent collecting details or sitting unassigned.
Make these rules explicit:
- A direct request for a person starts the handoff. Do not make another AI answer a condition of access.
- Carry the transcript, failed steps, and known facts into the receiving queue.
- Separate what the customer reported from what a system confirmed.
- Ask for missing contact details only when needed for follow-up. Further diagnosis can wait for the teammate.
- Check that later customer messages do not restart unwanted AI replies after human takeover.
If the platform cannot create a summary, preserve the transcript and have the teammate read it. A short, accurate history is useful; an invented diagnosis is not.
A handoff that saves the customer from repeating the story
This fictional exchange assumes the transfer succeeds. It makes no promise about when a repair will be available.
Customer
The report export failed twice. I need it for tomorrow's meeting. Please let me speak to someone.
AI, after the conversation reaches the support queue
Your conversation is now in the Technical Support queue, with both failed attempts and your meeting deadline included. A support teammate will continue from here.
Internal note for the teammate
Customer reports: Export failed twice; report needed for tomorrow.
Already tried: Two export attempts.
Verified by our system: Conversation reached Technical Support.
Still unknown: Report name and error message.
Customer wants: A person to help.
Promises made: No repair time or compensation promised.
Human reply
Hi, I'm Maya from support. I can see you've tried twice and need the report tomorrow. Which report are you exporting, and what error message do you see?
Maya asks for missing details. She does not ask the customer to explain the whole problem again or repeat the same failed step without a reason.
Cover offline hours and failed transfers
After a follow-up ticket has been created, a message for the fictional pilot could say:
Your request is in our support queue. We're offline now. Our support hours are Monday to Friday, 09:00–17:00 Europe/Warsaw. We'll reply by email when the team is back.
Use actual hours and make sure the next shift reviews the queue. Only quote a reply deadline if your team has agreed to meet it. Do not say someone will join shortly when live support is closed.
If ticket creation fails, the message must change:
I couldn't create a support ticket. Please contact us at the support email shown below. Include your report name and error message so the team can help.
Show a verified address your team monitors. If the failed route did not save the conversation, do not claim that the email team already has it.
4. Choose an agent that fits your helpdesk
Begin with the tools your team uses today. Changing the helpdesk also changes routing, training, and daily work.
Scroll sideways to see all columns.
| Current setup | Provider to explore | Main pilot question |
|---|---|---|
| Intercom with maintained help content | Fin | Can the pilot reach a small audience and pass exceptions to your existing queue? |
| Website chat in Tidio | Lyro | What happens to transfers while the team is online and offline? |
| Shopify store using Gorgias | Gorgias AI Agent | Which requests can it answer, and which need a person or a verified order lookup? |
These are starting points based on the documented features, not rankings from a shared performance test. If two tools fit, compare them with the same questions and handoff cases.
For cost, calculate the helpdesk subscription, seats, AI usage, and required channel charges. Ask what counts as billable usage, how failed conversations are treated, and what happens when an allowance runs out. Also budget for source maintenance and human follow-up.
Fin: check audience and handover settings
Intercom's linked chat route requires Messenger and at least ten public Help Center articles before setting Fin live.
Review content and escalation guidance under Fin AI Agent → Train. Use Test, then Deploy → Chat to set the audience and handover route. Start with internal testers. This route requires Let Fin introduce itself to be enabled.
Review the option to collect more information when someone asks for the team. For this pilot, avoid extra troubleshooting before the requested handoff.
Simple deploy takes priority over Advanced Workflows. Check which route actually runs and whether later messages bring Fin back into an escalated conversation. Live tests can incur usage charges. Fin chat deployment guide
Verify: A person request reaches the intended team, and human takeover stops unwanted AI replies.
Lyro: treat online and offline routing as separate choices
Add approved content under Lyro AI Agent → Knowledge and test it in Playground. Use Behavior → Handoff to configure online and offline handling. Check the customer messages as well as the route. Set writing instructions under Behavior → Guidance.
Tidio supports transferring a conversation or creating a ticket. Created tickets include the transcript and appear in the Unassigned folder of the Tickets inbox. Someone must pick them up.
Enabling Lyro disables existing “Visitor says” flows, which can be re-enabled. Review those automations before launch. Lyro setup and handoff guide
Verify: An offline request can receive a reply, and the next shift can find its history.
Gorgias: keep order actions outside the first pilot
Prepare approved store content in AI Agent → Knowledge, define the topic's Skill, and test in Playground. Add order-changing actions only after separately testing their rules. AI Agent setup
The documented Chat route needs a connected Shopify store, an active AI Agent subscription, and Lead, Admin, or Account Owner permissions. Install and connect Chat, then configure it under AI Agent → Deploy → Chat. Personal order details require shopper sign-in. Chat requirements
Set off-limits topics under Settings → Handover and exclusion. Under Deploy → Chat, review handover confirmation and instructions for online, offline, and error cases. Explicit requests for a person bypass confirmation. Handover settings
Verify: A failed sign-in or disputed order can reach a person without an invented status or an unconfirmed action.
5. Write messages that show useful progress
Give the assistant instructions about behavior as well as style:
Identify yourself as an AI assistant. Answer the customer's question first. Use short sentences. Recognize what they already tried. Ask only for details needed for the next step. Respect requests for a person. Describe an action as completed only after confirmation. Explain the actual follow-up route.
Apply these instructions through supported provider settings. Check fixed greetings and system messages too; a tone setting may not control every message.
Scroll sideways to see all columns.
| Situation | Weak reply | Better direction |
|---|---|---|
| Customer tried the suggested fix | “Please try again.” | Acknowledge the attempt; explain a different step or hand off |
| Customer asks for a person | “Before I connect you, let's try…” | Start the handoff and ask only for necessary contact details |
| Account information is unavailable | “Your order is on its way.” | Explain that the status could not be checked and offer the working support route |
| Team is offline | “Someone will be with you shortly.” | State actual coverage and how the reply will arrive |
| Refund action failed | “All done!” | Say that no refund was confirmed and route the request for review |
Match empathy to the situation. A customer who needs a report tomorrow benefits from a reply that recognizes the deadline and explains the next step. Repeated apologies without progress add more reading.
6. Test the full journey before launch
Use sample questions or past conversations with personal details removed. Write the expected answer or route before running each test.
Scroll sideways to see all columns.
| Test | Pass condition |
|---|---|
| Routine question | Answer matches the current source and helps complete the task |
| “I already tried that” | Failed attempt is recognized; no pointless loop |
| “I want a person” | Request reaches the human queue without another troubleshooting round |
| Missing or conflicting source | Gap is acknowledged and routed for review |
| Lookup or ticket creation fails | No invented result; a working fallback is shown |
| Request outside support hours | Correct hours, reply method, and saved conversation |
| Teammate takes over | History is visible and AI does not interrupt later replies |
| Supported second language | Meaning, contact details, and handoff still work |
Run tests in the customer interface and the receiving inbox. A preview answer cannot prove that a ticket exists, a notification arrives, or a teammate can reply.
Launch checklist
- Routine answers match the approved source.
- Every tested human request reaches the right queue with its history.
- A named teammate receives and replies to a test handoff.
- Offline requests and failed transfers have working follow-up paths.
- Later messages do not restart unwanted AI replies.
- The source owner and queue owner know their daily duties.
- The team has tested how to pause the AI and restore human handling.
These are suggested launch gates. Passing a small test set does not guarantee future performance.
Run an internal trial first. Next, use the smallest supported live audience or scope while a person can monitor it. Review conversations marked solved as well as handoffs. Expand one topic or audience at a time.
Pause the affected flow if it blocks human access, exposes another customer's details, or makes unsupported promises. Correct the cause and retest before restarting.
7. Measure the answer and the human follow-up
Track whether customers finish the task and whether your team spends less time repairing the interaction.
Scroll sideways to see all columns.
| Measure | What to record |
|---|---|
| Answer quality | Factually correct answers divided by reviewed answers; include the sample size and errors |
| Handoff delivery | Required handoffs that reached the right queue with context, divided by required handoffs checked |
| Human response time | Time from the customer's request for a person to the first human reply |
| Waiting requests | Unassigned conversations and the oldest request still waiting for a person |
| Repeat contact | Another contact about the same issue within a chosen, fixed time window |
| Customer feedback | Ratings and comments, with the number of survey replies |
| Staff effort and cost | Replying, review, corrections, maintenance time, and software charges |
Keep separate measures rather than combining them into one success score. In an illustrative review, 18 of 20 answers might be factually correct. A separate check might find that only three of four required handoffs reached the queue. The missing handoff needs repair even though most answers were correct.
List serious errors beside the numbers. A false repair promise deserves action even if the total score looks high. Track style problems separately from factual errors.
Use the same topic, channel, and definitions when comparing periods. Keep simple AI-only questions separate from complex escalations. A vendor's billable outcome or a closed ticket does not, by itself, prove that the customer completed the task.
Make the first pilot small enough to inspect
Choose a question your team already answers well. Fill in the brief, prepare the source, and name the person who receives exceptions. Then test a routine answer, a direct human request, an offline request, and a failed transfer in the real interface.
For a first step using human-reviewed drafts, find Support ticket triage in the JuicyAgents skills directory. It helps a compatible assistant sort requests and suggest an initial response. It needs its own setup; listing a skill does not connect it to your helpdesk or send replies.
Expand when your team can show both a useful automated answer and a working path to human help.