El ecosistema tiene seis etapas, un núcleo CRM compartido y un gobierno que lo sostiene todo. Esta imagen resume el modelo que desarrollamos en el resto del artículo y en el video.

Dos modelos conviven en la misma plataforma:

• B2C: el estudiante, su familia y quien paga.
• B2B: colegios y empresas, con sus estudiantes o empleados asociados.

Y todo esto se organiza por marcas o unidades de negocio: pregrado, posgrado, educación continua, doctorado, y también por campus o país. Esto último es clave en América Latina, donde muchas instituciones operan en varias ciudades o países y con diferentes marcas.

Nuestra recomendación es trabajar con la edición Enterprise, porque ahí viven las capacidades de gobierno, marcas, objetos personalizados y datos que una universidad necesita. Cada Hub cubre una parte del viaje del estudiante.

• Marketing Hub: campañas pagadas y orgánicas, correo, landing pages, formularios, eventos y redes sociales. Cubre la atracción y la conversión.
• Sales Hub: oportunidades por programa, secuencias de seguimiento, citas y asignación de consejeros. Cubre la admisión y la matrícula.
• Service Hub: casos, base de conocimiento, SLA y encuestas de NPS y CSAT. Cubre la vida estudiantil.
• Data Hub (antes Operations Hub): calidad de datos, sincronización y acceso a datos externos como un data warehouse. Cubre todo el ciclo.
• Content Hub (opcional): página web, blog y portal de membresías para el estudiante. Cubre la atracción y la aplicación.

La idea clave: un solo contacto, una sola base de datos. Lo menos que quieres es un HubSpot Marketing conectado a un Salesforce Sales Cloud y a un Zendesk, cada uno con su propia versión del estudiante. Es una opción válida, pero sumas integraciones, costos ocultos y deuda técnica.

Nota: las capacidades y límites de cada edición cambian con frecuencia. Verifica con HubSpot antes de cerrar el licenciamiento.

¿Content Hub o tu propio sitio web?

Content Hub es opcional. Muchas universidades ya tienen su sitio en una plataforma de experiencia digital (DXP) como Sitecore, Adobe o WordPress, y eso también funciona. La decisión depende de lo que quieras hacer con el portal y el contenido. Si quieres tener control de tu website y contenido, y tienes los recursos para manejar el website, es recomendable usar Content Hub.

"Enterprise va a salir caro"

Es la objeción más común (como todo CRM). La respuesta es sentarse con el director de finanzas y calcular el costo total de propiedad (TCO) y el retorno de la inversión. No todo es el costo de la licencia; también cuenta el beneficio de tener todo en un solo lugar: más matrículas, menos costos operativos y equipos más productivos.

Dos puntos prácticos:

• Define qué usuarios necesitan licencia completa y cuáles pueden trabajar con un tipo de acceso más limitado. Ahí suele haber ahorro.
• Piensa en escalar. Con ediciones menores, muchas veces descubres tarde que no puedes activar la funcionalidad que necesitas.

Los tipos de licencia y sus precios cambian. Valida siempre la oferta actual con HubSpot.

Sin gobierno de campañas, no hay forma de saber qué está generando matrículas. Todo empieza aquí. Dentro de Marketing Hub puedes activar todo tipo de campañas:

• Pagadas: integraciones con Meta (Facebook e Instagram), Google y otras plataformas de anuncios.
• Orgánicas: SEO, blogs, redes sociales, webinars y correo electrónico.
• Inbound y outbound: uso de contenido con tácticas de marketing inbound y outbound.

Cada campaña agrupa sus activos (assets): landing pages, formularios, anuncios, segmentos (listas dinámicas o estáticas de contactos) y UTMs, etc. Para que eso funcione necesitas tres cosas:

1. Una jerarquía clara. Por ejemplo: unidad académica → programa → ciclo → canal.
2. Una nomenclatura fija. Todos nombran igual las campañas, las listas y los formularios.
3. Disciplina en los UTMs. Cada enlace lleva sus parámetros bien puestos, siempre.

¿Por qué importa tanto? Porque cuando llega un prospecto, por el canal que sea, sabes de dónde llego y lo puedes medir. Y cuando ese prospecto se matricula, puedes conectar la matrícula con la campaña que lo trajo.

El prospecto decide el canal, no la universidad. Puede tienes que tener un tracking de los canales: un formulario, llamar, contestar un correo, escribir por SMS, WhatsApp o Facebook Messenger, etc. HubSpot junta esas conversaciones en el Conversations Inbox y en la sección de Activity/Interaction.

Llamadas con contexto. Puedes integrar Aircall u otra plataforma de call center o CCaaS (contact center como servicio). Cuando entra la llamada, el consejero ve en pantalla la ficha del prospecto (el famoso screen pop) y sabe con quién habla antes de decir hola.

Cambiar de canal sin perder el hilo. Esto es lo que llamamos contextual switching. Un ejemplo real:

• El consejero está en una llamada y el prospecto dice: "Tengo que colgar, ¿me escribes por WhatsApp?"
• La conversación sigue por WhatsApp, con todo el historial a la vista.
• Luego el consejero manda un correo con el plan de estudios, y después vuelve a WhatsApp.

Todo queda en el mismo registro del contacto.

Campañas masivas por WhatsApp. Además de las conversaciones uno a uno, hoy puedes enviar campañas de WhatsApp, de forma nativa o con una integración. Verifica las opciones y costos actuales, porque esta funcionalidad ha cambiado bastante. El resultado: mejor contactabilidad, porque le hablas a cada persona por el canal que prefiere.

Tu call center, integrado. Puede ser Aircall, Talkdesk, Twilio, Genesys, Five9 u 8x8. Lo importante es que la omnicanalidad viva dentro de HubSpot.

Journeys que combinan canales. Por ejemplo: envío un correo; si no contesta, le mando un WhatsApp; si tampoco, lo llamo; y después sigo por Messenger o SMS. Todo queda en el inbox y en el historial de actividades del contacto.

WhatsApp es importante, pero es más poderoso cuando se combina con los otros canales. Nuestra recomendación es empezar con una prueba de concepto o un piloto, con personas dedicadas que entiendan cómo funciona.

El camino tiene tres hitos (milestones) claros: la conversión (llega el prospecto), la aplicación (entrega documentos y se evalúa) y la matrícula (queda inscrito).

• Hito 1, Conversión: marketing entrega el prospecto para calificarlo. Herramientas: formularios, nurturing, secuencias y llamadas, el round robin.
• Hito 2, Aplicación: el estudiante llena la solicitud y sube documentos. Herramientas: workflows, portal de membresías, formularios avanzados y scheduler (para hacer citas).
• Hito 3, Matrícula: se aprueba y se registra en el sistema estudiantil. Herramientas: workflows, aprobaciones e integración.

Calificar y prospectar

Una vez convertido, el prospecto entra en calificación. Aquí combinas nurturing por correo, llamadas y citas. Si el estudiante va más rápido, puede empezar a llenar la aplicación por su cuenta.

La aplicación y los documentos

La aplicación es por programa y por ciclo. Con el portal de membresías de HubSpot (Content Hub), el estudiante entra a un espacio privado a subir sus documentos.

Esta parte requiere mucha lógica. Hay que saber:

• Quién es cada persona: el estudiante, el papá, la mamá.
• Quién paga y quién no.
• Qué documentos pide cada programa y si están válidos.

En Solvis usamos FormAssembly integrado con HubSpot para esto. Permite formularios con guardar y continuar después (save and resume), validación de documentos y datos, flujos de aprobación y hasta el pago inicial. HubSpot solo también tiene formularios, pero para lógica compleja esta combinación nos ha funcionado mejor.

