Tiempo de respuesta del cliente potencial: una guía práctica para un seguimiento mejor y más rápido

El tiempo de respuesta es un problema de diseño operativo.

Por lo general, las personas notan el tiempo de respuesta del cliente potencial solo cuando algo sale mal: un mensaje de voz que nadie posee, un formulario de notificación que se envía a un ex empleado, un acuse de recibo que solicita detalles ya proporcionados o una solicitud de reserva que se ofrece antes de que se entienda la solicitud. Estos no son simplemente problemas de mensajería. Revelan brechas entre un punto de contacto de cara al cliente y el trabajo interno necesario para dar un próximo paso creíble.

Los frecuentemente citados Discusión de Harvard Business Review sobre oportunidades de ventas en línea Es un contexto anterior útil que explica por qué los equipos examinan los retrasos en el manejo de clientes potenciales en línea. No debe tratarse como un objetivo universal actual para una empresa de servicios, un flujo de trabajo basado en llamadas o cualquier tipo de consulta. Un estándar defendible depende de lo que llega, cuándo llega, quién puede actuar, qué información está disponible y qué solicitudes necesitan un juicio antes de una respuesta.

Comience con una pregunta más útil: Cuando una persona se comunica con nosotros a través de este canal, ¿qué debe ser cierto antes de que consideremos que la respuesta está completa? Para un formulario básico, eso puede significar que la solicitud se registra, la persona recibe un acuse de recibo que refleja la categoría enviada y el propietario tiene la siguiente acción. Para una llamada perdida, puede significar que la llamada está clasificada, se selecciona una ruta de respuesta aprobada y el propietario de la devolución de llamada es visible. Para una solicitud de un cliente existente, puede significar que el mensaje se envía al servicio de atención al cliente en lugar de ser tratado como un nuevo cliente potencial de ventas.

Esto hace que el equipo pase de medir una única marca de tiempo a auditar una cadena corta de responsabilidad. También hace visibles las compensaciones. Una cola con personal puede ofrecer una revisión rápida. Es posible que un equipo pequeño deba acusar recibo e indicar una ventana de devolución de llamada veraz. Puede ser más seguro enviar una solicitud sensible, urgente o ambigua para que la revise una persona que enviar un mensaje genérico pulido.

Defina el reloj de respuesta antes de medirlo

Un informe de tiempo de respuesta se vuelve engañoso cuando diferentes personas inician o detienen el reloj de manera diferente. Antes de seleccionar un objetivo, defina los eventos que importan. El punto no es crear más informes; es hacer visible una promesa incumplida, una transferencia silenciosa o una conversación sin dueño.

No fuerces que todas las rutas utilicen el mismo evento final. Un simple reconocimiento puede ser suficiente para un formulario fuera de horario si describe con sinceridad el siguiente paso de revisión. No es suficiente si el reconocimiento afirma que una persona se comunicará con el líder inmediatamente cuando no haya ningún propietario de servicio. Para una solicitud de reserva, la respuesta puede estar incompleta hasta que la solicitud se confirme o se ponga en proceso de revisión. Para un problema de un cliente existente, el resultado correcto puede ser una cola de servicio en lugar de una conversación de ventas.

Mantenga las marcas de tiempo cerca del trabajo. Si un sistema recibe un formulario y otro sistema retiene al propietario, la auditoría necesita una forma de conciliarlos. Si una persona puede responder desde una bandeja de entrada personal sin ningún registro compartido, decida si esa ruta está dentro del alcance o está explícitamente excluida. Una ruta excluida no es fija; es simplemente un punto ciego conocido que debe mencionarse antes de que alguien reclame cobertura total.

Construir el estándar de respuesta en torno a canales, cobertura y excepciones.

Un estándar de respuesta es un acuerdo interno sobre un conjunto de decisiones repetibles. Debe ser lo suficientemente específico para ejecutarse en un día ajetreado y lo suficientemente modesto como para que el equipo pueda conservarlo. Los cuatro componentes básicos que aparecen a continuación son más útiles que una sola declaración amplia como "contactar a todos los clientes potenciales rápidamente".

1. Nombra cada vía de admisión

Enumere todas las rutas que pueden crear una nueva consulta o una obligación de seguimiento significativa: formularios de sitios web, llamadas entrantes, llamadas perdidas, solicitudes de reserva directa, chat web, referencias, mensajes del mercado, respuestas de correo electrónico y entradas manuales. Luego, separe los nuevos prospectos de los clientes, socios, candidatos a puestos de trabajo, proveedores y otras solicitudes existentes. Si una ruta atiende a más de una audiencia, la primera decisión puede ser la clasificación, no la calificación.

Para cada ruta, registre el evento de origen que se puede recuperar más adelante. Un formulario puede tener un ID de envío. Una llamada puede tener una marca de tiempo y un número de persona que llama. Una referencia manual puede necesitar el nombre de la persona que creó el registro. Evite confiar en la memoria, las capturas de pantalla o una bandeja de entrada personal como única evidencia de que llegó una pista.

2. Especificar contexto mínimo útil

