How to Build a Customer Service AI Agent (That Actually Resolves Tickets)

A customer service AI agent earns its keep by resolving the routine tickets outright and handing you the rest with the context already gathered. That second half is what separates a useful agent from a deflection bot that frustrates people into giving up. The goal is not to answer everything. It is to answer what it can, and escalate what it can't without making the customer repeat themselves.

On Deelo you build this as a no-code agent in the AI Assistant: give it a role and instructions, grant it the support apps it needs as tools, set a per-tool permission grid, and write clear escalation rules. This guide walks that build. For the strategy question of chatbot versus agent versus live chat before you start, live chat vs chatbot vs AI agent covers it; here we are configuring the agent itself.

Set expectations honestly up front, because it shapes every setting. The agent can read a conversation, pull up the customer and their history, answer from your knowledge and policies, and resolve the informational tickets -- hours, order status, how-to questions, policy explanations -- right there in the conversation.

What it does not do on its own is fire off external messages or take risky actions unsupervised. Sending an email or SMS to a customer is an external send, and on Deelo external sends stay approval-required under the high-risk floor even at full autonomy. Issuing a refund is money movement, which is on the same floor. So the honest shape of the agent is: resolve in-conversation where it can, draft-and-route where a send or a refund is involved, and escalate cleanly where judgment is needed. That boundary is a feature -- it is why you can trust it in front of customers at all.

Open the builder and create the agent -- call it something concrete like 'Support Front Line.' The instructions are its brain, in plain English: what it handles, the tone you want (warm and brief usually beats corporate), the policies it should rely on, and the hard rules it must never break. Spell out the never-dos: never invent a policy, never promise a refund, never guess at a delivery date, always offer a human for anything about money or a complaint.

The most important line in a support agent's instructions is the escalation rule, so write it deliberately: when to stop and hand off. 'If the customer is upset, asking for a refund, or raising something not covered in the knowledge base, summarize the issue and escalate to a human.' You can start from the shipped Support agent template, which arrives pre-briefed, and adjust from there.

A support agent needs a small, deliberate tool set. Grant it LiveChat so it can read the incoming conversation and its history, and CRM so it can look up the customer, their orders, and past tickets to answer in context. Add your knowledge base so it answers from your real policies rather than improvising. That is usually enough.

A note on deployment, because it trips people up: the agent can be deployed as its own public shareable web chat link -- that is a channel you switch on, a public shareable link priced like regular AI Assistant chats. Granting it LiveChat is a separate thing: LiveChat is a tool the agent reads and works within, not a widget the agent 'staffs.' Keep those straight. Resist handing the agent every app 'just in case' -- a narrow tool set is easier to predict and safer.

For each tool, set what the agent may do per verb. A safe support grid looks like this: read on conversations, customers, and orders -- allow, so it can see everything it needs to help. Write on internal notes or ticket tags -- allow, so it can log what happened. Delete -- off, always. Send an email or SMS to the customer -- allow-with-approval, so a draft lands in front of you before anything leaves for the customer's inbox.

That last setting is not optional friction; it is the high-risk floor doing its job. External sends stay approval-required no matter how much autonomy you grant, which is exactly why you can let the agent handle real conversations without worrying it will send something wrong to someone. Anything touching money -- a refund, a credit -- sits on the same floor and routes for approval or to a human. The companion guide, AI agent permissions and guardrails, walks the full grid with worked examples.

The handoff is where support agents live or die, so make it explicit. Tell the agent to escalate on three triggers: emotion (the customer is frustrated or angry), risk (anything involving a refund, a dispute, or money), and the unknown (anything your knowledge base does not cover). When it escalates, it should pass a written summary -- who the customer is, what they want, what it already tried -- so the human picks up warm, not cold.

One more rule matters on a public channel: an anonymous web visitor can never approve a high-risk action. If a stranger on your site asks the agent to do something on the floor, it defers and reports rather than acting -- it cannot be talked into it. That defer-and-report behavior is the safety mechanism that lets you put an agent in front of the public at all.

Before it goes live, feed it your hardest real tickets, not the easy ones. Give it a routine question and confirm it resolves cleanly. Give it an angry refund demand and confirm it escalates with a good summary instead of promising anything. Give it something ambiguous and see whether it asks a smart clarifying question or barrels ahead.

If it ever tries to send a customer message without routing for approval, or attempts a refund on its own, stop and tighten the grid -- though the floor should already be catching those. Start it assisted so you review its work for the first week, then loosen autonomy on the routine paths as it earns trust. Sends and money stay on the floor regardless; that part never loosens, and that is the point.