When should the agent hand over?
Three triggers cover almost every case. The customer asks for a person, in any wording: a representative, a manager, 'a real human'. The agent can't answer from its knowledge, and stopping at 'I don't know' would leave the customer stuck. Or the conversation is one your team wants to own regardless: a complaint, an upset customer, an urgent problem, a contract question, anything touching security or legal.
The first two are behaviours to build in. The third is policy, and in WireDesk it is written as plain-language instructions to the agent rather than configured in a rules engine: 'if the customer mentions a chargeback, offer to put them through'. Write those instructions the way you would brief a new starter, then test them with the phrasing your customers actually use.
Two failure modes sit either side. An agent that ignores a request for a person and keeps answering is why customers learn to hate bots. An agent that hands over everything the moment it is unsure has only moved your queue.
What context has to travel with the customer?
Enough that the person picking up can start at the customer's problem rather than their name. That means who they are and how to reach them, which channel they came in on, a two-line summary of what they want and what has already been tried, and the full transcript for anything the summary missed. Summary first, because that is what gets read. Transcript underneath, because that is where the detail lives.
When WireDesk opens a ticket in a connected helpdesk (Zendesk, Freshdesk, HubSpot, Intercom, Help Scout, Gorgias or Odoo) the ticket carries exactly that: the agent's summary, the customer's name, email and phone where it has them, the channel, a link back to the conversation, and the whole transcript. In Zendesk the transcript goes in as a private note, so the customer's 'we got your request' email doesn't repeat the conversation back to them. The agent then gives the customer the ticket number, so they leave with a reference.
Should handover be live or asynchronous?
Live when someone is there to take it and the customer needs it now. Asynchronous, meaning a message taken or a ticket opened, when nobody is, or when the answer needs research anyway. The mistake is promising live and delivering async. A customer told 'someone will be right with you' who then waits twenty minutes has been treated worse than one told 'I'll pass this to the team and they'll email you today'.
So give live handover a clock. In WireDesk chat, a request for a person flags the conversation, notifies your team by email or SMS with a link straight to it, and shows the customer that someone is being asked to join. The agent keeps answering while it waits, because a request is not a pause, and asks for a name and a way to reach them so nothing is lost. If nobody joins in time, the request times out somewhere between ten and twenty-five minutes after it was made, and the agent says plainly that nobody is free and asks how to follow up.
The analytics page counts every request for a person and what share of them a person answered, with the typical wait. That figure tells you whether live handover is a promise your team can keep.
How is handover different on phone, chat and email?
On the phone, handover is a transfer. A caller can't be parked in a widget, and 'someone will call you back' is a step down from a person now. WireDesk's phone agent tells the caller it is putting them through, then transfers the live call to the handover number set for that agent. It is a direct transfer: the person who answers gets the caller, not a spoken briefing, and the transcript and summary land on the conversation in the dashboard. If the transfer fails, the agent apologises and takes a message instead. The handover number must be a different line from the one forwarded to the agent, or the call would come straight back, and WireDesk checks for that before it transfers.
There is one handover number per agent. If billing and technical support need different people, route that inside your own phone system, or run a separate agent for each line.
In chat, a teammate claims the flagged conversation or simply replies from the dashboard. The agent stops answering the moment they do, and their replies appear in the customer's widget, so from the customer's side the conversation just carries on.
Email is already asynchronous, so handover is quieter. The thread is flagged, a teammate replies from the dashboard, and the reply reaches the customer in the same thread, sent from the agent's address. Nobody needs to be told to hold.
What should happen after hours?
Nobody is there, so don't offer anybody. In WireDesk you set business hours per agent, in your own time zone. Outside them, chat and email stop offering a person at all; the agent says it can't put anyone through right now and offers to take a message. A taken message records the customer's name, a callback number or email (on a call, it can use the number they are calling from) and what they need, and your team is notified.
Phone is the exception to watch. Business hours govern chat and email handover, not call transfer: if a handover number is set and call transfer is on, the agent will transfer at three in the morning. Point that number at somebody on call, or switch call transfer off out of hours so the agent takes a message instead.
How does the conversation get back to the agent?
Deliberately, or by default. A teammate who has finished hands the conversation back from the dashboard and the agent resumes. One who simply gets pulled away doesn't strand the customer: after half an hour of silence from the person who took it, WireDesk hands the chat or email back to the agent automatically. A transferred call doesn't come back, because the caller is on your line now, and it is filed as handed over.
Nothing is billed for the human part. Replies your team types aren't metered, and a transferred call stops counting minutes when the caller leaves the agent.