¿Por qué no usas con el sistema estudiantil? Muchos sistemas estudiantiles tienen su propio formulario de admisión, pero suele ser muy lineal. Y la realidad es otra: la solicitud tiene n documentos y n requisitos, cambia según el programa, el estudiante la llena desde el celular, con un amigo, con su papá o con su tío, y se le olvidan cosas. Necesitas un formulario con wizards, flexible y responsive, y super integrado con el CRM para temas de marketing y ventas.

Los workflows rescatan aplicaciones detenidas. Si el estudiante no subió un documento o se quedó en la página 2, un workflow de HubSpot le recuerda: "te falta este documento" o "termina tu solicitud para iniciar la aprobación".

Un ejemplo que vemos seguido: tienes 200 leads muy buenos, pero la mitad está atascada en la página 2 sin subir sus documentos. Sin visibilidad de eso, parece un problema de marketing cuando en realidad es un problema del proceso de aplicación.

Puede haber varias solicitudes por estudiante: la regular, la del examen de admisión, la de equivalencias si viene transferido, o una específica de ciertos programas. Todo eso es parte del modelo de datos.

Citas y aprobaciones

Con el scheduler de HubSpot, el estudiante agenda citas con el consejero, con profesores o un tour del campus. Para las aprobaciones usas reglas de round robin: el primer consejero, el segundo, quien aprueba el primer paso, quien aprueba el segundo. Así nadie se queda sin dueño y el proceso no se detiene.

Cuando el round robin se complica. A veces varios campus compiten por los mismos prospectos, o un convenio con una empresa o un colegio trae descuentos y beneficios. El prospecto tiene que llegar al consejero correcto según la marca, el campus y el convenio. El round robin nativo cubre la lógica básica y algo de la avanzada; cuando se complica, hacen falta workflows especializados o código.

Primero las reglas, después la IA. Muchos quieren poner inteligencia artificial a agendar citas, pero todavía no tienen esas reglas de negocio bien definidas dentro del CRM. Sin reglas claras, la IA solo automatiza el desorden.

Si no está listo ahora

No todos se matriculan en este ciclo. Si el prospecto dice "me interesa, pero para el próximo semestre", lo clasificas y lo mueves a otra campaña: una para este ciclo, otra para el próximo. Ese prospecto no se pierde, se recicla con su propio nurturing.

Un modelo de datos mal diseñado es la causa número uno de un CRM desordenado. Antes de configurar cualquier cosa, define bien quién es quién.

Una persona puede tener varias oportunidades. Si María aplica a dos programas o vuelve para un posgrado años después, cada uno es una oportunidad nueva, con su propio ciclo. La cuenta ayuda con las equivalencias. Si el estudiante viene transferido de otra universidad, saber de dónde viene facilita convalidar cursos.

El núcleo CRM compartido

Además de los objetos, el núcleo necesita reglas claras que todos respeten:

• La aplicación como registro propio, ligado al estudiante y a su oportunidad.
• Actividades y conversaciones de todos los canales en el mismo historial.
• Consentimiento: quién aceptó recibir qué comunicación y por qué canal. Revisa las leyes de protección de datos de cada país donde operas.
• Permisos por equipo y marca: cada unidad ve y trabaja lo suyo.
• Reglas de negocio y workflows documentados, no escondidos en la cabeza de una persona.

Un mismo estudiante puede aplicar a varios programas, regresar a un posgrado años después o inscribirse en un curso corto. El núcleo compartido hace que siempre sea el mismo contacto con toda su historia.

Secuencias: lo que mueve al estudiante de etapa

Cada oportunidad avanza por etapas hasta la matrícula. Las secuencias son las actividades que hace el consejero para moverla: llamar, mandar un WhatsApp, enviar un correo. Al final del día, el consejero puede ver la contactabilidad: a quién logró contactar, en qué etapa está cada prospecto y qué sigue.

La matrícula no termina en HubSpot, termina en el sistema estudiantil. Por eso la integración es obligatoria para cerrar el ciclo. Con herramientas de integración del mercado (nosotros hemos usado TIBCO, pero hay otras), por API o servicio web, puedes:

El catálogo académico dentro de HubSpot

La integración también trae el catálogo de programas y ciclos: precios, descuentos y becas. Esto tiene un beneficio directo en tus landing pages.

En el formulario, el prospecto escoge de un menú desplegable:

1. El programa y sus cursos.
2. El horario: diurno, matutino o nocturno.
3. El campus o la modalidad.

Y todo eso viene del mismo catálogo oficial, con sus precios. Una sola fuente de verdad, sin listas desactualizadas en cada landing page.

El catálogo es el gran reto. Un mismo programa puede ofrecerse por campus, país o región, en modalidad presencial, online o híbrida, y en horario diurno, nocturno o de fin de semana. Ese catálogo tiene que estar sincronizado con el sistema estudiantil, con el sistema de pagos o ERP (SAP, Microsoft, Oracle u otro) y con lo que promocionas en tu sitio web.

La última milla: ¿qué significa "matriculado"?

Parece obvio, pero no lo es. ¿Matriculado es cuando pagó? ¿Cuando entregó todos los documentos? ¿Cuando pagó pero le falta uno? Hemos trabajado con universidades que definen la matrícula como el estudiante sentado en su primer día de clase, o conectado a su primer curso online.

Definirlo bien es lo que te permite medir de verdad. Y te ahorra las peticiones de siempre: "expórtame los estudiantes que entraron", "expórtame los que pagaron".

Matricular no es el final. El objetivo es que el estudiante llegue al primer día y se quede. El marketing no se acaba cuando llega el lead. Tampoco cuando el estudiante se matricula, ni cuando no se matricula. El marketing sigue escuchando señales hasta que el estudiante está sentado en clase y continúa su vida estudiantil, porque la meta final es retenerlo.

El journey de onboarding

Desde HubSpot armas un workflow de bienvenida. Por ejemplo:

1. Correo de bienvenida, avisando que el sistema estudiantil le enviará instrucciones de pago.
2. Un blog o video con lo que debe saber antes de empezar.
3. Invitación a un webinar de orientación.
4. Recordatorios para registrarse y llegar al primer día, en el campus o frente a la computadora.

Traer la vida estudiantil de regreso a HubSpot

La información del e-learning y del sistema de administración estudiantil también puede regresar a HubSpot: cursos, progreso, pagos, quejas. Tienes dos caminos:

• Objetos personalizados: guardas los datos dentro de HubSpot (disponibles en Enterprise). Conviene cuando necesitas trabajar esos datos a diario en el CRM.
• Data Hub: consultas los datos donde ya viven, por ejemplo en Snowflake, y traes solo lo que necesitas. Conviene cuando no quieres duplicar datos ni sobrecargar el modelo.

El número de objetos personalizados permitido depende de la edición y puede cambiar. Verifícalo con HubSpot.

Service Hub para el estudiante activo

Con esa información, Service Hub te permite atender al estudiante como un cliente:

Atención proactiva con SIS, LMS y finanzas. Cuando conectas el sistema estudiantil, el LMS y el área de finanzas, HubSpot recibe señales como baja asistencia, poco progreso en los cursos o pagos atrasados. Con esas alertas, el equipo actúa antes de que el estudiante abandone, no después.

El resultado es una vista 360 del estudiante, desde el primer clic hasta su vida académica.

Un scoring para cada etapa

Un solo lead score no sirve para todo el ciclo. Define varios, cada uno con su propósito:

Estos scores generan señales para actuar a tiempo. Y el ciclo no termina en la graduación: el egresado puede ser donante y ayudarte a reclutar nuevos estudiantes.

Un score propio o uno combinado. Puedes tener un scoring por etapa, uno que combine todo, o calcular uno dentro de HubSpot y traer otro de un modelo de machine learning que vive fuera. Lo importante es que forme parte de la vista 360 del estudiante.

Señales que alimentan el score: abrió un correo, puso una queja, está sacando buenas notas, entra al LMS, asiste a clase. Con eso entiendes quién es buen estudiante y quién está en riesgo de irse.

