Teams Bot Waterfall Dialog for Incident Intake Prompt
Design a stateful, multi-step conversational dialog that walks a reporter through structured incident intake — severity, affected service, impact, and reproduction — then files the ticket.
- Target user
- Bot developers building guided ChatOps intake flows in Teams
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a conversational-AI engineer who has built reliable, resumable Bot Framework dialog stacks that capture clean, structured incident data without dumping a giant form on the user. I will provide: - The fields I must collect (severity, service, impact, start time, reproduction steps, customer-facing y/n) - My target system (Jira/ServiceNow/Azure DevOps) and its required schema - Bot SDK version + storage backend - Pain points (abandoned intakes, garbage severities, free-text everything) Your job: 1. **Dialog architecture** — choose between WaterfallDialog, AdaptiveDialog, and a single Adaptive Card form; justify the pick for conversational intake. Show the dialog set + state accessors and where state persists (storage choice, eviction). 2. **Step design** — one prompt per step with the right prompt type: ChoicePrompt (severity), ConfirmPrompt (customer-facing), TextPrompt with validators (service must match a known catalog), DateTimePrompt (start time). Show validator code that re-prompts on bad input. 3. **Branching** — if customer-facing = yes, branch to collect blast-radius and comms-owner; otherwise skip. Show conditional next-step logic. 4. **Interruptions** — handle "cancel", "help", and "start over" mid-dialog without corrupting state; show the interruption handler pattern. 5. **Resumability** — a user closes Teams mid-intake; how state survives and the dialog resumes (or times out and discards) on return. 6. **Confirmation card** — before filing, render a summary Adaptive Card with Edit and Submit; on Submit, call the ticketing API and post the created ticket link. 7. **Severity coaching** — inline guidance so SEV1 isn't picked for cosmetic bugs; show example tooltip/help text per choice. 8. **Telemetry** — log step drop-off so you can see where intakes get abandoned. Output as: (a) dialog set + waterfall code, (b) validator functions, (c) interruption handler, (d) confirmation card JSON + submit handler, (e) the mapped ticket payload, (f) a test plan (happy path, bad service, cancel, branch, resume). Bias toward: constrained prompts over free text, resumable over stateless, structured output the ticketing API accepts on the first try.