Vinculación a Cuenta Planilla — de un proceso manual a una experiencia conectada por reglas, automatización e IA

Video — cómo funciona la PoC

El contexto

Un proceso digital que todavía comenzaba con un Excel. La vinculación de nuevos colaboradores a Cuenta Planilla dependía de múltiples interacciones manuales antes de que el proceso llegara realmente al colaborador.

Cuando una empresa quería iniciar una vinculación, normalmente debía contactar a un asesor Banistmo para obtener el archivo Excel utilizado para registrar la información. En otros casos, los propios asesores visitaban las empresas con tablets para ayudar a diligenciar los datos de los colaboradores.

Después, Backoffice recibía esa información y continuaba manualmente el registro. Si existían datos incorrectos o incompletos, comenzaba un nuevo ciclo de contacto con la empresa, corrección y seguimiento.

El proceso real ocurría entre personas, tablets y hojas de cálculo — antes de tocar el producto digital

El reto de diseño

¿Cómo automatizar el proceso sin automatizar decisiones sensibles? El reto no era simplemente convertir el archivo Excel en un formulario.

Era necesario entender qué información debía entregar cada actor y qué partes del proceso podían automatizarse sin comprometer controles asociados a identidad, información personal o apertura de una cuenta bancaria. La solución se diseñó bajo tres principios.

La solución

Una vinculación dividida en dos experiencias conectadas. La propuesta divide la vinculación en dos momentos, cada uno con su propio responsable y su propio espacio dentro del mismo expediente.

Cada proceso genera un identificador único (PLN-XXXXXXXX). El sistema valida la información de la empresa y asigna un estado: Pendiente colaborador o Requiere corrección empresa. Al finalizar la etapa del colaborador, el mismo expediente cambia a Completado.

Etapa 1 (empresa) y Etapa 2 (colaborador), conectadas por el mismo idRegistro

La experiencia de la empresa

El pre-registro comienza dentro del producto. La empresa deja de depender del Excel como interfaz principal del proceso. Desde Banca en Línea puede registrar directamente al colaborador y consultar posteriormente el estado de cada vinculación.

El objetivo era reducir la dependencia del asesor y detectar problemas lo antes posible, antes de convertirlos en trabajo manual para Backoffice.

Banca en Línea Empresa — registro y seguimiento de cada vinculación

Diseñar también las excepciones

Un flujo correcto es importante. Un flujo con errores, todavía más. Uno de los objetivos de la PoC fue demostrar qué ocurre cuando la información ingresada no cumple una regla.

Por ejemplo, un teléfono registrado como 24680. La regla del sistema determina que el número no cumple con los 8 dígitos requeridos, y el caso cambia automáticamente a Requiere corrección empresa.

Esa comunicación no la escribió nadie manualmente — la IA transformó el resultado técnico de la regla en un mensaje comprensible, y devolvió el problema de inmediato al actor que podía corregirlo.

La decisión más importante sobre IA

La IA no valida el banco. La IA mejora la interacción. Desde el diseño de la solución definí un límite claro entre reglas de negocio e IA generativa.

Esta separación permite aprovechar IA generativa sin delegarle decisiones sensibles.

Del mockup a una PoC funcional

No quería presentar solamente un flujo en Figma. Para comprobar que el concepto podía funcionar de punta a punta construí una PoC funcional conectando interfaces, automatización, reglas, datos e IA generativa.

Arquitectura funcional

Dos workflows, un mismo idRegistro. La PoC funciona mediante dos escenarios independientes conectados por el mismo identificador.

El idRegistro permite que ambas experiencias operen independientemente sin perder continuidad.

Los dos workflows de Make, conectados por el idRegistro compartido

Un expediente compartido

La información necesitaba un punto común de trazabilidad. Para la PoC utilicé Google Sheets como simulador del expediente. No representa la arquitectura propuesta para producción; su función era comprobar que los dos workflows podían trabajar sobre un mismo registro.

Google Sheets como simulador del expediente único

La experiencia del colaborador

La información personal vuelve a manos de quien debe entregarla. La segunda experiencia permite que el colaborador complete directamente con Banistmo la información que la empresa no debería diligenciar en su nombre.