Del modelo predictivo a la acción. Si tienes un modelo predictivo en tu data warehouse, puedes traer su resultado de regreso a HubSpot y activar un workflow: "este estudiante se puede ir, hay que retenerlo" o "este estudiante puede ser referidor".

Unidades de negocio: juntos pero separados

HubSpot Marketing Enterprise permite manejar marcas o unidades de negocio. Puedes separar pregrado, posgrado, educación continua y doctorado, e incluso campus o países, cada uno con sus campañas, su identidad y sus reportes.

Todos comparten la misma base de datos, pero cada equipo trabaja lo suyo. Juntos pero separados.

El antipatrón que queremos evitar: hemos visto universidades donde egresados tiene un CRM, posgrado otro, pregrado otro y educación continua otro. Imagina orquestar todo eso. Las marcas tienen sus limitaciones y hay que revisarlas, pero son una de las formas más claras de escalar el ecosistema dentro de una sola plataforma.

Colegios, empresas y eventos

Las universidades también venden B2B: a colegios y a empresas. HubSpot te permite:

• Prospectar al colegio o a la empresa como cuenta.
• Dar seguimiento a sus estudiantes o empleados como contactos asociados.
• Hacer eventos en colegios con landing pages y QR codes para capturar a cada interesado y asociarlo a una campaña.

La herramienta de eventos de HubSpot sirve para eventos básicos. Para algo más complejo, integra la plataforma de eventos o webinars que ya usas.

Con gobierno de campañas, scoring y datos de la vida estudiantil, tienes datos ricos que puedes poner a trabajar.

Los UTMs no trabajan solos. Se combinan con los eventos de tu herramienta de analítica (Google o Adobe) y con los identificadores de cada plataforma, como el Pixel ID de Meta o el click ID de Google. Con eso sabes, dentro del pipeline, de dónde vino cada estudiante. Y cuando le devuelves a cada canal cuántos se matricularon y cuántos no, alimentas su algoritmo y ves en tiempo real dónde se está cerrando la matrícula.

Estos son los indicadores que recomendamos seguir:

El costo por matrícula es el indicador que más cambia conversaciones con la dirección. Pasa la pregunta de "cuántos leads tuvimos" a "cuánto nos cuesta un estudiante real".

Sin gobierno, el mejor ecosistema se desordena en meses. Cada nueva campaña, programa o integración agrega complejidad. El gobierno es lo que mantiene todo limpio y funcionando.

Un ejemplo práctico: una facultad pide un nuevo formulario para un programa. Sin gobierno, alguien lo crea directo en producción, con otros nombres de campos. Con gobierno, el requerimiento entra a la cola, se prueba en el sandbox, respeta el modelo de datos y sale en el próximo release.

En muchas universidades esto funciona mejor con un Centro de Excelencia (CoE) pequeño: pocas personas, reglas claras y reuniones fijas para decidir cambios.

Con agencias, no en contra de ellas. En muchos países, HubSpot se ha implementado desde la mirada de una agencia de marketing, y no hay nada malo en eso. Nosotros trabajamos y colaboramos con agencias. Pero no importa si tienes una o dos agencias, o gente interna de TI o del negocio: alguien tiene que ser dueño del gobierno transversal, desde la campaña hasta el egresado. Puede ser un Centro de Excelencia, un PMO o un líder de CRM con varios administradores.

Gobierno sano = listo para la inteligencia artificial. Si tienes bien definidos las campañas, los pipelines, las integraciones, el catálogo y los UTMs, todo documentado y consistente, vas a poder moverte mucho más rápido al mundo de la IA. Si no, la IA va a heredar el desorden.

Verifica la disponibilidad de sandboxes y otras funciones según tu edición y contrato de HubSpot.

HubSpot Enterprise sí puede cerrar el ciclo completo de admisión, integrado con el sistema estudiantil, y seguir acompañando al estudiante después. Pero la tecnología sola no lo resuelve. Lo que hace la diferencia es:

Por dónde empezar

1. Quick win: define la nomenclatura de campañas y la disciplina de UTMs. Es barato y te da visibilidad en semanas.
2. Mediano plazo: ordena el modelo de datos y el proceso de aplicación con oportunidades por programa y ciclo.
3. Largo plazo: integra el sistema estudiantil, activa Service Hub y devuelve conversiones a tus medios pagados.

¿En qué punto estás tú?

1. Ya tienes HubSpot y necesitas optimizarlo: mejora el modelo de datos a corto plazo y planifica las integraciones a largo plazo.
2. Tienes HubSpot solo para marketing: evalúa reemplazar las otras aplicaciones y llevar admisión y servicio a HubSpot.
3. Tienes dudas de qué CRM usar: respira hondo y haz un assessment antes de decidir.

En los tres casos, el primer paso es el mismo: dibuja tu ecosistema. Pon en la mesa qué tienes hoy, qué está en HubSpot y qué no, y define tus próximos pasos. Revisa los datos de todo el ciclo del estudiante, cómo se relacionan e integran, cómo trabajan marketing, admisiones, servicio y vida estudiantil, y si tienes las habilidades y las personas para operarlo. Y antes de hablar de IA, define un glosario y el contexto de tus datos.

Tu CRM es tuyo

El ecosistema no es de tu agencia ni de tu proveedor, sea Solvis o quien sea. Tú tienes que ser el dueño de tu HubSpot, de tus datos y de tus procesos. Suena fácil, pero requiere presupuesto, recursos y tiempo. Con la inteligencia artificial, tener el control de tus datos y de tu tecnología ya no es opcional.

¿Tu universidad ya sabe cuántas matrículas genera cada campaña? Si la respuesta es "no estoy seguro", ahí está tu primer paso.

Estudiar y trabajar a la vez cuesta tiempo, vida social y disciplina. Lucas lo dijo sin filtro: "Esto no es para todo el mundo".

Santiago contó cómo lo manejó:

• Aprovechar los huecos entre clases para adelantar trabajo o estudio.
• Sacrificar algunas horas del fin de semana para ponerse al día.
• Aprender a manejar entregables con horarios que a veces eran flexibles y a veces no.

Al principio, los dos se quedaban trabajando los sábados porque querían aprender. Nadie los obligó.

La recompensa: se graduaron con trabajo, con conocimiento de varias plataformas y con una empresa que los vio crecer desde cero.

En la universidad se sigue un paso a paso según la teoría y algo de practica con los laboratorios y ejercicios. Pero aca como becario es de frente al cliente, y siempre quedan cosas por fuera, y eso es la realidad de la práctica real.

Lucas lo vivió trabajando con un CMO en unos reportes y analytics del CRM. Fueron 3 o 4 reuniones por semana durante casi un mes. En cada reunión: "vamos a cambiar esto".

Lo que aprendió:

• Nunca vas a sacar los requerimientos perfectos. Y está bien.
• Los stakeholders reales no se parecen a los de una empresa ficticia en un proyecto de clase.
• La documentación real es mucho más compleja que la de la universidad.

Santiago, por su lado, ha validado pruebas con directores de distintas empresas. Sus Excel de 200 o 300 pruebas son lo que garantiza que se entregue algo que funciona.

Este programa con Solvis sirve para perfiles de marketing, ventas, servicio y desarrollo. 

• Si vienes de marketing: aprendes a usar el CRM como una base de datos organizada que centraliza correos, campañas, WhatsApp y llamadas. Lección clave: la nomenclatura de campañas y la jerarquía de compañías (padre/hija). Conversión y ventas con métricas reales en el CRM.
• Si vienes de ventas o RevOps: aprendes a armar un pipeline bien estructurado: contacto → oportunidad → solicitud → documentos. Lección clave: no hacer cambios en producción.
• Si vienes de servicio al cliente: aprendes a trabajar knowledge base, tickets internos y tiempos de respuesta. Lección clave: quién escribe el contenido importa, y pedir evidencias acelera la solución.
• Si vienes de desarrollo: aprendes Apex, AMPscript, APIs REST y pruebas con Postman. Lección clave: primero entender el proceso, luego programar.

