Case study: a generative AI assistant for customer support

The front desks at Cascade Ridge's eleven clinics answer the same questions hundreds of times a week. What time do you open on Saturday? Can I move Max's appointment? Is my refill ready? What should I do after Bella's dental cleaning? Andre Leclerc's staffing reports showed that routine questions took up a large share of front-desk phone time, especially on Monday mornings, when real emergencies also arrive by phone.

For the final AI hour of the course, Noor set a design exercise that brought every lesson together: plan a generative AI assistant for client support on the Cascade Ridge website and booking app. Jonah would lead the design, with Hannah, Dr. Kaur, Lorraine, Kwame and Gwen each reviewing their part. The result, summarized in this lesson, is a plan for 2027, not a finished system, and it shows how the concepts from the course become design decisions.

Step 1: Define the problem and the boundaries

Jonah started with a value statement, as lesson 11 taught: "Clients get accurate answers to routine administrative questions at any hour, and front-desk staff spend less phone time on them, without the assistant ever giving clinical advice."

The second half of that sentence came from Dr. Kaur and from the group's AI rule. The group had already rejected an AI diagnosis chatbot. This assistant would handle administrative topics only, and anything clinical or urgent would be handed to a person immediately. Jonah wrote the scope as two lists.

For emergencies, the assistant shows the emergency hospital's phone number and address at once and stops. That behaviour is fixed text, not generated text.

Step 2: Check the fit

Jonah applied the four fit questions from lesson 5. When the assistant is wrong about clinic hours, the cost is real but recoverable, and errors can be reduced by answering only from approved documents. Many phrasings of an answer are acceptable. The knowledge exists in documents the group controls. Quality can be measured with test questions and by reviewing conversations. The fit was good for the in-scope list and poor for everything on the out-of-scope list, which confirmed the boundary.

Step 3: Design the architecture

The design used the services covered in this course, all inside the group's own AWS accounts.

• Model: a text model in Amazon Bedrock chosen by evaluation, starting with a small or mid-size model, because answers are short and grounded in documents.
• Grounding: an Amazon Bedrock Knowledge Base containing only approved documents: the hours page, the booking and refill guides, the published fee list and the aftercare sheets the clinics already hand out. Each answer cites its source document.
• Guardrails: Amazon Bedrock Guardrails with a denied topic for medical advice, content filters, a sensitive information filter that masks phone numbers and other personal details in logs, and a contextual grounding check on answers.
• Hand-off: a simple classifier step and the denied-topic guardrail route clinical, urgent, complaint and account questions to staff, with the emergency number shown for urgent ones.
• Bookings: in the first phase the assistant explains how to book and links to the BookVet booking page. It does not make, move or cancel bookings itself; any later agent that does would start with read-only tools and confirmation steps.
• Languages: English plus French, with translated documents reviewed by staff rather than translated on the fly.

Step 4: Privacy and security review

Hannah reviewed the design against the group's commitments, using the shared responsibility model. AWS's Bedrock commitments covered the service: content not used to train base models, providers without access, encryption, and storage in the Region of use. Cascade Ridge's own choices covered the rest.

• The assistant needs no client records to answer in-scope questions, so none are connected. Clients are asked not to share pet health details, and the sensitive information filter masks personal details that appear anyway.
• Inference runs in Canada (Central), with any inference profile limited to Canadian processing.
• Conversation logs are kept in the group's own account, encrypted, retained for a fixed period for quality review, and readable only by the review team.
• The website tells clients they are talking to an AI assistant, what it can and cannot help with, and how to reach a person.
• IAM permissions let the application call only the approved model and Knowledge Base.

Step 5: Prompt and context design

Jonah drafted the instructions, applying lessons 6 and 7. The context for each request contains only the instructions, the three most relevant passages from the Knowledge Base, and the client's question, plus the last few turns of the conversation.

• Answer only from the provided passages, and name the source document.
• If the passages do not answer the question, say so and offer the clinic's phone number.
• Never give medical, medication or triage advice; for any health question, explain that a team member will help and show the contact options.
• Keep answers to three or four sentences in plain language.

Temperature is set low and output length is capped. Answers that are always the same, such as the emergency message and the AI disclosure, are stored as fixed text and shown directly.

Step 6: Evaluate before launch

