CRM de crédito hipotecario
Un CRM que usan a diario 60 asesores de ventas, riesgos y cobranza. Redujo de 30 días a 10 el tiempo entre la solicitud del crédito y el desembolso, y un modelo de IA integrado eliminó la curva de aprendizaje del asesor.
Cliente:
Fintech de crédito con garantía hipotecaria · Lima, Perú
Categoría:
Fintech · Crédito
Mi rol:
Product Designer · Design Engineer
Product Designer · Design Expert, IA y Product Design · Lima, Perú (remoto) · Tiempo completo · Junio 2024 – actualidad
Una fintech de crédito con garantía hipotecaria: una persona pone como garantía un inmueble que ya es suyo y toma un préstamo contra él. La empresa funciona con asesores — ventas, riesgos y cobranza — y antes de este proyecto funcionaba con hojas de cálculo, WhatsApp y un expediente de crédito que pasaba de mano en mano. Diseñé y llevé a producción el CRM que reemplazó todo eso. El front end es mío, lidero a una analista de QA y dos desarrolladores, y construí la capa de IA que vive dentro del producto. Sesenta asesores lo usan todos los días, y el tiempo entre la solicitud y el desembolso pasó de 30 días a 10.
En resumen
Rol: Product Designer y Design Expert en IA y product design. Diseño el producto, soy dueño del front end y lidero a una analista de QA y dos desarrolladores.
Alcance: un CRM, tres roles dentro de él — ventas, riesgos y cobranza — más la capa de IA que atraviesa a los tres.
Restricciones: dinero real contra un inmueble real. Cada paso tiene una consecuencia legal y crediticia, y quienes usan la herramienta no son usuarios expertos — son asesores, y los asesores rotan.
Resultado: de 30 días a 10 entre la solicitud y el desembolso. La curva del asesor pasó de meses a su primer día. Otra empresa adquirió el proyecto para operarlo con su propia fuerza de asesores en México.
Los tres roles
Un mismo expediente pasa por tres roles que están diseñados para no estar de acuerdo, y cada uno necesita una vista distinta de la misma verdad.
Ventas: quiere el crédito aprobado. Es dueño del expediente mientras el solicitante todavía está decidiendo si espera — la ventana que los treinta días estaban destruyendo. Abre el CRM y encuentra una cola ya ordenada, no una tabla que tiene que triar.
Riesgos: quiere las razones por las que el crédito no debería aprobarse. Lee el mismo expediente con las alertas que valen la pena primero, para que el trabajo sea criterio y no una lista que hay que moler.
Cobranza: hereda lo que decidieron los otros dos, meses después, cuando el cliente deja de pagar. Recibe primero las cuentas con más probabilidad de recuperarse, y necesita el historial que generaron ventas y riesgos para entender qué tiene entre manos.
La mayor parte de este proyecto no fue trabajo de pantallas. Fue decidir quién ve qué, en qué momento, y qué puede hacer al respecto.
El problema
Treinta días entre que una persona pide un crédito y el dinero llega. Casi nada de eso era evaluación crediticia. Era el expediente esperando en una bandeja de entrada, el documento pedido dos veces, la analista de riesgos esperando a un asesor comercial que estaba en una reunión, el estado que nadie podía ver sin preguntarle a alguien. En crédito esa demora es el producto: un solicitante que espera treinta días normalmente ya se fue a otro lado el día doce.
El segundo problema era más silencioso y más caro. Un asesor tardaba meses en volverse útil. El crédito hipotecario tiene su propio vocabulario, su secuencia y sus reglas, y las herramientas anteriores asumían que uno ya los conocía. Cada nueva contratación eran meses de sueldo antes de la primera venta.
Cómo trabajé
Discovery con el negocio, no un backlog: dirijo las sesiones directamente con ventas, riesgos y cobranza, planteadas como jobs to be done y no como pedidos de funcionalidades, y cierro cada una con una hipótesis escrita y la métrica que nos diría si funcionó.
Prototipos antes que tickets: construyo prototipos funcionales con herramientas de IA durante el discovery, para que un área del negocio pueda hacer clic en la idea en lugar de leer una especificación. Es mucho más barato equivocarse en un prototipo que en un sprint.
El modelo de datos antes que la interfaz: reviso el esquema con el equipo de backend sobre las queries y mutations reales de GraphQL antes de que se construya nada, para que la interfaz y los datos coincidan antes de que exista cualquiera de los dos.
La entrega es parte del diseño: entrego el trabajo construido, reviso los tickets de front end antes de que entren a desarrollo, y acompaño la funcionalidad durante la integración con backend hasta producción y el QA funcional y de regresión.
La capa de IA que eliminó la curva de aprendizaje
Un asesor necesitaba meses de formación antes de su primera venta. Con el modelo dentro del CRM vende desde el primer día.
Qué hace
La IA no es un chat pegado al costado del CRM. Lee el expediente — datos del solicitante, documentos, el inmueble, el historial — y lo convierte en lo siguiente que el asesor debería hacer, en el orden en que debería hacerlo.
Eliminó la curva de aprendizaje, que era el punto. Un asesor que antes necesitaba meses de formación ahora vende desde su primer día, porque el producto le dice qué necesita el expediente en lugar de esperar que ya lo sepa.
Jerarquiza el trabajo en lugar de listarlo. El asesor abre el CRM y encuentra una cola ya ordenada, no una tabla que tiene que triar.
El mismo patrón en cobranza y riesgos. Cobranza recibe primero las cuentas con más probabilidad de recuperarse; riesgos recibe primero las alertas que vale la pena leer.
Los problemas de diseño que creó el modelo
Meter un modelo dentro de un producto de crédito abre preguntas que no existen en un CRM normal, y son preguntas de interfaz antes que de ingeniería.
Qué mostrar cuando el modelo no está seguro. Una sugerencia que se ve segura construida sobre datos pobres es peor que ninguna sugerencia, así que la incertidumbre tenía que ser visible y no quedar disimulada.
Qué puede pasar por alto el asesor, y cuánta fricción debería costarle hacerlo.
Qué tiene que seguir visible para que una persona pueda estar en desacuerdo. En crédito, una sugerencia que el asesor no puede cuestionar es un problema de cumplimiento, no una funcionalidad.
Del diseño al código
No entrego este producto y me voy. El front end es mío: el modelo de datos revisado con backend sobre GraphQL antes de construir, los tickets de front end revisados antes de que entren a desarrollo, el trabajo entregado construido y no especificado, y una analista de QA y dos desarrolladores a mi cargo hasta el release.
Resultado
De la solicitud al desembolso: de 30 días a 10.
Sesenta asesores de ventas, riesgos y cobranza lo usan a diario.
La curva del asesor: de meses a su primer día.
Otra empresa adquirió el proyecto para operarlo con su propia fuerza de asesores en México.
Por confidencialidad no puedo publicar aquí los flujos ni las pantallas completas, y por eso el enlace de esta página lleva a mis datos de contacto y no al producto. Si quieres ver más de este proyecto — las pantallas reales, la capa de IA y las decisiones detrás — con gusto te lo muestro en una llamada.
Proyectos relacionados
