create-bk-agent 0.22.0 → 0.22.2

package/templates/base/orchestrator/soporte/vault/comunicacion/plantillas.md

@@ -0,0 +1,211 @@
+---
+title: Plantillas de Comunicación con Clientes
+tags: [plantillas, comunicacion, email, respuesta, cierre, escalacion, empatia]
+description: Templates reutilizables para las situaciones más frecuentes de soporte
+---
+
+# Plantillas de Comunicación con Clientes
+
+Usar estas plantillas como base y personalizar siempre con el nombre del cliente
+y los detalles específicos del caso. Una respuesta genérica es peor que una tardía.
+
+---
+
+## Respuesta inicial — Acuse de recibo
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID]
+
+Hola [Nombre],
+
+Recibimos tu ticket y ya lo tenemos en cola.
+
+Prioridad asignada: [P1/P2/P3/P4]
+Tiempo estimado de primera respuesta: [X horas/minutos]
+
+[Si es P1/P2]: Un miembro de nuestro equipo se está asignando ahora mismo a este caso.
+
+[Si necesitamos info adicional]: Para poder ayudarte más rápido, ¿podrías enviarnos:
+- [dato específico 1]
+- [dato específico 2]
+
+Seguimos en contacto.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Respuesta con solución — L1
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Resuelto]
+
+Hola [Nombre],
+
+Investigamos el problema que reportaste y encontramos la causa.
+
+**¿Qué estaba pasando?**
+[Explicación breve en términos del cliente, sin jerga técnica]
+
+**Cómo resolverlo:**
+1. [Paso 1]
+2. [Paso 2]
+3. [Paso 3]
+
+**Cómo verificar que funciona:**
+[Describir qué debe ver el cliente si la solución funcionó]
+
+Si seguís teniendo problemas o la solución no funciona en tu caso, respondé a este email
+y lo revisamos juntos.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Escalación a L2 — Notificación al cliente
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Actualización]
+
+Hola [Nombre],
+
+Quisimos darte una actualización sobre tu caso.
+
+Revisamos el problema y determinamos que requiere una investigación técnica más profunda
+por parte de nuestro equipo de ingeniería de soporte.
+
+**Próximo paso:** Un técnico especializado tomará el caso.
+**Tiempo estimado de respuesta:** [según SLA del plan]
+
+Mientras tanto, [si hay workaround: "podés usar este workaround temporal: [descripción]"].
+
+Te mantendremos informado de cada avance.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Pedido de información adicional
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Necesitamos más info]
+
+Hola [Nombre],
+
+Estamos investigando el problema. Para poder reproducirlo y encontrar la solución
+más rápido, necesitamos que nos ayudes con esta información:
+
+1. **[Dato específico 1]:** [explicar por qué lo necesitamos si no es obvio]
+2. **[Dato específico 2]:** [explicar por qué]
+3. **Pasos exactos para reproducir el problema:** [si no los tenemos]
+
+[Opcional: "Podés enviarnos capturas de pantalla o los logs de la consola del navegador
+(F12 → Console) si hay errores visibles."]
+
+Una vez que tengamos esta info, continuamos la investigación de inmediato.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Actualización de incidente — Status update (template periódico)
+
+```
+Asunto: [INCIDENTE #ID] Actualización de estado — [HH:MM]
+
+Hola [Nombre / Lista de clientes afectados],
+
+Les compartimos una actualización del incidente que está afectando [descripción breve].
+
+**Estado actual:** [Investigando / Identificada la causa / Aplicando fix / En monitoreo]
+
+**Qué hicimos desde la última actualización:**
+- [Acción 1]
+- [Acción 2]
+
+**Próximos pasos:**
+- [Paso 1] — responsable: [rol]
+- [Paso 2]
+
+**Tiempo estimado de resolución:** [ETA actualizado o "Sin ETA confirmado aún, próxima actualización en X minutos"]
+
+Seguimos trabajando en esto. Próxima actualización: [hora].
+
+[Nombre]
+Equipo de Soporte / Operaciones
+```
+
+---
+
+## Cierre de ticket
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Cerrado]
+
+Hola [Nombre],
+
+Confirmamos que el problema fue resuelto y cerramos el ticket.
+
+**Resumen de lo que pasó:**
+[2-3 líneas explicando el issue y la causa]
+
+**Cómo lo resolvimos:**
+[1-2 líneas con la solución aplicada]
+
+**Para que no vuelva a ocurrir:**
+[Si aplica: qué cambió o qué puede hacer el cliente para evitarlo]
+
+Si el problema vuelve a aparecer o tenés alguna pregunta adicional, respondé a este email
+y reabrimos el caso de inmediato.
+
+¿Pudimos ayudarte bien? Nos ayudaría mucho conocer tu opinión: [link encuesta CSAT]
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Comunicado de apertura de incidente (público / status page)
+
+```
+**[INCIDENTE] Problemas con [nombre del servicio/módulo]**
+[Fecha] — [HH:MM] (UTC-3)
+
+Estamos investigando un problema que afecta a [descripción del impacto al usuario].
+Los usuarios pueden experimentar [síntomas concretos: errores, lentitud, etc.].
+
+Nuestro equipo está trabajando activamente en la resolución.
+Próxima actualización: [hora].
+```
+
+---
+
+## Comunicado de cierre de incidente (público / status page)
+
+```
+**[RESUELTO] Incidente en [nombre del servicio/módulo]**
+[Fecha] — [HH:MM] (UTC-3)
+
+El incidente fue resuelto a las [hora]. El servicio está funcionando con normalidad.
+
+**Duración total:** [X horas Y minutos]
+**Clientes afectados:** [descripción sin números exactos si es sensible]
+
+**Qué pasó:** [Descripción técnica accesible, sin exponer vulnerabilidades]
+
+**Qué hicimos:** [Acciones de resolución]
+
+**Para que no vuelva a ocurrir:** [Medidas preventivas]
+
+Pedimos disculpas por el inconveniente. Estamos comprometidos con [uptime objetivo].
+Si tenés preguntas, contactá a soporte: [email/portal].
+```

