Encuestas por disparador sin caos

Una encuesta por disparador se envía de forma automática cuando le ocurre algo a un cliente, en lugar de salir a una lista en una fecha fijada. Escribir la pregunta cuesta veinte minutos. Las reglas que la rodean deciden si el programa sigue siendo útil dentro de seis meses, y esa es justo la parte que casi nadie construye.

Casi todos los equipos empiezan igual. Se completa una compra, sale una encuesta, la tasa de respuesta multiplica varias veces la del envío mensual y el paso siguiente parece obvio: más disparadores. Año y medio después hay catorce, cuatro no tienen dueño, dos dejaron de funcionar en silencio cuando alguien renombró un evento, y a un cliente que compró el lunes se le encuestó el martes, el jueves y el viernes. Nada de eso es un problema de redacción. Es gobierno, y de esa mitad va esta guía.

Qué es exactamente una encuesta por disparador

Una encuesta por disparador es una encuesta cuyo envío lo decide un evento y no un calendario. Ocurre algo en un sistema que ya tienes en marcha, ese sistema emite una señal, y una capa de reglas decide si a una persona concreta le corresponde una pregunta concreta por ese motivo. La encuesta en sí es corriente: los mismos tipos de pregunta y la misma lógica de ramificación que usarías en cualquier otro sitio, casi siempre mucho más corta. Lo único que cambia es la decisión de enviar, y eso es precisamente lo que mueve los números.

La comparación que vale la pena hacer es con el lote programado, la encuesta trimestral que sale a toda la base de datos en una fecha fija y pregunta por un periodo, así que quien responde promedia meses de experiencia en una sola nota.

	Lote programado	Por disparador
Quién decide el envío	Un calendario y una lista	Un evento y una capa de reglas
Por qué pregunta	Por un periodo, promediado de memoria	Por una interacción, todavía fresca
Longitud habitual	De diez a veinte preguntas	Una o dos, más un seguimiento
Patrón de volumen	Un pico y luego silencio	Un goteo diario constante
Quién actúa	Quien lea la presentación	El equipo nombrado en la regla de enrutado
Riesgo principal	Que no conteste nadie	Que se pregunte demasiado a todo el mundo

La diferencia de tasa de respuesta tiene una explicación aburrida. La relevancia es el mejor predictor de que alguien conteste, y un mensaje que nombra el pedido de ayer es relevante de una forma que un «ayúdanos a mejorar» nunca será. El recuerdo es la segunda razón, porque las opiniones se degradan rápido, y la longitud es la tercera, ya que un disparador solo justifica preguntar por una cosa. La misma mecánica aparece en cómo reducir el abandono de encuestas.

Nada de esto sustituye a la encuesta de relación. El feedback transaccional te dice si un proceso funcionó, pero no si la gente recomendaría la empresa, y nunca llega a los clientes que dejaron de interactuar, que son exactamente los que tienen más probabilidad de irse. Esa distinción está desarrollada en CSAT frente a NPS, y los programas maduros mantienen las dos cosas a la vez.

Los eventos que merecen un disparador

Un buen evento disparador tiene tres propiedades. Tiene un límite claro, de modo que las dos partes coinciden en que la cosa terminó. Es atribuible, así que la respuesta apunta a un equipo o a un proceso que puede cambiar. Y produce volumen suficiente para aprender sin encuestar a las mismas personas sin parar. Los eventos que fallan la primera prueba, como «visitó una página», generan feedback que nadie puede accionar.

La compra o el pago completado es el punto de partida habitual y suele usarse mal. Cuando el cobro se confirma, lo único que el cliente puede juzgar es la experiencia de compra: si la web era clara, si el pago funcionó, si encontró lo que buscaba. Todavía no puede juzgar el producto, y preguntárselo devuelve una nota que mide expectativas. Separa las dos cosas y las dos respuestas se vuelven útiles.

La entrega es donde la cuestión del retraso se pone afilada, porque la versión equivocada hace daño de verdad. Disparar con el estado «enviado» pide valorar un paquete que la persona no tiene. El aviso de «entregado» del transportista es mejor, pero sigue siendo prematuro: llega cuando el paquete se deja en un punto de recogida o en la recepción del edificio. Espera uno o dos días desde la confirmación, y suprime la encuesta si mientras tanto se abrió una devolución, una reclamación o un ticket, porque esos casos piden una persona y no un cuestionario.

