Where to start with AI · First workflow No. 3

Handling routine customer requests

A customer request assistant, rolled out in two stages: first it helps agents answer, then it answers the approved standard request types on its own.

A first AI use case doesn’t need to be spectacular. It does need to be narrow enough to test, measure, and improve.

Download the Scoping Sheet (PDF, 2 pages) View the Carousel (PDF)

Low risk, but only within a strict scope

Customer requests about order status, shipping and return terms, and how to use a product meet all four tests of a good first workflow: they come up often, they have a clear owner, they call for a clear output, and they are a pain point that agents and customers already feel.

The use case is low-risk only within a strict scope:

Informational requests order status, terms of sale, product guides.
Order data read-only access, authenticated customers only.
No commercial decisions no refunds or goodwill credits left to AI.
Complaints, disputes, and sensitive cases routed to an agent.

The assistant answers from data and documents the company already owns. The risk does not go away. It becomes more visible, measurable, and manageable once the sources, the scope, and the escalation rules are defined.

A three-step approach

Get the sources ready

Approve the standard replies, resolve conflicts, assign an owner to each document, and define which data can be accessed. The tool comes after.

The assistant drafts, the agent decides

The assistant drafts a reply that cites the relevant source or order. An agent reviews it, edits it if needed, and sends it. Every correction is logged, request type by request type.

The assistant answers approved request types

It answers when the request falls under an approved type, the customer is authenticated, and the reply can cite a current source or data point. It routes to an agent any complaint, dispute, or ambiguous case, any request involving a refund, goodwill credit, damage, or product safety, and any question whose source is missing, conflicting, or outdated.

Moving from stage 1 to stage 2

The move to stage 2 should not be decided in advance. It depends on what the customer service team observes during stage 1: the quality of the drafted replies, the corrections needed, and the system’s ability to recognize requests that fall outside its scope.

Accuracy of the reply and the cited sourceCorrections needed, by request typeExceptions routed correctlyNo significant incident observed within the tested scopeCurrent sources, each with an owner

Order status can move to stage 2 while product guides stay in stage 1.

Reference architecture: how the system stays under control

A hybrid architecture: order data accessed through a read-only API, limited to the authenticated customer; hybrid search (vectors + BM25) with reranking across the terms of sale, the FAQ, and the product guides; an LLM instructed to rely on this material and cite the source; input and output guardrails with routing to agents. A learning loop connects the log, team review, and the evaluation set.

Click the diagram to open it full size.

The controls required before any autonomous answer:

Evaluation. A reference set of about 150 real, anonymized requests. Metrics: accuracy, faithfulness to sources and data, correct citation, and the share of complaints, disputes, and out-of-scope cases detected and correctly routed. Rerun after every change to the model, prompt, or sources.

Observability. For each request, only what is needed is logged: the minimized request, references to the data and passages retrieved, the reply, control signals, and the routing decision. Access is limited to authorized staff, with a defined retention period.

Identity and access. Customer authenticated before any order data is shown. Access limited to the customer’s own orders, enforced at retrieval, not after generation.

Data. Hosting and data transfers verified for the chosen solution; contractual terms barring use of the data for model training; encryption; log retention and access defined; Swiss FADP assessment documented for the system as deployed.

Application security. Prompt injection defenses, including in incoming emails. The orchestration layer limits outbound actions to two: reply or route.

Corrections go first into improving the sources, routing, instructions, and evaluation set. Retraining the model is neither the starting point nor a substitute for that work.

The goal

The goal is not to replace agents. It is to cut response times on informational requests, stop the same replies from being rewritten, and give agents more time for customers who need to be heard or need a judgment call.

Download the Scoping Sheet (PDF) View the Carousel (PDF)

Illustrative case: fictitious company; all figures are approximate. Sergio Castagna Consulting is a member of the OpenAI Partner Network and a registered partner in the Google Cloud Partner Network. The tool comes after the problem is defined.