“¿En qué sede te gustaría atenderte?” suele ser una pregunta que llega después del primer contacto. Para entonces, el lead ya ingresó, alguien pudo responderle y existe información que conviene conservar. Crear otro registro para enviarlo al equipo correcto puede fragmentar precisamente ese contexto.
Conectar Respond.io y PerformLead permite diseñar una clasificación progresiva: recibir la consulta con los datos disponibles y, cuando aparece una preferencia relevante, derivar la oportunidad elegible al destino configurado. La clave no es automatizar cualquier movimiento, sino saber cuáles deben ocurrir y cuáles deben respetarse.
El primer mensaje rara vez contiene toda la información
Una persona puede llegar desde un anuncio general y preguntar por un precio. Más adelante indica sede, programa o tipo de atención. Pedir todos esos datos antes de responder puede hacer la conversación pesada; ignorarlos cuando llegan deja al lead en un equipo que quizá no le corresponde.
Por eso conviene separar dos momentos: recibir y clasificar con más información. Recibir permite iniciar la atención. Clasificar permite especializarla. No debería ser necesario perder la identidad del caso para pasar de uno a otro.
Este enfoque es útil para organizaciones con distintas sedes, líneas de servicio o equipos de admisión. Si toda tu operación tiene un único destino y los mismos asesores, quizá no necesites reglas complejas: una configuración sencilla y un seguimiento consistente pueden ser suficientes.
Canal, campo y destino inicial no significan lo mismo
El canal identifica por dónde llega la interacción. Un campo como sede expresa una preferencia o dato del contacto. El destino inicial cubre los casos nuevos que todavía no tienen una condición más específica. Confundirlos puede llevar a tratar el origen técnico del mensaje como si fuera una elección del cliente.
Al crear una oportunidad, PerformLead prioriza la primera regla de campo coincidente; después considera el canal y, finalmente, el destino predeterminado. Para oportunidades existentes, el canal o el predeterminado no funcionan como retorno automático cuando deja de coincidir una regla de campo.
Esta diferencia evita un comportamiento poco deseable: que una oportunidad que ya llegó al equipo correcto vuelva al flujo general porque se vació un dato o llegó una actualización sin una condición aplicable.
Ejemplo: de recepción general a la sede elegida
Ejemplo ficticio para explicar el funcionamiento. Una organización atiende en Norte y Sur. Un contacto llega sin sede. La configuración permite crear su contacto y una oportunidad en Recepción general. El asesor pregunta por su preferencia y registra Norte en Respond.io.
Cuando se recibe la actualización, la regla “sede es igual a Norte” puede trasladar esa oportunidad elegible al flujo y formulario de Norte. Se conserva su identificador e historial; no hace falta crear otra oportunidad por ese cambio.
| Elemento | Antes | Después de una derivación elegible |
|---|---|---|
| Identidad de la oportunidad | El caso recibido | El mismo caso |
| Destino | Recepción general | Flujo y formulario de Norte |
| Información e historial | Contexto ya registrado | Se conservan y se registra el movimiento |
| Responsable | Asignación existente | Se revisa según acceso y gestión del destino |
También puedes optar por crear solo el contacto y esperar una regla que defina destino. La elección depende de tu operación: ¿hay un equipo general encargado de conversar mientras falta la sede, o prefieres generar la oportunidad después de obtenerla?
La automatización no decide esa política por tu negocio. Te permite aplicarla de manera consistente una vez que la has definido.
La mejor regla también sabe cuándo no intervenir
Un asesor puede haber trasladado manualmente una oportunidad por una razón válida. Un caso puede estar cerrado. Dos registros pueden coincidir con una identidad y requerir revisión. Forzar una acción en todos esos escenarios no hace la integración más inteligente; puede desordenar el trabajo.
Por eso la derivación posterior protege oportunidades cerradas, archivadas o movidas manualmente y se limita a las elegibles controladas por estas reglas. Las coincidencias ambiguas no se resuelven escogiendo al azar. Si el destino no tiene un ejecutivo elegible, la oportunidad puede quedar sin asignación para revisión.
Estas situaciones deben formar parte del procedimiento del equipo. Una excepción visible con un responsable de revisión es preferible a una asignación silenciosa que parece correcta, pero no lo es.
Tres errores que conviene evitar
- Reglas generales antes de las específicas: “sede tiene algún valor” puede coincidir antes que “sede es Norte”. El orden cambia el resultado.
- Valores inconsistentes: “Norte”, “Sede Norte” y una abreviatura no son automáticamente equivalentes. Acuerda un vocabulario.
- Destinos sin equipo: no basta con que exista el flujo. Revisa quién puede atenderlo y cómo se distribuye el trabajo.
Cinco decisiones antes de activar una derivación
- Define el dato decisivo. Elige la sede, servicio u otro campo que realmente determina el destino. No agregues condiciones porque están disponibles.
- Decide qué hacer cuando falta. Flujo inicial o solo contacto: ambas opciones necesitan un responsable operativo.
- Relaciona cada valor con un destino. Documenta el flujo y formulario, y revisa sus campos y accesos.
- Ordena las reglas. Prueba las condiciones específicas antes de las amplias y contempla valores desconocidos.
- Define cómo revisar excepciones. Determina quién revisará decisiones ambiguas, destinos inválidos y casos sin responsable.
Después, comprueba un recorrido completo con datos ficticios autorizados: ingreso sin sede, actualización a una sede, repetición del evento y un caso que deba permanecer protegido. Guardar una configuración no equivale a haber probado esos escenarios ni redistribuye automáticamente el histórico.
Si eres administrador, el manual de reglas y derivaciones te lleva a los controles concretos. Si estás diseñando el proceso, el curso de destinos por canal y sede incluye una matriz y una práctica con respuestas.
Evalúa si el lead llega al equipo correcto
El resultado no se mide solo contando movimientos. Un volumen alto de derivaciones puede reflejar una operación bien segmentada o una entrada inicial mal diseñada. Revisa una muestra de casos y pregunta si el destino fue el correcto, si se conservó el contexto y si hubo una siguiente acción.
| Pregunta | Evidencia que conviene revisar |
|---|---|
| ¿La regla eligió el destino esperado? | Valor recibido, orden de reglas y decisión registrada |
| ¿El caso siguió siendo el mismo? | Identificador e historial de la oportunidad |
| ¿El equipo pudo atenderlo? | Responsable, accesos y próxima acción |
| ¿Se respetó la gestión previa? | Casos cerrados o trasladados manualmente que permanecieron protegidos |
Si luego quieres medir mejoras, compara periodos equivalentes y conserva una línea base: volumen, equipos, horarios y mezcla de canales. No atribuyas cambios de conversión únicamente a las reglas sin considerar esas diferencias.
Preguntas frecuentes
¿Necesito una regla por cada canal?
No. Configura solo los destinos que respondan a una necesidad operativa. Puedes usar un destino inicial y reglas de campo más específicas.
¿Se crea una oportunidad nueva cada vez que cambia la sede?
No es el comportamiento previsto para una derivación elegible: se conserva la oportunidad y su historial. Los casos ambiguos o protegidos requieren el tratamiento correspondiente.
¿Se reasigna automáticamente todo el histórico?
No. Guardar las reglas no ejecuta una redistribución masiva de oportunidades anteriores.
¿Sirve únicamente para educación?
No. La lógica puede aplicarse a otros negocios cuyos campos y destinos permitan separar equipos. El diseño debe ajustarse a tus servicios y a cómo obtienes esos datos.
¿Tu operación tiene varias sedes o líneas de servicio? Cuéntanos cómo distribuyes tus consultas.