El ticket de soporte cerrado es el disparador más limpio que existe. El límite no admite discusión, la experiencia es específica y la pregunta correcta va sobre el esfuerzo antes que sobre la satisfacción, que es la razón de que el customer effort score viva aquí. Es además el único caso en el que disparar de inmediato es correcto: envía a los pocos minutos de la resolución, mientras la conversación sigue fresca.

El final del onboarding es el que se amortiza más rápido en software. Defínelo como un evento real de finalización, el primer proyecto creado o la primera factura emitida, y no como «siete días desde el registro», que encuesta a gente que nunca empezó. Pregunta qué estuvo a punto de detenerlos, porque ahí se nombra la fricción que te cuesta activaciones en silencio; la nota sobre onboarding cubre la definición.

El primer uso de una función necesita un ajuste: dispara en el segundo o el tercer uso, no en el primero. Una primera interacción mide novedad y confusión a partes iguales; la segunda te dice si aquello valía la pena repetir. Acótalo a funciones en las que el equipo está trabajando y apágalo cuando el trabajo se entregue.

La renovación de una suscripción no es un momento de celebración, es un cargo en una tarjeta. Una encuesta de satisfacción que aterriza el mismo día invita a responder sobre el precio en lugar de sobre el producto. Espera de tres a siete días, o salta la renovación y usa un aniversario de antigüedad, que lleva la misma información sin la factura en el encuadre.

La cancelación nunca debería ser un correo. Pregunta dentro del propio flujo, en el momento de la decisión, con una pregunta cerrada y una caja abierta opcional; un correo posterior llega a alguien que ya se marchó mentalmente y rinde tasas de respuesta de un dígito bajo. Mantén la lista de motivos corta y mutuamente excluyente, porque suele ser la única entrada estructurada que un equipo consigue sobre su tasa de abandono y sobre el trabajo descrito en retención de clientes.

El carrito abandonado tiene una trampa dentro. Una encuesta y un correo con descuento son dos mecanismos distintos, y enviar los dos el mismo día enseña a la gente que irse tiene premio. Elige uno. Si eliges la encuesta, espera alrededor de un día, pregunta qué los detuvo y ponle un tope duro para no interrogar cada semana a quien navega por costumbre.

El aniversario de antigüedad, que a menudo se usa para llevar una pregunta NPS periódica, es un disparador donde el retraso es el punto entero. Noventa días después del registro y luego una vez al año da a todos los clientes la misma experiencia acumulada antes de preguntarles, lo que hace las notas comparables de un modo que un envío en lote nunca logra. Se comporta como una encuesta de pulso rodante.

El retraso es una decisión de diseño, no un valor por defecto

Casi todas las herramientas piden un retraso y casi todos los equipos lo dejan en cero. Ese es el ajuste sin examinar con más consecuencias de un programa por disparadores, porque el retraso correcto es distinto para cada evento y va de minutos a meses.

La regla que hay debajo es que la encuesta debe llegar en el primer momento en que el cliente puede responder con honestidad, y ni un minuto antes. Después de una conversación con soporte, ese momento es inmediato. Después de una entrega, es cuando la caja ya se abrió. Después de un primer uso, es después del segundo. Disparar al instante parece diligente y casi siempre es simplemente prematuro, y una encuesta prematura no solo baja la tasa de respuesta: devuelve una respuesta equivocada, porque la gente contesta sobre la parte que alcanza a ver.

Encima de eso se apoyan dos condiciones. Respeta la hora local, ya que una encuesta generada a las tres de la madrugada en la zona horaria de quien la recibe se lee como automatización que nadie supervisa. Y decide qué pasa cuando un evento posterior adelanta a una encuesta en cola, por ejemplo una de entrega prevista para mañana cuando esta noche se procesó un reembolso. Vuelve a comprobar las supresiones en el momento del envío y no solo en el del disparo; quien comprueba únicamente al recibir el evento manda los envíos más bochornosos de esta categoría.

Las reglas que un evento atraviesa antes de que se envíe nada

Entre la llegada del evento y la salida de un mensaje debería haber una cadena de comprobaciones. Todas y cada una existen porque alguien, alguna vez, publicó un programa sin ellas.

La deduplicación va primero. La entrega de eventos se reintenta por diseño, así que cualquier productor de webhooks mandará de vez en cuando el mismo evento dos veces. Dale a cada evento una clave de idempotencia construida con los identificadores del evento y del cliente, guárdala y descarta las repeticiones dentro de una ventana generosa. Sin esto acabarás enviando a una misma persona la misma encuesta tres veces en un minuto, que es el fallo que hace que alguien con galones ponga el programa en pausa.

