El portafolio de proyectos de automatización que sí convence a una empresa

La demo que impresiona cinco minutos y no cierra nada

Un candidato a un puesto de automatización llega a la entrevista con una presentación de veinte diapositivas: capturas de nodos conectados en n8n, un condicional aquí, un trigger de webhook allá, la lista completa de herramientas que domina (Make, Zapier, n8n, algo de Python). El entrevistador asiente, pasa las diapositivas rápido y en algún momento hace la pregunta que corta el ritmo: “¿y esto qué cambió en la empresa donde lo hiciste?”. Silencio. El candidato tiene flujos, no tiene un número.

La misma escena se repite en la reunión comercial, solo que quien pregunta es el cliente y lo que está en juego es el contrato. El consultor abre su portafolio y muestra capturas que, para alguien que no automatiza todos los días, podrían ser de cualquier empresa: cajas conectadas por líneas, nombres de herramientas, algún certificado. El cliente escucha, y en algún momento hace la pregunta que hace cualquier comprador que ya gastó plata en tecnología antes: “¿cuánto costaba este proceso antes y cuánto cuesta ahora?”. Si la respuesta tarda en llegar, la reunión ya se perdió, aunque nadie lo diga en voz alta.

Lo que un portafolio de automatización tiene que demostrar

El error de fondo no es de diseño ni de cantidad de proyectos. Es de qué se elige mostrar. Una captura de un flujo prueba que la persona sabe operar una herramienta: arrastrar nodos, conectar un disparador con una acción. Eso, para quien contrata o compra, ya es un piso mínimo, no un diferencial, porque asume que si alguien dice que hace automatizaciones, sabe usar el software. Lo que la empresa realmente necesita saber, y casi nunca pregunta directamente porque da por hecho que el portafolio se lo va a mostrar, es si ese trabajo cambió algo que le importa: un costo, un tiempo, un error que dejó de repetirse.

Esa es la diferencia entre un portafolio que impresiona y uno que convence. El primero exhibe dominio de herramienta. El segundo exhibe criterio: qué proceso se miró, qué decisión se tomó sobre qué automatizar y qué no, y qué pasó con un número real después de tocarlo. Nadie contrata ni compra una herramienta. Compra la certeza de que esa persona sabe diagnosticar un proceso antes de automatizarlo, y ese criterio no se ve en una captura de pantalla.

Qué sacar del portafolio: lo que ya se da por sentado

Antes de sumar algo, hay que sacar lo que ocupa espacio sin aportar nada nuevo. Tres elementos aparecen en casi todos los portafolios de automatización, y en ninguno de los que de verdad convencen en una decisión de compra o de contratación:

• Las capturas de nodos y flujos completos: muestran la mecánica interna del proceso, que solo le interesa a otro automatizador. A quien decide (gerente, dueño de negocio, cliente) esa captura no le dice nada sobre el resultado.
• La lista de herramientas dominadas: n8n, Make, Zapier, Python, la API de turno. Es información de currículum, no de caso. Confirma que la persona sabe operar, no que sepa diagnosticar.
• Certificados y cursos: acreditan que alguien estudió algo, no que lo aplicó con un resultado medible. Sirven como filtro inicial de un reclutador, nunca como argumento de cierre.

Ninguno de estos tres elementos está mal en sí mismo, ni hay que borrarlos del currículum. El problema aparece cuando ocupan el lugar central del portafolio, porque entonces la conversación se queda en “sé usar la herramienta” cuando la pregunta real es otra. Quien evalúa el portafolio de un candidato de IA suele mirar exactamente esto primero: si el enfoque está en la mecánica o en el resultado.

Qué poner en su lugar: proceso, número y lo que decidiste no automatizar

Lo que reemplaza a la captura de nodos es más simple de armar de lo que parece, y más difícil de sostener porque obliga a medir. Un caso que convence tiene tres piezas, no más:

• El proceso antes y después, en un párrafo cada uno: cómo se hacía la tarea (quién, cuántas veces, con qué herramienta) y cómo quedó después de automatizarla. No hace falta un diagrama técnico, hace falta que un gerente que nunca vio un flujo entienda el cambio en dos frases.
• Un número, aunque sea aproximado y declarado como tal: horas que se dejaron de gastar por semana, tiempo de respuesta que bajó, errores que dejaron de pasar. Si el número exacto es confidencial, se declara como rango u orden de magnitud, nunca se inventa.
• La decisión de qué no se automatizó: qué parte del proceso se dejó en manos de una persona a propósito, y por qué. Esa decisión, más que el flujo mismo, es la que demuestra criterio, porque cualquiera puede automatizar algo, pero pocos saben decir con argumento qué no conviene tocar.

Estas tres piezas son la diferencia entre un caso y una automatización suelta. Encadenar tres o cuatro flujos vistosos sin conectarlos a un objetivo del negocio es exactamente lo que describe cómo dejar de vender automatizaciones aisladas: trabajo real, pero sin relato de negocio detrás, así que no convence a nadie que no sea otro automatizador.

Cómo presentar un caso sin romper la confidencialidad del cliente

La objeción más común para no mostrar el proceso antes y después es la confidencialidad, y es una objeción real, no una excusa. La respuesta no es ocultar el caso, es anonimizarlo bien. La regla es simple: el caso se describe por sector, tamaño y país, nunca por nombre, y las cifras exactas se convierten en rango o en porcentaje cuando el número absoluto pueda identificar a la empresa.

