¿Cómo añade a su web un formulario de contacto que escriba directamente en su CRM?

01El problema de negocio

Todas las webs tienen uno: el formulario detrás de Contáctenos, Solicite ahora, Solicite una llamada, Regístrese aquí. Es el mismo requisito cada vez, diga lo que diga el botón: un desconocido escribe sus datos en una página pública, y el envío tiene que convertirse en un registro real de inmediato. No en una notificación que alguien transcribe al CRM, ni en una fila de una hoja de cálculo.

Lo que en la práctica significa todo esto a la vez:

• la persona se convierte en un registro que tiene propietario, tipo y un sello de su procedencia;
• alguien que envía dos veces no se convierte en dos personas;
• el solicitante recibe un acuse de recibo inmediatamente;
• se avisa a la persona interna adecuada;
• se hace seguimiento a quienes empezaron y nunca terminaron;
• y marketing puede rediseñar la página, y un administrador puede añadir una pregunta, sin que ninguno de los dos espere al otro.

Esa última restricción es la que hace fracasar la mayoría de las implementaciones. Un formulario cuya lista de campos vive en el código de la web convierte cada pregunta en un despliegue, así que el conjunto de preguntas se congela en lo que fuera el día del lanzamiento.

02Por qué falla el enfoque obvio

Construir el formulario con la propia tecnología de la web

El reflejo es construir el formulario a mano en el framework que use el sitio y enviarlo por POST a la API del CRM. Funciona el primer día y a partir de ahí se degrada. La lista de campos existe ahora en dos lugares y hay que mantenerlos sincronizados a mano; añadir una pregunta es un cambio de código, una revisión y una publicación; y la web se ha vuelto responsable de la validación, del spam y de guardar una credencial capaz de escribir en el CRM. Cada uno de esos problemas ya lo ha resuelto el formulario alojado.

Un producto de formularios más un puente de automatización

Una herramienta de formularios de terceros conectada a través de una plataforma de integración añade un salto que puede fallar sin avisar, y entrega un registro sin subtipo, sin propietario y sin procedencia, porque el puente no conoce su modelo de datos. Después necesita un proceso de conciliación para terminar el trabajo que debería haber hecho el formulario.

Copiar el marcado del formulario en la página

No hay marcado que copiar. El formulario alojado es una aplicación JavaScript servida desde una CDN estática y resuelta por su link id en tiempo de ejecución; el HTML de esa URL es un armazón de unos 1,7 KB que contiene un único elemento personalizado. Cualquier cosa que pretenda extraer o volver a alojar los campos del formulario no encontrará nada ahí.

Crear un registro por envío

El error más caro es el más sencillo: activar la creación de registros y nada más. La gente vuelve a enviar los formularios públicos como algo habitual: pierde la confirmación, no está segura de que funcionara, cambia una respuesta. En un formulario de solicitud real, 49 envíos procedían de 41 personas. Solo con creación se habrían producido ocho contactos duplicados en un formulario así de pequeño, cada uno con su propio email posterior, y la factura de la deduplicación llega más tarde y con intereses.

Suponer que el solicitante es un lead

Formulario público, persona desconocida: por tanto, un lead, seguro. No necesariamente. Alguien que se une a un programa está entrando en una relación, no en un pipeline de ventas: no tiene oportunidad, ni valor, ni fecha de cierre, y meterlo en un pipeline falsea todas las métricas del pipeline. Vincule el formulario a la entidad que corresponde a lo que la persona realmente es. La cuestión de dónde ubicarlo es el Blueprint 003.

03Modelo de datos

Las tres entidades implicadas (la definición del formulario, la respuesta y la unión de relación) se tratan en el Blueprint 012. Lo que es específico aquí es la frontera entre la web y el CRM.

Fuentes. Centro de ayuda de Coevera, Working with online forms para el formulario en sí y para la incrustación por iframe usada aquí, que describe como la opción más sencilla pero con limitaciones; y Working with online forms in JavaScript para la otra vía, un formulario incrustado por script que forma parte de la página.

El acoplamiento es una única cadena opaca

Una definición de formulario expone linkId, y el formulario público se sirve desde una URL con la forma:

https://forms.{vendor-host}/{link-id}/viewform

