AI Support Agent for an E-commerce Platform
A micromobility rental platform was drowning in thousands of repetitive tickets. We deployed an AI agent that processes tickets, resolves standard questions, and escalates complex cases to operators.
- 11 644tickets processed
- 26.5 minavg response time
- 41.5%closed by bot
- 4 689escalated / week (down)
Industry context
Support in micromobility works differently from classic e-commerce. The product is physical, scattered across a city, and it breaks, so tickets are tied not to an order but to a specific device and its state right now. Load peaks in the evenings and on weekends, exactly when the operator shift is thinnest. Add seasonality: in warm months ride volume multiplies, and the queue with it. Hiring for the peak is impossible, because those people would have nothing to do in winter. That is why automating support pays off more here than in a shop shipping boxes from a warehouse: the gap between average and peak load is far deeper.
The challenge
The support team received thousands of tickets a month, mostly repetitive: order status, breakdowns, returns, payments. Operators spent most of their time copy-pasting answers, response time spiked at peak hours, and complex cases got lost in the shared queue.
Our approach
- 01
Ticket audit
We analyzed ticket history and isolated the top intents that cover most of the queue.
- 02
Knowledge base + classification
We assembled answers into a structured knowledge base and taught the agent to detect ticket intent.
- 03
Routing & escalation
We defined rules: standard cases are closed by the bot, complex ones go to an operator with full context.
- 04
Launch & tuning
We launched on part of the traffic, collected errors, and iteratively raised accuracy.
How the solution works
- 01ZendeskA new ticket arrives
- 02n8n + GPT-4oClassifies the intent
- 03PostgreSQLFinds the answer in the knowledge base
- 04GPT-4oDrafts the reply
- 05OperatorGets complex cases with a summary
A GPT-4o agent inside an n8n pipeline is connected to Zendesk. Each new ticket is classified by intent, the agent searches a PostgreSQL knowledge base and drafts a reply; complex or emotional cases are auto-escalated to an operator with a summary and references.
Why this stack
Zendesk stayed the system of record: the agent does not replace the helpdesk, it works inside it, so operators keep their familiar queue and full history. n8n took over orchestration, because every ticket runs through several branching steps: classify, search the knowledge base, verify, then answer or escalate. Keeping that logic in code would mean rewriting and redeploying a service every time a rule changes; in a visual pipeline it is a one-node edit. PostgreSQL backs the knowledge base instead of a separate vector database: the answer set is measured in thousands, not millions, and pgvector inside the existing database removes one more system to maintain. GPT-4o was chosen for the combination of Ukrainian-language quality and speed: in support, response latency is felt more sharply than the last few percent of accuracy.
Where projects like this usually break
A bot that will not give up
The costliest mistake is forcing the agent to always answer. A customer with a broken device in the middle of the street, trapped in a clarification loop, costs more than a dozen unresolved tickets. A confidence threshold and instant escalation matter more than the automation percentage.
A knowledge base that goes stale quietly
Prices, parking zones and return terms change; the knowledge base does not. The agent confidently quotes last year's rules, and you only find out from complaints. You need an owner for the base and an update routine, otherwise accuracy decays invisibly.
Measuring the wrong thing
The share closed by the bot looks convincing until you find that some "closed" tickets simply reopen under a new number. What you must count is repeat contacts from the same customer, not closures.
Results
| Before | After |
|---|---|
| Operators copy-pasted the same answers | 41.5% of tickets are closed by the agent alone |
| Complex cases got lost in the general queue | Complex and emotional tickets reach an operator with a summary and links |
| Response time spiked at peak hours | Average response time 26.5 min across 11,644 tickets |
First working result in 2 weeks; full rollout within a month.
Who this fits
This kind of agent pays off where most tickets repeat and have a definite answer: order status, return terms, pricing, common breakdowns. The rough threshold is a few hundred tickets a month plus a visible gap between average and peak load. If volume is low, or every case is unique and needs negotiation, it is cheaper to equip operators with templates and search than to build an agent. Also weigh how stable your rules are: if pricing and terms change weekly, fix the source of truth first and automate answers to it second.
Frequently asked
Does the AI agent replace support operators?
No. It removes the repetitive part of the queue so operators can handle the hard cases: refunds, conflicts, non-standard situations. Complex or emotional tickets are handed to a human along with a conversation summary, so the operator does not start from scratch.
What happens when the agent does not know the answer?
A confidence threshold fires: instead of guessing, the ticket goes to an operator tagged with the reason for escalation. That is a deliberate choice: better to escalate once too often than to hand a customer a confidently worded falsehood.
How long does it take to launch an agent like this?
The first working result usually takes two weeks: ticket audit, a knowledge base covering the top intents, launch on part of the traffic. Full capacity takes about a month, because you need real conversations to surface errors and raise accuracy.
Can this agent work with a helpdesk other than Zendesk?
Yes. The logic lives in n8n and the helpdesk is attached through a connector, so Freshdesk, HelpScout, Intercom or an in-house system with an API means reworking the integration layer, not the agent itself. The same goes for channels: Telegram, WhatsApp and email plug into the same pipeline.