• Sector, tamaño y país en vez de nombre: “una empresa de logística de tamaño mediano en Perú” dice tanto como el nombre real para efectos de credibilidad del caso, y no expone a nadie.
• Cifras absolutas convertidas en porcentaje o rango: si el ahorro exacto en dólares identifica al cliente por el tamaño de su operación, se declara como “una reducción de entre 20% y 30% en el tiempo del proceso”, no como el monto exacto.
• Cero jerga interna ni capturas reales de pantalla de sistemas del cliente: ni el nombre del ERP, ni el logo, ni una captura con datos reales visibles, aunque estén difuminados. Ese difuminado se revierte más fácil de lo que parece.
• Permiso explícito antes de usar el nombre real: si el cliente autoriza usar su nombre, eso vale más que cualquier anonimización, pero el permiso tiene que quedar registrado, no asumido a partir de una conversación informal.

Con esas cuatro reglas se puede contar el proceso, el número y la decisión sin exponer un solo dato que identifique al cliente. Esa habilidad, armar un portafolio de consultor de IA sin romper confidencialidad, es la que separa a quien lleva años trabajando con clientes reales de quien todavía solo hizo proyectos de práctica: la primera persona ya tuvo que resolver este problema, la segunda todavía no.

Qué hacer si tus proyectos de automatización fueron pequeños

La objeción que sigue a la de confidencialidad es la del tamaño: “mis automatizaciones fueron para mi propio negocio, o para una empresa chica, o simplemente para ordenar mi propio trabajo”. El error es pensar que eso no cuenta. Lo que hace válido un caso no es la facturación de la empresa donde se hizo, es que exista un antes, un después y un número, sin importar la escala.

• Un proceso personal cuenta si tiene medición: automatizar el seguimiento de tus propias postulaciones a trabajo o el armado de reportes de un negocio propio vale como caso si puedes decir cuánto tiempo te ahorraba por semana.
• Un proyecto de práctica cuenta si el dato es real, no inventado: probar un flujo con datos ficticios está bien para aprender, pero no se presenta como caso de negocio. Un caso necesita un dato real detrás, aunque sea pequeño.
• Tres casos chicos bien medidos valen más que uno grande sin número: la cantidad no reemplaza la falta de medición, pero varios casos modestos y honestos sí construyen un patrón de criterio que un caso solo, sin cifra, no logra.

La empresa que evalúa no está comparando el tamaño de tu cliente anterior contra el de otro candidato. Está buscando evidencia de que ya pasaste por el ejercicio de medir un proceso y defender un número, sin importar si ese número fue de tres horas semanales o de tres mil. Esa evidencia es transferible a cualquier escala; la falta de ella no se compensa con más oportunidades de trabajo con inteligencia artificial listadas en el currículum.

Dónde publicarlo: por qué LinkedIn solo no alcanza

LinkedIn sirve para que te encuentren, no para que te evalúen. Un post con capturas y un resumen de dos líneas cumple una función de visibilidad: aparece en el feed, alguien lo comparte, genera una primera impresión. Pero cuando la conversación pasa a una entrevista o a una reunión comercial, nadie vuelve a desplazarse por tu historial de publicaciones buscando el caso completo. Hace falta un lugar fijo, con el proceso, el número y la decisión de qué no se automatizó, sin depender del algoritmo de una red social para seguir siendo visible.

Ese lugar puede ser tan simple como un documento de una página por caso, o una sección propia dentro de una web personal. Lo que importa no es el formato, es que el material exista fuera del feed y se pueda enviar como link o adjunto en el momento exacto en que alguien pregunta “¿tienes ejemplos?”. El consultor de IA que ya tiene ese material listo gana la mitad de la reunión antes de que empiece, porque no improvisa la respuesta, la reenvía.

Mi criterio sobre qué mirar primero en un portafolio

Cuando reviso el portafolio de alguien que quiere trabajar conmigo o con un cliente de IARVIX, hay un orden fijo en el que miro las cosas, y casi nunca empieza por los flujos.

Cómo se usa el portafolio en la reunión, no antes

El portafolio no se manda entero por correo antes de la reunión ni se lee en voz alta durante la llamada. Se usa como respaldo de lo que ya se está diciendo en la conversación: cuando el cliente o el entrevistador pregunta “¿tienes un ejemplo de algo parecido?”, ahí se comparte pantalla o se envía el link del caso puntual, no los veinte casos juntos. Mostrar todo de una vez diluye la atención sobre el caso que sí es relevante para ese cliente específico.

La pregunta que casi siempre sigue después del caso es la más incómoda y la más importante: “¿y si el proceso cambia, el flujo se rompe?”. Quien solo mostró capturas de nodos no tiene respuesta preparada, porque nunca pensó en el mantenimiento. Quien preparó el caso completo ya sabe qué responder, porque forma parte de la misma disciplina: la inteligencia artificial para empresas que dura más de un trimestre no es la que automatiza más rápido, es la que alguien sostiene después del lanzamiento.

La reunión no se gana por la cantidad de flujos que alguien pueda mostrar bajo presión, se gana por la claridad con la que explica un proceso, defiende un número y admite en qué parte del sistema decidió no meter la mano. Ese criterio, más que cualquier automatización, es lo único que un portafolio realmente necesita probar.