Al terminar, el mismo expediente que inició la empresa pasa automáticamente a estado Completado.

Portal del colaborador — flujo completo en móvil

Qué demostró la PoC

De concepto a funcionamiento end-to-end.

Cómo mediría el impacto

KPIs definidos para un piloto. Importante: estos son indicadores propuestos para validar un piloto — no corresponden a resultados reales de producción.

Priorización PACT

Antes de construir, evalué impacto y factibilidad.

Impacto

Factibilidad

Gobierno responsable

Diseñar IA en banca también significa diseñar sus límites.

De PoC a producto

Cómo evolucionaría la solución.

Reflexión

La parte difícil no era generar texto con IA. La parte más valiosa del proyecto fue decidir dónde no utilizarla.

En un flujo bancario, automatizar más no necesariamente significa diseñar mejor. Separar reglas determinísticas, IA generativa y revisión humana permitió construir una experiencia más eficiente sin perder control sobre las decisiones sensibles.

Este proyecto cambió mi forma de pensar el rol de Product Designer: no solo diseño interfaces y journeys; también puedo prototipar la lógica que los conecta y demostrar cómo una experiencia funciona de punta a punta.

Más proyectos

El contexto

El negocio de adquirencia de Banistmo — POS, mPOS y Wompi — reportaba pérdidas superiores a $11 millones. El producto se ofrecía como parte del paquete para conservar cuentas estratégicas, sin que el comercio percibiera un valor diferencial claro frente a la competencia. Antes de proponer cualquier solución, necesitábamos entender a fondo el journey completo — desde los ojos del comercio.

Entré al proyecto cuando el equipo comercial ya tenía hipótesis formadas: el problema era la tasa, la competencia, los cobros asociados. Mi rol fue salir a contrastar esas hipótesis con evidencia real, con una mente abierta a encontrar algo diferente. Diseñé el plan de investigación completo — la guía de entrevistas, la encuesta cuantitativa, la estructura del benchmark — y conduje personalmente la mayoría de las sesiones con clientes.

Proceso de investigación — 6 fases

Preguntas de investigación

Benchmark competitivo — alcance

Visita presencial a 4 competidores del sector para evaluar de forma directa su experiencia de adquirencia, además de un relevamiento de nuevos jugadores fintech enfocados en el segmento PYME. El objetivo no era copiar features, sino entender qué hacía que un comercio percibiera valor diferencial más allá de la tarifa.

Journey del cliente — 5 etapas críticas

Hallazgo 01 — Sin valor claro, la decisión es por costo

Hallazgo 02 — Promesa en ventas, enredo en instalación

Hallazgo 03 — Procesos cruzados sin sistema

La síntesis — de 28 sesiones a decisiones ejecutivas

El mayor reto no fue hacer las entrevistas. Fue transformar 28 sesiones en hallazgos que un comité ejecutivo pudiera convertir en decisiones de roadmap. Usé Dovetail para codificar la evidencia cualitativa por temas, la crucé con los datos de la encuesta y del benchmark, y construí un relato que conectara la experiencia del comercio con las pérdidas del negocio — sin perder la voz de los usuarios en el proceso.

Lo que encontré no siempre coincidía con lo que el negocio creía. El precio era un bloqueador real, sí — pero los datos mostraban que la instalación lenta y la falta de soporte estructurado pesaban casi igual. Presenté los hallazgos ante la VP de Experiencia, los equipos de producto y canales digitales, con recomendaciones priorizadas por impacto potencial y viabilidad de implementación.

¿Qué bloquea el cierre de ventas? — encuesta cuantitativa (+75 colaboradores)

Métricas de percepción de valor — clientes PYME y NEG

Prioridades del segmento NEG

Resultados — impacto de la investigación

Los hallazgos fueron presentados a liderazgo de producto, canales digitales y la VP de Experiencia. La investigación se convirtió en insumo directo del roadmap 2025–2026 de adquirencia.

Más proyectos

Consola de Ventas — pantalla de inicio del sistema estandarizado

El problema

