¿Cómo lanza una encuesta a clientes desde su CRM y recupera las respuestas en el registro?

01El problema de negocio

Hay momentos en que un cliente le dirá algo útil: justo después de una renovación, justo después de una reunión, unas semanas después de la puesta en marcha, en el momento en que se revisa una relación. Preguntar es la mitad fácil. La mitad difícil es que la respuesta tiene que llegar allí donde ya trabaja la persona que actúa en consecuencia.

Una puntuación de satisfacción en una hoja de cálculo no es una intervención. El gestor responsable de la relación abre el registro del cliente y, si el registro no dice nada de la encuesta, la encuesta no ha existido. Así que el requisito no es "hacer una encuesta", sino:

• preguntar en un momento disparado por algo que ocurre en el CRM,
• que cada respuesta sea atribuible a un cliente, una oportunidad o un contacto concretos,
• que las respuestas lleguen a ese registro como valores que un informe y un filtro puedan ver,
• avisar a la persona adecuada cuando llega una respuesta determinada,
• y saber a quién se preguntó y no ha contestado.

Este último es el requisito que se olvida, y es el que decide si el ejercicio produce una lista de seguimiento o una cifra de vanidad.

02Por qué falla el enfoque obvio

Una herramienta de encuestas más una integración

Lo habitual es recurrir a un producto de encuestas dedicado con un conector para el CRM. Falla en la atribución. El conector asocia las respuestas a los registros por la dirección de correo electrónico, y una dirección de correo es precisamente lo que no sobrevive a un envío real: el destinatario reenvía la invitación a un compañero, responde desde una dirección personal o es una de cuatro personas de la misma empresa. Lo que llega es una respuesta que el CRM no puede ubicar, y el resultado habitual es una respuesta que queda sin asociar sin que nadie lo note, o peor aún, asociada al registro equivocado más cercano.

Crear las preguntas como campos y enviar un enlace de edición

La siguiente idea es poner las preguntas en el registro del cliente como campos y enviar al cliente un enlace para editarlos. Ese enlace no existe. Los formularios de registro son internos; existen tras la autenticación y los permisos de rol, y ninguna configuración expone uno a un encuestado no autenticado.

Detectar un envío vigilando un campo

La recomendación habitual es añadir una casilla de "condiciones aceptadas" o "encuesta completada", hacerla obligatoria en el formulario y colgar de ella un proceso disparado por cambios. Funciona, y es realmente el patrón que conviene usar cuando una encuesta llega desde fuera de la plataforma. Aquí es la opción por defecto equivocada, por tres motivos:

• Se dispara en el registro equivocado. Un proceso disparado por cambios en la cuenta ve la cuenta. No puede ver qué formulario se respondió ni cuáles fueron las respuestas, porque estas residen en un registro de respuesta aparte.
• Un segundo envío puede no dispararlo. El campo centinela ya es true. Una respuesta repetida no cambia nada, así que no se ejecuta nada.
• Es innecesario. El envío de formulario es un tipo de disparador nativo. El centinela es un apaño para un hueco que no existe.

Un formulario para todo el recorrido del cliente

El último error es estructural, no mecánico: suponer que un cuestionario puede acompañar a un cliente a lo largo de todo su recorrido. Una definición de formulario indica un único tipo de entidad. Un cuestionario previo a una reunión que debe vincularse a un lead antes de la conversión y a una oportunidad después son dos definiciones de formulario, no un formulario con un interruptor.

03Modelo de datos

Tres entidades sostienen una encuesta, y lo primero es tener claro cuál es cuál, porque los nombres inducen a error. La visión del administrador sobre la misma funcionalidad está en el artículo del centro de ayuda de Coevera Working with online forms.

A qué puede vincularse una respuesta

La relación admite cuenta, contacto, lead, oportunidad, presupuesto, proyecto y entidad personalizada, con una de ellas marcada como principal. Así, una sola respuesta puede estar en la cuenta y en la oportunidad sobre la que se preguntó, y el indicador de principal es lo que un informe usa para agrupar.