La web guarda esa URL y un título legible, y nada más. En una implementación real, el propio modelo de contenido de la página contiene exactamente dos claves para el formulario (la URL y el título), y el botón lo abre en un marco modal en el momento del clic. El título no es decorativo: se convierte en el nombre accesible del marco, que es lo único que un lector de pantalla tiene para anunciar antes de que se cargue el contenido del marco.

Lo que cuesta realmente incrustarlo

La respuesta del formulario alojado no lleva X-Frame-Options ni ninguna restricción frame-ancestors, que es precisamente por lo que se puede incrustar en cualquier sitio. Incrustado como iframe, como aquí, se derivan tres consecuencias, y las tres suelen descubrirse tarde:

• No es rastreable. Dentro del iframe las preguntas se renderizan por script, así que los motores de búsqueda y los modelos ven el armazón. Cualquier contenido que deba indexarse tiene que estar en la página alrededor del marco, no dentro de él.
• Sin JavaScript no hay formulario. No un formulario degradado: nada.
• La página contenedora no puede ver dentro del marco. Con el formulario en un iframe, su analítica y sus herramientas de consentimiento observan el clic que lo abrió y nada después, así que el abandono a nivel de campo es invisible desde fuera.

Y como nada restringe quién puede enmarcarlo, el mismo formulario puede incrustarse en un sitio que no es suyo. El link id es el único secreto, y está en el código fuente de su página.

Los campos de formulario se comparten entre formularios

Las definiciones de campos de formulario viven en un repositorio común a todo el espacio y no dentro de un formulario. Cuatro identificadores de campo de este formulario de solicitud (nombre, apellidos, email, empresa) son idénticos a los de una encuesta a clientes no relacionada del mismo espacio. Así que «añadir una pregunta de email» reutiliza una definición existente en lugar de crear una nueva. No se probó si editar una definición compartida se propaga a todos los formularios que la usan; compruébelo antes de renombrar una.

Lo que el registro necesita y el visitante no puede dar

Un registro creado sigue teniendo que cumplir los requisitos ordinarios de la plataforma, y un envío anónimo no cumple ninguno:

04Configuración a nivel de campo

El conjunto de preguntas, y lo que debería significar «obligatorio»

El formulario real hace once preguntas, nueve de ellas obligatorias:

De esa tabla merece la pena copiar dos cosas. Primero, el tipo de campo del formulario sigue al tipo de campo del CRM, no a la pregunta: la pregunta de la calle es un área de texto porque el campo de dirección del contacto subyacente es multilínea, y ninguna configuración del formulario lo cambia. Segundo, el conjunto obligatorio no es la lista de deseos de marketing: la dirección postal completa es obligatoria porque el programa paga a las personas y no puede avanzar sin ella, mientras que el nombre de la empresa (el campo en el que insistiría un responsable de marketing) es opcional. Exija lo que el siguiente paso realmente no puede ejecutar sin ello, y nada más.

Observe también que todos los campos tienen el prerrelleno desactivado. No hay ningún registro del que prerrellenar; la combinación de prerrelleno y autolink que identifica a un cliente conocido en el Blueprint 012 no se aplica cuando quien responde es un desconocido.

Los tres ajustes que lo convierten en un upsert

La plantilla de creación

Con createRecordEnabled, el formulario lleva una plantilla de registro. Es una carga útil completa del registro, no un parche: enumera los campos estándar, incluidas las cinco ranuras de teléfono y las cinco ranuras de email, la mayoría vacías:

{
  "contactTypeId": "{sub-type-id}",
  "ownerId":       "{nominated-owner-id}",
  "unitId":        "{nominated-unit-id}",

  "firstName": "<ppl-tag data-id=\"{first-name-field}\" data-relation-type=\"Responses\"></ppl-tag>",
  "lastName":  "<ppl-tag data-id=\"{last-name-field}\"  data-relation-type=\"Responses\"></ppl-tag>",
  "email1":    "<ppl-tag data-id=\"{email-field}\"      data-relation-type=\"Responses\"></ppl-tag>",
  "phone1":    "<ppl-tag data-id=\"{phone-field}\"      data-relation-type=\"Responses\"></ppl-tag>",
  "address":   "<ppl-tag data-id=\"{street-field}\"     data-relation-type=\"Responses\"></ppl-tag>",
  "city": "…", "zipCode": "…", "stateProvince": "…", "country": "…",

  "email2": "", "email3": "", "phone2": "", "phone3": "",
  "middleName": "", "title": "", "position": "",
  "accountRelations": [], "tags": [], "staticProfiles": [],

  "shareMode": "Standard",
  "isUnsubscribed": false,
  "comments": "Created via {a hand-typed page path}",
  "customFields": {
    "cfRegistrationDate": "<ppl-tag data-id=\"CurrentDate\"></ppl-tag>",
    "cfSource": "{the page URL}"
  }
}

