Where an agent fits if you already run a helpdesk
Most teams considering an email agent already have a helpdesk. The question is not whether to replace it, because you will not, but where the agent sits relative to it, and that choice decides whether you get a clean deployment or two systems arguing over the same inbox.
4 min read
Four placements
In front, on a category. A forwarding rule sends one category to the agent's address. It answers what it can, and anything else it forwards into the helpdesk as a normal ticket. Reversible in one click, and the usual starting point.
Behind, as a drafter. The agent never sends; it writes a suggested reply into the ticket for an agent to approve. Popular because it feels safe, and it is the placement with the weakest return: the work was never the typing, per what your team does once the agent handles the easy half.
Beside, on its own address. A new published address for a specific job, like order status or renewals, with the helpdesk untouched. Clean, and it works well when the category has a natural boundary.
Instead of, for a whole queue. The agent owns a queue end to end and escalates into the helpdesk. Correct eventually, and a poor place to start.
| Placement | Return | Risk | Start here if |
|---|---|---|---|
| In front, one category | High | Low | You have a clear repetitive category |
| Behind, drafting | Low | Very low | You need to build internal confidence |
| Beside, new address | High | Low | The job has its own natural address |
| Instead of, whole queue | Highest | High | You have already done one of the above |
The rule that prevents the mess
One address, one owner. Whichever placement you pick, no inbound address should be watched by both the agent and the helpdesk, because the two will answer the same customer within minutes of each other and occasionally contradict each other.
That sounds obvious and is violated constantly, usually by a forwarding rule that copies rather than moves, or by a helpdesk that keeps polling the mailbox it used to own. Check it explicitly after setup by sending one message and confirming exactly one system reacts, per the routing discipline in deciding what reaches your agent.
Handing over without losing the thread
When the agent escalates, the human needs the conversation, not a summary. Two ways to give it to them, and the difference matters.
Forward into the helpdesk. The thread arrives as a ticket with the full history. Simple, and the customer's later replies go to the ticket rather than back to the agent, which is usually what you want once a person owns it.
Mark unread and leave it. The thread stays in the agent's inbox, and a person works it there. Fine for small teams, and it means your helpdesk does not see the volume, which distorts your reporting if the helpdesk is where you measure.
Pick one per category and be consistent, because mixed handling is how threads end up half in each system, per when an agent and a person are on the same thread.
Your reporting will look wrong for a while
Worth flagging early because it causes arguments. Volume in the helpdesk drops, average handling time rises, and satisfaction scores move in ways nobody predicted, all because the easy tickets stopped arriving there.
None of that means the agent is failing. It means your baseline changed, and the numbers to watch are the ones in evaluating an email agent, measured across both systems rather than in the helpdesk alone.
The specific trap: judging the agent by helpdesk metrics it deliberately removed from the helpdesk.
What the helpdesk still does better
Being honest about this makes the deployment easier to sell internally.
Ticket workflows with SLAs, assignment, and internal notes. Reporting your team already trusts. A UI built for people working a queue all day. Integrations with everything else you use. Multi-channel, if you also do chat and phone.
An agent replaces none of that. It removes a category of work from arriving, which makes the helpdesk better at what it was already for. The comparison pages, Zendesk and Front, lay out what each is actually built to do.
A sensible sequence
- Pick one repetitive category with a documented answer.
- Forward it to the agent's address, leaving everything else alone.
- Escalations forward into the helpdesk as tickets.
- Read every thread for a week, per the first week with an email agent.
- Measure across both systems, not one.
- Widen the category, or add a second, once corrections are near zero.
Nothing about that requires changing your helpdesk configuration, which is the point: it is reversible at every step.
Questions
- Do I have to replace my helpdesk to use an email agent?
- No, and you should not plan to. The agent sits in front of one category, beside it on its own address, or eventually owns a queue and escalates into the helpdesk.
- Should the agent draft replies for humans to approve instead?
- It is the safest placement and the weakest return, because the typing was never the expensive part. Useful for building confidence, not as a destination.
- What is the most common setup mistake?
- Two systems watching one address, usually from a forwarding rule that copies rather than moves. Send one test message and confirm exactly one system reacts.
- How should escalations reach my team?
- Forward the whole thread into the helpdesk as a ticket, so the history arrives and the customer's next reply lands with the person who now owns it.
- Why did my helpdesk metrics get worse?
- Because the easy tickets stopped arriving there, which raises average handling time by removing the fast ones. Measure across both systems rather than in the helpdesk alone.
- What does the helpdesk still do better?
- Queue workflows, assignment, SLAs, reporting your team trusts, and multi-channel. An agent removes work from arriving rather than replacing any of that.
Give your agent an address it can answer from.
Create an inbox