Assignment
Ask a peer to act as a support lead. Prepare five synthetic tickets: ordinary, ambiguous, missing data, permission restricted, and an exception to policy.
Build sequence
- Observe the peer handling two tickets and record each step and delay.
- Interview a user, operator, and decision-maker role with distinct questions.
- Create a current-state workflow and an assumption register.
- Write a one-page problem statement with excluded tasks.
Acceptance checks
- The proposed intervention addresses an observed bottleneck.
- Measurements and estimates are clearly separated.
- Each unresolved assumption has an owner and a concrete validation action.
Evidence to keep
Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.
Guided workshop: interview a fictional customer
Use one customer throughout this course: Northstar Support, a fictional software company with two customer tenants, Alder and Birch. Six support staff search policy documents and draft replies. Leadership wants “an AI agent that resolves every ticket.” The initial exercise must determine what problem is worth solving before choosing an agent.
Role cards: the support lead says searching takes too long; an operator says outdated policies cause rework; the security owner prohibits cross-tenant access and automatic external messages; the sponsor wants a measurable reduction in handling time. These statements can conflict. Record each speaker's authority and separate preferences from hard constraints.
Use five synthetic tickets: password reset, duplicate invoice, unclear account problem, request for another tenant's invoice, and a policy exception. Ask the support lead to handle two while explaining their actions. If no partner is available, simulate each role in writing and label observations as assumptions rather than measurements.
Interview sequence: ask “Show me the last example,” “What did you check before replying?”, “Where did you wait?”, “Who decides exceptions?”, and “What happens if the answer is wrong?” Follow the work rather than asking whether they would like a chatbot. Record system switches, evidence consulted, decisions, and escalation points.
Worked problem statement: “Operators need to find the current permitted policy and draft a cited reply. The pilot will suggest drafts for ordinary support tickets. It will not send messages, alter billing, or decide policy exceptions.” This is testable and preserves human ownership of consequential actions.
Create an assumption register:
| Assumption | Evidence now | Owner | Next check |
|---|---|---|---|
| Search is the main delay | Two simulated observations | Support lead | Time ten representative tickets |
| Policies are current | Unknown | Policy owner | Review document versions |
| Tenant identity is available | Architecture claim | Integration owner | Inspect sandbox identity flow |
Exercise: write a one-page discovery brief containing users, current workflow, bottleneck, baseline plan, desired outcome, constraints, exclusions, and unresolved assumptions. Have the customer role correct it before proceeding.
Review rubric: strong discovery identifies a specific workflow and evidence gaps. Weak discovery repeats “build AI” as the requirement, invents measured savings, or ignores the operator who must use the result. An interview question for the learner: what new evidence would make you recommend a search-only tool instead?