package/templates/base/orchestrator/soporte/vault/procesos/escalacion.md

@@ -0,0 +1,106 @@
+---
+title: Protocolo de Escalación
+tags: [escalacion, l1, l2, l3, incidente, protocolo, guardia]
+description: Cuándo y cómo escalar tickets e incidentes, con responsables y canales
+---
+
+# Protocolo de Escalación
+
+## Niveles de escalación
+
+### L1 → L2: Escalación Técnica
+
+**Cuándo:** ver criterios en manejo-de-tickets.md
+
+**Cómo:**
+1. Actualizar el ticket con todo el contexto recopilado
+2. Cambiar estado a ESCALADO_L2
+3. Asignar al equipo técnico (o al técnico de guardia si es P1/P2)
+4. Notificar al cliente: "Escalamos tu caso a nuestro equipo técnico especializado. Te contactaremos en [tiempo según SLA]"
+5. Hacer handoff verbal (Slack/Teams) para P1/P2
+
+**Información obligatoria en el handoff:**
+- Resumen del problema en 3 líneas
+- Pasos ya intentados y resultados
+- Información del entorno del cliente
+- Historial de tickets relacionados del mismo cliente
+- Nivel de urgencia y SLA restante
+
+---
+
+### L2 → L3: Escalación a Ingeniería
+
+**Cuándo:**
+- Bug confirmado en el código (no configuración)
+- Requiere acceso a producción con permisos de ingeniería
+- Issue de seguridad de cualquier tipo
+- Pérdida de datos confirmada
+- L2 lleva más de 2 horas sin avance en un P1
+
+**Cómo:**
+1. Crear un bug report en el sistema de issues de ingeniería (Jira/Linear/GitHub Issues)
+2. Incluir: steps to reproduce, expected vs actual, logs relevantes, impacto al cliente
+3. Vincular el bug al ticket de soporte
+4. Notificar al Engineering Manager con el bug report
+5. Mantener el ticket de soporte abierto y actualizar al cliente
+6. No cerrar el ticket hasta que ingeniería confirme el fix deployado
+
+---
+
+### Escalación a Dirección
+
+**Cuándo:**
+- Cliente Enterprise amenaza con churn o acciones legales
+- SLA incumplido por más de 2x el tiempo prometido
+- Incident P1 que afecta a más del 10% de la base de clientes
+- Issue de seguridad con posible exposición de datos de clientes
+- Segunda reapertura del mismo ticket por el mismo cliente
+
+**Quién notificar:**
+- Customer Success Manager (siempre)
+- Director de Customer Experience (si es Enterprise o impacto > 5 clientes)
+- CEO (solo si hay impacto reputacional, legal o de seguridad significativo)
+
+---
+
+## Guardia de incidentes P1/P2
+
+### Roles en guardia
+
+| Rol | Responsabilidad | Contacto |
+|-----|-----------------|----------|
+| Ingeniero de Guardia | Diagnóstico técnico y fix | [definir en tu empresa] |
+| CS Manager de Guardia | Comunicación con cliente y coordinación | [definir en tu empresa] |
+| Engineering Manager | Decisiones de arquitectura o rollback | [definir en tu empresa] |
+
+### Cómo activar la guardia (fuera de horario)
+1. Llamar al número de emergencias del Ingeniero de Guardia
+2. Si no responde en 5 minutos, llamar al Engineering Manager
+3. Abrir el canal de War Room en Slack: `#incident-[fecha]-[descripción-breve]`
+4. Invitar a CS Manager, Ingeniero de Guardia, y Engineering Manager
+
+### War Room — reglas
+- Un solo responsable de comunicación con el cliente (CS Manager)
+- Un solo responsable técnico de coordinar el fix (Ingeniero de Guardia)
+- Actualizar el canal cada 15 minutos con estado
+- No hacer cambios en producción sin anunciarlo en el canal con al menos 2 minutos de anticipación
+- Documentar todo en tiempo real (se usa para el postmortem)
+
+---
+
+## Postmortem
+
+### Cuándo es obligatorio
+- Todo incidente P1
+- Incidentes P2 que duraron más de 4 horas
+- Cualquier incidente donde el SLA fue incumplido significativamente
+- Bugs que causaron pérdida de datos aunque sea parcial
+
+### Cuándo realizarlo
+- Draft del postmortem: dentro de las 24 horas post-resolución
+- Review con el equipo: dentro de los 3 días hábiles post-resolución
+- Publicación (versión resumida para clientes): opcional, según impacto y política
+
+### Principio: postmortem blameless
+El objetivo es entender los sistemas y procesos, nunca culpar personas.
+Preguntar "¿por qué el sistema permitió que esto pasara?" en lugar de "¿quién cometió el error?".