Después, comprueba que es un cliente real. Los pedidos de prueba, las cuentas de demostración, las direcciones internas y el tráfico de pruebas de carga emiten exactamente los mismos eventos que la actividad real. Filtra por tipo de cuenta y por dominio, y trata como no elegible por defecto todo lo que venga de un entorno que no sea producción.

Luego, consentimiento y contactabilidad. La persona necesita un canal válido, un idioma conocido y permiso para ser contactada con fines de investigación. El consentimiento transaccional y el de marketing no son lo mismo, y la frontera cambia según el mercado, así que guarda una preferencia de investigación separada en lugar de deducirla. Quien se dio de baja se queda fuera de todas las campañas, de forma permanente.

Luego, la lista de supresión, donde vive el criterio. Cualquiera que haya respondido una encuesta en los últimos treinta días, o recibido una en los últimos catorce, queda suprimido. También quien tenga una queja abierta, una disputa de reembolso o una escalada en curso, porque una pregunta de satisfacción en mitad de un problema sin resolver se lee como una falta de tacto. Durante una incidencia, todos los disparadores se pausan con un solo interruptor, ya que las respuestas medirían la caída. Las cuentas nombradas que lleva un gestor de éxito de cliente pasan a esa persona, y los empleados, socios y cuentas de prensa nunca reciben investigación automatizada.

Luego, el tope de frecuencia, que tiene su propia sección más abajo, y tras él el muestreo. En un evento de alto volumen no necesitas a todo el mundo, y encuestar a un porcentaje fijo da volumen suficiente dejando intacta a la mayor parte de la base; la nota sobre tamaño de muestra cubre cuánto es suficiente.

Por último, la prioridad. Antes o después, dos disparadores se activarán para la misma persona el mismo día y algo tiene que decidir. Un orden que funciona: la cancelación gana a todo, una incidencia de soporte abierta gana a una encuesta transaccional, y una encuesta transaccional gana a una de relación o de función. El perdedor se descarta en lugar de aplazarse, porque una cola de encuestas diferidas reconstruye en silencio el problema que el tope venía a resolver.

Tope de frecuencia global, no por campaña

El error estructural más común aquí es poner el tope dentro de cada campaña. Cada disparador aislado parece educado con su «una vez por trimestre», y un cliente que compró algo, escribió a soporte, recibió una entrega y renovó en la misma quincena se lleva cuatro encuestas porque ninguna regla individual se incumplió. El tope tiene que ser global, evaluado sobre todas las campañas y canales, y guardado en un único sitio que consulten todos los emisores.

Valores por defecto que sobreviven al contacto con la realidad: no más de una encuesta por persona cada treinta días contando todo, ampliado a noventa días cuando alguien completa una, con un techo anual duro de cuatro. Trata dos invitaciones ignoradas seguidas como una señal y silencia a esa persona durante seis meses. Cuenta invitaciones y no respuestas completadas, porque el desgaste viene de que te pregunten.

La aplicación importa más que las cifras. Si la herramienta de encuestas pone tope, la plataforma de marketing pone tope, y una automatización del helpdesk manda una quinta encuesta que nadie contó, entonces no tienes tope. Elige un sistema como fuente de verdad sobre cuándo se preguntó algo por última vez a esta persona, escribe en él desde todos los emisores y consúltalo antes de cada envío. Esta es la cara operativa de la fatiga de encuestas, y su síntoma más temprano no son las quejas sino una caída lenta de la tasa de respuesta en todas las campañas a la vez.

Pasa el contexto, nunca lo preguntes

Una encuesta por disparador la lanza un sistema que ya conoce el número de pedido, el importe, el transportista, el agente, el plan y la antigüedad. Cada uno de esos datos convertido en pregunta es una pregunta desperdiciada, un impuesto sobre la finalización y una invitación a una respuesta inexacta, porque la gente recuerda mal detalles que tu base de datos tiene exactos.

Adjunta el contexto como campos ocultos en el enlace de la encuesta o a través de la API que crea la respuesta. Qué conviene adjuntar depende del disparador, pero el patrón se repite.