Dos frases que fueron "drop the mic":

• Santiago: el pecado número uno es hacer cambios en producción.
• Lucas: cuiden los emails. Son la llave principal del modelo de datos.

Y una más de Lucas sobre desarrollo: si entiendes el proceso, a veces descubres que dos contratos de API se pueden resolver con uno solo.

Primero, las bases del CRM y luego IA. Pero hoy los dos usan IA. Y los dos llegaron a la misma conclusión:

• Datos sucios = IA confundida. Si un nombre entra como "40 signos de interrogación", el agente no sabe qué hacer.
• La IA no conoce tu proceso. Sabe lo general, pero no cómo funciona el pipeline de admisiones de esa universidad.
• La IA alucina. Santiago la usa para documentar pruebas a partir de historias de usuario bien escritas, pero siempre revisa el resultado.
• La IA consume mucho. Santiago investigó modelos y consumo de tokens, y se llevó sorpresas.

Lucas está trabajando en un agente que revisa la salud del CRM y manda alertas. Para él, ese es el primer agente que una empresa debería considerar.

Resumen: esto es sentido común. Buena documentación, un CRM saludable y alguien que monitoree. Si no, se te van los tokens, los APIs y el presupuesto.

Un CRM nunca vive solo. Un formulario llena datos, esos datos alimentan otro proceso, y ese proceso toca marketing, ventas, admisiones o facturación.

Santiago lo describió bien: en un momento tenía dos clientes con dos CRM distintos. En uno eran deals, en el otro oportunidades. 

Bienvenido a la vida real. Hay empresas con dos CRM, y hemos visto hasta tres.

En el día a día se han topado con cosas que ningún curso enseña:

• Conectar Zapier para llevar leads de Facebook a Salesforce.
• Capturar UTMs en un formulario para que lleguen al CRM y a Google Analytics.
• Saltar a Zoho Analytics, Tableau o Power BI cuando los reportes del CRM se quedan cortos.
• Evitar que una integración por API se coma los límites de ambos sistemas.

¿Y las certificaciones? Los dos las están sacando. Pero coinciden: el curso es la base y el complemento. En el curso creas un campo y ya. Con el cliente, tienes que pensar cómo se va a poblar y para qué.

Los mentores hacen la diferencia. Santiago y Lucas destacaron al equipo de Solvis, en su mayoría mujeres, que les enseñó día a día: desarrollo, organización del CRM, documentación, y hasta cómo negociar un plazo extra con el cliente.

Santiago lo puso en perspectiva: sacar 22 años de experiencia de una mentora en 3 años es imposible. Pero se aprende lo más que se pueda, cada día.

Los dos llegaron pensando lo mismo: "yo quiero programar, y esto del CRM es drag and drop". Salieron pensando otra cosa:

• Lucas: el CRM puede ser más complejo que programar, porque cada empresa es un mundo. Mismo sector, procesos diferentes.
• Santiago: estudió sistemas para hacer soluciones a la medida. Eso es justo lo que hace hoy, pero en CRM. Y no quiere encasillarse en una sola plataforma.

Como los atletas. El que quiere ser futbolista o nadador empieza desde chiquito a desarrollar sus destrezas. Aquí pasa igual. Y ya se nota. Hoy me levantan la mano: "Jesús, eso no está en el alcance". "Jesús, veo un riesgo en ese entregable". "Jesús, esto se puede hacer mejor". Eso es pensar como consultor.

El CRM es complicado porque las empresas son complicadas. Tienen islas, archipiélagos y continentes que no se hablan. Por eso necesitamos gente que entienda el negocio y las herramienta.

Santiago y Lucas lo resumieron en dos ideas: conocimiento y arriésgate a aprender. Al principio es difícil. Después se va poniendo más fácil.

Lo que viene: vamos a arrancar un programa de masterclass, mentoría y becarios con una universidad en Puerto Rico. Pendiente a las redes sociales de Solvis.

Si te identificas con esta historia:

• Estudiante: búscame (Jesús Hoyos) en LinkedIn y conversemos.
• Universidad: si quieres algo así para 2027, sentémonos a hablar. Para este año ya estamos a full.
• Empresa: si tienes talento recién graduado o un programa de becarios, también podemos explorar cómo sumarte.

El episodio completo de Conversaciones de CRM con Santiago Avilés y Lucas Porras ya está disponible.

El contacto en el centro (una persona, múltiples roles)

En HubSpot todo gira alrededor del contacto. No de la cuenta, como en otros CRM. Esto cambia la forma de pensar el diseño, sobre todo si vienes de Salesforce.

El contacto es la persona. Y una persona tiene muchos roles al mismo tiempo: es contacto de su familia, de su empresa, de una otra empresa; es cliente, proveedor, influenciador, sponsor, el que firma, el que decide. Todo lo demás cuelga de ese contacto a través de asociaciones:

Esa es la gran ventaja: un solo contacto, un solo modelo en todo el CRM, sin depender de otros sistemas y/o modelo de datos. No son dos o tres modelos separados como cuando tienes marketing automation por un lado, ventas por otro y servicio en un tercer sistema.

Un buen modelo de datos no se “configura una vez”. Se diseña, se integra, se mantiene y se activa — en ese orden. Y lo mas importande es que luego de esto pasos tienes que proteger el modelo de datos con un gobierno, reglas, auditorias, reportes, procedimientos para que la calidad de los datos se buena y el modelo siga funcionando con los cambios del negocio. O sea el mantener el modelo de datos es un proceso continuo.

Nota: Es post esta escrito sobre la premisa que tienes HubSpot Enterprise Edition.

Antes de tocar un workflow, define tu plano: objetos, propiedades, IDs y reglas.

Los objetos estándar de HubSpot —contactos, empresas, negocios (deals), tickets y algunos más— cubren la gran mayoría de los casos B2B y B2C. Pero a veces necesitas guardar un tipo de dato que no encaja en ninguno: suscripciones, pólizas, vehículos, propiedades, matrículas, envíos. Para eso existen los custom objects.

Un custom object tiene la misma funcionalidad que uno estándar: propiedades, asociaciones (con etiquetas), pipelines, workflows y reportes. La diferencia es que le pones tu propio nombre y tus propias reglas.

La señal clara de que necesitas uno es cuando te encuentras metiendo un dato donde no va: suscripciones dentro de propiedades del deal, o eventos manejados con un sistema de tags que ya no se sostiene. Son muchos mas ejemplos.

Y aquí viene la disciplina, que es lo que de verdad importa:

Cada custom object que creas es parte de tu modelo de datos, y hay que diseñarlo como tal: nombre, propiedades, asociaciones y etiquetas, pipelines, permisos y mantenimiento continuo. No es “créate un objeto y ya”.

Mi regla: acóplate primero a lo que HubSpot trae de caja. Y si el dato vive en otro sistema, muchas veces conviene traerlo con el Data Hub en lugar de inflar tu portal con custom objects que después nadie mantiene.

En Latinoamérica casi nunca compramos 2 o 3 CRM para separar B2B de B2C. Un banco te vende una cuenta a ti como persona (B2C) y una línea de crédito a tu empresa (B2B). Es el mismo contacto.

La clave está en cómo usas el objeto de cuenta (account) y las etiquetas de asociación en relacion al Contacto y su rol:

Ejemplo real: yo le vendo a Jesús Hoyos, pero quiero conocer a la familia Hoyos completa. Mi esposa y mis hijas son contactos adicionales, asociados a esa cuenta-familia. No inventes un custom object para la familia: usa el objeto de cuenta y dale una clasificación. va a ver la historia incompleta.

El objeto lead como lo conocemos en Salesforce o Zoho —prospecto que luego “conviertes” en contacto— está obsoleto.

Un lead es un interés. Un contacto puede tener muchos intereses a lo largo del tiempo.

Mi recomendación práctica:

Y aquí está el pecado más común: entra una persona por una forma, el sistema mira el email, hace un merge y sigue el proceso… sin validar primero si esa persona ya es cliente. Si ya es cliente, ese contacto debería ir por un workflow distinto, con otro score, sabiendo qué producto tiene y cómo están su NPS y su CSAT. Y de paso, dejas de pagar de más por marketing contacts.

Nada de lo anterior sobrevive sin un dueño del modelo de datos. Alguien que diga: “este campo no va aquí”, “esta es la llave única, no inventes otra”, “para esto usa el objeto de cuenta, no un custom object”.

Yo lo comparo con Excel: en toda empresa hay esa persona que domina los pivot tables. En HubSpot necesitas a esa persona protegiendo el modelo, en marketing, ventas y servicio. Lo que necesitas montar:

El modelo de datos es tuyo, no de HubSpot. Diséñalo, intégralo, mantenlo y actívalo, y protegelo con gobierno de por medio.

Ahí es donde tu CRM deja de ser un Excel glorificado y se convierte en el corazón de tu ecosistema, y en un input real para tu estrategia de inteligencia artificial.

¿Tu modelo de datos está diseñado y protegido, o estás dando vueltas con hojas de Excel dentro de tu CRM?

En muchas universidades el proceso de admisión es académico, rígido y estructurado. Pero cuando lo llevas al mundo real —promover tu ciclo, tus programas, llenar tus cohortes— se vuelve un proceso comercial y de marketing. Y ahí es donde choca con el CRM.

Hoy tienes tres cosas conviviendo mal: un student admin (los “Banner” del mundo, y muchos locales de Latam), tu CRM (Sales Cloud, Service Cloud o HubSpot Marketing y Sales Hubs) y… un archipiélago de formas: un Google Forms por aquí, un Microsoft Forms por allá, un form builder del AppExchange, WhatsApp, Google Drive. Islas desconectadas del continente que es tu CRM.

Y cada punto de entrada trae su propio sabor del dato: admisión tiene un sabor, ventas otro, marketing otro, onboarding otro. Ninguno protege el modelo completo, y los académicos y advisors necesitan datos limpios, concretos, accionables, incluyendo documentos completos para aprobar la matricula.

Los datos de una forma para un programa específico entra por un API. Admisiones por un conector nativo. Servicio estudiantil por otro. Egresados los exportas e importas a mano. Multiplica eso por unidades de negocio y procesos de admisión distintos, y tienes un espagueti de conexiones que desemboca en tu CRM y de ahí al sistema estudiantil. 

No hay un proceso único para manejar la calidad ni proteger el modelo.

El problema más silencioso —y más caro— es el catálogo de los programas académicos. Si una forma deja que el estudiante escriba el nombre de un programa o una sede que no coincide con lo parametrizado en el CRM (y peor, que no coincide con el sistema académico), ese dato se pierde. No se puede conciliar, no se puede reportar, y el sistema académico ni se entera. Cuando intentas retroalimentar de un lado al otro, no cuadra.

El catálogo —sedes, periodos, carreras— vive en el sistema estudiantil. Debe reflejarse y protegerse en el CRM, y la forma de la aplicación estudiantil debe leerlo de ahí, nativamente, no tener su propia copia en la forma. Si tienes 20 formas con su propio catálogo, terminas con 20 versiones del catálogo

FormAssembly controla el punto de captura y protege tu modelo antes de que el dato toque el CRM:

La mayoría de las plataformas de creación de formas solo hacen input. Nunca comparan contra el CRM. Entonces crean, crean y crean… hasta que tienes duplicados de contactos, de prospectos y de aplicaciones. Es una herramienta de entrada que nunca pregunta si contacto ya existía.

FormAssembly valida antes de escribir: ¿ya existe este correo? ¿ya existe esta aplicación para esta persona, esta sede, esta carrera, este periodo? Y según tu regla de negocio, decide: crea, actualiza o ignora. Eso es el update-or-insert, y aplica tanto a los objetos estándar (contacto, cuenta, oportunidad) como a los custom objects. 

El error clásico: un campo “papá” y un campo “mamá” con un correo metido ahí y ya. No. El papá, la mamá, el representante legal y el representante financiero cada uno tiene nombre, apellido, correo, teléfono y dirección. Pueden estar casados o divorciados. A veces quien paga es un tercero —una empresa, una beca— y también necesita su nombre.

FormAssembly puede crear esos contactos y sus relaciones —estudiante–colegio, estudiante–universidad, estudiante–representante legal, estudiante–representante financiero— a lo largo de varias formas, sin una sola línea de código y sin duplicar las relaciones. Un modelo jerárquico real. Esto en otros sistemas te toca a mano, con código y validaciones; y donde falle, revienta y pierdes la captura del contacto. Este es uno de los diferenciadores más fuertes de FormAssembly.

Cada programa académico pide documentos distintos. Sin un lugar centralizado, terminan en Drive, WhatsApp o email —“es que era muy grande y rebotó”— y desaparecen. Y adivina quién sufre después: el asesor buscando un documento que no sabe si el estudiante mandó.

Con FormAssembly, la carga es segura y queda vinculada al expediente en el CRM:

Y ojo con el ciclo de vida del documento: durante la admisión vive en el CRM; cuando termina la matrícula lo mueves al sistema estudiantil (Banner) o a un archival tipo Amazon, por compliance, regulaciones y backups. Muchas universidades nos piden justamente eso: verlo en el CRM durante el proceso, y sacarlo cuando ya no debe estar ahí.

Casi siempre pensamos solo en el journey de la admisión. Pero el estudiante vive un ciclo completo: visitante → lead → prospecto → aplicante → matriculado → estudiante → egresado/alumni. 

Cada aplicación en esa vida (marketing, servicio con Zendesk, el LMS, Banner) va a necesitar capturar datos. La idea es que todo eso quede centralizado en un solo modelo de datos, en el CRM, y de ahí se distribuya con integraciones y, cuando llegue el momento, tu data warehouse.

Aquí es donde admisiones y marketing por fin hablan el mismo idioma:

Y la atribución es end-to-end: la forma sabe a qué campaña pertenece, el deal se asocia a esa campaña, y ves el comportamiento por etapa —lead, contactado, seleccionado, matriculado, perdido—. Se leen UTMs, campaign IDs y Google events hacia Analytics, y el reporte de rendimiento de campaña sale nativo en HubSpot. Un input de formulario terminó impactando la medición de la campaña completa.

Un wizard puede ir de una página a siete, ocho o nueve, según el caso de negocio. Todo customizable: look and feel, HTML/CSS, dominio propio, preview antes de enviar, firma electrónica  y save & resume. Las reglas de negocio se arman low-code/no-code —sin escribir Java ni APIs— y aun así hacen validaciones, insert/update y lectura de metadatos y picklists.

Y no hay un solo tipo de aplicación. Hemos montado admisión regular, transferencias, equivalencias, pagos parciales, citas, examen de admisión, admisión para personas con discapacidad y aprobación de becas.

Filipinas. Un grupo de unas 7 universidades sobre una sola plataforma, con varias unidades de negocio, formas compartidas, y despliegue de sandbox a producción. Por regulación, los papás tenían que subir documentos y la promesa de pago; todo capturado en el flujo.

Sudáfrica. Programas para adultos trabajadores donde, por regulación y tema de fraude, había que capturar certificados del empleador. Entraban por FormAssembly, llegaban al CRM y de ahí al sistema estudiantil.

Latinoamérica. Pagos, aprobaciones, validaciones, tipo de estudiante, becas y aprobaciones financieras y académicas —integrado con Salesforce y HubSpot—. Con webhooks validamos si el estudiante ya existe, tiene créditos o equivalencias, o está en cobranza, antes del proceso de aprobación en el CRM. Y en onboarding, journeys en HubSpot más carga de documentos pendientes que pasamos por webhook al e-learning o al sistema de admisión.