package/templates/base/orchestrator/soporte/vault/procesos/manejo-de-tickets.md

@@ -0,0 +1,101 @@
+---
+title: Proceso de Manejo de Tickets de Soporte
+tags: [proceso, tickets, atencion, workflow, l1, l2, l3]
+description: Guía completa del proceso de atención desde la recepción hasta el cierre del ticket
+---
+
+# Proceso de Manejo de Tickets
+
+## Ciclo de vida de un ticket
+
+```
+NUEVO → EN_TRIAGE → EN_ATENCIÓN → ESPERANDO_CLIENTE → RESUELTO → CERRADO
+                          ↓
+                    ESCALADO_L2 → ESCALADO_L3 → RESUELTO
+```
+
+### Estados y sus significados
+
+| Estado | Significado | Quién puede cambiarlo |
+|--------|-------------|----------------------|
+| NUEVO | Ticket recibido, sin asignar | Sistema (automático) |
+| EN_TRIAGE | Siendo clasificado por triage-agent | Sistema / L1 |
+| EN_ATENCIÓN | Asignado y trabajando activamente | L1, L2, L3 |
+| ESPERANDO_CLIENTE | Pedimos info, esperamos respuesta | L1, L2 |
+| ESCALADO_L2 | Requiere investigación técnica | L1 |
+| ESCALADO_L3 | Requiere ingeniería o es incidente crítico | L2 |
+| RESUELTO | Solución entregada, pendiente confirmación del cliente | L1, L2, L3 |
+| CERRADO | Confirmado resuelto o 48hs sin respuesta tras resolución | Sistema / cliente |
+
+---
+
+## Canales de entrada y prioridad default
+
+| Canal | Prioridad default | Notas |
+|-------|------------------|-------|
+| Teléfono de emergencias | P1 automático | Solo Enterprise, fuera de horario |
+| Chat en vivo | P2 | Si el cliente dice que es urgente |
+| Email directo al CS Manager | P2 | Escalar a L2 inmediato |
+| Portal de soporte | Según formulario | El cliente selecciona la prioridad |
+| Email de soporte general | P3 | Default para consultas |
+| Redes sociales | P3 | Mover al portal oficial |
+
+---
+
+## Cuándo escalar a L2
+
+Escalar inmediatamente a L2 cuando:
+- El issue requiere acceso a logs del servidor o base de datos
+- La solución de KB no funcionó después de 2 intentos documentados
+- El cliente reporta pérdida de datos (aunque sea parcial)
+- El bug no está documentado y no hay workaround conocido
+- El cliente tiene plan Enterprise y lleva más de 1 hora sin solución para P2
+
+**Al escalar a L2:** incluir siempre en el ticket:
+1. Pasos ya intentados y sus resultados
+2. Información del entorno del cliente (versión, OS, navegador, etc.)
+3. Mensajes de error completos (no solo capturas de pantalla)
+4. Horario en que el cliente puede ser contactado
+
+---
+
+## Cuándo escalar a L3 / activar protocolo de incidente
+
+Activar el protocolo de incidente crítico cuando:
+- El issue afecta a más de 1 cliente simultáneamente con el mismo síntoma
+- Hay pérdida de datos confirmada o sospechada
+- El sistema está completamente caído (no solo degradado)
+- El issue tiene potencial impacto en seguridad
+- L2 lleva más de 2 horas sin encontrar el root cause en un P1
+
+---
+
+## Buenas prácticas de atención
+
+### Apertura del ticket
+- Responder siempre dentro del SLA aunque no tengamos solución
+- Si necesitamos tiempo para investigar, confirmarlo: "Recibimos tu ticket, estamos investigando y te respondemos en [tiempo]"
+- No decir "revisaremos tu caso" sin un tiempo concreto
+
+### Durante la investigación
+- Actualizar el ticket con cada hallazgo aunque no sea la solución
+- Si el cliente pregunta el estado, responder en menos de 1 hora durante horario hábil
+- Si el SLA está por vencerse, notificar proactivamente con un nuevo ETA
+
+### Cierre del ticket
+- Siempre preguntar si la solución resolvió el problema antes de cerrar
+- Esperar 48 horas la respuesta del cliente tras marcar como RESUELTO
+- Incluir siempre un resumen de qué pasó y cómo se resolvió (útil para la KB)
+- Invitar a completar la encuesta de satisfacción
+
+---
+
+## Métricas de calidad
+
+| Métrica | Objetivo | Crítico |
+|---------|----------|---------|
+| First Response Time (FRT) | Dentro del SLA 95% de los tickets | < 90% |
+| Resolution Time | Dentro del SLA 85% de los tickets | < 75% |
+| CSAT (Customer Satisfaction) | > 4.2 / 5.0 promedio mensual | < 3.8 |
+| First Contact Resolution (FCR) | > 70% de tickets L1 | < 60% |
+| Reapertura de tickets | < 5% | > 10% |