• Identificadores de la transacción. Pedido, ticket, envío o suscripción, para que una nota baja se rastree hasta el caso exacto sin preguntarle nada a nadie.
• Atributos del evento. Importe, categoría de producto, método de entrega, canal de soporte, tiempo de gestión.
• Quién intervino. Agente, equipo, tienda o región, que es lo que convierte las notas en formación en lugar de en comentario.
• Atributos del cliente. Plan, antigüedad, franja de valor, idioma, para poder leer los resultados por segmentación y no como un promedio único.
• El nombre del disparador y de la variante. Sin ellos no sabrás qué disparador produjo una respuesta cuando haya varios activos, ni podrás comparar variantes en una prueba A/B.

Dos límites. Mantén los datos personales fuera de los parámetros de URL, porque los enlaces se reenvían, se registran y se pegan dentro de tickets; pasa un identificador interno que no signifique nada fuera de tus sistemas. Y nunca llames anónima a una encuesta que lleva un identificador de cuenta, una regla que se detalla en la nota sobre encuestas anónimas.

Lleva la respuesta a donde alguien actúa

Una respuesta que aterriza solo en un panel de encuestas es una respuesta sobre la que nadie va a actuar, porque quienes arreglan las cosas no abren paneles de encuestas. El enrutado forma parte del diseño tanto como la pregunta, y hay que dejarlo escrito antes del primer envío.

Escribe la nota de vuelta en la ficha del cliente en el CRM, como campo en el contacto y en la cuenta, para que la próxima persona que abra esa ficha la vea. Un equipo comercial se comporta distinto ante una cuenta que puntuó dos la semana pasada, y ese cambio vale más que cualquier informe. Empuja también la respuesta completa al almacén de datos, para cruzarla más adelante con ingresos y retención.

Después define la ruta de alerta para las respuestas malas. Una nota baja sobre un ticket de soporte debería abrir una tarea de seguimiento en el helpdesk, enlazada al ticket original, asignada con las mismas reglas con las que se asignan los tickets y con un tiempo de respuesta objetivo. Una nota baja de una cuenta de alto valor debería avisar a una persona con nombre y apellidos dentro de la hora, no aparecer en un resumen semanal. La regla que conviene sostener es que toda respuesta negativa tenga dueño y plazo antes de que el disparador se active, porque si no habrás construido una máquina que recoge quejas y las ignora.

Casi todo esto es configuración y no ingeniería: la herramienta de encuestas emite un webhook o escribe a través de un conector existente, y el helpdesk o el CRM hacen el resto, que es para lo que están las integraciones. Lo que no se puede automatizar es cerrar el círculo, y contarle a alguien qué cambió después de su queja es el factor que más influye en si volverá a responder.

Mide cada disparador por separado

El informe agregado destruye los programas por disparadores. Un único número de satisfacción mezclado entre nueve disparadores se mueve por razones que nadie sabe nombrar, casi siempre porque cambió la mezcla de volúmenes y no porque algo mejorara. Informa por disparador, y compara cada disparador solo contra su propia historia.

Lo que vale la pena vigilar en cada uno: la tasa de respuesta, la tasa de finalización entre quienes empezaron, la distribución de notas antes que la media, y el volumen de eventos suprimidos junto con el motivo. Ese último es el diagnóstico que nadie construye y todo el mundo necesita, porque es así como se descubre que un tope se está comiendo el ochenta por ciento de tus encuestas de entrega. Leer la tasa de finalización por separado también importa: una invitación que nadie abre es un problema de canal o de momento, mientras que una encuesta que la gente empieza y abandona es un problema de preguntas.

Dos costumbres mantienen esto honesto. Mira las distribuciones, ya que una media de cuatro puede esconder un grupo endurecido de unos, y lee el texto abierto por temas con recuentos y no por anécdota, con el enfoque de análisis temático. Los disparadores de poco volumen nunca darán cifras semanales limpias, así que léelos por trimestre.

Lo que se rompe de verdad

Las encuestas por disparador fallan de un número reducido de formas repetibles, y ninguna tiene que ver con la redacción de las preguntas.

El disparo doble por reintento de webhooks es el clásico. Un productor no recibe confirmación a tiempo y reintenta, o un pedido pasa por tres cambios de estado que se mapean al mismo disparador. Las claves de idempotencia y una ventana de deduplicación lo arreglan, y nada más lo hace. Pruébalo reproduciendo un mismo evento tres veces antes de salir a producción, porque en producción pasará un sábado.

