hatjicon/agent-skills

Analizador de Puntos Débiles del Cliente

Objetivo

Analizar una transcripción de llamada de cliente (Markdown o texto plano) e identificar hasta cinco puntos débiles validados del cliente. Centrarse en necesidades operativas subyacentes, no en soluciones solicitadas.

Entradas

• Requerido: transcripción de la llamada del cliente.
• Opcional: nombre del cliente, nombres de los entrevistadores, nombres de los hablantes del cliente, stack técnico, destino de tickets y lista de tickets existentes.
• Si los roles de los hablantes no están claros, pide aclaración o marca la atribución como incierta. No trates a cada hablante no identificado como cliente.

Atribución de hablantes

Extraer puntos débiles solo de declaraciones atribuibles a clientes. Las preguntas, interpretaciones y soluciones propuestas por el entrevistador no son evidencia del cliente a menos que el cliente las confirme explícitamente. No inferir roles de clientes solo por los nombres.

Contexto del cliente

Identificar el rol/persona del cliente y el entorno técnico solo cuando esté respaldado por la transcripción. En caso contrario, indicar No establecido en la transcripción.

Criterios de validación

Un punto débil válido refleja una dificultad operativa concreta, como:

• Frustración, ineficiencia o trabajo manual repetitivo
• Retrasos, riesgo, poca visibilidad o problemas de fiabilidad
• Limitaciones de escalabilidad o brechas de observabilidad

Declaraciones como "tenemos que", "terminamos haciendo manualmente", "no tenemos visibilidad" o "toma demasiado tiempo" pueden ser señales útiles, pero la redacción por sí sola no es validación. Solicitudes como "quiero" o "sería genial si" requieren evidencia de un problema subyacente.

Excluir solicitudes de funciones no respaldadas, declaraciones de solo solución y opiniones genéricas. No inventar detalles.

Proceso de análisis

1. Identificar a los hablantes clientes y distinguirlos de los entrevistadores.
2. Extraer evidencia del comportamiento actual, soluciones alternativas, consecuencias y resultados deseados.
3. Agrupar declaraciones relacionadas en problemas subyacentes distintos; evitar puntos débiles duplicados.
4. Clasificar los puntos débiles validados por frecuencia, intensidad e impacto en el negocio. No equiparar las indicaciones repetidas del entrevistador con la frecuencia del cliente.
5. Devolver como máximo cinco. Si se validan menos, devolver menos. Si no se valida ninguno, indicar: Punto débil no claramente validado en esta llamada.
6. Para cada uno, escribir una historia de usuario centrada en resultados: Como [tipo de usuario], cuando [contexto], necesito [capacidad], para poder [resultado de negocio].
7. Incluir una cita corta textual de evidencia del cliente o una referencia precisa de la transcripción cuando esté disponible. No fabricar citas.
8. Distinguir el impacto empresarial confirmado de las implicaciones plausibles pero no confirmadas.

Evitar sesgo de solución. No prescribir elementos de UI o implementaciones técnicas a menos que se indiquen explícitamente como restricciones y sean relevantes para el problema.

Flujo de trabajo de tickets (opcional)

Predeterminado: solo análisis. No crear ni modificar tickets a menos que se solicite y autorice explícitamente.

Si el acceso a tickets y un destino están disponibles:

1. Recuperar tickets existentes en el grupo o tablero objetivo.
2. Comparar el problema subyacente, no solo el título, con los tickets existentes.
3. Si son sustancialmente similares, proponer agregar la nueva historia de usuario con Validación adicional de [Nombre del Cliente] (cuando se conozca).
4. En caso contrario, proponer un título nuevo, corto, orientado al problema y centrado en resultados.
5. Presentar las acciones propuestas para confirmación antes de cualquier escritura, a menos que el usuario haya aprobado explícitamente la creación/actualización automática de tickets.
6. Después de la ejecución, informar los enlaces reales de los tickets y los resultados. Nunca afirmar que una acción se realizó con éxito sin confirmación de la herramienta.

Si el sistema de tickets no está conectado, mostrar Propuesto: Crear nuevo ticket, Propuesto: Añadir a ticket existente o Desduplicación no verificada según corresponda; nunca implicar que se creó un ticket.

Salida requerida

Repetir esta estructura para cada punto débil validado:

Punto Débil N – [Título corto orientado al problema]

Fuente de la Llamada del Cliente: [Nombre del cliente o desconocido] Stack técnico y persona del cliente: [Contexto respaldado o no establecido]

Historia de Usuario: Como [tipo de usuario], cuando [contexto], necesito [capacidad], para poder [resultado de negocio].

Comportamiento Actual: [Descripción basada en evidencia]

Comportamiento Deseado: [Resultado deseado, no una función presunta]

Problema Raíz: [Necesidad central no satisfecha]

Impacto en el Negocio: [Impacto confirmado; etiquetar cualquier inferencia]

Evidencia del Cliente: [Cita corta o referencia de la transcripción]

Acción del Ticket: [Acción propuesta, acción completada verificada, o Desduplicación no verificada]

Controles de calidad

• Ninguna afirmación solo del entrevistador tratada como validación del cliente.
• No más de cinco puntos débiles; menos cuando la evidencia es débil.
• No inventar persona, stack, impacto, cita o estado de ticket.
• Los títulos de los puntos débiles describen problemas, no funciones.
• Las escrituras de tickets requieren autorización y acceso real a la herramienta.