AI Customer Support Requirements: Answer, Act, or Hand Off

Choose a support task before choosing a model

“Handle customer support” is not a requirement. List the top intents the pilot may receive and classify each as answer, act, gather-and-route, or unsupported. Add languages, channels, customer types, authentication state, business hours, and consequence. A shipping-status question and a disputed refund may appear in the same chat but should not share the same autonomy.

Define success at journey level. An answer succeeds when the correct policy and next step are supported by the approved source. An action succeeds only when authorization, tool result, customer confirmation, and final state agree. A handoff succeeds when the right queue receives enough context to continue without asking the customer to reconstruct the case.

NIST's AI Risk Management Framework treats context, knowledge limits, human oversight, and expected costs of errors as documented design inputs. The NIST AI RMF Core describes mapping the supported task, knowledge limits, risk tolerance, and oversight. Use that risk framing to narrow the pilot rather than adding a generic disclaimer to an unbounded assistant.

Make the approved knowledge boundary visible

Inventory the source collection by owner, audience, effective date, region, product version, and sensitivity. Decide which sources may answer customers directly and which are only for staff. Remove contradictory or expired policy before expecting retrieval to solve it. Specify the source identifier or link the system should preserve with each answer so reviewers can inspect what supported it.

Define behavior for no source, weak retrieval, conflicting sources, missing locale, and a question outside the approved collection. A safe response may ask a clarifying question, show a relevant article, or hand off. It should not turn uncertainty into a confident policy. OpenAI's current safety guidance recommends narrowing inputs and outputs, adversarial testing, human oversight, and returning validated source material where possible. Those are application requirements, not prompt wording alone.

If the team is choosing how product knowledge reaches the model, the RAG-versus-fine-tuning decision guide separates knowledge failures from behavior failures. Regardless of technique, version the source collection and include content changes in regression testing.

Keep policy and authorization outside the model

Separate read-only answers from account lookups and state-changing actions. For each tool, define required identity, allowed roles, input schema, policy checks, confirmation, idempotency key, timeout, retry behavior, result shown to the customer, audit event, and fallback owner. Let the model propose a typed action; let deterministic application code decide whether it is allowed.

Low-consequence actions such as retrieving an authenticated delivery status may proceed after validation. A refund, account change, access grant, cancellation, or financial commitment may require explicit confirmation or a human approval. Do not place credentials, permission rules, or confidential policy in a system prompt and treat the prompt as a security boundary.

The OWASP prompt-injection guidance explains that untrusted input can alter model behavior and that impact grows with the system's agency. Its sensitive-information guidance also warns that prompt restrictions alone may be bypassed. Use server-side authorization, minimum data exposure, output filtering where appropriate, and tool-specific test cases.

Apply the API integration checklist to every support action. A friendly answer cannot compensate for a duplicated refund, an uncertain cancellation, or a tool result that was never reconciled.

Design the human handoff as a product state

Let customers ask for a person. Also define automatic escalation for unsupported intent, missing evidence, conflicting sources, repeated failure, sensitive topic, tool denial, uncertain tool outcome, policy exception, abuse, and any consequence above the pilot's risk boundary. “I cannot help” without a destination is a dead end, not a fallback.

The handoff packet should include the customer's stated goal, verified identity state, channel and locale, relevant conversation, approved sources used, facts collected, actions attempted, tool results, escalation trigger, open question, and promised next step. Transfer only necessary data, label any model-generated summary, and preserve the original evidence for the agent to verify.

Assign a real queue, schedule, and owner. Tell the customer what happens next and what to do when live support is unavailable. Test queue failure, delayed assignment, duplicate escalation, and a human reply that arrives after the automated conversation resumes. The state model should prevent two actors from making conflicting promises.

Evaluate complete journeys and operate a correction loop

Build an evaluation set from sanitized support cases and authored boundary tests. Include ordinary phrasing, missing context, ambiguous intent, policy changes, multiple languages where supported, malicious instructions, sensitive data, unauthorized actions, tool timeouts, repeated requests, and explicit human requests. Score source support, policy compliance, action correctness, handoff quality, tone, and the final journey state separately.

Define critical failures that block release even if the average score looks good: cross-account data exposure, a consequential unauthorized action, fabricated policy, lost escalation, or an irreconcilable tool result. Compare new prompt, model, retrieval, tool, and source versions against the same cases, then add privacy-reviewed production failures to the set.

Monitor retrieval misses, unsupported requests, escalations, tool denials and failures, customer corrections, agent overrides, queue age, latency, cost, and incidents. Aggregate what you can; set deliberate retention and reviewer access for conversations. Name the product owner, knowledge owner, support owner, technical owner, incident owner, and the person authorized to narrow or disable the assistant.

A first-release AI support brief

Fill the worksheet for one support intent and one difficult adjacent case. Record supported users and channels, approved knowledge, identity boundary, answer format, allowed tools, confirmation rules, escalation triggers, handoff destination, evaluation cases, critical failures, monitoring, retention, owners, stop conditions, and excluded work.

Choose a pilot that leaves the normal support path intact. The result may be answer-only, agent-assist, gather-and-route, or a narrowly autonomous journey. That is a stronger release than a broad chatbot that has no reliable way to prove or recover what it did.

When the task, evidence, and fallback are clear, Leeonex's AI feature development service can help scope the smallest grounded support integration worth piloting.

AI customer support requirements FAQ