Los eventos de prueba que llegan a clientes reales son los que causan daño de verdad. Un script de control de calidad corre contra producción, se crea una cuenta de demostración con la dirección real de un compañero, o una migración reproduce dos años de eventos históricos y todo el que alguna vez compró algo recibe una encuesta sobre un pedido de hace tres años. Protégete con una marca de entorno comprobada en el momento del envío, una lista de permitidos para envíos fuera de producción y un limitador que detenga cualquier campaña que supere un volumen por hora plausible.

La muerte silenciosa es el fallo más caro porque nadie lo nota. Alguien renombra un evento, un campo cambia de tipo, un token caduca, y el disparador se detiene. Un disparador muerto tiene el mismo aspecto que uno sin eventos elegibles, así que alerta sobre la ausencia de volumen: si algo que normalmente produce doscientos envíos por semana produce cero durante dos días, debería despertar a una persona.

La deriva de zona horaria e idioma genera las pequeñas vergüenzas: una encuesta a las cuatro de la madrugada, una encuesta en inglés a alguien que lleva dos años usando tu producto en portugués, un retraso de «veinticuatro horas» que aterriza en un día festivo.

La proliferación sin registro es la lenta. Cada disparador nuevo es fácil de añadir y nada obliga a nadie a retirar uno viejo, así que la cuenta solo sube. Todo disparador activo necesita un dueño con nombre, un propósito, una fecha de revisión y un interruptor de apagado, y cualquier disparador cuyos datos nadie ha leído en dos trimestres debería apagarse en vez de mantenerse.

La debilidad honesta: fácil de empezar, difícil de gobernar

Esta es la parte que los proveedores no dicen. Las encuestas por disparador son trivialmente fáciles de lanzar y genuinamente difíciles de operar bien, y la dificultad es administrativa antes que técnica. El primer disparador no tiene nada de complicado. La complejidad es emergente: aparece cuando hay nueve, en manos de tres equipos, enviando por dos sistemas, con audiencias solapadas y sin un tope compartido.

El coste, además, cae en un sitio distinto del beneficio. Marketing se lleva la tasa de respuesta; ingeniería se lleva los reintentos de webhook y la alerta de guardia; soporte se lleva los tickets de seguimiento que genera cada nota baja. Los programas se degradan cuando quien carga con el coste no es quien lee los resultados, y por eso los artefactos de gobierno que sirven son aburridos: un registro de cada disparador activo con dueño, evento, retraso, tope y fecha de última revisión, una revisión trimestral que retire tantos disparadores como añade, y alguien capaz de pausarlo todo durante una incidencia.

La cobertura es la segunda limitación. Los disparadores solo alcanzan a quien hizo algo, lo que deja fuera a los desenganchados, y el desenganche es el mejor predictor de abandono que existe. Un programa construido solo sobre disparadores muestra notas saludables mientras pierde en silencio a clientes que dejaron de interactuar hace meses, así que conviene mantener una encuesta periódica apuntando a toda la base. La tercera es que las encuestas cortas compran su tasa de respuesta preguntando menos: una pregunta después de una entrega te dice que un paquete llegó mal, no por qué. Los disparadores son un instrumento de monitorización, y tratarlos como uno de diagnóstico termina en decepción.

Montar uno, paso a paso

El orden de abajo es deliberado, porque la mayoría de los fallos anteriores vienen de hacer estos pasos en la secuencia equivocada.

• Nombra primero la decisión. Escribe qué harás distinto según la respuesta, y quién lo hará. Si nadie sabe contestar eso, el disparador no debería existir.
• Elige un evento con un límite limpio, escribe su definición exacta y luego fija el retraso desde el lado del cliente, junto con las reglas de supresión y el tope, antes de redactar la pregunta.
• Escribe una pregunta más un seguimiento condicional. Una microencuesta es la forma correcta, las trampas de redacción están listadas en preguntas para un formulario de feedback, y el método general está en cómo crear una encuesta online.
• Ajusta el canal al evento. El correo encaja tras la entrega y tras la compra, como se explica en encuestas por email; los momentos dentro del producto pertenecen al feedback in-app; una cancelación pide un formulario emergente o en línea dentro del propio flujo.
• Cablea los campos de contexto y el enrutado antes del primer envío real, incluido quién se hace cargo de las respuestas negativas.
• Prueba con eventos reproducidos, incluyendo duplicados, un evento de un cliente suprimido y otro en un segundo idioma; luego escala con muestreo y revisa a los treinta días contra la decisión que escribiste en el primer paso.

Hacerlo sin un proyecto de ingeniería