El área comercial operaba con dos herramientas en paralelo — Merli y SalesLogic — sin un estándar compartido. Cada comercial registraba a su manera, los datos eran inconsistentes y era imposible medir el pipeline de forma homogénea. Una plataforma nueva sin diseño solo reproduciría los mismos problemas con otro nombre.

Cuando me asignaron el proyecto, lo primero que hice fue salir a entender el proceso real — no el que decían los documentos, sino el que ocurría cada día. Me reuní con comerciales de distintos perfiles, observé cómo registraban una gestión, pregunté qué información capturaban y cuál dejaban de lado. Lo que encontré era más fragmentado de lo esperado: cada equipo tenía su propia lógica, sus propias hojas de cálculo extra y sus propias formas de compensar lo que el sistema no hacía.

Antes y después

Proceso — 8 sesiones con usuarios piloto

El nudo — alinear 7 perfiles con lógicas distintas

Facilitar las ocho sesiones de co-diseño fue la parte más exigente del proyecto. El reto no era técnico — era de alineación. Cada rol tenía una versión diferente de cómo debía funcionar el proceso: el comercial gerenciador quería libertad para registrar a su manera; el gerente quería visibilidad inmediata; el equipo de datos exigía campos completos. Mi trabajo fue escuchar todas esas versiones, encontrar el patrón común y proponer un estándar que cada perfil pudiera reconocer como propio.

Cuando en la sesión de validación un gerente regional dijo "así es exactamente como debería funcionar", entendí que el estándar había pasado de ser una propuesta de diseño a ser el proceso del equipo. Eso definió el tono de la guía final: no un manual de software, sino un documento del proceso comercial de Banistmo que usa Salesforce como herramienta.

Proceso comercial estandarizado — 7 etapas

Este fue el corazón del proyecto: la correspondencia entre cada etapa del proceso comercial y el objeto/acción específica que el comercial debía registrar en Salesforce — de la fase S3–4 del co-diseño.

Extracto de la guía — mapa de proceso comercial → objetos Salesforce

Hallazgos que cambiaron el diseño

Hallazgo 01

Cada comercial registraba diferente — sin estándar ni campos obligatorios

Sin un estándar, los datos del pipeline eran incomparables entre equipos. Imposible construir reportes o medir la gestión colectiva.

Pantalla evaluada — anatomía de una Oportunidad

Decisión: Campos obligatorios por etapa con validaciones automáticas. El flujo no avanza si los datos críticos están incompletos.

Hallazgo 02

La terminología de Salesforce no hablaba el idioma del negocio bancario

"¿Qué es un Lead? ¿Cuándo creo una Cuenta vs. una Oportunidad?" — preguntas recurrentes en todas las sesiones de validación.

Decisión: Glosario bancario contextualizado al proceso comercial real de Banistmo, integrado como anexo de la guía.

Hallazgo 03

Los referidos entre equipos se perdían fuera del sistema

Cuando un comercial refería un cliente a otro segmento, la gestión se realizaba por WhatsApp sin registro ni seguimiento.

Decisión: Flujo de referidos estandarizado con Tareas y Chatter. Notificaciones automáticas y campos definidos para trazabilidad completa.

Hallazgo 04

Los vencimientos no estaban en el flujo diario del comercial

Los comerciales se enteraban de vencimientos de forma reactiva — tarde o por reportes externos. Oportunidades de renovación perdidas.

Pantalla evaluada — alertas de vencimiento

Pantalla evaluada — Vista 360 de Cuenta

Decisión: Componente de alertas en pantalla de inicio y Vista 360, vinculado a oportunidades de renovación accionables.

Glosario bancario — extracto de la guía

El anexo que resolvió el Hallazgo 02: los términos de Salesforce traducidos al lenguaje real del negocio bancario de Banistmo.

La guía — artefacto de adopción

La guía documenta 8 perfiles de acceso en total: los 7 roles comerciales con flujo propio, más un perfil adicional de consulta (Reportería) que se sumó para dar visibilidad ejecutiva sin permisos de edición.

Resultados — impacto medible

Más proyectos

Truconnect — pantalla de Integraciones, punto de entrada al flujo de conexión de APIs externas