Al final del día el manejo de formas es sobre cómo proteger el foundation de tu CRM desde el primer punto de contacto. Si el dato entra sucio, no hay dashboard, ni reporte, ni IA que lo arregle después. Y si el modelo de datos no está establecido y protegido, tu inteligencia artificial simplemente no va a funcionar: vas a pasar más tiempo limpiando que aprovechando.

Proteger el modelo de datos es la regla #1 en un CRM. FormAssembly es una de las herramientas que lo hacen bien (cuando trabajamos en Zoho, usamos Zoho Forms). Lo importante es que protejas el modelo de datos, y no que persiga el sabor del día.

¿Quieres verlo con tus propios procesos? Puedes pedirnos un demo personalizado. 

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:

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?

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.

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.

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.

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.

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 banca y fintech, un buen form builder lo mas seguro te funcione 100% en tu ecosistema de CRM.

Es el que:

1. Protege tu modelo de datos — sabe si eres cliente o prospecto, qué producto tienes, y no duplica nada.
2. Protege tu ciclo de relacionamiento — varios préstamos, varios productos, la cuenta personal y la de la pyme, todo relacionado.
3. 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.

En Solvis Consulting llevamos años implementando FormAssembly, y honestamente, cada vez que lo explico me doy cuenta de que la gente lo ve como “un form builder más” — tipo Google Forms o Microsoft Forms con más funciones. Y no. FormAssembly es una plataforma de captura de datos con integraciones muy nativas y detalladas con Salesforce y HubSpot.

Nosotros lo usamos principalmente con bancos e instituciones educativas (universidades), aunque, la verdad, aplica a cualquier industria que necesite capturar datos de clientes — un cliente, un prospecto — y llevarlos sus datos limpios, organizados y seguros al CRM.

Y ahí está el tema real que vemos todos los días en el mundo del CRM: ¿cómo capturas data de clientes o prospectos en procesos como una aplicación estudiantil, una solicitud de hipoteca, un webinar, o un evento de prospección, sin que ese dato llegue sucio, duplicado o desconectado de tu CRM?

Muchas empresas todavía usan Google Forms o Microsoft Forms para esto. Funciona... hasta que no. El problema no es que esas herramientas sean malas, sino que no fueron diseñadas para alimentar un CRM enterprise con field-level mapping, validaciones de negocio y flujos de aprobación. Siempre exportamos, limpiamos, mapeamos e importamos, y en este proceso nos brincamos 20 reglas de negocio. O terminamos usando Zapier para conectarlas. Y otros “form builders” del mercado se limitan a ciertos tipos de objetos. FormAssembly no. Con FormAssembly puedes mappear a muchos objetos nativos y custom, aplicar reglas, flujos y tener todo un proceso de formas conectadas, entre otras funciones.

FormAssembly tiene integraciones nativas y bien detalladas con Salesforce y HubSpot, que incluyen subir documentos de forma segura y transferirlos al CRM, o bien solo compartir el enlace del documento. Y lo que más me importa, como consultor, es proteger el CRM y sus datos, es decir, el modelo de datos y su calidad.

Porque la mayoría de los problemas de calidad de los datos en un CRM no surgen en el propio CRM. Nacen en el punto de entrada. Si tu formulario permite que la gente escriba lo que sea, en texto libre y sin validar nada, tu CRM hereda ese caos. Y adivina quién paga esa factura después: tu equipo que usa el CRM, va a estar limpiando duplicados, limpiando datos y arreglando reportes.

FormAssembly ataca esto antes de que el dato toque tu modelo de datos:

Aquí la integración es bien profunda, y hay tres cosas que a mí me parecen clave:

También es una integración nativa, de dos vías, con mapeo a propiedades estándar y personalizadas. Un detalle operativo que vale la pena documentar: si agregas opciones nuevas a un dropdown en HubSpot después de crear la conexión, no se sincronizan solas, hay que reiniciar el sync. Tema importante, pero si no lo tienes en tus procesos de gobierno de datos, te puede brincar.

Trata tu formulario como si fuera un esquema, no como una pantalla bonita. Si cambias una etiqueta, o metes una rama condicional nueva, la data capturada antes y después de ese cambio puede dejar de ser comparable. Es la misma lógica de versionamiento, aplicada a formularios, y casi nadie lo piensa así. ¡Ah! Y tiene sandboxes para conectarse a sandboxes de Salesforce.

Y cada mapeo campo a campo debería ser intencional, documentado, y revisado cada vez que cambie el formulario o el esquema del CRM. Eso no es burocracia, es lo que evita que tu CRM se convierta en un dolor de cabeza dos años después.

Banca — el PPP durante COVID. En Solvis trabajamos con un banco por dos años implementando FormAssembly a través de las distintas versiones del PPP (Paycheck Protection Program – programa en EE. UU. para ofrecer préstamos a las PYMES durante COVID). Ahí vimos, en carne propia, la escalabilidad de FormAssembly, su manejo de documentos, su seguridad, y una integración bien fuerte con Salesforce, en un contexto donde el volumen y los cambios constantes de reglas no dejaban espacio para procesos frágiles. Si aguanta el PPP (en el que el gobierno dictaba las reglas del préstamo), aguanta casi cualquier cosa.

Educación — varias universidades. También lo hemos implementado con distintas universidades en Latam y Sudáfrica, cada una con sus propios flujos de aprobación, tipos de validación y manejo de documentos para diferentes tipos de solicitudes de admisión de sus programas académicos. Ahí confirmamos que la plataforma se adapta bien a estructuras institucionales complejas, no solo a un caso de uso genérico.

1. Integración nativa con Salesforce o HubSpot, sincronizando datos en tiempo real sin duplicar información.
2. Formularios dinámicos y multi-página, con lógica condicional según programa/producto, sede y perfil.
3. Preview y revisiones.
4. Formas con Wizards y workflows.
5. Firma electrónica dentro del mismo flujo.
6. “Save & resume”, clave para bajar el abandono en solicitudes largas.
7. Gestión centralizada de documentos, vinculados automáticamente al expediente en el CRM.

Al final del día, no se trata de tener un formulario más bonito. Es sobre proteger la base de tu CRM desde el primer punto de contacto. 

FormAssembly les da a los equipos que usan el CRM el control para validar, mapear y gobernar ese dato antes de que toque el modelo de datos. Y en industrias como la banca y la educación (entre otras), donde el volumen y la complejidad regulatoria e institucional son altos, esa disciplina en la captura termina siendo la diferencia entre un CRM sano y uno que se convierte en un dolor de cabeza años después.

Solvis es partner de FormAssembly para Latam.

Nos vemos en los webinars, pero si ya quiere ver un demo, agenda una reunión con nosotros para entender los requerimientos y luego agendamos el demo.

Antes de hablar de agentes, tienes que entender el ciclo completo.

El prospecto no aparece de la nada el día que firma la matrícula. Pasa por varias etapas:

Cada etapa tiene actores diferentes, objetivos diferentes, datos diferentes, y — esto es clave — necesidades de IA diferentes.

Debes considerar usar User Stories de AI Agents ya que es un instrumento de trabajo para los equipos que realmente quieren implementar esto bien.

¿Qué debes considerar en el user story?

Uno de los errores más caros que vemos en proyectos de AI Agents es querer usar un LLM para todo. GPT para calificar. GPT para agendar. GPT para validar documentos. GPT para saludar.

Eso es caro, lento, y muchas veces innecesario.

La pregunta correcta para cada tarea es esta: ¿cuál es la capacidad mínima de IA que resuelve este problema con la calidad requerida?

Algunas respuestas prácticas:

