Qué necesita un agente de tu sistema de diseño en Markdown
El contenido del portfolio en texto estructurado para leerlo, compartirlo o usarlo como contexto en un asistente de IA.
_IA APLICADA · VOICE OF CUSTOMER_
# De 25.000 comentarios a un backlog
Un piloto que convierte las opiniones públicas de los clientes en problemas clasificados, para que los Product Owners decidan su roadmap con datos reales y no por intuición.
**Rol:** Autor único: Product Owner, diseñador UX, front-end y back-end, del concepto a producción
**Estado:** Piloto probado por el equipo de producto de la app, en pausa por una reorganización interna
**Periodo:** Septiembre a noviembre de 2026
**Stack:** Claude Code, Codex, n8n, Supabase, Hostinger, Notion y Figma
**Segunda iteración de diseño,** con datos de ejemplo. Las capturas del caso son de este diseño.
## Uso y resultados
- **25.000+** comentarios (evidencias) de los últimos dos años, agrupados en 136 issues.
- **300 → 20–30** issues que, al definir bien qué es un issue único, resultaron ser solo entre 20 y 30.
- **1** persona, de principio a fin: producto, diseño, front-end y back-end, en unos tres meses.
## Por qué lo emprendí
Antes no se gestionaba el feedback de los clientes: no se trataba de ninguna manera y no llegaba a los equipos de producto. Ese era el problema y el origen de todo. Lo primero era que los Product Owners recibieran cada semana información sobre problemas, quejas y opiniones de usuarios reales, que se pudiera traducir en acciones planificables para los equipos de My Sunrise, la app, Rewards, roaming o la eShop.
Sin datos medibles, el producto se construía por la intuición de los Product Owners. Yo tenía dos hipótesis. La primera, que un diseñador de producto puede crear algo funcional de principio a fin, y que los equipos pueden construir sus propias herramientas especializadas con poco presupuesto. La segunda, que la herramienta fuera realmente útil: que permitiera construir los backlogs de producto sobre la realidad y no sobre intuición.
## Qué construí
Voice of Customer es la herramienta que muestra los problemas activos de los usuarios, para tomar decisiones y planificar el roadmap. Lo construí yo solo, de principio a fin, y lo puse en producción en Hostinger con Supabase. Los datos son opiniones públicas, porque se trataba de probar la viabilidad de la idea: la comunidad de Sunrise, Reddit, las tiendas de apps y X. No recoge ningún nombre ni dato personal: solo los issues.
### **Arquitectura de la solución:** de las fuentes públicas al panel y a Jira, con agentes en cada paso previo a la decisión.
**Fuentes · Opiniones públicas**
- Comunidad de Sunrise
- Reddit
- Tiendas de apps
- X
- Después: llamadas, encuestas, tests y entrevistas
**Extracción · Agentes, cada lunes**
- Por API o MCP, cuando se puede
- Por navegador, cuando no
**Limpieza y clasificación · Agentes entrenados**
- Solo quedan los issues
- Taxonomía de negocio
- Ontología facetada
- A mano si no se puede
**Repositorio · Base de datos común**
- Issues y evidencias
- Seis facetas por issue
- Sin datos personales
**Plataforma · Panel web**
- Product Owner, Business Analyst y UX
- Volumen, urgencia y tendencia
**Jira:** Los tickets se crean desde la herramienta y se siguen conectados.
**Construido con:** n8n (flujos) · Supabase (datos) · Hostinger (alojamiento) · Claude Code y Codex (construcción)
## El proceso, cada semana
La clave del proceso es que se repite sola cada lunes y que cada paso tiene un responsable claro: los agentes preparan, las personas deciden.
### **El ciclo semanal.** Los cinco primeros pasos los hacen agentes entrenados; el último es siempre de una persona.
1. **Extraer** (Agente): Cada lunes, de cada fuente. Por API o MCP, o por navegador cuando no hay otra vía.
2. **Limpiar** (Agente): Descarta las opiniones sueltas y se queda solo con los problemas reales.
3. **Definir el issue** (Agente): ¿Es un issue? ¿Cuántos describe? Un caso de roaming puede ser de red, de facturación y de soporte.
4. **Unificar** (Agente): Junta los que son el mismo problema: de 300 «issues» a 20–30 únicos.
5. **Clasificar** (Agente y persona): Seis facetas con la taxonomía del negocio. Lo que no se puede clasificar, a mano.
6. **Decidir** (Persona): El panel ordena por volumen y urgencia. El Product Owner decide y puede crear el ticket de Jira.
Un issue sin señal durante uno o dos meses pasa a «sin señal»: quizá ya no esté activo. Lo anterior a dos años se descarta, porque ya está resuelto.
## Quién lo usa y para qué
Una vez limpios y ordenados, los issues se suben a la plataforma, donde el Product Owner, el Business Analyst y el diseñador UX acceden a la información de cada uno, organizada por volumen y cantidad. El Product Owner no tiene que hacer nada más que decidir.
### **Roles y tareas.** El agente prepara la información; cada rol decide sobre una parte distinta del trabajo.
**Agentes de IA**
- Extraen el feedback cada lunes
- Limpian el ruido
- Definen y unifican los issues
- Los clasifican con la taxonomía
- No deciden qué se resuelve
**Product Owner**
- Ve los issues por volumen y urgencia
- Decide qué se resuelve y cuándo
- Crea el ticket de Jira desde la herramienta
**Business Analyst**
- Accede al detalle y a la evidencia de cada issue
- Decide de qué forma se resuelve
**UX Designer**
- Lee las palabras de los usuarios
- Diseña con información de primera mano
**Jira.** Los tickets se crean desde la propia herramienta y se siguen conectados.
## Decisiones clave
### Decisión 01 · Definir primero qué es un issue
- **Situación:** Los comentarios mezclan opiniones sueltas con problemas reales, y un mismo mensaje puede describir varios. En la primera prueba, el sistema contaba como distintos los que eran el mismo: de 300 issues abiertos se pasó a 20 o 30 únicos.
- **Alternativas:** Clasificar cada comentario tal cual, o dejar que el modelo decida solo qué es un problema.
- **Decisión y por qué:** Definir qué es un issue y entrenar a los agentes, a mano y con más de 300 casos, para decidir si un mensaje lo es, cuántos describe y cuándo dos son el mismo.
- **Efecto:** De 300 issues a 20–30 únicos, y fuera las opiniones sin un problema real.
**Detalle de un issue:** la descripción, las evidencias que lo respaldan y los issues relacionados.
### Decisión 02 · Una taxonomía de negocio y una ontología facetada
- **Situación:** Un issue se puede mirar desde muchos puntos de vista: dónde se genera, por qué, quién lo debe resolver, cuándo. Una lista de etiquetas planas no sirve a equipos tan distintos como My Sunrise, la app, Rewards, roaming o la eShop.
- **Alternativas:** Etiquetas libres, o un único árbol de categorías.
- **Decisión y por qué:** Mapear la taxonomía del negocio y clasificar cada issue con una ontología de seis facetas. La última, quién lo arregla, se deriva por regla y no se clasifica nunca a mano.
- **Efecto:** Cada equipo ve lo suyo, y cambiar al responsable de un tema no obliga a reetiquetar nada. Lo que el agente no sabe clasificar se corrige a mano.
**Las seis facetas** con las que se clasifica cada issue.
1. **Qué pasa:** El síntoma: por ejemplo, bloqueado, no puede continuar.
2. **Sobre qué:** El producto o el hardware: por ejemplo, un modelo de móvil.
3. **Haciendo qué:** La etapa del recorrido: por ejemplo, la activación.
4. **Dónde intentó resolverlo:** My Sunrise, línea de atención, chatbot o tienda.
5. **Por qué pasa:** La causa raíz, si era evitable y a quién se atribuye.
6. **Quién lo arregla:** Se deriva por regla, a partir del tema y el hardware. Nunca a mano.
### Decisión 03 · El agente limpia y clasifica; la persona decide
- **Situación:** Los Product Owners decidían por intuición, sin datos reales y medibles, y el feedback no les llegaba. La tentación con IA es que también decida.
- **Alternativas:** Que el agente también priorice y decida qué se hace.
- **Decisión y por qué:** El agente solo limpia y clasifica; todo lo revisan agentes entrenados, con contexto de negocio y una taxonomía específica. El Product Owner decide y planifica. Lo que redacta la IA aparece marcado como sin revisar hasta que alguien lo acepta, lo edita o lo descarta.
- **Efecto:** El Product Owner decide con información real, planifica por volumen y urgencia y crea el ticket sin salir de la herramienta.
**Recomendaciones:** la propuesta redactada por la IA se marca como sin revisar, con las opciones aceptar, editar o descartar.
## Cómo lo probé
Lo probó el equipo de producto de la app, con un feedback muy positivo, sobre todo porque se construye a partir de necesidades reales y no de decisiones de negocio que a veces no se pueden demostrar. La primera prueba fue mal: la clasificación fallaba el 95 % de las veces. Hubo que trabajar la taxonomía y entrenar a los agentes, a mano y con más de 300 issues, para que entendieran qué es realmente un issue y lo clasificaran bien, y para que supieran qué es un issue único. Después de ese trabajo, todo se revisa con agentes entrenados.
## Qué funcionó y qué no
- **Funcionó:** la clasificación, una vez entrenados los agentes y afinada la taxonomía. Lo más complicado fue pulir el modelo de clasificación y la priorización.
- **Funcionó:** la hipótesis. Un diseñador de producto puede crear algo funcional de principio a fin, con poco presupuesto, y el resultado es útil para construir backlogs con datos reales.
- **Sigue sin resolver:** el proyecto está en pausa por una reorganización interna, así que no ha pasado de piloto.
## Qué sigue
La idea era incorporar los datos de las llamadas, que son los que más volumen generan. Para eso habría que pasar de piloto a proyecto real y transcribir las llamadas para analizarlas. También quería sumar el feedback de la investigación: cuestionarios, tests de usuario y entrevistas, que son otra fuente de feedback.
**Estudios:** en el diseño, los resultados de tests, entrevistas y encuestas se cruzan con cada issue.