Las cinco decisiones dentro de esa carga útil:

• El subtipo se fija en la creación. Esto es lo que convierte a «todos los que se inscribieron a través de la web» en un conjunto filtrable y no en una suposición.
• El propietario y la unidad se designan, no se deducen. Ambos son obligatorios y ninguno puede venir del visitante. Elija un marcador de posición deliberado en lugar de la cuenta de una persona real, o el marcador de posición se convertirá por accidente en la carga de trabajo de alguien.
• La procedencia se sella dos veces: una en el texto del comentario y otra en un campo de origen específico. Prefiera el campo: es filtrable, sirve para informes y no se deteriora. Lo que nos lleva al siguiente punto.
• La procedencia escrita a mano diverge. En la plantilla real, la cadena del comentario y el campo de origen no coinciden en la ruta de la página, porque uno de ellos se escribió y nunca se revisó. Nada valida una cadena de texto libre frente a la realidad. Mantenga una única fuente de verdad y haga que sea un campo.
• La fecha de registro procede de CurrentDate, no de un proceso que se ejecuta más tarde.

La notificación, y el ajuste que la gente configura al revés

Active notificationEnabled y diríjala al propietario del formulario, no al propietario principal del registro. En un formulario de captación, el propietario del registro creado es el marcador de posición designado en la plantilla, así que notificar al propietario del registro envía un correo a un marcador de posición. Es lo contrario de la respuesta correcta en una encuesta enviada a un cliente existente, donde el propietario del registro es la persona que necesita saberlo.

El resto, en breve

• reCAPTCHA es un indicador por formulario. Está desactivado en este formulario y activado en el formulario de contacto general del mismo espacio. Un formulario público sin él acumulará basura, y basura en un formulario de upsert son registros basura.
• attachResponseAsPdf archiva el envío en el registro. En cualquier cosa que se parezca a una solicitud o a un acuerdo, esto es lo que hace defendible el registro un año después.
• La página de confirmación es una promesa. Configurarla para que diga «revise su email para ver las instrucciones» crea una obligación que el §5 tiene que cumplir.

05Automatización y lógica

El manejador del envío

Un proceso, vinculado a este formulario concreto por su id, que se dispara con el envío. Su entidad disparadora es la respuesta y su tipo de registro es el contacto al que se resolvió la respuesta, así que el proceso puede leer las respuestas y actuar sobre la persona en la misma ejecución. En la implementación real es deliberadamente pequeño (un filtro, un email) y existe para cumplir la frase de la página de confirmación.

Latencia observada: el proceso se ejecutó por última vez unos ocho segundos después de la última respuesta registrada del formulario. Es una observación, no un benchmark, pero resuelve la cuestión de diseño: es un traspaso en vivo, no un lote, así que el email de acuse de recibo puede formar parte de la experiencia del envío.

Recuperar la métrica con un segundo formulario, enviado

El patrón que merece la pena copiar es lo que ocurre después. El formulario de solicitud está incrustado, así que nunca puede informar de una tasa. El formulario de acuerdo que viene a continuación se envía, y un formulario enviado informa de todo. El embudo real, de principio a fin:

De esa tabla se desprenden dos lecturas. La obvia: ponga la etapa medible donde está la decisión. La más sutil: sentCount ÷ sentUniqueCount es 144 ÷ 41 ≈ 3,5, así que la proporción entre los dos contadores de envíos le dice cuántas veces hizo seguimiento a cada persona, un número que nada más en la plataforma muestra.

Hacer seguimiento a quienes no terminaron

Un formulario incrustado no tiene lista de sin respuesta, porque no tiene lista de envíos. Así que el seguimiento tiene que reconstruirse al otro lado: un proceso programado sobre los registros creados, filtrado a los que llegaron al estado de solicitud y nunca llegaron al de completado, que envía un recordatorio.

Esta es la lección estructural de todo el blueprint. Cada medición que un formulario incrustado no puede darle tiene que reconstruirse como informes sobre los registros que ha creado, lo cual solo es posible porque el §4 insistió en un subtipo, un campo de procedencia y una fecha de registro. Esos tres campos son por los que filtra el proceso de seguimiento. Si los omite en la creación, el seguimiento no se puede construir en absoluto.