package/templates/base/orchestrator/soporte/vault/productos/coberturas-de-soporte.md

@@ -0,0 +1,94 @@
+---
+title: Coberturas de Soporte por Plan
+tags: [planes, cobertura, soporte, enterprise, professional, starter]
+description: Qué está incluido y qué no en cada plan de soporte
+---
+
+# Coberturas de Soporte por Plan
+
+## Plan Enterprise
+
+### Incluye
+- Soporte 24/7/365 para P1 y P2 por teléfono, email y chat
+- SLA garantizado con créditos por incumplimiento
+- Ingeniero de cuenta dedicado (Technical Account Manager)
+- Acceso a canal de Slack privado con el equipo de soporte e ingeniería
+- Revisiones técnicas trimestrales
+- Early access a nuevas funcionalidades
+- Capacitación del equipo (hasta 4 horas por trimestre)
+- Onboarding personalizado (hasta 20 horas)
+
+### No incluye
+- Desarrollo de features a medida (requiere contrato de desarrollo)
+- Integración con sistemas de terceros no documentados
+- Soporte a código personalizado no desarrollado por nosotros
+- Data recovery de datos eliminados por el cliente (evaluar caso a caso)
+
+---
+
+## Plan Professional
+
+### Incluye
+- Soporte en horario hábil (L-V 9:00-18:00) para todas las prioridades
+- Soporte fuera de horario para P1 únicamente (respuesta en 4 horas)
+- Portal de soporte con priorización
+- Acceso a base de conocimiento y documentación completa
+- Webinars mensuales de producto
+- Onboarding básico (hasta 4 horas)
+
+### No incluye
+- Soporte telefónico (solo email y portal)
+- TAM dedicado
+- Canal de Slack privado
+- Revisiones técnicas proactivas
+
+---
+
+## Plan Starter
+
+### Incluye
+- Soporte en horario hábil ART (L-V 9:00-18:00)
+- Portal de soporte con formulario de tickets
+- Acceso a base de conocimiento y documentación
+- Foro de comunidad de usuarios
+
+### No incluye
+- Soporte fuera de horario (ninguna prioridad)
+- Chat en vivo
+- Prioridad sobre otros tickets
+
+---
+
+## Qué nunca está incluido en ningún plan
+
+- Consultoría de arquitectura o diseño de soluciones (servicio separado)
+- Desarrollo o modificación de código del cliente
+- Soporte a versiones EOL (End of Life) — ver política de versiones
+- Recovery de datos si el cliente borró información hace más de 30 días
+- Soporte en idiomas distintos al español e inglés
+
+---
+
+## Política de créditos por incumplimiento de SLA (Enterprise)
+
+| Incumplimiento | Crédito |
+|---------------|---------|
+| FRT fuera de SLA en P1 | 5% del MRR del mes |
+| Resolution Time fuera de SLA en P1 | 10% del MRR del mes |
+| FRT fuera de SLA en P2 | 2% del MRR del mes |
+| Resolution Time fuera de SLA en P2 | 5% del MRR del mes |
+
+**Límite de créditos:** máximo 30% del MRR mensual por mes calendario.
+Los créditos se aplican en la próxima factura. No son transferibles ni canjeables por dinero.
+
+---
+
+## Versiones soportadas
+
+| Versión | Estado | Soporte hasta |
+|---------|--------|---------------|
+| v3.x (latest) | Activo — soporte completo | Indefinido |
+| v2.x | Mantenimiento — solo bugs críticos y seguridad | 31/12/2026 |
+| v1.x | EOL — sin soporte | Venció 31/12/2025 |
+
+Clientes en versiones EOL deben migrar para recibir soporte.