El contexto mínimo no es un cuestionario de admisión largo. Es el conjunto más pequeño de información necesario para tomar la siguiente acción responsable. Para una consulta de servicio, eso podría incluir la categoría de solicitud, la preferencia de contacto y la ubicación cuando el área de servicio cambia de ruta. Para una solicitud B2B, puede incluir el objetivo indicado y el canal de seguimiento preferido. Para un cliente existente, el contexto de cuenta o trabajo puede ser más útil que un campo de puntuación de nuevos clientes potenciales.

el Orientación de Nielsen Norman Group sobre formularios de sitios web Es útil aquí como contexto de usabilidad: recopilar información deliberadamente, hacer que los requisitos sean comprensibles y evitar que las personas trabajen con formularios poco claros. No establece que una cantidad particular de campos, cadencia de mensajes o velocidad de respuesta producirán un resultado comercial particular. Trate los campos de su ingesta como opciones operativas que merecen revisión.

3. Asigne el primer propietario responsable

Un propietario puede ser una persona designada, una función de servicio o una cola supervisada con una regla de transferencia. “El equipo” normalmente no es suficiente. La persona que revisa la cola debería poder ver lo que posee a continuación, y la persona que recibe una transferencia debería poder ver por qué se envió la solicitud. Si el propietario cambia fuera de horario, anote los límites. Si no hay nadie disponible, conviértalo en una sucursal veraz, no en una promesa tácita.

4. Defina rutas de excepción antes de que sean necesarias.

Las excepciones no son fallas del estándar. Son aquellas solicitudes para las cuales la norma debería deliberadamente hacer algo diferente. Los ejemplos incluyen lenguaje relacionado con la seguridad o la emergencia, solicitudes fuera del alcance de la organización, disputas de cuentas o pagos, un problema con un cliente existente, información contradictoria, una solicitud de criterio profesional, una persona que solicita no ser contactada o un mensaje sin contexto suficiente para elegir una ruta. El método de respuesta debe decir qué está permitido, qué debe detenerse y quién decide a continuación.

Utilice este árbol de decisión de enrutamiento en la configuración

Ejecute este árbol de decisión para cada ruta entrante. Es intencionalmente operativo en lugar de específico para un producto. Las palabras de la respuesta deben coincidir con la rama real seleccionada.

Este árbol evita un error común: tratar la "respuesta enviada" como la línea de meta. Una respuesta que lleva a una persona a la cola equivocada, crea trabajo duplicado o fuerza una segunda explicación puede ser rápida en un tablero y pobre en la práctica.

• ¿Se puede identificar y registrar la señal? En caso negativo, cree una ruta de conciliación o de entrada manual antes de prometer un estándar para ese canal. En caso afirmativo, conserve el evento fuente y el contexto original.
• ¿La solicitud es claramente una nueva consulta, una solicitud de un cliente existente u otra audiencia? Si no está claro, diríjalo a una cola de revisión en lugar de aplicar una secuencia de clientes potenciales genérica.
• ¿La solicitud contiene una señal de parada brusca? Los ejemplos incluyen una solicitud que necesita un juicio humano inmediato, una inquietud sobre privacidad o preferencia de contacto, o una situación que el equipo ha decidido que no debería recibir una respuesta automática. En caso afirmativo, utilice la ruta humana documentada y no haga promesas excesivas.
• ¿El contexto existente respalda una próxima acción segura? En caso afirmativo, acuse recibo, preserve el contexto y ofrezca esa acción. En caso negativo, haga solo la pregunta que cambia la ruta o ponga en cola la solicitud de revisión.
• ¿Es apropiada una invitación de reserva ahora? Ofrézcalo solo cuando el tipo de trabajo solicitado, el propietario y las reglas de preparación lo respalden. De lo contrario, ofrezca una ventana de devolución de llamada, una ruta de revisión u otro próximo paso veraz.
• ¿Puede el próximo propietario ver la solicitud original y la sucursal seleccionada? Si no, el traspaso no está listo. Repare el registro antes de ampliar el flujo de trabajo.

Artefacto del operador: Estándar de respuesta del canal y hoja de muestreo

Utilice la hoja de trabajo a continuación para cada ruta durante la configuración. Es copiable por diseño. No es un punto de referencia, un SLA, una promesa pública ni una prueba de los resultados del cliente. Los equipos pueden comenzar con una única ruta de alto volumen o alto riesgo y luego agregar otras después del primer ciclo de revisión.

Cómo samplear sin inventar una historia de actuación

Seleccione una muestra pequeña y documentada de registros completos e incompletos de una ruta. No es necesario que la muestra demuestre un resultado universal. Es una forma de encontrar defectos operativos. Registre el período de revisión, cómo se seleccionaron los registros, qué se excluyó y si el sistema fuente estaba disponible. Luego inspeccione cada registro según el estándar.

Después de la muestra, agrupe las lagunas por causa en lugar de culpar a un propietario de registro individual. Las categorías comunes incluyen contexto de origen faltante, propiedad de la cola poco clara, un límite de cobertura que nunca se documentó, un registro duplicado, un script desactualizado, un enlace de reserva utilizado demasiado pronto o una solicitud que debería haberse excluido de la ruta. Repare la causa, pruebe la ruta modificada y registre lo que cambió. No publique una tasa, mediana o afirmación de mejora hasta que el equipo tenga su propio conjunto de datos definido y un método apropiado para comparar períodos.