Cómo distribuir consultas entre sedes sin perder seguimiento

Separa dónde llegó la consulta de dónde debe atenderse

Registra tres datos distintos: la página o canal de origen, la ubicación donde el cliente necesita el servicio y la sede finalmente asignada. No sustituyas uno por otro al hacer una derivación. Una página de Bogotá puede atraer una consulta para Medellín; eso no convierte a Bogotá en el lugar de prestación.

Pregunta por la ciudad del servicio cuando determine la cobertura. Si la persona puede elegir un local, muestra opciones comprensibles y permite indicar que necesita orientación. La ubicación de facturación o la residencia del contacto pueden ser diferentes del destino del trabajo.

Usa etiquetas claras, como “¿En qué ciudad necesitas el servicio?”, en lugar de un campo ambiguo llamado “Ubicación”. La guía de formularios de W3C explica cómo asociar etiquetas con los controles para que su propósito sea accesible. No necesitas pedir datos que no cambien la asignación.

Fuentes: W3C WAI: Labeling Controls: etiquetas accesibles en formularios

Decide las reglas antes de automatizar el reparto

La sede más cercana no siempre es la que puede atender: pueden cambiar el servicio disponible, la capacidad o el horario comercial. Define un orden de decisión y un destino para las excepciones. Estas son reglas operativas sugeridas, que cada empresa debe adaptar a su capacidad real:

• Cobertura: ¿qué sede atiende la ciudad o zona solicitada?
• Servicio: ¿esa sede ofrece lo que la persona necesita?
• Disponibilidad: ¿hay alguien que pueda asumir la consulta dentro del horario comunicado?
• Excepción: si ninguna sede encaja, ¿qué responsable revisa el caso y explica las alternativas?
• Reasignación: ¿quién conserva la responsabilidad hasta que el siguiente equipo acepta?

Utiliza una ficha breve que el siguiente equipo pueda entender

La ficha puede vivir en un CRM o, al principio, en un registro compartido con acceso restringido. Lo importante es que exista una referencia única por consulta y un historial de cambios. Este formato sirve como punto de partida; los campos entre corchetes se completan con información real:

• Consulta: [identificador único] · Recibida: [fecha y hora].
• Origen: [página o canal] · Ciudad solicitada: [ciudad del servicio].
• Necesidad: [servicio y breve contexto, sin datos innecesarios].
• Asignación: [sede] · Responsable: [persona o función con cobertura].
• Aceptación: [pendiente o confirmada, responsable y hora].
• Próxima acción: [qué se hará] · Vencimiento interno: [fecha y hora].
• Estado: [pendiente, en atención, cerrada con venta o cerrada sin venta].
• Reasignaciones y cierre: [motivo, fecha y responsable].

Conserva los datos de contacto en el sistema autorizado para atender al cliente, con acceso limitado a quienes los necesitan. No pegues conversaciones completas en reportes generales. Un identificador interno permite buscar el caso sin divulgar esos datos en cada resumen.

Haz que el traspaso termine con una aceptación

“Se lo envié a la sucursal” solo describe una acción del emisor. Para cerrar el traspaso, el receptor debe confirmar que tiene la información y que asume el siguiente paso. Hasta entonces, un responsable anterior o central mantiene el caso bajo seguimiento.

Ejemplo hipotético: una empresa con sedes en Bogotá y Medellín recibe la consulta C-104 desde su página de Bogotá. El cliente solicita un servicio en Medellín. Atención central verifica cobertura y lo asigna a la sede de Medellín, conservando Bogotá como página de origen.

El equipo receptor registra: “C-104 aceptada por atención comercial de Medellín a las 10:15. Próxima acción: confirmar el alcance solicitado antes de las 12:00”. Son horas ilustrativas, no un estándar ni una promesa de respuesta. Si la sede no puede asumirlo, informa el motivo y solicita reasignación; no deja que el caso desaparezca de su bandeja.

Al cliente se le explica quién continuará la conversación y para qué. Evita pedirle que vuelva a contar todo. Define también qué ocurre fuera de horario: confirmación de recepción, expectativa realista y responsable de revisar pendientes al abrir.

Mide el recorrido sin contar una derivación como una nueva oportunidad

Para la operación, cuenta consultas únicas y sus cambios de estado. Si C-104 pasa de Bogotá a Medellín, sigue siendo un caso. Mantén separados el origen que atrajo la consulta y la sede que la trabajó, para poder corregir tanto la captación como la atención.

Google Analytics recomienda eventos como generate_lead, qualify_lead y close_convert_lead para distintas etapas. La documentación oficial aclara que estos eventos requieren implementación y contexto: no aparecen por nombrar así una columna del CRM. Una consulta recibida tampoco demuestra por sí sola una venta.

El informe de adquisición de clientes potenciales utiliza usuarios únicos en sus métricas de etapas. Por eso, no esperes que coincida automáticamente con un registro que cuenta consultas: una persona puede enviar más de una. Reconciliar ambas fuentes requiere acordar qué representa cada unidad.

No envíes nombres, correos, teléfonos ni texto libre del formulario en URLs o parámetros de Analytics. Revisa la guía de Google para evitar información de identificación personal. Una revisión técnica de esa configuración es distinta del registro comercial que necesita el equipo para responder.

Fuentes: Google: Eventos recomendados de Google Analytics · Google: Informe Adquisición de clientes potenciales · Google: Evitar el envío de información de identificación personal a Analytics

Prueba las excepciones antes de dar el proceso por resuelto

Prepara casos de prueba identificados como tales, en un entorno de prueba o coordinados con los responsables para que no se confundan con oportunidades reales. Comprueba el recorrido completo, no solo el mensaje de confirmación de la web.

• Una consulta para una sede concreta llega al equipo correcto y conserva su origen.
• Una ciudad fuera de cobertura tiene un responsable y una respuesta prevista.
• Un caso recibido fuera de horario queda visible para el siguiente turno.
• Una reasignación conserva el contexto, el historial y una sola referencia.
• El vencimiento de una aceptación pendiente genera una revisión interna.
• El cierre indica un resultado real; enviar una cotización no se registra como venta.

Empieza por revisar los pendientes sin responsable y los traspasos sin aceptación. Después observa por qué se reasignan y qué información falta. Ese diagnóstico permite decidir si hace falta ajustar el formulario, las reglas, la capacidad de atención o una integración.