Plantilla de recepción de incidentes

Cuando algo falla, los primeros minutos cuentan. Mensajes directos dispersos y textos a medias frenan el triage y duplican esfuerzo. Una plantilla de recepción de incidentes en Dailybot hace que cada quien reporte responda las mismas preguntas, deje un registro uniforme para quien atiende y enrute el trabajo al lugar correcto antes de que la situación crezca.

Estructura de la plantilla

Preguntas núcleo

Empiecen con un conjunto pequeño de campos obligatorios. Severidad (por ejemplo, SEV1–SEV4 o crítica / alta / media / baja) fija expectativas de tiempo de respuesta. Sistemas afectados debería ser multi-selección o etiquetas cortas—servicios, regiones o áreas de producto—para mapear dueños con claridad. Descripción es texto libre, pero pidan síntomas, hora de inicio y qué cambió recientemente. Alcance del impacto indica a quién afecta: solo internos, un segmento de clientes, una geografía o caída total. Triage inicial guarda qué intentó quien reporta (rollback, feature flag, reinicio) y dudas abiertas.

Lógica condicional

Usen ramificaciones para que el formulario sea corto en casos simples y crezca en incidentes mayores. Si la severidad es crítica, muestren campos extra: visible para clientes sí/no, riesgo estimado de ingresos o SLA, y si comunicaciones o legal podrían involucrarse. Si se elige un sistema concreto, muestren enlaces a runbooks o responsables por defecto. La lógica condicional reduce fatiga del formulario sin saltarse campos cuando importan.

Reglas de enrutado

Mapeen respuestas a destinos: canal de incidentes dedicado, hilo por servicio o canal privado de liderazgo para eventos graves. Severidad y etiquetas de sistema deberían disparar qué workflow corre—publicar un resumen formateado, mencionar alias de guardia o abrir tarea de seguimiento. Documenten el enrutado en un solo lugar para que cambios de equipo no obliguen a revisar diez automatizaciones.

Personalización para su equipo

Alineen el vocabulario con cómo ya hablan: si usan impacto al cliente en lugar de “severidad,” renombren campos pero mantengan la escala subyacente estable. Agreguen campos opcionales para enlaces (dashboards, trazas, páginas de estado) sin hacerlos obligatorios en cada reporte. En entornos regulados, incluyan una casilla de “contiene datos personales” para que quien responda maneje evidencia con cuidado.

Capaciten una vez a quienes reportan: cuándo usar el formulario versus un chat rápido. Impulsen el formulario para lo que pueda volverse registro de incidente; dejen el chat para preguntas puras. Actualicen la plantilla después de postmortems: si quien atiende siempre pregunta lo mismo, agréguenlo.

Integración con herramientas de gestión de incidentes

Dailybot funciona mejor como puerta de entrada, no como reemplazo de su centro de comando. Patrones comunes: el workflow publica un mensaje estructurado que incluye la clave del ticket al crearlo; un webhook envía respuestas del formulario a una API que abre un issue en Jira o Linear; o ops copia un bloque formateado a notas de PagerDuty para correlación. El objetivo es un esquema de intake que fluya a su sistema de registro sin reescribir.

Si usan página de estado, agreguen campo de “¿público?” y enruten respuestas afirmativas a dueños de comunicación. Si usan bots de chatops, incluyan un pie amigable para máquinas (JSON o líneas etiquetadas) para que scripts lean severidad y servicio sin NLP.

Esquema de campos de ejemplo

Úsenlo como lista de verificación al armar el formulario:

• Título (una línea, orientado a la acción)
• Severidad (con definiciones visibles en texto de ayuda)
• Inicio (con zona horaria clara)
• Sistemas afectados (lista controlada)
• Impacto al usuario (ninguno / degradado / no disponible)
• Descripción (síntomas y línea de tiempo)
• Pasos ya intentados
• Enlaces (opcional)
• Quién reporta y mejor contacto

Refinen la lista con sus últimos tres incidentes reales: ¿qué hubiera querido quien atiende al minuto cero?

Después del lanzamiento, revisen volumen de envíos y tiempo hasta la primera respuesta semanalmente durante dos sprints. Si lo crítico sigue llegando primero por canales paralelos, ajusten las instrucciones o agreguen un acceso directo desde la sala principal del equipo para que la plantilla siga siendo el camino más fácil.

Un intake disciplinado convierte el ruido del pánico en señal limpia y enrutable. Ops y desarrollo gastan menos tiempo persiguiendo contexto y más arreglando el problema.