• ¿Calificar por criterios fijos? Eso es lógica de reglas o workflow clásico. No necesita IA.
• ¿Clasificar la intención de un mensaje en WhatsApp? NLU + intent classification. No necesitas el modelo más caro del mercado.
• ¿Generar un resumen de la conversación para el asesor? Ahí sí necesitas un LLM — pero probablemente el tier medio es suficiente.
• ¿Orquestar múltiples pasos, tomar decisiones complejas, coordinar herramientas? Eso es Agentic AI, y sí, ahí justificas el modelo más avanzado.
• ¿Validar un documento de identidad? Computer Vision + OCR.

El diseño ganador siempre es híbrido. La tecnología más cara no es la mejor solución — es la que resuelve el caso de uso al costo correcto.

Y antes de comprar cualquier capacidad de IA externa, tienes que revisar qué ya tienes licenciado en tu stack. Salesforce Einstein / Agentforce, HubSpot Breeze, Zoho Zia, Microsoft Copilot for Sales — muchas universidades están pagando por capacidades que nunca activaron.

Si vas a implementar un AI Agent en admisiones y no defines KPIs antes de encenderlo, no tienes caso de negocio. Solo tienes un gasto.

Hay tres capas de métricas que necesitas medir:

Un tip importante: una tasa de contención muy alta no siempre es buena noticia. Puede esconder mala experiencia — prospectos que se rinden antes de escalar. Siempre crúzala con CSAT.

Y segmenta por programa, sede y ciclo. Un agente puede funcionar excelente para pregrado presencial y estar generando una experiencia terrible para posgrado en línea. 

Si estás evaluando implementar AI Agents en admisiones — o ya tienes uno que no está dando los resultados esperados — el punto de partida siempre es el mismo: hacer el discovery bien.

Eso significa sentarte con los líderes de marketing y admisiones, definir las historias de usuario con precisión, inventariar lo que ya tienes en tu stack, y diseñar la arquitectura de IA por tarea antes de escribir una sola línea de configuración.

En Solvis Consulting hemos diseñado este framework a partir de implementaciones reales. Si quieres conversar sobre cómo aplicarlo en tu institución, estamos disponibles.

Antes de tocar una sola configuración de CRM, siempre empezamos con la misma pregunta: ¿Cómo llega un estudiante desde el primer contacto hasta su primera clase?

La respuesta, en casi todas las universidades con las que hemos trabajado, pasa por las siguientes etapas:

Cada una de estas etapas tiene procesos, datos, canales de comunicación, equipos responsables, y criterios de avance o descarte. Si el CRM no fue diseñado para reflejar esta realidad, no importa cuánto costó la licencia: va a fallar.

Uno de los errores más costosos que vemos en implementaciones de CRM para universidades es arrancar sin un modelo de datos claro. Se carga una lista de prospectos, se crean algunos campos custom, y listo. Seis meses después, el sistema está sucio, los equipos no confían en los datos, y nadie sabe qué fue de los 3,000 leads que llegaron de la campaña de septiembre.

En Solvis, el modelo de datos no es un tema técnico. Es un tema de negocio. Y para la educación superior, ese modelo tiene que reflejar quién es el estudiante y su contexto completo:

Esto lleva directamente a un punto que pocas universidades consideran desde el inicio: no tienen un único modelo de ventas. Tienen dos o más. Y diferentes marcas con diferentes procesos.

Para programas de pregrado y algunos postgrados, el modelo es B2C: el prospecto es el estudiante, la decisión es personal, y el ciclo de ventas suele ser más corto y masivo.

Para programas ejecutivos, maestrías corporativas, y cursos de formación continua, el modelo frecuentemente es B2B: la empresa paga, la empresa decide, y el estudiante es el ejecutor, no el decisor final.

Y tenemos el proceso de ventas a colegios que es tanto B2B como B2C.

Un CRM universitario bien diseñado tiene que soportar ambos modelos, con sus respectivos funnels, criterios de avance, y atribuciones de conversión. Si no, estarás forzando el proceso de ventas corporativas en un flujo diseñado para estudiantes individuales, y viceversa.

Para que este funnel funcione, los leads de las campañas deben llegar directamente al CRM con su fuente, campaña, UTMs, IDs, atributos de los anuncios y el término de búsqueda. Y las conversiones del CRM (matriculados) deben volver a alimentar las plataformas de ads para optimizar las audiencias.

Sin esta integración, tendrás datos en silos. Con esta integración, tienes inteligencia de marketing real.

Uno de los conceptos que más trabajo nos cuesta instalar en los equipos de admisiones es el de la contactabilidad. No basta con tener los datos del prospecto. Tienes que poder contactarlo, en el canal correcto, en el momento correcto, con el mensaje correcto.

En América Latina, esto se complica porque la fragmentación de canales es real:

1. El email open rate en muchos mercados es bajo, pero sigue siendo el canal de récord.
2. WhatsApp tiene tasas de lectura altísimas, pero requiere opt-in y manejo cuidadoso y ahora conlleva tener un gobierno de operación y control de costos.
3. Facebook Messenger sigue siendo relevante en algunos segmentos.
4. SMS tiene alta entrega, pero baja tolerancia del usuario si no se usa bien (depende del país en la región) y ahora el SMS viene con soporte de RCS.
5. La llamada telefónica sigue siendo el cierre más efectivo en algunos casos.
6. Pero la contactabilidad aumenta al usar todos estos canales en conjunto.
7. Y, eventualmente, el chatbot con Conversational AI.

Una estrategia de omnicanalidad no implica usar todos los canales al mismo tiempo. Significa tener un modelo de contactabilidad definido: cuándo usar qué canal, en qué etapa del funnel, con qué frecuencia, y con qué tipo de contenido.

Una vez que el estudiante es admitido, el proceso no termina en el CRM. Empieza la fase de inscripción y matrícula, que en la mayoría de las universidades involucra sistemas separados: el sistema de información estudiantil (SIS), el sistema de pagos, y frecuentemente un portal de autoservicio del estudiante.

Aquí es donde la integración se vuelve crítica. El CRM necesita saber que el estudiante completó el pago y está oficialmente matriculado para activar el proceso de onboarding. Y el sistema estudiantil necesita recibir los datos limpios del CRM para crear el expediente académico sin duplicaciones ni errores.

Una integración bien diseñada entre CRM y SIS elimina la recaptura manual de datos, reduce errores y permite al equipo de admisiones tener visibilidad completa del estado de cada estudiante hasta que pasa al equipo académico. Aquí usamos herramientas de integración y/o APIs.

El catálogo de programas: el tema de integración que nadie anticipa

Hay un componente de la integración entre el CRM y el sistema estudiantil que casi ninguna universidad anticipa correctamente al inicio de un proyecto: el catálogo de programas.

En la superficie, parece simple: una lista de programas académicos con su nombre, duración y costo. Pero cuando empezamos a trabajar con el equipo de admisiones, marketing, finanzas, y el área académica al mismo tiempo, el catálogo revela una complejidad que afecta todo el ecosistema.

El problema del título de marketing vs. el título del sistema: 

Un catálogo de programas bien construido para un ecosistema de CRM no solo incluye el nombre y el costo. Tiene metadatos estructurados que permiten personalizar la experiencia del prospecto, segmentar campañas correctamente, y aplicar reglas de negocio automatizadas.

Los metadatos esenciales que trabajamos con las universidades incluyen (entre otros más):

• Título de marketing - El nombre comercial del programa, optimizado para campañas, landing pages, y comunicación con prospectos.
• Título de sistema estudiantil - el nombre oficial tal como existe en el SIS. Es el identificador de récord para expedientes, acreditaciones, y reportes regulatorios.
• Descripción corta — para emails, WhatsApp y notificaciones (máx. 160 caracteres)
• Descripción larga — para landing pages, brochures digitales y el CRM
• Modalidad — presencial, semipresencial, online, híbrida
• Duración — semestres, meses, horas
• Precio base — el precio de lista antes de descuentos
• Precio con descuento — por periodo de inscripción, convenio corporativo, o campaña
• Becas disponibles — tipos, porcentajes, requisitos de aplicación
• Fechas de inicio — periodos académicos activos para el ciclo de admisión vigente
• Sede o campus — para universidades con múltiples ubicaciones
• Audiencia objetivo — para routing automático de leads en el CRM
• Código de programa — el identificador de integración con el SIS
• Código financiero — el identificador para facturación y sistema de pagos