Contexto del producto

Truconnect es la plataforma de Truora para crear chatbots sin código. Para que los chatbots accedieran a información de sistemas externos — bases de datos de clientes, CRMs, plataformas de e-commerce — los usuarios necesitaban conectar APIs externas. El proceso requería entender conceptos como autenticación, HTTP requests y manejo de credenciales.

El producto ya existía y funcionaba, pero el flujo de configuración de integraciones nunca había sido diseñado — lo que había era documentación técnica. Suficiente para quien sabía exactamente qué buscar, pero confusa para quien llegaba por primera vez. Me asignaron como responsable de diseño con autonomía total para definir la arquitectura y el flujo desde cero.

La decisión más importante que tomé fue no abrir Figma hasta tener claro cómo pensaba el usuario. Cuatro sesiones con seis ingenieros antes de dibujar un solo wireframe. Esas conversaciones me enseñaron que el problema no era falta de información — era falta de estructura mental. Los ingenieros saben qué es una API; lo que no tenían era una forma de relacionar ese conocimiento con los pasos específicos que el producto les pedía.

Proceso de diseño — 4 fases

Arquitectura de la solución — 4 etapas

Las 4 etapas reflejadas en el producto — Name, Authentication, Credentials, Actions

El filtro — 131 comentarios y cómo usarlos

La revisión interna con 40 personas generó 131 comentarios en Figma. En lugar de procesarlos de forma lineal, me senté con el PM a categorizar: qué era una corrección real de experiencia, qué era preferencia personal y qué era conflicto entre perspectivas técnicas. De los 131 comentarios, alrededor de 30 eran accionables para el diseño. Los demás eran valiosos, pero de otro tipo.

Ese ejercicio de filtrado fue tan importante como el diseño en sí. Si hubiera intentado incorporar todo, el flujo habría perdido coherencia. Si hubiera ignorado la revisión, me habría perdido señales reales de problemas de interacción que luego confirmaron los tests con usuarios.

Pruebas de usabilidad

Se realizaron 8 pruebas de usabilidad con ingenieros usando un prototipo en Figma y un script con 11 tareas directas a realizar.

Hallazgos de usabilidad y decisiones de diseño

Problema 01 · Crítico · 4/8 usuarios

Los pasos no se percibían como secuencia progresiva

Los usuarios no entendían el orden ni en qué paso estaban. Intentaban saltarse etapas o repetir pasos ya completados.

Pantalla evaluada — Authentication, listado de pasos

Solución: Numeración explícita (1, 2, 3) con indicador visual de estado por paso — activo / completado / pendiente. Contraste de color para comunicar progreso sin texto adicional.

Problema 02 · Alto · 2/8 usuarios

El campo "Label name" era semánticamente vacío

Los usuarios no entendían qué se les pedía ni en qué contexto se usaría ese nombre después en el chatbot.

Pantalla evaluada — modal Add authentication field

Solución: Nombres contextuales específicos por paso (ej. "Nombre de la autenticación") con descripción y ejemplo en placeholder.

Problema 03 · Alto · 2/8 usuarios

El botón de acción no comunicaba qué seguía

"Save and go" no indicaba si el sistema iba a ejecutar algo inmediatamente. Generaba incertidumbre sobre el resultado del clic.

Pantalla evaluada — Configure a test request

Solución: Renombrado a "Save and go to test" — verbo de acción + destino explícito.

Problema 04 · Medio · 2/8 usuarios

Los campos opcionales no se diferenciaban visualmente

Los usuarios trataban todos los campos como obligatorios, generando confusión al no saber si debían completarlos.

Pantalla evaluada — Name and description

Solución: Etiqueta "Opcional" explícita + menor peso visual en campos no requeridos.

Flujo completo — demo en video

El flujo final de conexión de una API externa en Truconnect, de principio a fin, con las decisiones de diseño ya integradas.

Resultados — impacto de la entrega

Más proyectos

El problema

TruChecks era un producto robusto pero su crecimiento dependía 100% del equipo de ventas. El usuario potencial no podía llegar, probar y entender el valor del producto de forma autónoma — lo que alargaba el ciclo de adopción.

