Defining the Customer-Support Workflow and Acceptance Criteria

Welcome. This course builds a portfolio-ready AI customer-support platform by developing a thin, explainable product slice before adding infrastructure and models. The first decision is not which LLM or database to use; it is what customer outcome the product must reliably produce.

In this lesson, you will define the capstone’s primary workflow: a customer asks for support, the system attempts a grounded answer from the organization’s knowledge base, and it routes the conversation to a human agent when automation should stop. You will turn that workflow into user stories and measurable acceptance criteria that can later guide API, retrieval, UI, and test decisions.

---

Start with a deliberately narrow product promise

“AI customer support platform” is a product category, not yet a buildable feature. It could include chat, email, voice, ticketing, refunds, account changes, analytics, multilingual support, and more. Trying to define all of that at once invites an unfocused implementation.

For this capstone, choose one thin, complete vertical slice:

A customer submits a web-chat support question. The platform searches that organization’s approved knowledge base and either provides a cited answer or creates an escalated ticket for a human agent. An agent can review the conversation, resolve it, and the customer can confirm the outcome.

This is a useful primary workflow because it reaches the core of an AI support product:

• it gives a customer an immediate path to help;
• it uses organization-specific knowledge rather than generic model knowledge;
• it acknowledges that AI should not handle every case;
• it preserves a human support workflow rather than treating an LLM answer as automatic resolution;
• it gives you an end-to-end scenario to demonstrate in a portfolio project.

The Zendesk workflow image captures the high-level shape: a request enters, AI helps triage it, the system routes it, an outcome is reached, and the customer confirms it. Your implementation will give each of those labels precise behavior.

Before writing requirements, establish the boundaries of version 1. A clear boundary is as important as a feature list because it prevents accidental scope expansion.

In scope for the primary workflow	Explicitly out of scope for this first slice
Web-chat support questions	Email, social-media, and voice channels
Organization-specific knowledge-base answers	General web search
Cited answers when evidence is available	Unsourced answers presented as fact
Human handoff for unsupported or requested cases	Autonomous refunds, account changes, or other consequential actions
Agent review, resolution, and customer confirmation	Automatic closure after an arbitrary number of days
Basic escalation reason and conversation history	Advanced analytics, CSAT reporting, and agent-feedback learning loops

These are not permanent product limitations. They are intentional constraints that allow you to build and explain one reliable workflow before extending it.

---

Map the workflow before specifying the software

A support workflow should describe what happens to a request over time, who owns it, and the conditions that change its path. A useful starting frame is intake, triage, investigation, resolution, and closure.

Apply that framework to the capstone as follows.

1. Intake: capture a support request

A customer uses the web chat for a particular organization and submits a message. The system acknowledges receipt and preserves the message as part of a conversation.

At this point, the system should not claim that it has solved anything. It has accepted a request.

Input: a non-empty customer message associated with one organization.
Output: a conversation containing the new message, initially marked as open.

2. Triage: choose a safe path

Triage answers a limited operational question: can the platform attempt a knowledge-backed answer, or should this conversation be sent to a human?

For the initial slice, use only two paths:

1. Attempt an AI-supported answer when the customer has not requested a human and relevant knowledge-base evidence is available.
2. Escalate to a human when the customer explicitly asks for one or when the system lacks sufficient evidence.

Later lessons will add intent classification, urgency, and richer routing rules. Do not make those prerequisites for the first workflow. A small number of reliable branches is preferable to an elaborate but ambiguous routing scheme.

3. Investigation: find evidence before answering

For an AI-supported path, “investigation” means searching the organization’s approved knowledge sources for relevant material. The eventual retrieval system may use embeddings, full-text search, or both, but the workflow requirement should stay outcome-focused:

The platform may answer only when it has relevant, organization-scoped evidence to support that answer.

This requirement prevents an important failure mode: a fluent answer that sounds helpful but has no basis in the customer’s actual support documentation.

4. Resolution: provide an answer or human action

A resolution has two forms in the first version:

• Self-service resolution: the customer receives a concise answer with a citation to the supporting knowledge source.
• Agent-assisted resolution: an agent reviews the escalated conversation and records a final response or action.