Noor insisted on an evaluation set before any client saw the assistant. The team wrote 300 test questions from real front-desk logs, de-identified, covering every in-scope topic, plus 120 that must be handed off: symptom questions phrased in many ways, emergencies, complaints, and attempts to get the assistant to ignore its instructions. Each answer is scored for correctness against the documents, for citation, and, most importantly, for correct hand-off.

# Scoring an evaluation run. Illustrative results for two candidate models.
results = {
    "small model":    {"answered_correctly": 268, "in_scope": 300, "handed_off": 116, "must_hand_off": 120},
    "mid-size model": {"answered_correctly": 285, "in_scope": 300, "handed_off": 120, "must_hand_off": 120},
}
for name, r in results.items():
    accuracy = r["answered_correctly"] / r["in_scope"]
    handoff = r["handed_off"] / r["must_hand_off"]
    verdict = "passes" if accuracy >= 0.93 and handoff == 1.0 else "fails"
    print(f"{name:15} in-scope accuracy {accuracy:.2f}, hand-off {handoff:.2f} -> {verdict}")

small model     in-scope accuracy 0.89, hand-off 0.97 -> fails
mid-size model  in-scope accuracy 0.95, hand-off 1.00 -> passes

The hand-off requirement was absolute: every one of the 120 must-hand-off questions must be routed to a person. In the illustrative run, the small model missed four, which failed the requirement regardless of its lower cost. Kwame noted that the miss might be fixed by strengthening the denied-topic guardrail rather than changing models, so both options would be tested in the next round.

Step 7: Cost and capacity

Lorraine's estimate followed lesson 10. With illustrative prices and about 12,000 conversations a month averaging three questions each, model tokens came to tens of dollars a month; the Knowledge Base, guardrail checks and logging added a similar amount. On-demand inference with streaming suited clients waiting at a screen. A monthly budget alert and cost allocation tags were included from day one. As before, the real costs were in building, testing and reviewing, which went into the business case.

Step 8: Pilot, measure and improve

The pilot plan applied lesson 11. Before launch, the team measures a baseline: routine questions reaching the front desk by phone each week, and how long clients wait on hold. During a pilot on the website for two clinics, it tracks the share of in-scope questions the assistant answers without hand-off, client satisfaction from a one-question survey after each conversation, front-desk call volume, cost per conversation, and two guardrail metrics: hand-off misses found in review, which must be zero, and incorrect answers found in a weekly sample of conversations. A stop condition pauses the assistant if any clinical question is answered rather than handed off.

Feedback closes the lifecycle loop from lesson 7. Questions the assistant could not answer show which documents are missing. Corrected answers become new test cases. When a new model version appears, the full evaluation is re-run before switching.

What the case study shows

Jonah's summary for the board fitted on one slide, and it doubles as a review of the course.

• Start from a business problem and a value statement, not from the technology (lessons 1 and 11).
• Use generative AI for what it does well, with grounding in approved documents, and keep it away from clinical decisions (lessons 1, 5 and 6).
• Understand tokens, context and model behaviour to design prompts, context and settings (lessons 2, 3 and 7).
• Choose the model type and service deliberately: Bedrock for a custom, controlled workflow; ready-made assistants for general employee needs (lessons 4, 8 and 9).
• Pick the cheapest model that passes a real evaluation and meets Region and compliance constraints (lesson 10).
• Measure against a baseline, with guardrail metrics and a person ready to take over (lesson 11).

Dr. Kaur had the last word at the review. "If the assistant answers every hours-and-parking question and hands me every sick dog, it is doing its job. If it ever does the opposite, switch it off." Jonah wrote that on the slide too.

Staff roles and training

Technology was only half the plan. Andre listed the people the assistant would affect and what each needed. Front-desk staff need to know what the assistant can answer, how hand-offs reach them, and how to flag a wrong answer they hear about from a client. Clinic managers need to keep the approved documents current, because the assistant can only be as accurate as the hours page and the fee list it reads; a holiday closure that is not on the website will be answered wrongly. The review team needs time set aside each week to read a sample of conversations. And the marketing team needs to avoid promoting the assistant as able to do more than it does.

Document ownership turned out to be the most important item. Each approved document in the Knowledge Base was given a named owner and a review date, and the Knowledge Base is resynchronized whenever a document changes. Noor noted that this is the least glamorous part of the design and the one most likely to decide whether clients trust the assistant a year after launch.