Mantener legible la familia

Un embudo como este llega rápidamente a varios procesos: acusar recibo de la solicitud, reaccionar a la firma, hacer seguimiento a quienes no firmaron, puntuar al solicitante, lanzar la campaña. Son procesos separados porque un proceso lleva un filtro cuyas ramas se rigen por la primera coincidencia, y estas condiciones pueden cumplirse todas a la vez; la restricción y la disciplina de nombres están en el Blueprint 011. Vincule cada uno a los ids de formulario concretos a los que sirve; un disparador acepta una lista de formularios, así que una familia de formularios casi idénticos puede compartir un único proceso en lugar de multiplicarlo.

06Límites y compromisos

• Una pregunta obligatoria puede no ir a ninguna parte. Verificado en el formulario real: la casilla de privacidad es obligatoria para enviar y no figura en la plantilla de creación, así que el consentimiento se registra en la respuesta y no en el contacto. El mismo silencio se aplica a cualquier pregunta que nadie haya mapeado: la respuesta se almacena, y no está en el registro.
• Un upsert por email es una vía de escritura basada en un identificador adivinable. Cualquiera que envíe una dirección conocida actualiza el registro de esa persona. En un formulario de primer contacto, la exposición suele ser aceptable, porque los campos editables son los que esa persona controla de todos modos, pero es una decisión, no un valor predeterminado, y es el mismo mecanismo señalado como riesgo para las encuestas en el Blueprint 012. Cuando el formulario actualice algo comercialmente relevante, haga coincidir con un valor que solo la persona prevista pueda tener.
• El mismo ajuste es correcto en un diseño e incorrecto en otro. Dejar sin restricción las respuestas repetidas es lo que hace funcionar el upsert aquí; en una encuesta enviada es lo que lleva la tasa de respuesta por encima del 100 %. No hay un valor predeterminado seguro: decida para cada formulario cuál de los dos está construyendo.
• El número de campos obligatorios es un coste de conversión que usted no puede ver. Nueve campos obligatorios, incluida una dirección postal completa, es mucho pedir a un desconocido, y el abandono ocurre dentro de un marco que la página contenedora no puede observar. Verá los envíos que se completaron y nunca los que no, así que este compromiso tiene que razonarse en lugar de medirse.
• En un iframe, el formulario es invisible para los rastreadores y para los visitantes sin JavaScript, y su contenido no puede aportar nada al peso de búsqueda o de citación de la página.
• Nada restringe quién puede enmarcarlo. Sin frame-ancestors, sin X-Frame-Options: la propiedad que hace trivial la incrustación también significa que el formulario funciona en cualquier sitio que conozca el link id, y el link id está en el código fuente de su página.
• La procedencia escrita como texto libre diverge, en silencio y para siempre. Dos mecanismos de procedencia en un mismo formulario real ya no coinciden.
• La propiedad se aplaza, no se resuelve. El propietario designado satisface a la plataforma y no asigna el trabajo a nadie. Un proceso de enrutamiento o una vista compartida es un trabajo aparte, y olvidarlo es como un formulario de captación acaba alimentando una cola que ningún humano abre.
• Las definiciones de campos se comparten en todo el espacio. Aparecen identificadores de campo idénticos en formularios no relacionados del mismo espacio. Práctico para reutilizar; no se probó cómo se propaga una edición, así que trate el cambio de nombre de una pregunta compartida como un cambio en todos los formularios que la usan mientras no se demuestre lo contrario.

El compromiso que conviene exponer claramente

Alojar el formulario en el CRM le da lo que más importa y más cuesta incorporar a posteriori: la web deja de saber nada de su modelo de datos. Las preguntas cambian sin publicación, ninguna credencial sale del CRM, y el registro llega con tipo, propietario y sello. A lo que renuncia es a todo lo que depende de ver el formulario como parte de su página: integración visual más allá del propio estilo del formulario, analítica del embudo por campo, contenido indexable y un formulario que funcione sin JavaScript. Para un formulario de inscripción detrás de un botón, es un buen intercambio. Para un formulario que es la landing page, no lo es, y la respuesta honesta en ese caso es una página construida a mano que envíe a la API y asuma el coste de mantenimiento que describe el §2.