A displayed AI response is not automatically a closed case. A customer may say the answer did not work, ask a follow-up, or request a person.

5. Closure: record confirmed outcome

Closure happens when the customer confirms the solution. In this version, lack of a reply is not confirmation. The platform keeps a closed conversation available as historical support context, but it should not mix records between organizations.

A small state vocabulary makes these rules visible and later gives the API and UI stable concepts to work with.

Conversation status	Meaning	How it is reached
open	A customer message needs processing or follow-up.	A valid message is received.
awaiting_customer	The system or agent has provided an answer and awaits the customer’s response.	A cited answer or agent resolution is sent.
escalated	Human review is required.	The customer requests a person or evidence is insufficient.
resolved	An agent has completed their support action.	An agent records a resolution.
closed	The customer has confirmed the outcome.	The customer confirms resolution.

The word status here is a product contract, not a database design. The schema that stores these values comes later; for now, the values clarify observable behavior.

---

Separate automation from judgment

A customer-support platform can automate repetitive decisions without pretending every decision is safe to automate. A practical distinction is:

Suitable for deterministic automation	Requires human ownership in this first version
Acknowledge a valid message	Make account, billing, or security changes
Search approved knowledge sources	Decide on exceptions outside documented policy
Detect an explicit request for a person	Handle sensitive or frustrated situations requiring judgment
Create an escalation ticket	Declare success when the customer has not confirmed it
Route a ticket to the organization’s agent queue	Override a customer’s request for human help

The LLM can contribute to an answer or a future classification, but it should not become the policy engine. For example, “the customer typed speak to an agent” is an observable condition. The resulting escalation can be enforced by a deterministic rule even if an LLM is unavailable, slow, or incorrect.

This distinction will matter throughout the course:

• retrieval provides evidence;
• generation phrases an answer using that evidence;
• product rules determine when the application must hand off;
• agents remain responsible for cases outside automated support.

---

Turn the workflow into user stories

A workflow describes the whole service. A user story describes one actor’s desired outcome within that workflow. It has a specific role, a desired capability, and a reason that capability creates value.

For this capstone, split the workflow into two user stories. This keeps customer-facing behavior and agent-facing behavior understandable without trying to pack the entire platform into one oversized story.

Story 1: customer self-service and safe handoff

As a customer seeking help from an organization, I want to receive a knowledge-backed answer or be connected to a human agent, so that I can make progress without being given unsupported guidance.

Story 2: agent resolution

As a support agent, I want to review conversations escalated for my organization and record a resolution, so that customers with unresolved issues receive accountable human support.

Notice what these do not say:

• “As a user, I want FastAPI to call an embedding model.”
• “As a customer, I want a pgvector query.”
• “As a developer, I want an LLM prompt.”

Those may become implementation tasks or architecture decisions. They do not communicate customer value, and they would prevent you from changing a technical choice without rewriting the product requirement.

---

Write criteria that can pass or fail

Acceptance criteria define what must be true for a story to count as complete. They are not a vague quality aspiration and not an implementation checklist. A criterion should describe an outcome that a stakeholder, developer, or automated test can verify.

Compare these statements:

Weak criterion	Why it fails	Improved criterion
“The AI gives helpful answers.”	“Helpful” has no pass/fail definition.	“When a matching approved source is available, the answer displays at least one citation to that source.”
“Escalate complicated issues.”	“Complicated” is subjective.	“When the customer explicitly requests a human agent, the conversation is marked escalated and appears in the organization’s agent queue.”
“The chat should be fast.”	There is no measurable threshold or test conditions.	“In the local baseline test with a stubbed model response, 95% of valid message acknowledgements appear within 2 seconds.”
“Use PostgreSQL and an LLM.”	This specifies a recipe, not a product result.	“A customer can retrieve a prior closed conversation belonging to their organization.”

A useful writing pattern is Given, When, Then:

• Given establishes relevant initial conditions.
• When names the customer, agent, or system event.
• Then states the observable outcome.

The wording need not be mechanically identical every time, but the logic should be present. Quantify limits where they matter: status values, allowed states, response times, counts, displayed fields, and fixture-specific expected outcomes.

---

Baseline acceptance criteria for the capstone

