El paso a una persona: diseñar el relevo en un proceso automático

Ningún proceso se automatiza al cien por ciento, así que todo proceso automatizado tiene un punto donde pasa a una persona. Ese relevo casi nunca se diseña, y es exactamente donde se pierde el beneficio que la automatización había conseguido.

A continuación: por qué el relevo se descuida, cuándo debe ocurrir, qué debe llevar consigo y cómo se mide.

La escena la reconoce cualquiera que haya sido cliente. Un sistema atiende la solicitud, avanza un tramo, y al llegar al límite de lo que puede resolver transfiere a una persona que pregunta todo otra vez.

Desde dentro parece un detalle de implementación. Desde fuera anula el trabajo previo: el cliente concluye que el sistema le hizo perder tiempo antes de llevarlo a donde debía haber empezado.

Por qué el relevo se descuida

Porque el proyecto se define por lo que automatiza. El indicador que se presenta es el porcentaje de casos resueltos sin intervención, y ese número mejora sin que nadie mire qué ocurre con el resto.

Además, el camino automático es el que se prueba. Los casos que salen del flujo son, por definición, los menos frecuentes y los menos ensayados, así que llegan a producción con el diseño menos maduro.

Y hay un incentivo silencioso: reconocer que un caso necesita una persona se siente como una limitación del proyecto, cuando en realidad es una decisión de diseño legítima.

Cuándo conviene pasar a una persona

Cuando la confianza es baja. Si el sistema no está razonablemente seguro de haber entendido, insistir produce peores resultados que transferir. El umbral es un parámetro de negocio, no un detalle técnico.

Cuando la consecuencia es alta. Un error recuperable admite que el sistema decida; uno que afecta dinero, salud o cumplimiento merece confirmación humana aunque la confianza sea alta.

Cuando el caso se sale del patrón. Una excepción legítima no debería forzarse dentro del flujo. Reconocerla temprano y transferirla es mejor que intentar resolverla y fallar tarde.

Cuando la persona lo pide. Un cliente que pide hablar con alguien está entregando información sobre su estado. Ignorarlo para preservar la estadística de automatización cambia un indicador interno por una relación.

Qué debe llevar el relevo

El principio es simple: la persona que recibe debe empezar donde el sistema llegó, no desde cero.

Eso significa trasladar el historial completo de la interacción, los datos ya verificados, lo que el sistema intentó y el motivo concreto de la transferencia. Sin el motivo, quien recibe repite el diagnóstico.

También significa no volver a pedir lo entregado. Si el cliente ya se identificó y ya explicó su caso, solicitarlo otra vez comunica que el sistema y la persona no se hablan, que es lo que el cliente sospechaba.

Y conviene trasladar el contexto de sentimiento cuando existe: saber que la conversación viene tensa cambia cómo la persona la retoma.

Lo que exige criterio

El umbral de transferencia se ajusta con la operación, no se acierta al diseñar. Empezar conservador —transferir antes— y ajustar con evidencia produce mejor resultado que empezar ambicioso y corregir tras las quejas.

También hay que decidir qué ocurre cuando no hay nadie disponible. Un relevo diseñado para horario laboral que se dispara de madrugada necesita una respuesta prevista, y no el silencio.

Y conviene revisar los relevos periódicamente. Los motivos de transferencia más frecuentes son el mejor mapa de qué automatizar después, porque describen lo que el sistema todavía no resuelve pero se le pide a diario.

Cómo se mide

El indicador de automatización por sí solo empuja en la dirección equivocada: premia retener casos que deberían transferirse.

Conviene acompañarlo de la resolución en el primer contacto, incluyendo los casos transferidos. Esa medida trata al sistema y a la persona como un solo servicio, que es como lo experimenta el cliente.

Y un tercero, más revelador: cuántas veces la persona que recibe tiene que volver a pedir información que el sistema ya tenía. Si ese número no es cercano a cero, el relevo está mal construido por más que el resto funcione.

Qué se necesita antes

Un catálogo de motivos de transferencia acordado y un canal técnico que traslade el contexto completo. Sin lo segundo, el relevo se hace con lo que la persona alcance a leer en pantalla.

Conviene además decidir desde el inicio que el relevo es parte del alcance del proyecto y no una tarea posterior. Cuando se deja para después, se implementa con prisa y con lo que quede de presupuesto.

Los dos relevos que conviene distinguir

No todos los relevos son iguales, y tratarlos igual es parte del problema.

El relevo planificado es el que el diseño previó: el caso llega a un punto donde siempre interviene una persona, como una aprobación o una excepción conocida. Se puede preparar, se puede medir y quien recibe sabe qué esperar.

El relevo por fallo ocurre cuando el sistema no logra avanzar y no estaba previsto que ocurriera. Es el que llega sin contexto, el que frustra y el que conviene contar por separado, porque su número dice cuánto le falta al diseño.

Mezclar ambos en una sola estadística oculta justamente la información útil: un proceso puede tener muchos relevos y estar bien construido, o pocos y estar fallando en silencio.

¿Un proceso bien automatizado no debería evitar el relevo?

No. Todo proceso tiene casos que exigen criterio, y reconocerlos temprano es una decisión de diseño, no una limitación del proyecto.

¿Cuál es el error más común?

Transferir sin contexto. La persona que recibe empieza de cero y el cliente concluye que el sistema le hizo perder tiempo.

¿Qué indicador conviene usar?

La resolución en el primer contacto incluyendo los casos transferidos, en lugar del porcentaje de automatización aislado. El segundo premia retener casos que deberían pasar a una persona.

¿Para qué sirven los motivos de transferencia?

Son el mejor mapa de qué automatizar después: describen lo que el sistema todavía no resuelve y que se le pide todos los días.