Clasificador de comentarios: errores, solicitudes y preguntas
Clasifica comentarios en Reporte de error, Solicitud de función, Elogio o Pregunta. Distingue fallas de lo prometido y nuevas necesidades.
La prueba gratuita tiene límites. Inicia sesión para usar tus créditos y conservar un historial.
Tu próxima decisión empieza aquí.
Agrega contexto arriba o empieza con un ejemplo.
Clasifica la observación antes de asignar prioridad
Los comentarios llegan por soporte, entrevistas y mensajes dentro del producto. Una frase puede describir una capacidad faltante o una función prometida que falla. Usa una definición consistente del producto para distinguirlas. Esta herramienta propone una categoría, no una decisión de hoja de ruta. Conserva la fuente y la versión para diferenciar reportes repetidos de un incidente y solicitudes independientes de una función nueva.
Revisa casos concretos
Entradas ilustrativas y criterios de revisión, no resultados registrados del modelo. Ejecuta tu propio contexto para examinar una decisión.
Falta una confirmación
Hago clic en Guardar y no pasa nada. Debería aparecer un mensaje que diga si funcionó.
Comprueba si los datos se guardaron. Si la acción documentada falla, revisa un Reporte de error. Si guardar funciona pero nunca se ofreció una confirmación, puede ser una Solicitud de función. El texto por sí solo no resuelve una promesa de producto desconocida.
Un elogio aparente alrededor de una falla
Qué maravilla, el panel volvió a fallar justo antes de mi presentación.
La palabra “maravilla” no convierte el mensaje en Elogio. La observación concreta es una falla recurrente. Conserva la acción y la versión afectadas e incluye sarcasmo en tus muestras revisadas, sin asumir que las palabras de sentimiento determinan el tipo de comentario.
Una pregunta que puede revelar un defecto
¿Cómo exporto un PDF? La ayuda dice que hay un botón, pero no lo encuentro.
Es una Pregunta, pero la diferencia con la ayuda puede revelar un error, una restricción de permisos o documentación desactualizada. Agrega el plan y la disponibilidad documentada cuando sean pertinentes. Vincula la consulta con la investigación si ambas necesitan atención.
Define los límites antes de clasificar
Estos son criterios de revisión sugeridos. Incluye las reglas de tu equipo en la pregunta o el contexto al ejecutar una decisión.
| Opción | Cuándo usarla | Límite que debes revisar |
|---|---|---|
| Reporte de error | El comportamiento observado contradice una función admitida y documentada. | Una expectativa no prometida no demuestra un defecto. |
| Solicitud de función | Una capacidad nueva o un cambio al comportamiento existente. | “Ojalá funcionara” puede describir una función existente que está fallando. |
| Elogio | Una evaluación favorable sin una solicitud o problema principal pendiente. | El lenguaje positivo puede ser sarcástico o acompañar una queja. |
| Pregunta | Una consulta sobre cómo usar o entender el producto. | La consulta puede revelar un error que necesite seguimiento vinculado. |
Situaciones que requieren atención
Contar un incidente como muchas solicitudes nuevas
Conserva la versión, el flujo afectado y una referencia de origen. Identifica duplicados antes de comparar volúmenes: una sola falla puede hacer que una categoría parezca más representativa de lo que es.
Perder matices entre idiomas
Los comentarios con idiomas mezclados, sarcasmo y abreviaturas locales necesitan muestras revisadas por separado. Si agregas traducción, conserva el original; la intención puede cambiar al reformularlo.
Evalúa las categorías antes de confiar en la tendencia
Para reportes, revisa una muestra de cada categoría e identifica cuáles se confunden. Confundir sistemáticamente errores y solicitudes puede distorsionar la planeación aunque una equivocación aislada parezca barata. Revisa los casos inciertos en lugar de imponer un umbral bajo universal.
Separa gravedad, clientes afectados y valor estratégico de esta puntuación. Un defecto de accesibilidad poco frecuente puede importar más que una petición estética común. Los conteos describen lo que recibes; no deciden la hoja de ruta.
Un ejemplo de API Jev para tu próxima integración
Llama a la API REST de iajev con cURL. Recibe una opción, probabilidades y confianza en JSON.
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "Sería útil exportar mis reportes semanales como PDF y compartirlos con mi equipo."
},
"decision": {
"type": "choice",
"question": "¿Qué tipo de comentario de cliente es este?",
"choices": [
"Reporte de error",
"Solicitud de función",
"Elogio",
"Pregunta"
]
}
}'Preguntas sobre esta herramienta
¿Un mensaje puede tener dos categorías?
Sí, aunque la herramienta devuelve una opción seleccionada. Divide las observaciones independientes si tu proceso necesita ambas categorías. Conserva la fuente común para no contar una pregunta y su error asociado como clientes diferentes.
¿Debo clasificar por separado los comentarios anónimos?
Usa las mismas definiciones. Registra la procedencia por separado para detectar duplicados o dar seguimiento. Conocer la identidad no debería cambiar la categoría de un mismo problema del producto.
Cómo usar iajev
Agrega contexto
Incluye los hechos necesarios para esta decisión.
Revisa las opciones
Adapta la pregunta y las opciones a tu proceso.
Ejecuta y revisa
Examina la distribución antes de actuar.
¿La confianza es la probabilidad de una decisión correcta?
No. La confianza es una estimación independiente del modelo; las probabilidades describen la distribución entre tus opciones. Ninguno de estos valores garantiza una exactitud medida.
¿Puedo comparar dos entradas?
Edita el contexto y ejecuta la misma pregunta para comparar probabilidades. Cambiar la pregunta o las opciones inicia una comparación nueva.