Incident intake template

When something breaks, the first minutes matter. Scattered DMs and half-written messages slow triage and duplicate effort. An incident intake template in Dailybot gives every reporter the same questions, produces a consistent record for responders, and routes work to the right place before the situation escalates.

Template structure

Core questions

Start with a small set of non-negotiable fields. Severity (for example, SEV1–SEV4 or a simple critical / high / medium / low scale) sets expectations for response time. Affected systems should be a short multi-select or tags—services, regions, or product areas—so ownership maps cleanly. Description is free text but prompt for symptoms, start time, and anything that changed recently. Impact scope captures who is affected: internal only, a customer segment, a geography, or full outage. Initial triage holds what the reporter already tried (rollback, feature flag, restart) and open questions.

Conditional logic

Use branching so the form stays short for simple cases and expands for major incidents. If severity is critical, show extra fields: customer-visible yes/no, estimated revenue or SLA risk, and whether communications or legal might be involved. If a specific system is selected, surface runbook links or default assignees. Conditional logic reduces form fatigue while ensuring you never skip fields when they matter.

Routing rules

Map answers to destinations: a dedicated incidents channel, a service-specific stream, or a private leadership channel for severe events. Severity and system tags should drive which workflow fires—posting a formatted summary, tagging on-call aliases, or opening a follow-up task. Document routing in one place so changes to team structure do not require hunting through ten automations.

Customizing for your team

Align vocabulary with how you already talk: if you use customer impact instead of “severity,” rename fields but keep the underlying scale stable. Add optional fields for links (dashboards, traces, status pages) without making them mandatory for every report. For regulated environments, include a checkbox for “contains personal data” so responders handle evidence correctly.

Train reporters once: when to use the form versus a quick chat. Encourage the form for anything that might become an incident record; keep chat for pure questions. Rotate the template after post-incident reviews—if responders always ask the same missing question, add it.

Integrating with incident management tools

Dailybot works best as the front door, not a replacement for your command center. Common patterns: workflow posts a structured message that includes a ticket key once created; webhook pushes form answers to an API that opens a Jira or Linear issue; or ops copies a formatted block into PagerDuty notes for correlation. The goal is one intake schema that flows into your system of record without retyping.

If you use a status page, add a field for “public-facing?” and route affirmative answers to comms owners. If you use chatops bots, include a machine-friendly footer (JSON or tagged lines) so scripts can parse severity and service without NLP.

Sample field outline

Use this outline as a checklist when you build the form:

• Title (one line, action-oriented)
• Severity (with definitions visible in help text)
• Started at (timezone-aware)
• Affected systems (controlled list)
• User impact (none / degraded / unavailable)
• Description (symptoms and timeline)
• Steps already taken
• Links (optional)
• Reporter and best contact

Refine the list with your last three real incidents—what did responders wish they had on minute zero?

After go-live, review submission volume and time-to-first-response weekly for two sprints. If critical incidents still arrive first through side channels, tighten prompts or add a one-click shortcut from your main team room so the template stays the path of least resistance.

A disciplined intake template turns noisy panic into clean, routable signal. Ops and developers spend less time chasing context and more time fixing the problem.