---
title: "¿Cómo lanza una encuesta a clientes desde su CRM y recupera las respuestas en el registro?"
blueprint: 012
slug: customer-survey-answers-onto-the-record
category: Feedback
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/es/blueprints/customer-survey-answers-onto-the-record/
language: es
translation_of: https://blueprints.coevera.com/blueprints/customer-survey-answers-onto-the-record/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---
# ¿Cómo lanza una encuesta a clientes desde su CRM y recupera las respuestas en el registro?
**Respuesta corta.** Coevera tiene un subsistema nativo de **formularios en línea**, y la encuesta
es un formulario. La definición del formulario indica **exactamente un tipo de entidad** al que
puede vincularse. Un envío crea un **registro de respuesta** que guarda las respuestas, y la
propia configuración del formulario decide qué ocurre después: vincular la respuesta al registro
encuestado, **escribir las respuestas en él** o crear un registro nuevo.
El envío de formulario es uno de solo **cuatro** tipos de disparador de procesos —junto con cambio
de registro, programación y manual—, así que una encuesta es un evento de automatización de primer
nivel y no algo que se detecta a posteriori.
La salvedad es la métrica. La **tasa de respuesta integrada es respuestas ÷ destinatarios
únicos**, así que queda vacía en cualquier formulario que usted haya publicado en lugar de
enviarlo por correo, y supera el 100% en cuanto llegan respuestas de personas a las que nunca se
envió el formulario, a través de un enlace reenviado o publicado.
## 01 · El 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.
## 02 · Por 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.
## 03 · Modelo 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](https://help.coevera.com/en/articles/8039971-working-with-online-forms).
| Entidad | Qué es en realidad | Propiedades clave |
|---|---|---|
| **Online form type** | La **definición del formulario**: la encuesta que usted diseñó | `name`, `entityType` (solo uno), el diseño, un `styleId` obligatorio, un `link` y un `linkId` públicos, `isEnabled`, `hasDraft`, y los contadores `sentCount`, `sentUniqueCount`, `responseCount`, `responseRate`, `lastResponseDate` |
| **Online form** | Una **única respuesta enviada**. No el formulario. | `answers`, `respondedBy`, `responseDate`, `onlineFormTypeId`, sus propios `customFields`, y `primaryAccount` / `primaryContact` / `primaryLead` / `primaryOpportunity` / `primaryQuote` / `primaryCustomEntity` |
| **Online form relation** | La relación entre una respuesta y los registros a los que se refiere | `accountId`, `contactId`, `leadOpptyId`, `quoteId`, `projectId`, `customEntityId`, además de `isPrimary` |
> **Trampa de nombres.** La entidad llamada *online form* es una respuesta, y la entidad llamada
> *online form type* es el formulario. Todo se lee correctamente en cuanto se traduce "type" como
> "definición" y "form" como "envío".
### 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](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/).
### 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:
| Categoría | Qué le proporciona |
|---|---|
| `Sent` | Cada registro al que se envió el formulario |
| `Responded` | Los registros que respondieron: registros, no respuestas |
| `SentAndNotResponded` | **La lista de seguimiento.** Es la que hace que una encuesta sea operativa |
| `UnknownRespondents` | Respuestas que llegaron pero no coincidieron con ningún registro |
### 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](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/). 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.
## 04 · Configuración a nivel de campo
### Los tipos de campo disponibles en un formulario
Quince, y las ausencias importan tanto como las presencias:
| Grupo | Tipos |
|---|---|
| Texto | entrada de una línea, área de texto, correo electrónico, teléfono |
| Numérico | entero, decimal, **valoración** |
| Selección | desplegable, botón de opción, casillas de selección múltiple, casilla de verificación única |
| Temporal | fecha, fecha y hora |
| Otros | carga de archivos, productos y servicios |
| **Ausentes** | ningún campo lookup, ningún campo de moneda |
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](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/).
### Lo que lleva cada campo del formulario
| Propiedad | Finalidad |
|---|---|
| `fieldId` | El campo del CRM al que se asigna esta pregunta |
| `required`, `visible`, `readOnly` | Estándar; `visible: false` es determinante, véase más abajo |
| `prefillEnabled`, `prefillType` | `Field` toma el valor de un campo del registro, `Custom` usa un valor fijo |
| `prefillFieldId`, `prefillLookupFieldId` | Qué campo del registro, opcionalmente a través de un lookup |
| `conditionalRulesFilter` | Un filtro de campo normal: así es como una pregunta aparece solo cuando una respuesta anterior lo justifica |
| `name` | La etiqueta de la pregunta, y es **HTML**. Si la pega desde un documento, los colores pegados viajan con ella |
### 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:
| Situación | Ajuste | Cómo llega la identidad |
|---|---|---|
| Enviado a una persona conocida sobre un registro conocido | `linkRecordEnabled` | Del propio envío. No hace falta ninguna respuesta para establecer la identidad, y el autolink permanece desactivado |
| Publicado en una página o incrustado en un correo electrónico | `autolinkEnabled` + `autolinkFormFieldId` + `autolinkRecordFieldId` | Un campo del formulario se compara con un campo del registro |
| El encuestado todavía no está en el CRM | `createRecordEnabled` | Se crea un registro nuevo a partir de las respuestas |
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":
"",
"cfSurveyDateFilled":
"",
"cfSurveyRespondent":
" ",
"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
| Ajuste | Por qué importa en una encuesta |
|---|---|
| `limitToSingleResponse`, `checkForExistingResponse` | Ambos vienen desactivados por defecto. Dejarlos así es lo que permite que un destinatario responda repetidamente, y cada respuesta se guarda como una respuesta nueva |
| `notificationRecipientType` | `Owner` \| `PrimaryRecordOwner` \| `Custom`. `PrimaryRecordOwner` envía un correo al propietario del registro al que se vinculó la respuesta, es decir, al gestor de la relación. Una simple alerta no necesita ningún proceso |
| `attachResponseAsPdf` | Archiva el cuestionario completado en el registro como documento. Es lo que hace que la encuesta sea auditable un año después |
| `responseAcceptanceDateLimitEnabled` + fecha | Cierra la encuesta en una fecha con su propio título y mensaje, en lugar de recoger respuestas rezagadas en un periodo sobre el que ya informó |
| `responseAcceptanceThresholdType` | `TotalResponses` \| `CustomCondition` \| `ProductsLimits`: límites de capacidad, para una encuesta que también sirve de inscripción |
| `recordIdentificationEnabled` | Pide al encuestado que identifique su propio registro cuando el autolink no puede hacerlo |
| `confirmationPageType` | `ConfirmationPage` \| `ExternalUrl` |
| `attachFiles`, `maxTotalUploadedFilesSize` | Necesarios si alguna pregunta invita a adjuntar un archivo |
## 05 · Automatizació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:
| Propiedad | Valor | Consecuencia |
|---|---|---|
| `entityType` | la respuesta | **El proceso se ejecuta sobre el registro de respuesta**, no sobre el cliente. Sus filtros leen las respuestas |
| `recordType` | cuenta, oportunidad, lead, … | A qué se vinculó la respuesta, para que las acciones puedan llegar al registro del cliente a través de la relación |
| `onlineForms` | una **lista** de ids de formulario | Un proceso puede servir a muchos formularios: una familia de cuestionarios hermanos comparte una sola automatización |
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](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/)
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:
| Vía | Coste | Cuándo usarla |
|---|---|---|
| La plantilla de actualización del propio formulario (§4) | Declarativa, una escritura, ningún proceso | Las respuestas pertenecen al registro encuestado como su estado actual: última puntuación, fecha de la última encuesta, último comentario literal |
| Un proceso que crea un registro relacionado por respuesta | **Un nodo por respuesta.** Una encuesta de veinte preguntas es un proceso de veinte nodos, y crece cada vez que se añade una pregunta | Cada respuesta debe ser su propia fila revisable con historial: cuando la segunda encuesta no debe sobrescribir la primera |
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.
## 06 · Límites y compromisos
> **La tasa de respuesta integrada es respuestas ÷ destinatarios únicos.** No es una tasa de
> respuesta en el sentido que cualquiera le da. Queda vacía en todo formulario que nunca se envió
> por correo, y supera el 100% en cuanto llegan respuestas de personas a las que no se envió el
> formulario: un enlace reenviado o publicado las pone en el numerador y nunca en el divisor. Las
> respuestas repetidas no son una causa documentada —el centro de ayuda indica que [si el mismo
> encuestado envía más de una respuesta, cuenta como
> una](https://help.coevera.com/en/articles/8039971-working-with-online-forms)—, aunque
> `limitToSingleResponse` está desactivado por defecto.
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](https://help.coevera.com/en/articles/8039971-working-with-online-forms), 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.
## 07 · Verificació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?](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/)
— 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?](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/) — 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?](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/) — 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?](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) —
frente a qué se calcula el precio de la pregunta de productos y servicios.
## Preguntas frecuentes
### ¿Cómo lanza una encuesta a clientes desde su CRM y recupera las respuestas en el registro?
Utilice el subsistema nativo de formularios en línea. Una definición de formulario está ligada exactamente a un tipo de entidad; un envío crea un registro de respuesta que guarda las respuestas como cadenas de texto; y la propia configuración del formulario decide si la respuesta solo se vincula al registro encuestado, se escribe en él o se usa para crear uno nuevo. El envío de formulario es uno de los cuatro tipos de disparador de procesos de la plataforma, así que la automatización se ejecuta sobre la respuesta y llega al registro encuestado a través de ella.
### ¿Cómo sabe una encuesta a qué cliente se refiere?
Mediante dos mecanismos. Cuando el formulario se envía desde el registro, los campos ocultos del formulario se prerrellenan a partir de campos del registro y la identidad viaja en el enlace, de modo que la respuesta se vincula en cuanto llega. Cuando el formulario se publica o se incrusta y cualquiera puede acceder a él, el autolink compara un campo del formulario con un campo del registro —normalmente una dirección de correo electrónico que también fue el origen del prerrelleno— y vincula la respuesta al registro que coincida.
### ¿Por qué la tasa de respuesta de una encuesta supera el 100%?
Porque la tasa de respuesta integrada es el número de respuestas dividido entre el número de destinatarios únicos. Una respuesta que llega desde un enlace reenviado o publicado cuenta en el numerador sin aparecer nunca en el denominador, así que las respuestas de personas a las que nunca se envió el formulario la llevan por encima del 100%. El centro de ayuda indica que las respuestas repetidas de un mismo encuestado cuentan como una, así que un destinatario que responde dos veces no es una causa documentada. La cifra solo tiene sentido para un formulario que se envía en lugar de publicarse y que limita a cada destinatario a una sola respuesta.
### ¿Qué ocurre con una respuesta de encuesta que no puede asociarse a un registro?
Se conserva. Las respuestas se resumen por formulario en cuatro categorías —respondidos, enviados, enviados y no respondidos, y encuestados desconocidos— y una respuesta sin coincidencia va al grupo de encuestados desconocidos en lugar de descartarse o vincularse al registro equivocado. Nada procesa ese grupo automáticamente, así que necesita un responsable.
### ¿Puede un mismo formulario de encuesta servir tanto para leads como para oportunidades?
No. Una definición de formulario indica un único tipo de entidad, así que el mismo cuestionario planteado antes y después de convertir un lead son dos definiciones de formulario. Cada una necesita su propio mapeo de respuestas, y la automatización que reaccione a cualquiera de ellas tiene que nombrar ambos formularios en su disparador o existir por duplicado.
---
Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos
de clientes, sin datos personales.