# Case 06: what should the service agent know and do?

**HVE-DECISIONS-1.0. Fictional client interview/design feedback. RULE-06, approved knowledge and service-cases.csv remain authoritative.**

## Client interview evidence

- **C06-F1 / Mia:** "The agent should explain Repair and Delivery. It may help an employee submit a request, but it cannot promise a booking or compensation."
- **C06-F2 / Employee:** "Before anything is submitted, show the category and my description so I can correct or cancel."
- **C06-F3 / Service team:** "A request needs an accountable requester, reference, category, description and review status."
- **C06-F4 / Operator:** "If a user retries, they should not create a second request. If details changed, we must distinguish a new request from a retry."
- **C06-F5 / Mia:** "We have not asked to retain entire conversations. Do not store passwords, payroll or payment details just because they appear in chat."
- **C06-F6:** Allowed categories are Repair/Delivery, description is required and at most 500 characters, and the intended caller must have permission.

## Technology-specific decision context

Copilot Studio can answer from approved knowledge, collect information and call a bounded business action. Decide which of those capabilities the first service needs, what must remain human-owned and what information is transient conversation state versus persistent business data.

Do not assume that every conversational variable needs a database table or that adding a tool authorizes every user.

## Proposal to inspect

- **C06-P1:** Give the agent booking, compensation and payroll tools to make it look useful.
- **C06-P2:** Persist every chat message and use it as the only request record.
- **C06-P3:** A retry is always a new request; a changed description always overwrites the existing request.

## Change for discussion

- **C06-C1:** Mia asks whether users should see request status later. Decide the feature, identity/data needs and access boundaries before adding it.
- **C06-C2:** The user changes category after seeing the summary. Determine what confirmation/identity/history information must be retained and what can remain transient.

## Supplied fictional design-review feedback

| ID | Walkthrough finding |
|---|---|
| C06-T1 | The feature list confuses request submission with repair booking. |
| C06-T2 | The model has no stable way to identify the same request across a retry. |
| C06-T3 | Conversation text is stored but the service team cannot identify the accountable requester or request state. |
| C06-T4 | Status lookup would reveal another employee's requests. |
| C06-T5 | Unnecessary full-chat retention is included without a stated business purpose. |

No live agent conversation, flow execution or stored-row test is supplied.