El cliente no siempre cuenta todo en su primer mensaje. Puede empezar preguntando un precio y recién después indicar la sede, el programa o el tipo de servicio. Diseñar una derivación útil significa aceptar esa información progresiva sin multiplicar oportunidades ni deshacer el trabajo del equipo.
Este curso está pensado para administradores y supervisores. Necesitas conocer los flujos de tu cuenta; para aplicar la configuración, también necesitas la integración activa y permisos adecuados. El ejercicio de diseño se puede realizar sin modificar producción.
1. Diseña el destino, no solo la condición
Una regla está incompleta si únicamente dice “sede = Norte”. Debes definir a qué flujo y formulario irá la oportunidad, quién puede atenderla y cómo se manejarán los casos sin sede. En esta integración, el destino combina flujo y formulario; seleccionarlos conserva el contexto de datos que utilizará el CRM.
Antes de crear reglas, responde cuatro preguntas: ¿qué dato identifica el destino?, ¿quién lo obtiene?, ¿qué pasa mientras falta? y ¿qué persona revisa las excepciones? Si no hay una respuesta, la automatización trasladará una ambigüedad organizativa a la herramienta.
| Situación | Decisión prevista | Motivo |
|---|---|---|
| Contacto nuevo sin sede | Admisión general o solo contacto | Evitar adivinar la preferencia |
| Sede igual a Norte | Flujo Norte y su formulario | Atención del equipo correspondiente |
| Sede igual a Sur | Flujo Sur y su formulario | Mismo criterio para todos |
| Valor desconocido | Revisión por el equipo | No confundir “dato presente” con “dato correcto” |
Elegir “solo contacto” es útil cuando prefieres esperar una regla que determine destino. Elegir un flujo inicial es útil cuando un equipo general debe atender y completar la información. Ninguna alternativa es universal: depende de quién se hace cargo de los contactos incompletos.
2. Comprende la prioridad real de las reglas
Para crear una nueva oportunidad, el sistema considera primero la primera regla de campo que coincide. Si ninguna coincide, busca un destino por canal y, después, el predeterminado. Son alternativas para una decisión, no tres movimientos sucesivos.
El orden importa. Imagina que la primera regla dice “sede tiene algún valor” y la segunda “sede es igual a Norte”. Cuando llega Norte, la primera ya coincide; la segunda no se utiliza. Pon antes las condiciones específicas y reserva las generales para después.
La comparación “Es igual a” ignora mayúsculas y espacios en los extremos. Eso no transforma valores diferentes en sinónimos: “Norte”, “Sede Norte” y “Nte.” necesitan una convención coherente o reglas que contemplen esas variantes.
3. Asegura que el dato signifique lo mismo en ambos sistemas
El nombre visible de un campo puede parecer correcto y, aun así, el evento contener otra clave o valor. Identifica el campo que realmente recibe la integración y acuerda valores con el equipo que configura Respond.io. Cuando puedas, utiliza opciones consistentes en lugar de texto libre.
Ejemplo ficticio: el bot pregunta “¿En qué sede prefieres atenderte?” y registra “Norte”. El asesor no debería reemplazarlo por “por el norte” si la regla espera la opción exacta. La calidad de la derivación depende tanto de esa disciplina como de la condición configurada.
- Documenta clave de campo, valores esperados y destino de cada valor.
- Define qué hacer con “aún no decide”; no lo mezcles con una sede real.
- Comprueba que las actualizaciones posteriores se envíen mediante Contact Updated.
- No uses información sensible que no sea necesaria para elegir el equipo de atención.
Un evento de actualización no equivale a importar todos los contactos históricos. Diseña el recorrido a partir de la relación que la integración identifica y mantiene, no de la suposición de que cualquier cambio creará una oportunidad nueva.
4. Configura y revisa antes de activar
En la integración Respond.io de PerformLead, busca Alta automática y reglas de derivación. El manual incluye el detalle de cada control; aquí trabajaremos el criterio para elegirlos.
- Crear el contacto si no existe: decide si los nuevos ingresos deben crear una persona cuando no se encuentra una coincidencia identificable.
- Flujo inicial y formulario: elige un destino o “Solo contacto · esperar una regla que defina destino”.
- Destino inicial por canal: úsalo si el canal indica un equipo real de atención. No confundas el canal técnico con una sede que el cliente aún no eligió.
- Reglas por campos: agrega condiciones específicas, valores y destinos válidos; revisa el orden completo.
- Derivar al completarse o cambiar un campo: habilítalo solo si quieres mover las oportunidades elegibles cuando llegue esa información.
- Guardar y activar: hazlo con el plan de prueba y la revisión del administrador. Guardar reglas no reorganiza registros históricos.
Revisa después Últimas decisiones automáticas. Esa evidencia permite distinguir una regla que no coincide de una oportunidad protegida. “No se movió” no siempre significa que el sistema falló.
5. Protege la gestión que ya existe
Las derivaciones posteriores se aplican a oportunidades elegibles creadas y controladas por estas reglas, que siguen en gestión y no han sido trasladadas manualmente. El propósito es completar la clasificación automática, no sobrescribir una decisión comercial del equipo.
| Situación | Comportamiento que debes esperar |
|---|---|
| Oportunidad elegible y nueva sede coincidente | Puede trasladarse conservando su identificador e historial |
| Oportunidad cerrada, archivada o trasladada manualmente | Se protege frente a la derivación automática |
| Varias coincidencias de identidad u oportunidad | Se requiere revisión; no se elige al azar |
| Destino inválido | Hay que corregir la configuración |
| Sin ejecutivo elegible en el destino | Puede quedar sin asignación para revisión o distribución |
Destino y responsable son decisiones relacionadas, pero distintas. Revisa los accesos al flujo de destino y su modalidad de gestión. No prometas que cambiar de sede siempre conservará al mismo asesor: depende de que pueda operar en ese destino y de sus reglas de asignación.
6. Construye tu prueba de aceptación
Usa registros ficticios en una cuenta autorizada. Para cada caso conserva la configuración relevante, la decisión registrada y el identificador de la oportunidad antes y después. No publiques datos personales, tokens ni la URL privada del webhook en evidencias compartidas.
| Caso | Entrada | Resultado a comprobar |
|---|---|---|
| A | Nuevo contacto sin sede | Destino inicial previsto o solo contacto |
| B | Nuevo contacto con Norte | Primera regla específica correspondiente |
| C | Oportunidad elegible que informa Sur después | Mismo identificador, nuevo destino e historial conservado |
| D | Se repite un dato ya procesado | No aparece otra oportunidad por ese cambio |
| E | Oportunidad cerrada o movida manualmente | No hay traslado automático |
| F | Destino sin ejecutivo elegible | Excepción visible y revisión del responsable |
Ejercicio de diagnóstico
Has definido “sede tiene algún valor → General” antes de “sede es igual a Norte → Norte”. Llega el valor Norte, pero la oportunidad nueva va a General. Explica qué cambiarías y qué caso volverías a probar.
Ver solución razonada
La condición general coincidió primero. Coloca la regla de Norte antes de la condición general y prueba de nuevo con un registro autorizado. Revisa también Sur, un valor desconocido y el caso sin sede para que la corrección no altere los demás destinos.
¿Por qué borrar la sede no devuelve una oportunidad a General?
La oportunidad existente no utiliza el canal ni el predeterminado como retorno automático cuando no coincide una regla de campo. Esa protección evita movimientos involuntarios.
¿Guardar las reglas redistribuye todos los leads anteriores?
No. La configuración se aplica al procesamiento de eventos; no ejecuta una migración histórica masiva.
Entregable final: tu matriz de destinos, el orden de reglas, los resultados de A a F y el nombre del responsable de revisar excepciones. Si un caso no se ha probado, regístralo como pendiente en tu control interno.