Tanto el enum de tipos de entidad como la relación admiten una entidad personalizada. Esto está verificado en el esquema, pero no en el comportamiento: no había ningún ejemplo real de un formulario ligado a una entidad personalizada que pudiera leerse. Importa porque es lo contrario del subsistema de aprobaciones, que no puede tener como destino una entidad personalizada en absoluto; véase el Blueprint 001.

Las respuestas en sí

Una respuesta es un par: el id del campo del formulario y un valor de cadena. La respuesta no tiene tipos. Una valoración de 4 llega como texto, una selección múltiple llega como texto, una fecha llega como texto. Todo lo que usted quiera filtrar, promediar o representar en un gráfico tiene que escribirse en un campo tipado de un registro, que es precisamente para lo que sirven §4 y §5.

A quién se preguntó y quién respondió

Las respuestas se agregan por formulario en cuatro categorías, y son la superficie de informes que importa más que el número de respuestas:

La alternativa descartada

Modelar una respuesta de encuesta como entidad personalizada es el reflejo habitual cuando el subsistema nativo de una plataforma parece escaso. Aquí cuesta más de lo que aporta: habría que reconstruir la URL pública, el seguimiento de envíos, las cuatro categorías de agregación, el grupo de encuestados desconocidos, el PDF de la respuesta y el disparador de envío, y seguiría sin haber un motor que muestre el formulario. El marco de decisión para ese juicio es el Blueprint 003. Una entidad personalizada es la respuesta correcta cuando lo que se necesita es un registro revisable con su propio ciclo de vida y su propio responsable, y una respuesta no lo es. El registro de respuesta sí admite campos personalizados propios, así que una puntuación derivada puede residir en la respuesta sin una entidad nueva.

04Configuración a nivel de campo

Los tipos de campo disponibles en un formulario

Quince, y las ausencias importan tanto como las presencias:

Conviene conocer el campo de productos y servicios en una encuesta y no solo en un formulario de pedido: convierte "¿le interesan servicios adicionales?" en una selección con precio sobre una lista de precios concreta, de modo que una muestra de interés llega ya cuantificada. El comportamiento de los precios se describe en el Blueprint 007.

Lo que lleva cada campo del formulario

Campos de valoración

Un campo de valoración está acotado por valueFrom y valueTo, con valueFromLabel y valueToLabel como anclajes. Una pregunta de recomendación neta es 0–10 con las etiquetas Most unlikely / Most likely; una pregunta de satisfacción es 1–5; un semáforo es 1–3. El mismo tipo de campo, tres encuestas. Elija los límites una sola vez: cambiarlos más adelante invalida la comparación con todas las respuestas ya recogidas, y nada se lo advierte.

Cómo encuentra la respuesta su registro: la decisión central

Tres ajustes en el formulario, y elegir entre ellos es todo el diseño:

La parte elegante es cómo se combinan el prerrelleno y el autolink. Ponga un campo de correo electrónico en el formulario, prerrellénelo desde el campo de correo del registro y configure el autolink para comparar ese mismo campo del formulario con ese mismo campo del registro. Enviado desde el registro, llega prerrellenado y se vincula al instante. Si se llega a él en frío desde un enlace publicado, el encuestado escribe su dirección y se vincula igualmente. Una sola configuración, ambas vías.

Además, lleve la identidad en la que realmente confía en campos ocultos prerrellenados: visible: false, prefillEnabled: true, apuntando al nombre de la cuenta y al identificador de la cuenta. Nunca se muestran, viajan en el enlace y dan a la respuesta una identidad que no depende de lo que haya escrito el encuestado.

Escribir las respuestas en el registro encuestado

Con updateRecordEnabled, el formulario lleva una plantilla de actualización: una plantilla de registro corriente cuyos valores son referencias ppl-tag a campos del formulario:

{"customFields": {
  "cfLikelyToRecommend":
    "<ppl-tag data-id=\"{rating-form-field-id}\" data-relation-type=\"Responses\"></ppl-tag>",
  "cfSurveyDateFilled":
    "<ppl-tag data-id=\"CurrentDate\"></ppl-tag>",
  "cfSurveyRespondent":
    "<ppl-tag data-id=\"{first-name-field-id}\" data-relation-type=\"Responses\"></ppl-tag> <ppl-tag data-id=\"{last-name-field-id}\" data-relation-type=\"Responses\"></ppl-tag>",
  "cfSurveysCompleted": ["{option-uuid}"]
}}

• data-relation-type="Responses" es lo que toma el valor del envío.
• CurrentDate es una etiqueta integrada: registre aquí la fecha del envío, no en un proceso.
• Dos etiquetas en un mismo valor de destino se concatenan, que es como el nombre y el apellido se convierten en un solo campo.
• Un destino desplegable o de selección múltiple se establece por UUID de opción, nunca por etiqueta.
• Cada clave de la plantilla forma parte de la escritura. Limítela a los campos que pretende cambiar: una clave con un valor vacío sigue estando en la carga útil. No se ha probado si un valor vacío borra el campo de destino o se omite.

El resto de ajustes que conviene configurar a conciencia

05Automatización y lógica

El envío es un tipo de disparador

La plataforma tiene exactamente cuatro tipos de disparador de procesos: cambio de registro, programación, manual y envío de formulario en línea. Por tanto, una respuesta de encuesta es un evento de primer nivel, no algo que se deduce de un campo que ha cambiado.

El disparador indica tres cosas, y la primera sorprende:

Esa lista es la parte útil. Cuando una encuesta se reparte en varios formularios casi idénticos —uno por departamento, uno por público—, todo el conjunto puede colgar de un único proceso en lugar de un proceso por formulario.

Un formulario, varios procesos

Lo inverso también es cierto, y no es mala señal. Un proceso lleva exactamente un filtro en su raíz, y las ramas de ese filtro se rigen por la primera coincidencia. Así que cuatro cosas independientes que hacer con un envío —acusar recibo, enrutar la valoración, abrir una tarea si se pidió una reunión, avisar a un responsable de producto si se mencionó una funcionalidad— son cuatro procesos, porque cualquiera de ellas puede cumplirse al mismo tiempo que las demás. Es la misma restricción que decide el número de procesos en todo el resto de la plataforma; el Blueprint 011 la trata, junto con la disciplina de nomenclatura que mantiene legible una familia así.

El enrutador de valoraciones

El patrón que realmente compensa: filtrar por la franja de valoración y enviar un mensaje distinto por franja. Una puntuación baja envía un correo de inmediato al responsable de la relación; una puntuación alta avisa a quien recopila referencias. Ambas son ramas de un mismo filtro, porque una respuesta tiene exactamente una valoración: se trata de un conjunto real de alternativas, así que un solo proceso es lo correcto.

Convertir respuestas en estructura

Dos vías, con costes muy distintos:

Recurra primero a la plantilla. La vía del registro relacionado es la respuesta correcta cuando el historial importa, pero es la cara y es donde la automatización de encuestas se vuelve inmantenible más rápido.

Enviar la encuesta

Un formulario tiene un enlace público, así que enviarlo es una acción de correo electrónico corriente que lleva ese enlace con los parámetros de prerrelleno. La consecuencia es que el envío es la identidad: un proceso que envía el enlace desde el registro es también lo que coloca ese registro en la categoría Sent, que es lo que hace que SentAndNotResponded —la lista de seguimiento— exista siquiera. Una encuesta publicada en una página web no tiene lista de seguimiento, por construcción.

06Límites y compromisos

En un conjunto en producción de 74 definiciones de formulario con tres años de historial, la aritmética se cumplió exactamente en los 30 formularios que indicaban una tasa, y:

• 10 de esos 30 indicaban más del 100%.
• 44 formularios no indicaban ninguna tasa, y 21 de ellos reunían 491 respuestas entre todos. Un formulario que se publica en lugar de enviarse tiene un divisor de cero, así que no tiene tasa, por muchas personas que hayan respondido.

Considere la cifra significativa solo para un formulario que se envía en lugar de publicarse y que limita a cada destinatario a una sola respuesta. En caso contrario, calcule su propia tasa a partir de las categorías Sent y Responded, y tenga en cuenta que Responded cuenta registros, no respuestas.

Otros límites, en el orden en que se hacen notar

• Un formulario pertenece a un único tipo de entidad. Un cuestionario que debe vincularse a un lead antes de la conversión y a una oportunidad después son dos definiciones, dos mapeos de respuestas y, o bien dos procesos, o bien un proceso que nombre ambos formularios. No hay herencia entre ellos: una pregunta añadida a uno no se añade al otro.
• Un formulario público con autolink y actualización de registro habilitados a la vez es un punto de escritura. Cualquiera que aporte un valor que coincida con el campo de registro del autolink escribe en ese registro. Si el campo de coincidencia es una dirección de correo electrónico, el formulario solo es tan seguro como difícil sea adivinar las direcciones de correo de sus clientes. Limite los formularios públicos a createRecordEnabled y concilie después, o use para el autolink un valor que solo el destinatario previsto pueda tener.
• Las respuestas sin coincidencia se conservan, pero nada las procesa. Van a UnknownRespondents, lo cual es mucho mejor que descartarlas o vincularlas mal, y en una encuesta incrustada real reunían 10 de 39 respuestas. Pero es un grupo, no una cola: sin responsable, sin tarea, sin antigüedad. Asígnele una persona y una cadencia, o se convertirá en un lugar donde el feedback de los clientes se cuenta pero no se lee.
• Las respuestas son cadenas. Nada de una respuesta tiene tipo ni puede agregarse tal cual. Todo lo que deba representarse en gráficos, promediarse o filtrarse tiene que escribirse en un campo tipado mediante la plantilla o un proceso, lo que significa que una pregunta que nadie asignó es una pregunta sobre la que nadie puede informar, aunque la respuesta esté guardada.
• Una respuesta sobrevive al registro al que apunta. Tanto la respuesta como el resumen por registro llevan un indicador de disponibilidad, así que un registro eliminado o inaccesible deja respuestas que no apuntan a nada. El historial de encuestas no es motivo para conservar un registro, y eliminar un registro no limpia sus respuestas.
• No se puede confiar en el valor de respuesta resumido de la plataforma. El campo existe tanto en el formulario como en el resumen por registro, y era nulo en cada uno de los 74 formularios examinados. Calcule la puntuación que le interesa en un campo propio; no construya un informe sobre esa propiedad.
• Deshabilitar un formulario conserva sus respuestas. Once formularios deshabilitados del conjunto seguían guardando respuestas. Por tanto, deshabilitar es seguro como paso de archivo, pero no es una eliminación: las respuestas siguen vinculadas a sus registros y visibles en los informes. Un formulario deshabilitado tampoco acepta respuestas nuevas: el centro de ayuda documenta que un formulario inactivo sigue en línea, pero no puede almacenar las respuestas, y quien intente enviarlo solo ve una página estática.
• Los límites de valoración no se versionan. Cambiar valueFrom o valueTo hace, sin aviso, que las respuestas nuevas no sean comparables con las antiguas. Nada marca la discontinuidad.

El compromiso que conviene exponer sin rodeos

Los formularios nativos aportan atribución, un disparador de envío, una lista de seguimiento y un mapeo de respuestas a campos que no necesita código. Lo que no aportan es una plataforma de encuestas: no hay gestión de paneles, ni programación de recordatorios propia, ni comparativas entre formularios, ni análisis estadístico. Si el requisito es un instrumento de investigación, esta es la herramienta equivocada. Si el requisito es que el registro de la cuenta sepa lo que dijo el cliente y que alguien reciba el aviso —que casi siempre es el requisito real—, es la correcta, y es la única opción en la que la respuesta llega al registro sin una integración de por medio.