The following criteria are a practical baseline. They intentionally make a few product decisions that can be tested before the deeper AI implementation exists.

Story 1 criteria: customer self-service and safe handoff

1. Message acceptance
   Given a customer session associated with Organization A, when the customer submits a non-whitespace chat message between 1 and 2,000 characters, then the platform creates or updates an open conversation, stores the message, and displays an acknowledgement within 2 seconds in the local baseline environment with model responses stubbed.

2. Grounded answer path
   Given Organization A has an active knowledge-base source containing the documented answer to a test question, when the customer submits that test question and has not requested a human, then the platform returns an answer containing at least one citation to a source belonging to Organization A and sets the conversation to awaiting_customer.

3. Insufficient-evidence path
   Given no eligible knowledge-base source for Organization A supports a customer’s question, when the platform evaluates that question, then it does not present a factual answer as supported, creates an escalated ticket with reason insufficient_evidence, and sets the conversation to escalated.

4. Customer-requested handoff
   Given the organization has relevant knowledge-base evidence, when the customer explicitly requests a human agent, then the platform creates an escalated ticket with reason customer_requested_human rather than treating the automated answer as the final resolution.

5. Organization isolation
   Given Organization A and Organization B each have support content and conversations, when a customer session for Organization A submits or views a conversation, then neither citations nor conversation records from Organization B are returned.

Story 2 criteria: agent resolution

1. Visible escalation queue
   Given an agent belongs to Organization A and Organization A has an escalated conversation, when the agent opens the escalation queue, then the conversation appears with its current status, customer messages, escalation reason, and creation timestamp.

2. Organization-restricted agent access
   Given Organization B also has an escalated conversation, when an Organization A agent opens the queue or requests an individual ticket, then the Organization B conversation is absent and cannot be retrieved.

3. Recorded agent resolution
   Given an agent opens an escalated conversation for their organization, when the agent records a non-empty resolution message, then the message is added to the conversation, the status becomes resolved, and the customer can see the resolution.

4. Customer-confirmed closure
   Given a conversation has status resolved, when the customer selects Confirm resolved, then its status becomes closed. If the customer has not confirmed, the conversation remains resolved; silence alone does not close it.

These criteria are specific enough to turn into future automated tests. They also expose product decisions that are easy to miss if you start coding too early:

• the system needs a defined organization context;
• an answer needs a visible connection to evidence;
• a human-request condition overrides the automated path;
• resolution and closure are different states;
• data isolation is part of correct behavior, not an optional hardening task.

---

Create the workflow specification artifact

Your output for this lesson is a one-page workflow specification. Keep it in a document for now; when the monorepo is created later in this module, it can become a version-controlled project document.

Use this structure:

Primary workflow:
Customer web-chat support with knowledge-backed answers and human handoff.

Actors:
Customer, AI support platform, support agent.

Entry condition:
A customer session is associated with one organization and submits a valid chat message.

Happy path:
The platform finds organization-scoped supporting knowledge, provides a cited answer,
and waits for customer confirmation.

Exception paths:
- The customer explicitly requests a human agent.
- The platform has insufficient supporting evidence.
Both create an escalated ticket.

Terminal condition:
The customer confirms a recorded resolution, and the conversation becomes closed.

Out of scope:
Email, external web search, autonomous account changes, automatic closure by inactivity.

User stories:
[Insert Story 1 and Story 2.]

Acceptance criteria:
[Insert the criteria, adapting numeric thresholds only if you can state how they will be tested.]

Treat the criteria above as the initial product contract, not as immutable truth. For example, you may later choose a different maximum message length or acknowledgment target. The key is that any change must be intentional, documented, and paired with an updated test expectation.

---

Key takeaways

A reliable AI support product begins with a workflow, not a model call. Your primary workflow has five stages: intake, triage, investigation, resolution, and customer-confirmed closure. Its most important branch is the safe boundary between an evidence-backed answer and human handoff.

You also now have two focused user stories and a baseline set of measurable acceptance criteria. Good criteria describe outcomes, use explicit conditions and observable results, avoid implementation details, and include quality and isolation requirements where they matter.

Next, you will translate this product contract into a system architecture connecting the React client, FastAPI service, PostgreSQL with pgvector, file storage, and replaceable model providers.