07Verificación

Leído el 2026-09-10 en un espacio de producción real y en la página pública real que incrusta el formulario: un formulario de solicitud a un programa de partners en servicio desde abril de 2026.

• El acoplamiento se verificó desde ambos extremos. El link id almacenado en la definición del formulario es idéntico byte a byte al id de la URL que guarda el modelo de contenido de la página pública, que contiene exactamente dos claves para el formulario: esa URL y un título accesible.
• Se consultó el endpoint público. Devuelve HTTP 200 con un armazón HTML de ~1,7 KB que contiene un elemento personalizado y tres scripts de módulo de una CDN estática, y ninguna cabecera X-Frame-Options ni frame-ancestors, que es la base de todas las afirmaciones sobre la incrustación del §3.
• El upsert se confirmó con sus propios contadores: 49 respuestas, 41 registros en la categoría de respondidos, 0 encuestados desconocidos. Por tanto, ocho envíos coincidieron con un registro existente en lugar de crear uno, sin que nada quedara sin coincidencia.
• Los ajustes y la plantilla de creación se leyeron literalmente: los tres indicadores del upsert, el par de autolink, el subtipo, los ids fijos de propietario y unidad, ambos sellos de procedencia, y la ausencia de cualquier campo de consentimiento. La enumeración en la plantilla de las cinco ranuras de teléfono y las cinco de email es lo que establece que es una carga útil completa y no un parche.
• El conjunto de campos se leyó entero: once preguntas, nueve obligatorias, prerrelleno desactivado en todas ellas, la pregunta de la calle un área de texto donde sus hermanas son entradas de una línea.
• Se rastreó la automatización: un proceso vinculado solo a este id de formulario, con la respuesta como entidad disparadora y el contacto como tipo de registro, dos nodos. La marca de tiempo de su última ejecución es unos ocho segundos posterior a la marca de tiempo de la última respuesta del formulario.
• Las cifras del embudo se leyeron de los propios contadores de los dos formularios, y la cifra del 85,4 % se reproduce exactamente como 35 ÷ 41: la misma aritmética de respuestas sobre destinatarios únicos verificada en todo un conjunto de formularios en el Blueprint 012.

No observado, y se indica como tal:

• Un envío hecho a propósito. Cada hallazgo se ha leído de la configuración almacenada, los resultados almacenados y el endpoint público, no de datos de prueba enviados a través de un formulario real.
• Si editar una definición compartida de campo de formulario se propaga a los demás formularios que la usan.
• Si un valor vacío en la plantilla de creación escribe un vacío o se omite.
• El comportamiento de reCAPTCHA en sí; solo que es un indicador por formulario, desactivado en este formulario y activado en otro del mismo espacio.

Qué indicaría una regresión

• Que los encuestados desconocidos suban por encima de cero en un formulario de upsert significa que el par de autolink se ha roto, y como la creación sigue funcionando, se presenta como un formulario sano que produce registros que nadie encuentra.
• Que el número de registros crezca al mismo ritmo que el número de respuestas. En un formulario con envíos repetidos, un registro por respuesta significa que la coincidencia ha dejado de producirse y que usted está acumulando duplicados.
• Que sigan llegando respuestas mientras el acuse de recibo se detiene. La página de confirmación seguirá prometiendo un email de todos modos; la promesa y el proceso se configuran en lugares distintos y nada los une.
• Que el número de registros del propietario designado crezca sin que se ejecute el proceso de seguimiento. Esa es la firma de un formulario de captación que alimenta una cola que nadie trabaja.

Blueprints relacionados

• Blueprint 012 — ¿Cómo lanza una encuesta a clientes desde su CRM y recupera las respuestas en el registro? — el modelo de datos de los formularios en línea, el prerrelleno con autolink para clientes conocidos y la aritmética de la tasa de respuesta.
• Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible? — por qué un embudo de captación se convierte en varios procesos, y cómo nombrarlos.
• Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un objeto? — decidir en qué entidad debe convertirse un envío público.
• Blueprint 001 — ¿Cómo gestiona cinco tipos distintos de solicitudes de clientes en un único servicio de asistencia? — el discriminador de subtipo que fija la plantilla de creación.
• Blueprint 005 — ¿Cómo migra contactos desde otro sistema sin perder datos sin darse cuenta? — por qué el email es una clave de deduplicación frágil a gran escala.