Fichas de producto y notas de uso redactadas a partir de una tabla de atributos, con edición humana obligatoria antes de publicar.
El catálogo interno de la empresa había pasado de unas pocas decenas de referencias a más de cuatrocientas en menos de un año. Cada producto necesitaba su ficha: descripción comercial, notas de uso, advertencias según la familia a la que pertenecía y una lista de atributos técnicos que venía de la hoja de cálculo que usaba el área de compras. El equipo de contenido, dos personas a tiempo parcial, no podía seguir el ritmo. Las fichas se acumulaban en una carpeta compartida con nombres como pendiente_revisar_v3 y nadie sabía cuáles estaban al día.
La primera decisión fue no tocar la fuente de datos. La hoja de cálculo se mantuvo tal cual, con sus columnas irregulares y sus celdas vacías, porque cualquier cambio ahí habría roto el trabajo diario de compras. El flujo lee esa tabla, agrupa los productos por familia y genera un borrador de ficha por cada fila. La plantilla de redacción cambia según la familia: no es lo mismo describir un accesorio de conexión que un consumible con instrucciones de manipulación.
El borrador incluye tres bloques: descripción breve, notas de uso y advertencias. Cuando un atributo necesario falta, el texto no lo inventa. En su lugar aparece una marca visible, algo como dato pendiente: peso neto, para que quien edite sepa exactamente qué revisar antes de dar por buena la ficha. Esa marca es la parte del flujo que más discusiones generó al principio, porque algunos atributos se daban por obvios y no lo eran.
Los campos que quedaron fuera del modelo fueron deliberados: códigos internos, referencias de proveedor y cualquier valor que solo tuviera sentido dentro de la empresa. El modelo redacta, pero no decide qué se publica ni con qué nombre comercial.
El equipo pasó de redactar cada ficha desde cero a editar un borrador ya estructurado. El tiempo por ficha bajó, aunque nadie se atrevió a poner un número porque dependía mucho de la familia y de cuántos datos faltaran. Lo que sí quedó claro es que la revisión humana sigue siendo el paso crítico: el flujo acierta en la forma, pero falla cuando la tabla trae valores contradictorios entre dos columnas.
En las notas de implementación se recogieron dos aprendizajes. El primero: conviene mantener una lista corta de campos prohibidos para el modelo, sobre todo los que se refieren a compatibilidades y certificaciones. El segundo: las plantillas por familia hay que revisarlas cada vez que se añade una categoría nueva, porque heredan frases que no aplican. El flujo no se cierra nunca del todo.
Puedes ver el resto de casos en el portafolio de proyectos o comparar este flujo con el de triaje de correo interno, que comparte la misma lógica de aprobación humana antes de actuar.
Lo que sigue no es una receta cerrada: son las precisiones que el equipo de contenido pidio por escrito antes de arrancar el piloto de fichas. Sirven para que nadie espere magia donde hay reglas, y para que las decisiones sobre datos faltantes queden firmes desde el primer dia.
Si el borrador de una ficha llega con campos marcados como incompletos, o si una plantilla por familia de producto no encaja con los atributos que sí existen en la hoja de cálculo, conviene escribirnos antes de editar a mano. Revisamos el caso concreto: qué columna falta, qué categoría quedó fuera del modelo y qué frase se generó sin respaldo de datos. Respondemos en horario laboral de Paraguay y ordenamos las consultas por tipo para no perder contexto entre mensajes.
Escribe a info@streamlineaiq.com adjuntando el identificador del producto y la captura del campo marcado. Es la vía más útil cuando el problema está en una plantilla por familia o en un atributo que el flujo no debería tocar. Respondemos en un plazo de uno a dos días hábiles.
Llama al +595 991 255 068 si necesitas revisar cómo se conecta la hoja de cálculo con la generación de fichas o cómo se ajustó el umbral de campos obligatorios. Atendemos consultas breves de configuración y derivamos los casos largos al correo.
Cuando una advertencia por categoría no corresponde al producto real, indícalo con el nombre de la familia y el texto exacto que quieres corregir. Ajustamos la plantilla y dejamos constancia en las notas de implementación para que el cambio no se pierda en la siguiente iteración.
Las incidencias que bloquean la publicación de una ficha se atienden primero. Las sugerencias de mejora sobre redacción o estructura se agrupan y se revisan al cierre de semana. Si tu consulta queda abierta más de lo previsto, responde al mismo hilo y la retomamos con prioridad.
Muchas dudas sobre campos fuera del modelo, edición humana obligatoria y límites del flujo ya están resueltas en la sección de ayuda. Si después de leerlas el caso sigue sin encajar, escríbenos con los detalles y lo vemos juntos.
Consulta primero las preguntas frecuentes o revisa las condiciones de uso en soporte antes de enviar tu caso.
Detrás de este flujo de generación de borradores para el catálogo interno hay trabajo de campo: revisar hojas de atributos mal normalizadas, discutir con el equipo de contenido qué frases sí y qué frases no, y aceptar que el modelo nunca va a saber más que la tabla que le damos. Soy Hector Torres Perez, coordino la implementación técnica de los proyectos que ves en este portafolio y me encargo de que cada flujo quede documentado con sus límites, no solo con sus aciertos.
La mayoría de los encargos llegan desde equipos pequeños de operaciones, compras o contenido que ya probaron herramientas sueltas y necesitan algo más ordenado: una tubería que conecte la hoja de cálculo con el sistema donde vive el catálogo, que marque los campos vacíos antes de redactar y que deje el texto en estado borrador hasta que una persona lo apruebe. Ese es el patrón que se repite en los tres casos publicados, incluido el de fichas de producto.
Si tienes una tabla de atributos que crece más rápido de lo que puedes redactar, o quieres revisar cómo se conectaron las plantillas por familia de producto, escríbeme y vemos si el enfoque encaja con tu catálogo. También puedes pedir las notas de implementación y las plantillas reutilizables del proyecto.
Estas capturas salen del entorno de trabajo real del proyecto de generacion de borradores. No son mockups: son pantallas del flujo tal como lo usa el equipo de contenido cuando recibe una tanda de productos nuevos y necesita tener algo editable sobre la mesa antes de la reunion semanal. Cada imagen corresponde a un momento concreto del recorrido, desde la hoja de atributos hasta el borrador marcado para revision.
Recorrido visual del pipeline: entrada de datos, plantillas por familia de producto, marcado de campos faltantes y salida lista para edicion humana.
Ver la ficha completa del proyecto