Cuando entré al proyecto, el producto no tenía medición de comportamiento. Sin datos, sin funnel, sin forma de saber dónde y por qué se perdían los usuarios. Lo primero que hice fue construir la infraestructura de medición: Mixpanel para el funnel de activación, Typeform para perfilar al usuario real, Hotjar para observar el comportamiento en pantalla. Solo desde ahí podía diseñar con certeza — no desde suposiciones.

Antes y después — el cambio de modelo

Antes — formulario genérico, sin personalización

Después — selección de caso de uso primero

Perfil del usuario — encuesta Typeform (65 respuestas)

El giro — el problema no era el producto, era el contexto

Las entrevistas confirmaron algo que el funnel ya insinuaba: el producto no fallaba por falta de valor, sino por falta de contexto. El usuario llegaba, veía una pantalla con decenas de opciones de bases de datos, y no sabía por dónde empezar. La primera consulta — el momento donde debería ocurrir el AHA moment — se convertía en una experiencia de ensayo y error.

El insight que cambió el diseño no vino de un análisis sofisticado. Vino de una respuesta sencilla en una entrevista: "No sabía que podía hacer una consulta vehicular". El usuario no conocía todo lo que el producto podía hacer por él. Si el sistema sabía para qué necesitaba verificar el usuario, podía mostrarle exactamente lo que necesitaba — y filtrar todo lo demás. Eso fue lo que guió el rediseño.

Métricas del tour guiado — Intercom · 45 días

Análisis de funnel — Mixpanel (154 usuarios)

🔍 Lectura del funnel: La caída más pronunciada ocurre entre el 2do y 3er check (73% → 44%). El usuario ya ve valor pero aún no entiende del todo la plataforma — señal de que el onboarding guiado necesitaba activarse antes.

Mapa de experiencia — de la primera consulta a la suscripción

Mapeo de los tres puntos de contacto del producto — ingresar inputs, analizar resultados y suscribirse — cruzando actividades, nivel de fricción, expectativas del usuario e insights accionables en cada paso.

Desliza para ver el mapa completo — el punto de mayor fricción está en "ver resultado de la consulta" y en el formulario de facturación

Solución — verificador personalizado por caso de uso

El rediseño reorganizó el punto de entrada: el usuario selecciona su caso de uso primero, y la plataforma pre-configura las fuentes relevantes, reduce el ruido informativo y entrega un resultado accionable para ese contexto.

Ejemplo — Consulta vehicular, con campos y fuentes filtradas a ese caso de uso

Decisiones de diseño basadas en datos

Dato: 90% de free trials con puntaje = 10

La escala 0–10 no generaba decisiones — era ruido visual

En el 90% de los casos el puntaje era 10, pero los usuarios no sabían qué hacer con ese número. El momento de valor no llegaba porque el resultado no era accionable.

Antes — puntaje 0–10 sin contexto

Después — estados: Aprobada · Rechazada · Sin definir

Decisión: Reemplazar el puntaje por tres estados con semántica clara: Aprobado · Rechazado · Sin definir, con contexto sobre fuentes consultadas.

Insight de entrevistas

Consulta genérica sin personalización generaba sobrecarga

El flujo original mostraba todas las bases de datos disponibles sin filtrar — el usuario tenía que entender toda la taxonomía antes de obtener algo útil.

Decisión: Flujo iniciado desde la selección del caso de uso. El sistema filtra automáticamente las fuentes relevantes para ese contexto específico.

Dato del funnel: 7% de contacto a ventas

El llamado a la acción de conversión aparecía en el momento equivocado

Solo el 7% de los usuarios que hicieron un check contactaron a ventas. La mayoría terminaba el free trial sin una guía clara de qué hacer después.

Decisión: Reposicionar el llamado a la acción al momento en que el usuario agota su tercer check — cuando el valor ya está demostrado y la decisión de escalar es natural.

Prototipo — flujo completo del verificador

El flujo rediseñado de principio a fin: selección de caso de uso, ingreso de datos filtrados y resultado con estado accionable.

Resultados — impacto del rediseño

Más proyectos