La mitad de la encuesta no necesita código propio. Una encuesta alojada se ocupa de las preguntas, la ramificación, los campos ocultos que llevan el contexto de pedido y ticket, las versiones por idioma y los informes, mientras tus sistemas conservan solo el evento y las reglas. Ese reparto convierte el primer disparador en un trabajo de dos días en lugar de un sprint, y partir de una plantilla lista elimina la mayoría de los errores de redacción antes de que llegues a los de momento.

SurveyNinja cubre esa mitad: lógica que manda las notas bajas y altas por caminos distintos, variables ocultas para cada pieza de contexto del evento, conectores y webhooks para que las respuestas aterricen en el CRM o el helpdesk donde alguien actúa, e informes filtrados para leer cada disparador por su cuenta; la mecánica está en la lista de funciones. El plan gratuito no tiene tope de respuestas, algo que aquí importa más que en ningún otro formato, porque un disparador conectado a un evento con tráfico produce un flujo diario constante y una cuota es lo peor que puedes encontrarte a mitad de trimestre; los detalles están en la página de precios. Monta la encuesta, conéctala a un solo evento limpio y dale un retraso que alguien haya pensado de verdad.

Preguntas frecuentes

¿Qué es una encuesta por disparador?

Una encuesta cuyo envío lo decide un evento y no un calendario. Ocurre algo en un sistema que ya tienes en marcha, ese sistema emite una señal, y una capa de reglas decide si a una persona concreta le corresponde una pregunta concreta por ese motivo. La encuesta en sí es corriente y suele ser muy corta; lo único que cambia es la decisión de enviar.

¿En qué se diferencia de una encuesta enviada en lote?

Una encuesta en lote sale a una lista en una fecha y pide promediar un periodo de memoria. Una encuesta por disparador pregunta a una persona por una cosa que acaba de pasarle. Esa relevancia explica que las tasas de respuesta sean varias veces mayores, y que las respuestas apunten a un proceso concreto en lugar de a una sensación general.

¿Sobre qué eventos vale la pena disparar una encuesta?

Sobre eventos con un límite claro y un responsable: una compra completada, una entrega confirmada, un ticket de soporte cerrado, el onboarding terminado, el segundo uso de una función nueva, una renovación, una cancelación, un carrito abandonado y un aniversario de antigüedad. Eventos como visitar una página fallan la prueba del límite y generan feedback que nadie puede accionar.

¿Cuánto conviene esperar antes de enviar una encuesta por disparador?

Hasta el primer momento en que el cliente pueda responder con honestidad. Tras una conversación con soporte, eso es inmediato. Tras una entrega, es uno o dos días después de la confirmación, porque el aviso del transportista llega antes de que el paquete esté en manos de nadie. Tras un primer uso de una función, espera al segundo. Tras una renovación, espera de tres a siete días para que el cargo no sea lo último que ocurrió.

¿Con qué frecuencia es demasiado encuestar al mismo cliente?

Más de una vez cada treinta días sumando todas las campañas, y más de cuatro veces al año en total. Amplía el intervalo a noventa días después de que alguien complete una encuesta, y silencia durante seis meses a quien ignoró dos invitaciones seguidas. Cuenta invitaciones y no respuestas completadas, porque el desgaste viene de que te pregunten.

¿Por qué las encuestas por disparador envían duplicados?

Porque la entrega de eventos se reintenta por diseño y varios cambios de estado suelen mapearse al mismo disparador. La solución es una clave de idempotencia construida con los identificadores del evento y del cliente, guardada y consultada para descartar repeticiones dentro de una ventana generosa. Reproduce el mismo evento tres veces en las pruebas, porque en producción pasará seguro.

¿Qué contexto conviene adjuntar a una encuesta por disparador?

El identificador de aquello que se valora, sus atributos como el importe o el canal, quién intervino como el agente o la tienda, y atributos del cliente como el plan y la antigüedad, además del nombre del disparador. Pásalos como campos ocultos para no preguntar nada que un sistema ya sabe, mantén los datos personales fuera de los parámetros de URL y nunca llames anónima a una encuesta que lleva un identificador de cuenta.

¿Cuál es la principal debilidad de las encuestas por disparador?

Que son fáciles de empezar y difíciles de gobernar. Cada disparador se monta en minutos, nada obliga a nadie a retirar uno viejo, y al cabo de un año hay varios equipos enviando a audiencias solapadas sin un tope de frecuencia compartido. Además solo alcanzan a quien hizo algo, lo que deja fuera a los clientes desenganchados, que son los que más probablemente se van.