package/templates/base/orchestrator/soporte/vault/sla/niveles-de-servicio.md

@@ -0,0 +1,104 @@
+---
+title: Niveles de Servicio (SLA)
+tags: [sla, prioridad, tiempos, soporte, acuerdo]
+description: Definición de prioridades, tiempos de respuesta y resolución por plan y tier de soporte
+---
+
+# Niveles de Servicio (SLA)
+
+## Definición de Prioridades
+
+### P1 — Crítico
+**Definición:** Sistema o servicio completamente caído. Sin workaround disponible. Impacto en producción.
+
+**Ejemplos:**
+- Plataforma inaccesible para todos o gran parte de los usuarios
+- Pérdida de datos en producción
+- Brecha de seguridad activa
+- Funcionalidad de pago o facturación no disponible
+
+### P2 — Alto
+**Definición:** Funcionalidad core degradada. Hay workaround pero es significativamente limitante.
+
+**Ejemplos:**
+- Módulo principal con rendimiento muy degradado (> 5x más lento de lo normal)
+- Feature crítica del negocio no disponible para un segmento de usuarios
+- Integraciones clave caídas (pagos, autenticación)
+
+### P3 — Medio
+**Definición:** Bug o problema que afecta una feature no crítica. Hay workaround razonable.
+
+**Ejemplos:**
+- Error en un reporte o export que tiene alternativa
+- UI con comportamiento incorrecto pero funcional
+- Notificaciones no enviándose pero datos disponibles en la plataforma
+
+### P4 — Bajo
+**Definición:** Consulta, mejora sugerida, cosmético o comportamiento no esperado sin impacto operativo.
+
+**Ejemplos:**
+- Pregunta de "cómo hacer X"
+- Solicitud de nueva funcionalidad
+- Texto o label incorrecto en la interfaz
+
+---
+
+## Tiempos de Respuesta y Resolución por Plan
+
+### Plan Enterprise
+
+| Prioridad | Primera respuesta | Actualización de progreso | Resolución objetivo |
+|-----------|-------------------|--------------------------|---------------------|
+| P1 | 15 minutos | Cada 30 minutos | 4 horas |
+| P2 | 1 hora | Cada 2 horas | 8 horas hábiles |
+| P3 | 4 horas hábiles | Diaria si está abierto | 3 días hábiles |
+| P4 | 1 día hábil | Semanal | 10 días hábiles |
+
+**Horario de cobertura P1/P2:** 24/7/365
+
+### Plan Professional
+
+| Prioridad | Primera respuesta | Resolución objetivo |
+|-----------|-------------------|---------------------|
+| P1 | 1 hora | 8 horas hábiles |
+| P2 | 4 horas hábiles | 2 días hábiles |
+| P3 | 1 día hábil | 5 días hábiles |
+| P4 | 2 días hábiles | 15 días hábiles |
+
+**Horario de cobertura:** Lunes a viernes 9:00-18:00 (zona horaria del cliente)
+
+### Plan Starter
+
+| Prioridad | Primera respuesta | Resolución objetivo |
+|-----------|-------------------|---------------------|
+| P1 | 4 horas hábiles | 2 días hábiles |
+| P2 | 1 día hábil | 5 días hábiles |
+| P3 | 2 días hábiles | 10 días hábiles |
+| P4 | 5 días hábiles | Best effort |
+
+**Horario de cobertura:** Lunes a viernes 9:00-18:00 ART
+
+---
+
+## Cómputo del SLA
+
+- El reloj del SLA **empieza cuando el ticket se recibe**, no cuando es asignado
+- El SLA se **pausa** cuando esperamos información del cliente (estado: "Esperando cliente")
+- El SLA se **reanuda** cuando el cliente responde
+- El SLA **se cumple** cuando el cliente confirma resolución o cuando han pasado 48hs sin respuesta tras nuestra solución
+- Los **días feriados** del país del cliente no cuentan en planes Professional y Starter (sí cuentan en Enterprise P1/P2)
+
+---
+
+## Escalación por Incumplimiento de SLA
+
+Si el SLA está en riesgo (>75% del tiempo consumido sin resolución):
+1. Notificar al Team Lead de Soporte
+2. Escalar automáticamente a L2 si está en L1
+3. Notificar proactivamente al cliente con actualización de estado y nuevo ETA
+
+Si el SLA se incumple:
+1. Notificar al Director de Customer Success
+2. Registrar el breach en el sistema de métricas
+3. Analizar en la reunión semanal de soporte
+4. Evaluar compensación según política de créditos