Banca y Fintech: cómo proteger el foundation de tu CRM desde el primer formulario
Hace poco hicimos un webinar con el equipo de Solvis —Adriana, Luz Dary y Santiago— sobre un tema que en banca y fintech nos duele todos los días, pero que casi nadie ataca donde de verdad nace: la captura de datos en la apertura de productos financieros integrado con el CRM y el Core Bancario.
Y ojo con esto, porque es el error mental más común: la gente ve un formulario como "una pantalla bonita para llenar datos". No. En un banco o un fintech, ese formulario es la puerta de entrada a tu CRM. Si por ahí entra data sucia, duplicada o desconectada, no hay dashboard, ni core bancario, ni IA que lo arregle después.
Importante: Este webinar y post asume que no tienes un vertical de banca como Salesforce Financial Cloud o nCino, o unas aplicaciones terceras de loan origination o apertura de otros productos financieros. Este webinar asume que tiene HubSpot Marketing y Sales Hubs (Enterprise Edition) o Salesforce Sales Cloud y Marketing Cloud / Agentforce.
Te cuento lo que conversamos, con el ejemplo real que mostramos en vivo en el webinar / livestream.
Los dos dolores de cabeza que vemos todos los días
Cuando alguien nos pide "un formulario" para capturar una solicitud de hipoteca, un préstamo comercial o una apertura de cuenta, o para un proceso de onboarding y/o subir documentos en realidad hay dos problemas escondidos:
- Uno: proteger los datos desde el punto de entrada. Hoy en día casi todo el mundo usa Google Forms, Microsoft Forms u otro form builder que encontró en el marketplace del CRM. Funcionan... hasta que no. El problema no es que sean malos, es que esos conectores solo llegan a dos o tres objetos —contacto, lead, a veces la oportunidad— y no fueron diseñados para alimentar un CRM enterprise con custom objects, record types, validaciones de negocio y flujos de aprobación, y la incorporación de manejo de documentos.
- Dos: amarrar todo a un journey completo. El formulario no vive solo. La persona te ve en un anuncio, entra a un landing page, pide info, te escribe por WhatsApp, le pasas el enlace del wizard, avanza, sube documentos, abandona, regresa. Todo eso —desde que es visitante hasta que hace onboarding— tiene que estar conectado a tu CRM y a tu motor de campañas (Pardot/Engagement Studio, Marketing Cloud Journey, o el workflow de HubSpot Marketing / Sales Hubs). No es "un proceso de apertura de cuenta"; es un proceso integrado de punta a punta.
Y todo esto arranca con una sola pregunta, la que en inglés llamamos KYC — know your customer: cuando llega una solicitud, ¿esta persona ya es cliente o es un prospecto nuevo?
El drama silencioso: los duplicados
Un contacto que ya es cliente te entra por una campaña de marketing como si fuera prospecto nuevo. Entra por una marca o producto, luego por otra. Y empiezas a acumular duplicados con distintos record types, sin una vista única de quién es cliente y quién es prospecto.
¿Y quién paga por esto? Tu equipo de RevOps y de Operaciones, limpiando duplicados, actualizando datos incompletos y arreglando reportes. Peor aún: cuando quieres arrancar una iniciativa de IA, te das cuenta de que no tienes la base de datos para sostenerla. Nadie toma ownership de la limpieza porque son procesos independientes, cada uno por su lado.
La solución no es limpiar después. Es no ensuciar desde el principio.
Los documentos son parte del modelo de datos
El otro tema grande en banca es documental. "Mándame los papeles por correo", "súbelos al Drive", "pásamelos por WhatsApp"... ¿el WhatsApp de quién, exactamente? Y luego no sabes si el documento llegó, si es la foto que era, si se ve, si tiene el tamaño correcto.
El punto no es solo tener el documento. Es que ese documento haga parte del modelo de datos: que esté relacionado al préstamo, a la apertura de la cuenta. Que dos años después, para un tema de cumplimiento, puedas ir y decir "esta persona me sacó un préstamo en tal fecha, necesito ver los balances bancarios que adjuntó en ese momento". Eso no lo hace un folder. Eso lo maneja una plataforma que trata el documento como parte de la transacción, con su nomenclatura y su gobernanza.
Cómo se ve en la práctica: el demo de Solvis Bank
Para el webinar montamos un banco ficticio, Solvis Bank, con un wizard de varios pasos para solicitar un crédito comercial, integrado con Salesforce Sales Cloud (con HubSpot Sales Hub funciona igualito). Esto es lo que enseñamos:
El solicitante. Nombre, apellido, correo, teléfono, tipo de entidad, relación con la compañía. Aquí pasa lo importante: con el correo electrónico validamos si el contacto ya existe en Salesforce. Si existe, lo actualizamos; si no, lo creamos. Ese es el famoso update-or-insert, y es la protección #1 contra duplicados. El email es nuestra llave primaria (pare este demo y puede ser otra tipo de llave): una persona puede pedir muchos créditos, pero el contacto se crea una sola vez.
Y un detalle que le encanta a quien conoce Salesforce: los campos de tipo picklist —tipo de entidad, relación con la compañía— no están cargados en el formulario. Se conectan en automático al picklist de Salesforce. ¿Mañana agregas una opción nueva? Solo la creas en Salesforce y se refleja sola. Cero mantenimiento manual del formulario.
La empresa (o familia - household). Aquí capturamos datos de la compañía (ventas anuales, patrimonio) y usamos el seguro social empresarial (el ID de impuestos, RFC, RUT) para validar si la account ya existe. Misma lógica: si existe, no se duplica. Una misma empresa puede tener varios solicitantes —Luz Dary, Adriana, y Santiago, — y no se crea cuatro veces. Se crea una vez, y cada contacto queda ligado a ella con un account contact relation. Así se ve toda la red de relaciones sin duplicar nada.
Save & resume. ¿Te faltan documentos? ¿No tienes toda la info? No pasa nada. Guardas y sigues después. Y esto no es un lujo: en solicitudes largas, el abandono es enorme en todas las industrias. Muchas plataformas no guardan lo que ya llenaste, así que ni siquiera sabes que la persona empezó. Con save & resume recuperas esos datos, disparas un flujo, creas una tarea de seguimiento, y ese abandono deja de ser una oportunidad perdida (entra en un journey o flujo de nurturing).
Documentos con reglas y lógica. Puedes limitar formatos (nada de subir un .word donde no va), tamaños y hasta renombrar el archivo al guardarlo en Salesforce para que quede legible para el asesor. Y con lógica condicional: según lo que la persona llenó antes, le pides unos documentos y no todos. Ejemplo clásico: si el solicitante es menor de edad, pides representante legal; si es extranjero, pides otra documentación; si es nacional, otra. No son formularios planos donde todo el mundo llena lo mismo.
Preview y firma. Antes de enviar, la persona revisa un preview y firma electrónicamente (automática o escrita). Y como la firma tiene requerimientos legales que cambian por país, ahí siempre metemos un webhook con los términos de la ley local.
El resultado: el modelo de datos protegido en Salesforce o en HubSpot
Cuando la solicitud llega a Salesforce, todo respeta el modelo de datos:
- El contacto es el dato maestro (se crea una vez).
- El préstamo es un dato transaccional. Relación uno-a-muchos: un contacto puede tener tres, cuatro préstamos —de auto, tarjeta, hipoteca— cada uno con su record type or brand (marca en HubSpot), sin duplicarse.
- La cuenta (account) conecta a la persona con sus empresas o su familia.
- El documento no cuelga del contacto ni de la cuenta: cuelga del préstamo, porque pertenece a esa transacción específica. Y llega con su nombre correcto y su visualizador dentro de Salesforce. Y si el documento que subieron está mal, salen email templates desde Salesforce pidiendo la corrección con un enlace de regreso al formulario.
Lo clave: esta lógica no la estás programando en Salesforce, la estás configurando desde el formulario, conectado de forma nativa con los metadatos. No es un conector que "inserta un contacto y ya".
Y no te olvides del marketing: trazabilidad de la campaña
Usamos un campo hidden con la campaña. Así, cada solicitud queda ligada a esa campaña pagada o orgánica (que esta ya creada en Salesforce o HubSpot como campaign member (sin duplicar: si la misma persona llena el formulario tres veces, sigue siendo miembro una sola vez). En el thank you page puedes taggear la conversión, pasar UTMs y campaign IDs, y cuando el préstamo se gana, calcular el ROI real de la campaña: cuánto invertimos, cuántos prospectos entraron, cuántos préstamos se materializaron y por cuánto valor. Trazabilidad completa, del anuncio a la conversión.
Y puedes hacer retargeting con journeys y flujos para campañas outbound dependiendo del progreso de aprobaciones y abandono o inactividad en el formulario.
La pregunta que debes hacerte antes de bajar una app del marketplace del CRM
Este es el consejo que más quiero que te lleves. Cuando estés en Salesforce o HubSpot, vas a estar tentado a bajar la primera aplicación del marketplace que encuentres. Mi respuesta: no lo hagas todavía.
Primero valida el caso de uso. Y con ese caso de uso en mano, pregúntate: ¿esta app protege el modelo de datos que ya tengo dentro del CRM? ¿Respeta mis custom objects, mis picklists, mis record types, mis metadatos? Si no pasa esa pregunta, sigue buscando. Nosotros nos hicimos esa misma pregunta en un montón de implementaciones, y una y otra vez terminamos en FormAssembly justamente por eso.
Porque los metadatos son el corazón de todo. Si estás exportando, importando y forzando campos que no calzan —los pueblos de Puerto Rico, las colonias de Mexico, lo que sea— los datos no van a sincronizar y vas a heredar el caos. Y sin metadatos limpios, la IA no te va a funcionar. Punto.
En resumen
En banca y fintech, un buen form builder lo mas seguro te funcione 100% en tu ecosistema de CRM.
Es el que:
- Protege tu modelo de datos — sabe si eres cliente o prospecto, qué producto tienes, y no duplica nada.
- Protege tu ciclo de relacionamiento — varios préstamos, varios productos, la cuenta personal y la de la pyme, todo relacionado.
- Te da un flujo completo — desde el anuncio y la campaña, pasando por la captura y los documentos, hasta el onboarding, todo low code, no code.
No importa la tecnología ni el presupuesto que elijas. Lo que quiero que te lleves es esto: protege el modelo de datos y el ciclo de almacenamiento desde el primer punto de contacto. Si el dato entra sucio, ya perdiste.