Cada uno de estos campos tiene un responsable en la organización. La descripción de marketing la gestiona el equipo de marketing. El precio base y los descuentos los gestionan finanzas o la dirección académica. Las fechas de inicio las gestiona el área de planeación académica. El código del sistema lo gestiona TI.

Sin un diseño claro de quién es dueño de qué dato, el catálogo se desactualiza rápidamente y el CRM empieza a mostrar información incorrecta a los asesores y a los prospectos.

La lógica de precios en una universidad latinoamericana es, con frecuencia, mucho más compleja de lo que parece desde afuera. No hay un solo precio por programa. Hay un precio de lista, descuentos por inscripción anticipada, descuentos por convenio con empresa, descuentos por hermano o familiar estudiante, becas por mérito académico, becas por necesidad económica, y precios diferenciados por modalidad o campus.

Esta complejidad tiene que vivir en algún lugar. Y tiene que estar conectada al CRM de manera que el asesor de admisiones pueda comunicar la información correcta al prospecto, sin tener que llamar a finanzas cada vez que alguien pregunta cuánto cuesta.

Las opciones de integración que hemos implementado varían según la madurez tecnológica de cada institución:

La integración del catálogo no termina en el punto en que se conectan el CRM y el SIS. Hay un tercer sistema que casi siempre está en la ecuación: el sistema financiero o ERP.

Cuando un estudiante acepta una oferta de admisión, debe pagar. Y ese pago tiene que generar una factura, registrarse contra el código correcto del programa, aplicar el descuento o beca correspondiente, y reflejarse en el CRM como confirmación de matrícula. Si cualquier paso de esa cadena se rompe o requiere intervención manual, se generan errores, retrasos, y fricción que impactan directamente la experiencia del estudiante y la eficiencia del equipo.

El flujo de integración completo que diseñamos en Solvis conecta cuatro sistemas:

Cada uno de estos sistemas tiene sus propios códigos, su propia lógica de datos, y sus propios equipos responsables. Hacer que hablen correctamente requiere un diseño de integración modular, con transformaciones de datos bien documentadas, manejo de errores, y un proceso de governance para cuando algo falla.

En lugar de construir una integración monolítica donde todo está conectado directamente con todo, diseñamos cada integración como un módulo independiente con responsabilidades claras:

• Módulo de catálogo — gestiona la sincronización de programas, precios y becas
• Módulo de prospecto — gestiona el traspaso de datos del estudiante del CRM al SIS
• Módulo de matrícula — gestiona la confirmación de pago y creación del expediente
• Módulo de onboarding — dispara los procesos de bienvenida una vez confirmada la matrícula
• Módulo de reporte — consolida datos de todos los sistemas para dashboards de admisiones

Cada módulo puede actualizarse, reemplazarse, o escalarse de forma independiente. Si la universidad cambia su sistema de pagos, solo afecta el módulo de matrícula. Si marketing necesita agregar nuevos campos al catálogo, solo afecta el módulo de catálogo.

Este enfoque también permite que la institución agregue nuevas integraciones en el futuro — con plataformas de LMS, con sistemas de CRM de retención estudiantil, o con herramientas de IA — sin tener que reescribir la arquitectura completa.

La integración del catálogo de programas, los sistemas estudiantiles, y el sistema financiero es uno de los trabajos más transversales que hacemos. No es solo un proyecto de TI. Requiere alinear a múltiples áreas de la universidad que raramente trabajan juntas en el mismo proyecto:

En Solvis, actuamos como el integrador que facilita esa conversación, documenta las reglas de negocio, diseña el modelo de datos compartido, y construye o supervisa las integraciones técnicas. No solo entregamos la configuración del CRM. Entregamos el ecosistema completo funcionando, con la documentación necesaria para que el equipo interno pueda operarlo y evolucionarlo.

Solvis Consulting no es un implementador monomarca. Hemos implementado y optimizado ecosistemas completos de CRM universitario en las tres plataformas más relevantes del mercado latinoamericano de educación.

Tenemos experiencia con más de 20 universidades en Estados Unidos, América Latina, Inglaterra, España y Sudáfrica en implementar ecosistemas de adquisición de estudiantes usando una gran variedad de tecnologías de AdTech, Martech, CRM, CaaS, SIS, soluciones de integraciones, eLearning y Form Builders.

Aquí un vistazo a lo que hemos construido recientemente en cada una:

Zoho One es una opción muy competitiva para instituciones que buscan controlar los costos sin sacrificar funcionalidad. Hemos implementado el siguiente stack:

Salesforce es la opción para instituciones que buscan escalabilidad empresarial y tienen procesos de admisión más complejos o múltiples sedes. El stack que hemos implementado incluye:

HubSpot Enterprise es la plataforma que más hemos visto ganar terreno en universidades medianas y grandes de LATAM en los últimos años. Su fortaleza radica en la unificación nativa del stack de marketing y ventas. En una implementación particularmente compleja, construimos:

La gestión de tres marcas distintas dentro de un solo CRM requirió diseñar un modelo de datos cuidadoso, con propiedades compartidas y específicas por marca, y una lógica de segmentación que evitara que los prospectos de una marca recibieran comunicaciones de otra.

Lo que distingue la forma en que Solvis Consulting trabaja con universidades es que nunca entregamos únicamente una configuración de CRM. Entregamos un ecosistema operando. Y para que ese ecosistema funcione, hay cinco pilares que trabajan juntos:

Ya todas las plataformas de CRM van a potenciar sus funcionalidades de inteligencia artificial: scoring predictivo de prospectos, recomendaciones de siguiente mejor acción para asesores, análisis de sentimiento en conversaciones, automatización de seguimiento con agentes de IA, y mucho más.

Pero toda esa inteligencia depende de una condición: datos limpios, completos, y bien estructurados.

Si tu CRM tiene duplicados, campos sin estandarizar, funnels inconsistentes, y canales desintegrados, la IA va a amplificar el caos, no a resolverlo. Los modelos de scoring serán imprecisos. Los agentes de IA tendrán un contexto incompleto. Y las recomendaciones se basarán en datos que no reflejan la realidad.

La deuda técnica de hoy es el bloqueo de IA de mañana

Lo que construimos hoy con las universidades — el modelo de datos correcto, el funnel bien definido, los canales integrados, la calidad de los datos asegurada — es exactamente lo que van a necesitar para activar la IA de manera efectiva en los próximos 12 a 36 meses.

No es un proyecto de CRM. Es la infraestructura de datos y procesos que habilita la transformación digital integral del área de admisiones.

En Solvis Consulting contamos con Squid Connect, un CRM integrado y preconfigurado, listo para usarse con precios accesibles que te puede apoyar en todo el ciclo de relacionamiento del estudiante y sus padres. 

Squid Connect ya viene con:

1.  Implantación de la solución preconfigurada en Zoho CRM Plus 

Si estás leyendo esto y reconoces algunos de los dolores que describimos — datos sucios, funnels inconsistentes, canales desintegrados, o un CRM que nadie usa correctamente — la buena noticia es que el punto de partida es siempre el mismo:

En Solvis Consulting, hemos hecho este camino con universidades de diferentes tamaños, presupuestos, y niveles de madurez tecnológica, siempre con el mismo enfoque: no vendemos plataformas, construimos ecosistemas.

Si quieres conocer más sobre cómo podemos apoyar a tu institución, o si simplemente quieres explorar qué tan listo está tu CRM actual para soportar una estrategia de IA, hablemos.

Universidad en línea — México

Escuela de negocios — México

Red de universidades — Centroamérica y el Caribe

Red de colegios K-12 — Latinoamérica

Lo que tienen en común todos estos retos