Conectando CallRail → GoHighLevel → Clio con lógica de enrutamiento real (no solo webhooks)
La mayoría de los sistemas de admisión de bufetes de abogados que he visto están unidos con cinta adhesiva: un número de seguimiento de CallRail suena en algún lugar, se crea un contacto en GHL si se recuerda conectar el webhook, y un asistente legal finalmente vuelve a escribir el asunto en Clio a la mañana siguiente. El resultado es una fuga de información: el idioma del llamante, la atribución de la fuente y el contexto de calificación se pierden entre sistemas. Esta publicación describe el flujo de trabajo de producción en funcionamiento en Vasquez Law Firm — 4 oficinas, áreas de práctica diversas, base de llamantes bilingüe — y la lógica de enrutamiento que lo hace funcionar de principio a fin. No es la lógica de una página de marketing de proveedor. Son las reglas que ajustamos en producción después de que las llamadas en vivo fallaran de maneras que no habíamos anticipado.
El flujo de trabajo general
Las llamadas entrantes llegan a los números de seguimiento de CallRail (uno por oficina, uno por campaña de área de práctica principal). CallRail reenvía la llamada a un punto final SIP que llega a nuestro agente de voz basado en LiveKit. Tan pronto como el agente ha capturado la preferencia de idioma y la intención, un webhook se activa en GoHighLevel — creando o haciendo coincidir un contacto, abriendo una oportunidad en el flujo de trabajo correcto. El agente continúa la calificación (tipo de asunto, urgencia, conflictos), y al finalizar, un flujo de trabajo de n8n traduce la oportunidad de GHL en un asunto de Clio con el subtipo correcto, campos personalizados y atribución de fuente. Todo el ciclo se ejecuta sin intervención humana para admisiones típicas. Los humanos se involucran en la consulta o antes cuando el agente escala.
Por qué Zapier no fue suficiente
Nuestra primera versión usó Zapier como el pegamento. Funcionó para el escenario ideal: entra una llamada, se crea un contacto, el asunto finalmente aparece en Clio. Falló de tres maneras que resultaron ser críticas: (1) El precio por 'zap' de Zapier escaló mal cuando agregamos enrutamiento específico por idioma, subflujos por área de práctica y verificaciones de conflictos — cada condicional era su propio 'zap'; (2) el manejo de errores era opaco — cuando un 'zap' fallaba a las 11 p.m., nos enterábamos a la mañana siguiente que faltaban asuntos para 6 llamadas; (3) compartir el estado entre pasos era incómodo — pasar la preferencia de idioma + área de práctica + resultado de la verificación de conflictos a través de una cadena de 'zaps' resultaba costoso en llamadas a la API y frágil en reintentos.
Migramos a n8n autoalojado en 6 semanas. La ventaja fue menos sobre el costo (aunque es más barato a nuestro volumen) y más sobre la capacidad de depuración. Cada ejecución del flujo de trabajo es inspeccionable, reintentable y controlada por versiones. Cuando una llamada de un martes por la mañana termina siendo enrutada incorrectamente, podemos reproducir el flujo de trabajo con las entradas exactas y ver dónde la lógica eligió la rama incorrecta.
Reglas de enrutamiento que realmente importan
Lo primero que le importa a la capa de enrutamiento es el idioma. Si el llamante habló español en la llamada con el agente, cada paso posterior utiliza el español: la etiqueta del flujo de trabajo de GHL, el idioma de las notas del asunto de Clio, el SMS de confirmación de consulta. Esto suena obvio; no es como la mayoría de los proveedores prefabricados lo manejan. La mayoría trata el idioma como una rama de enrutamiento (cola en inglés vs. cola en español) en lugar de como una propiedad del asunto en sí. Necesitábamos que fuera una propiedad — porque el mismo bufete maneja el asunto y el llamante bilingüe continuará interactuando en su idioma preferido a través de correos electrónicos, seguimientos y consultas.
Segundo es el área de práctica. Cada oficina tiene una combinación diferente. Charlotte tiene mucha inmigración y PI; Smithfield tiene más PI y derecho de familia; Orlando tiene más PI e inmigración. Enrutar por oficina sin considerar el área de práctica significa que una llamada de inmigración a Smithfield termina con el abogado de guardia equivocado. El agente captura explícitamente el tipo de asunto durante la admisión, y el flujo de trabajo de n8n usa eso — no la oficina del número de seguimiento — para asignar el asunto.
Tercero es la urgencia. Una admisión de defensa criminal que menciona un arresto dentro de las 24 horas, una llamada de inmigración que menciona una Notificación de Comparecencia, o una llamada de derecho de familia que revela violencia doméstica activa una ruta inmediata al móvil del abogado de guardia, no a una cola. El agente no decide esto por sí mismo a partir de la comprensión del lenguaje natural en bruto; tenemos reglas de patrones explícitas — el agente marca ciertas entidades (NTA, master calendar, in-custody, DV) y la capa de enrutamiento reacciona. Fue mejor codificar esto que intentar inferir la urgencia a partir del sentimiento.
- ✓La preferencia de idioma del llamante es una propiedad del asunto, no una rama de enrutamiento
- ✓El área de práctica impulsa el enrutamiento, no la oficina que recibió el número de seguimiento
- ✓La urgencia se detecta mediante indicadores de entidad explícitos, no por inferencia de sentimiento
- ✓Las verificaciones de conflictos se ejecutan ANTES de que se reserve la consulta, no después
- ✓La atribución de la fuente (campaña, número de seguimiento, URL) fluye a los campos personalizados del asunto de Clio
Verificación de conflictos antes de la reserva de consulta
Este fue el cambio que más importó para la confianza en las reglas éticas. El flujo original reservaba la consulta primero y ejecutaba la verificación de conflictos durante la noche como un proceso separado. Eso significaba que en raras ocasiones tendríamos que volver a llamar a un cliente para cancelar — una mala experiencia y un riesgo pequeño pero no nulo. Ahora el agente recopila los nombres de ambas partes (cuando corresponda — divorcio, derecho de familia, penal con múltiples acusados) y una búsqueda en Clio se ejecuta sincrónicamente contra los registros de clientes y asuntos existentes antes de que el agente ofrezca un espacio para consulta. Si se encuentra un conflicto, el agente recopila la información de contacto pero ofrece un seguimiento por escrito en lugar de una consulta, y el asunto se marca para revisión humana.
Atribución de fuente que perdura
El valor de CallRail sobre un proveedor de telefonía genérico es la capacidad de atribuir una llamada a una campaña, anuncio o página de destino específica. Solíamos perder esa atribución para cuando el asunto estaba en Clio — quedaría en un informe de CallRail que nadie abría. Ahora los datos de sesión de CallRail (campaña, fuente, medio, página de destino, palabra clave de búsqueda si está disponible) fluyen a través de GHL hacia el asunto de Clio como campos personalizados. Cuando revisamos las victorias por fuente trimestralmente, los datos están en el mismo sistema que los resultados de los asuntos. El cálculo del ROI se vuelve posible.
Qué falló durante la implementación
Tres cosas fallaron que quiero señalar para cualquiera que siga este camino. Primero: condiciones de carrera en la creación de contactos. Si dos llamadas entraban para el mismo llamante en cuestión de segundos (lo cual sucede — el llamante cuelga e inmediatamente vuelve a marcar), GHL crearía dos contactos y terminaríamos con asuntos divididos. Solución: clave de idempotencia en la creación de contactos, derivada del número de teléfono + área de práctica + ventana de 5 minutos.
Segundo: límites de tasa de la API de Clio. Los alcanzamos una vez durante un pico de tráfico impulsado por el marketing y los asuntos comenzaron a fallar en su creación. La lógica de reintento de n8n ahora usa retroceso exponencial con 'jitter', y tenemos una cola de respaldo para asuntos que no pueden crearse en tiempo real — se crean dentro de 15 minutos cuando la API tiene capacidad. Nunca hemos perdido un asunto por esto desde entonces.
Tercero: confusión de zonas horarias en la programación. El agente funciona en UTC; las oficinas están en la zona horaria del Este; algunos abogados viajan y quieren consultas en su hora local. Estandarizamos el almacenamiento de cada marca de tiempo en UTC + el almacenamiento de la zona horaria de la oficina y del abogado por separado, y la representación en la zona apropiada para el consumidor (correo electrónico de confirmación de consulta, invitación de calendario, etc.). Vale la pena hacerlo desde el primer día si estás construyendo esto.
