Configure the native Gorgias handover
In AI Agent > Settings > Handover and exclusion > Handover topics, add the subjects your team must handle. Choose the correct store first. Under AI Agent > Deploy > Chat > Handover instructions, configure online, offline, and error scenarios.
Chat normally asks shoppers to confirm a handover; explicit requests for a human and technical errors skip confirmation. Offline handovers request an email. Online email capture can be optional, required, or off. Error fallback text is sent as written. See the handover guide.
Write response expectations your team can meet. Do not paste a generic “within 24 hours” promise if nobody owns that commitment. Likewise, do not make customers repeat an order number or explanation already visible in the conversation.
Keep exclusion separate from escalation
This retained Gorgias screenshot shows an older layout. Use the current handover guide for navigation and choose topics that match your policy, not the example entries.
The Prevent AI Agent from answering rule applies ai_ignore: no AI response or handover. Use it for tickets your team should handle directly, not as a substitute for a customer-facing escalation. Native handovers can be routed using ai_handover in an assignment rule. These are distinct paths in the handover documentation.
Before changing a rule, list who receives its matching tickets. A ticket excluded from automation still needs an owner. Avoid broad exclusions such as every message containing “refund” unless that is your team's policy.
Test the shopper's next step
Open AI Agent > Playground, choose Chat, and test both Online and Offline availability. The Playground documentation supports these configurations. Preview conversations do not create tickets or contact shoppers. Actions are disabled by default; enabling them can change real customer or order data. Keep them off for a handover-message test.
I would use this small review matrix before a controlled live check:
| Scenario | What to inspect | Failure to catch |
|---|---|---|
| Shopper explicitly requests a person | Whether the request is respected | Another irrelevant troubleshooting loop |
| Team is offline | Follow-up route and honest expectations | A promise that someone is joining immediately |
| Shopper has already explained the problem | Context passed to the reviewer | Asking for the whole story again |
| Ticket is excluded from AI | The human queue receiving it | An ignored ticket nobody watches |
| Human takes ownership | Behavior after the next customer message | Competing AI and human responses |
These are suggested checks, not measured results. Record the expected response before testing. When a preview passes, verify the actual ticket's queue, assignment, and customer-visible message in an authorized live test.
Review the handover as a sequence
A useful record has four parts: why the AI stopped, what the customer was told, what information reached the team, and who owns the next action. Check the final part with the receiving team. A ticket can have a clear summary and still sit unassigned.
Repeat the check after changes to staffing hours, routing rules, or escalation policy. Keep a valid human handover when it is needed; reducing the handover count is not a success if customers lose access to the person who can resolve their case.
Review a Gorgias handover workflow through eesel CLI
A handover needs more than a sentence saying a human will help. Someone must receive the ticket, understand what happened, and know whether the AI has stopped replying. If you are evaluating an eesel helpdesk teammate for Gorgias, use the CLI to check that workflow before expanding its responsibilities.
The eesel CLI gives people, scripts, and coding agents access to the same eesel agent and workspace as the dashboard. Claude Code, Cursor, or Codex can read its JSON output, inspect the setup, and help prepare a test. The CLI does not configure Gorgias's native AI Agent handover settings; it operates your eesel teammate.
Inspect existing automations before adding another
With Node.js 18.17 or newer, identify the account and agent:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
npx @eesel/cli integrations --agent TEST_AGENT_ID
npx @eesel/cli instructions --agent TEST_AGENT_ID
npx @eesel/cli automations --agent TEST_AGENT_ID
npx @eesel/cli status --agent TEST_AGENT_ID
Replace TEST_AGENT_ID with your selected agent. An existing workspace may already have enabled automations. Check them and the dashboard action permissions before connecting another source or running chat.
A full Gorgias connection is needed for ticket sources, triggers, and actions. Quick start reads public help-center articles only; it cannot route a ticket or post an internal note.
npx @eesel/cli integrations connect gorgias --agent TEST_AGENT_ID
npx @eesel/cli status --agent TEST_AGENT_ID
A person opens the authorization link. If a coding agent is helping, it should hand over that link and wait. After authorization, inspect the source counts and toggles in Integrations > Gorgias. Confirm the escalation policy and approved response expectations are available.
Gorgias chat conversations arrive as ordinary tickets for eesel. Its customer-message trigger, gorgias_ticket_commented, can fire on the opening message and later public replies. That matters after a human takes over: do not assume an instruction to escalate once prevents another automation from replying later.
The official integration example shows what is connected and downloaded. It does not establish who will receive an escalated ticket.
Test the decision without claiming a real transfer
For a fictional text test, keep public replies, assignment, and other write actions off in the dashboard. Then create a conversation:
npx @eesel/cli new --name "chat-handover-review" --agent TEST_AGENT_ID
npx @eesel/cli chat "Fictional test: a shopper asks for a human after two unsuccessful answers about a refund. Using the approved escalation policy, draft a brief acknowledgment and an internal summary. Do not ask the shopper to repeat details already provided. Do not send messages, assign tickets, or change records." --agent TEST_AGENT_ID
npx @eesel/cli chat "Now assume the human team is offline. Revise the proposed acknowledgment using only the documented response expectations. Identify any missing contact information. Do not promise a reply time that the policy does not support." --agent TEST_AGENT_ID
The second message continues the same conversation. I would compare the drafts against the escalation policy, not just whether they sound empathetic. Check for invented response times, repeated questions, and a summary that omits the reason the customer requested help.
This test supplies availability as a fictional fact. It does not prove that eesel reads Gorgias's live availability settings, captures an email in the widget, or transfers a real ticket. Validate each of those requirements separately if your rollout depends on it. CLI chat is billed work, and a new conversation does not create an isolated workspace.
Ask a coding agent to find gaps before changing anything
A useful first assignment is read-only:
Inspect the selected eesel agent's instructions, sources, and automations. Compare them with the approved handover policy. Identify how the workflow handles a request for a human, unavailable staff, and a later customer reply after human takeover. Report any behavior you cannot verify. Do not run chats, change settings, or create automations until I approve.
The coding agent can collect the CLI's JSON results into a review. Keep policy recommendations separate from verified configuration. If it cannot establish who owns the ticket after escalation, that is an open question, not a successful handover.
Verify a private summary and human ownership separately
Start with an authorized test ticket and an on-demand internal-note workflow. In eesel's action settings, keep Send ticket reply off and set Leave internal note to ask first. Leave assignment and other writes off for this first check.
After reviewing existing automations, ask for the pilot:
npx @eesel/cli chat "Create an on-demand Gorgias automation using gorgias_eesel_mentioned. When mentioned on TEST_TICKET_ID, prepare a private handover summary with the customer's request, steps already tried, unresolved question, and next action needed from a human. Do not claim anyone has accepted the ticket. Do not send public replies or assign the ticket. Keep Leave internal note approval-gated." --agent TEST_AGENT_ID
npx @eesel/cli automations --agent TEST_AGENT_ID
Replace TEST_TICKET_ID before running it. That ticket instruction is not an access-control boundary. Use a restricted test setup where isolation matters. Creating an automation changes the workspace and may enable it immediately; inspect the trigger and permissions before mentioning @eesel in an internal note.
Review the held summary, approve it once if correct, then open Gorgias and verify private delivery. Have an authorized person assign the ticket for this pilot. The integration guide also lists an assignment action, but automating that write should be a separate, explicitly reviewed change.
| Handover check | Evidence to inspect | What does not prove it |
|---|---|---|
| Summary reached the team | The private note on the correct ticket | A generated draft in terminal output |
| Someone owns the next step | The actual assignee and team's queue | Wording that says “passed to a specialist” |
| Customer knows what to expect | The customer-facing message actually sent | An internal note that the customer cannot see |
| AI does not interrupt takeover | Behavior after a later authorized test reply | A single successful escalation |
Approving a private note does not send the customer an acknowledgment or make someone available. Decide who sends that acknowledgment and verify it in the actual channel. Before enabling a customer-message automation, test how human ownership and later replies interact with its filter and instructions.
This documented private-note example is a reply draft, not the handover summary generated by this tutorial. It illustrates private delivery only, not assignment or customer notification. Its promises need policy review before sending.
npx @eesel/cli approvals --agent TEST_AGENT_ID
npx @eesel/cli activity --agent TEST_AGENT_ID
Use these records alongside the Gorgias ticket. If a later message triggers an unwanted AI response, stop the relevant automation and review its scope before continuing the rollout.
Make the handover observable
For native Gorgias AI Agent, test the configured handover path in the shopper's channel. For an eesel teammate, use the CLI to inspect and test its separate workflow. In either case, check the message, summary, ownership, and next reply rather than treating a reassuring sentence as completion.
Try eesel with your Gorgias helpdesk and start with one private handover-summary pilot before automating customer-facing transfers.
Frequently asked questions
Where are Gorgias chat handover instructions?
Under AI Agent > Deploy > Chat. See the handover guide.
Does ai_ignore transfer a ticket to a human?
No. ai_ignore prevents AI Agent from responding or handing over the ticket. See exclusion settings.
Can I test Gorgias handovers when the team is offline?
Yes. Choose Chat and Offline in Playground. Keep Actions disabled for a message-only check; enabling them can affect real data. See test conversation settings.
Does eesel CLI control the native Gorgias AI Agent?
No. It operates your eesel teammate and the same workspace used in eesel's dashboard. Native Gorgias settings remain a separate configuration. See the CLI reference.
Does an eesel private summary mean the customer was notified?
No. An internal note is visible to your team. A public reply is a separate action. Verify both the actual message and ticket ownership before treating the handover as complete. See Gorgias actions.
Can a later customer reply trigger eesel again?
The customer-message trigger covers public customer replies, including later messages. Check its filter and instructions before enabling it on tickets humans handle. See the trigger reference.
Are the eesel CLI handover examples free simulations?
No. CLI chat is billed work, and a new conversation does not isolate the agent from its tools. Review action permissions before testing. See the CLI guide.
Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.