07Verificación

Leído de un espacio de producción real el 2026-09-10: 74 definiciones de formulario acumuladas durante tres años, su configuración, su configuración a nivel de campo, sus agregaciones de respuestas y los procesos que disparan.

• La fórmula de la tasa de respuesta se comprobó aritméticamente en todos los formularios que indicaban una: 30 formularios, cero discrepancias con respuestas ÷ destinatarios únicos × 100. Los 44 formularios sin tasa tenían todos cero envíos registrados.
• Las cuatro categorías de agregación se leyeron por formulario, y fue una encuesta incrustada la que fijó la aritmética: 170 enviados, 155 enviados y no respondidos, 23 respondidos, 10 encuestados desconocidos, frente a un número de respuestas de 39. Respondidos más desconocidos no es igual al número de respuestas porque Responded cuenta registros; enviados menos no respondidos no es igual a respondidos porque ocho encuestados nunca la recibieron y llegaron a través de la versión incrustada.
• Se leyeron por completo dos configuraciones reales contrapuestas. Una encuesta incrustada con autolinkEnabled y updateRecordEnabled activados y linkRecordEnabled desactivado; y un reparto por envío con linkRecordEnabled activado y los otros dos desactivados: la identidad procede del envío en un caso y de una respuesta en el otro.
• La plantilla de actualización se leyó literalmente de un formulario real, y de ahí proceden la forma de ppl-tag, el tipo de relación Responses, la etiqueta CurrentDate, la concatenación de etiquetas en un solo destino y los destinos desplegables por UUID de opción.
• Se contó la automatización disparada por formularios: 32 procesos del espacio usan el disparador de formulario en línea, todos ellos con la respuesta como entidad disparadora. Uno está ligado a seis formularios hermanos a la vez; un formulario es atendido por cuatro procesos distintos.
• Se confirmó el uso de la visibilidad condicional de preguntas: una pregunta de productos y servicios en una encuesta real lleva un filtro de campo y solo aparece cuando una respuesta anterior lo justifica.

No observado, y así se indica:

• La propia vía de envío pública: todas las conclusiones aquí se leen de la configuración y los resultados almacenados, no de un envío realizado a propósito.
• Un valor de respuesta resumido rellenado. Era nulo en todos los lugares donde aparece.
• Un formulario ligado a una entidad personalizada. Verificado en el esquema, pero no en el comportamiento.
• Si un valor vacío en la plantilla de actualización borra el campo de destino o se omite.

Qué indicaría una regresión

• Que el recuento Sent de un formulario solo enviado se estanque mientras siguen llegando respuestas significa que los envíos han dejado de registrarse, lo que destruye sin aviso la lista de seguimiento.
• Un número creciente de encuestados desconocidos es la alarma más útil aquí: significa que la vía de identidad —prerrelleno, autolink o el propio envío— se ha roto, y en cualquier otra medida aparecerá como "la encuesta funciona bien".
• Un número de respuestas que sube mientras los campos asignados de los registros no se actualizan significa que la plantilla de actualización ha dejado de aplicarse. Compruebe el registro, nunca la confirmación del envío.

Blueprints relacionados

• Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible? — por qué un formulario necesita varios procesos y cómo nombrarlos.
• Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un objeto? — el marco que justifica descartar una entidad personalizada para las respuestas.
• Blueprint 001 — ¿Cómo gestiona cinco tipos distintos de solicitudes de clientes en un único servicio de asistencia? — el límite del subsistema de aprobaciones con las entidades personalizadas, que los formularios no comparten.
• Blueprint 007 — ¿Cómo fija precios distintos para un mismo producto por región, segmento o contrato? — frente a qué se calcula el precio de la pregunta de productos y servicios.