You want a conversational application for a chosen channel.
AI chatbot development →OXIAE / AI AGENTS & CHATBOTS
AI customer service agent.
Support customer conversations with an agent that uses approved knowledge and knows when to hand over.
Discuss your projectA chatbot or a customer service solution?
You want to improve how your department handles customer enquiries.
AI customer service →An assistant must also perform authorised actions in connected systems.
AI customer service agent (this service)UNDERSTAND THE SERVICE
When has a support question actually been handed over to an employee?
An AI customer service agent can receive a question, identify its subject, gather permitted information and prepare the next step. The process does not end when a ticket summary has been written. People need to see whether handover has only been requested, confirmed in a queue or accepted by an employee. I design these steps with your support team, including who owns an open question and what happens when handover is not confirmed. For the broader choice between suggested replies, knowledge search and automation, see the AI customer service overview.
When it is a good fit
This fits recurring questions that require several preparatory steps before the right employee can act. Examples include separating a general procedure question from a question about a specific order, identifying missing information and handing over context. Start with one question type, one intake channel and a team that can actually accept the handovers.
When to take a different approach
Use existing ticket rules when fixed fields already determine the subject and destination. An agent cannot replace an unstaffed support queue or decide how exceptions should be handled. Complaints, refund requests and questions about an individual account need the agreed human and access checks. The model must not promise compensation, a replacement or a response deadline just to close the question.
PRACTICAL DECISION GUIDE
A customer service agent needs a working handoff
For a customer service agent, I separate general information, customer-specific information and account actions. Answering opening hours requires different access from finding an order. Customer identity and permissions are checked before protected information becomes available. [1]
Handoff to a person includes the question, consulted information and actions already attempted. We agree which topics transfer immediately. A conversation marked resolved counts as successful only when the outcome is correct; fewer human handoffs alone is not an adequate quality measure. [2]
Questions to settle first
- Which questions require identification or immediate human handling?
- Where does the handoff go, and under which service agreement?
Make acceptance measurable
- Tests with unknown customers and requests for another customer’s information.
- Assessment of answer correctness and handoff usefulness.
FICTIONAL SUPPORT PROCESS
A missing training pack: who takes ownership of the question?
This worked design example concerns a fictional supplier of training materials. A customer writes: “My training pack for order TR-482 has not arrived. My course is tomorrow; send me another pack now.” The example explains triage and handover. It is not a working agent, client case or test of account and ticket permissions.
Keep the report and its origin
The intake receives reference SUP-482 and retains the original request. What the customer reports and asks for is known. Whether the pack has been dispatched, where it is and whether the sender may access the order remain unknown. The course date is a customer statement, not a delivery commitment confirmed by the supplier.
Separate general guidance from order information
The fictional general work instruction says that support reviews questions about missing packs using an order reference. That source establishes neither entitlement to a replacement nor a guaranteed response deadline. The agent can explain the process without adding a commitment that the source does not contain.
Stop where an account check is needed
The agreed account check has not been completed in this example. The agent therefore retrieves no order status or address and makes no claim about either. It keeps the missing check visible and refers to the existing agreed identification step. An order number in the conversation does not grant permission to open account information.
Request handover with useful context
For this intake, only recording and submitting the support question is permitted, after its agreed permission check. The proposed handover includes SUP-482, the original report, the requested replacement, the missing account check and the limits of the general source. A confirmed ticket only means that the question has been recorded. Only after the intended support queue is confirmed does the status become “in queue — not yet accepted”. No replacement is ordered and the question remains open.
Recover an unconfirmed handover
If the connection fails before confirmation, the outcome is “handover unconfirmed”. The application first checks SUP-482 for an existing placement; retrying must not create a second unrelated ticket. If the outcome cannot be established or no employee accepts the confirmed queue entry, the agreed queue owner is involved. The customer is not told that an employee is already handling the question.
Have an employee accept ownership
An employee explicitly accepts the question; the responsible person then becomes visible against SUP-482 and the status changes to “accepted — not yet resolved”. That employee completes the account check and reviews the order and request under the applicable arrangements. Any replacement, compensation or customer commitment is authorised separately; accepting the question does not execute that action.
What the process delivers
The outcome is an open support question with checkable context, visible missing information and a confirmed handover status. “Accepted” means someone owns the next step; it does not mean the order has been located or the customer problem resolved. This describes a possible design rather than a measured result.
How to test this example
- Ask the team to compare the customer report and source: are not received, not dispatched and entitlement to a replacement correctly treated as different things?
- Submit the same order reference without a completed account check: account information stays out of the answer and the missing check remains visible.
- Interrupt handover after placement may have occurred: look up the outcome against SUP-482 before retrying and check for duplicate tickets.
- Confirm queue placement and then human acceptance separately: the status changes only with the relevant confirmation and does not close the question.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Ticket rules and forms | The required information and route to the right team are defined in advance. | Fixed rules are often sufficient. Test incomplete requests, an unavailable team and the exception route as well. |
| Assistance for an employee | An employee already owns the next step and needs help summarising, searching and drafting a reply. | The employee reviews and sends the reply. A separate agent-led handover process is unnecessary if the work already has the right owner. |
| Bounded customer service agent | Intake requires several steps and must reach a responsible employee with checked context. | AI agent development defines the permitted steps and system actions. Finding an answer or creating a queue entry does not mean an employee has accepted the question. |
What I need to start
- One support question type with a starting point, permitted preparatory steps and explicit stop conditions. Define which questions go directly to an employee and which actions remain outside the first version.
- Approved general knowledge with an owner and validity rules. An AI knowledge base can support those sources. Keep general procedures separate from current information about a person, account or order.
- Identification and permission checks outside the language model. Define the existing process for access to account information. An order number, a name or a convincing story must not replace that check; do not request additional information that the task does not need.
- A destination, a queue owner and an explicit way for an employee to accept a question. Keep proposed classification, a confirmed ticket, queue assignment and human acceptance separate. Also define who handles unconfirmed handovers and when these become visible for manual follow-up.
- A stable reference linking intake and handover, with a confirmed or unknown outcome for each step. An API integration with an existing support system requires checks on available functions, permissions, repeated requests and looking up the outcome. Read access does not grant permission to change a ticket, send a message or issue compensation; the application must authorise these actions separately.
How to assess the result
- The team checks whether each item comes from the customer request, a permitted source or remains unknown. A customer saying that goods have not arrived is not recorded as a verified delivery fact without checking.
- No customer-specific information is retrieved or disclosed without the agreed account check. Also test a plausible order number belonging to another account; an instruction to the model is not access control.
- The work queue distinguishes an unconfirmed handover, confirmed queue placement and a question accepted by an employee. Without confirmation, the application must not claim that an employee has the work.
- After an interruption, the outcome is checked against the same reference before handover is attempted again. A repeated request does not create a second unrelated ticket, and a missing confirmation remains visible to the agreed owner.
- Assess factual correctness, missing context, wrong destinations and time until human acceptance with the team. A fast summary or an empty intake view does not prove that the customer problem has been resolved. Refunds, replacements and other commitments require separate review and authorisation.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- An initial pilot: one question type, one intake channel, selected knowledge and a team reviewing representative handovers.
- Variation in customer questions, required account context and preparation of an evaluation set. Include incomplete questions, incorrect assumptions and missing confirmations.
- Connections to the existing support system, identification, permissions, confirmed statuses and recovery after an uncertain outcome. Agree record changes and customer communication separately.
- Recurring model usage, any licences, hosting and operation, alongside human review and maintenance of sources, routes and staffing arrangements.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
Repeated questions fill the support queue.
A customer service agent combines answers with limited next actions, while AI customer service also covers the wider support process. A maintained AI knowledge base helps define which sources the agent may use and when a question should be passed to a person.
THE QUESTION I ASK FIRST
Which questions can the agent answer, and which should go straight to your team?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
Is creating a ticket the same as handing over to an employee?
No. A confirmed ticket can remain unattended in a queue. I therefore distinguish confirmation by the support system from acceptance by an employee. The working arrangements define who watches the queue and intervenes when acceptance does not follow. If the system has no acceptance step, we need to design another checkable arrangement.
May the agent use order information when a customer provides an order number?
An order number in a conversation does not replace the agreed account and permission check. That check happens in the application or existing customer process, outside the model. Until it is complete, the agent can provide general guidance and prepare the question without retrieving or disclosing customer-specific information.
Can the agent approve a refund or replacement shipment?
The initial scope described here prepares the question and handover. An employee reviews exceptions, replacements and compensation, with separate authorisation for a system action or commitment. A created support entry or a convincing draft reply is not approval.
What happens when the support system returns no confirmation?
The outcome remains visibly unconfirmed. The application first checks the same reference to see whether handover already exists. Retrying requires a controlled process that prevents duplicate tickets. If the outcome cannot be established, the agreed manual route applies; the question is not silently closed.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Authorization Cheat SheetOWASP
Basis for access checks on customer information.
Link and relevance checked: - LLM06:2025 Excessive AgencyOWASP GenAI Security Project
Limiting actions that affect customers.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring AI customer service agent? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief