Casi toda la conversación sobre tercerizar soporte trata el volumen como un dato del problema. Llegan tantos contactos al mes, se necesitan tantos agentes, el precio sale de multiplicar. Es una forma cómoda de plantearlo porque convierte una operación en una división, pero deja fuera la única pregunta que cambia la estructura de costos de verdad: ¿cuántos de esos contactos tenían que existir?
No es una pregunta retórica. En cualquier operación de soporte hay una parte del volumen que responde a la demanda legítima del negocio —el cliente compró, tiene una duda razonable, alguien la resuelve— y otra parte que es reparación: gente que escribe porque algo aguas arriba salió mal, porque la información que necesitaba no estaba donde debía, o porque ya escribió antes y nadie le cerró el caso. La segunda parte se puede bajar. La primera, no.
El contacto que no debería existir
Conviene nombrar los tipos, porque cada uno se ataca distinto y confundirlos lleva a soluciones que no muerden:
- Contacto evitable aguas arriba. El proceso, el producto o la comunicación previa generaron la duda. El soporte solo la recibe.
- Contacto repetido. El mismo usuario vuelve por el mismo asunto porque la primera respuesta no resolvió, no se entendió, o no hubo cierre.
- Contacto de seguimiento. El usuario pregunta en qué va algo que él no puede consultar por su cuenta.
- Contacto mal enrutado. Llegó a un canal o a un nivel que no puede resolverlo y tiene que moverse, generando trabajo en dos lugares.
- Demanda legítima. El resto.
Un tablero de operación normal no distingue entre estos cinco. Mide contactos, tiempo de respuesta, resolución. Todo eso puede verse impecable mientras la mitad del volumen es reparación de errores que nacieron en otra parte de la empresa.
Clasificar el motivo real, no la categoría de cierre
El obstáculo práctico es la taxonomía. Casi todas las operaciones cierran los casos con categorías que describen qué se hizo: "información suministrada", "caso escalado", "solicitud gestionada". Sirven para facturar y no sirven para nada más. Para reducir volumen hace falta registrar por qué el usuario escribió, con un nivel de detalle que permita rastrear la causa hasta el proceso que la produjo.
Eso implica una lista de motivos corta, mutuamente excluyente, escrita en el lenguaje del usuario y no en el del sistema, y revisada cada mes: los motivos nuevos aparecen y los que dejaron de ocurrir deben salir. Una taxonomía de sesenta opciones que nadie mantiene produce datos peores que no tener taxonomía, porque el agente elige la primera que encuentra.
Si el reporte mensual no puede responder "cuáles fueron los cinco motivos que más contactos generaron y qué área los origina", no hay nada que reducir todavía.
Cuatro palancas, en orden de dificultad
Con los motivos a la vista, las opciones no son infinitas. Son cuatro, y valen distinto.
1. Arreglar la causa. Es la única que elimina el contacto en lugar de moverlo. También es la que el proveedor no controla: si el volumen viene de un cobro confuso en la factura o de un mensaje ambiguo en el checkout, quien lo arregla es el cliente. El aporte del BPO es la evidencia: cuántos contactos, con qué texto, con qué costo asociado. Sin ese dato la conversación no pasa de anécdota.
2. Informar antes de que pregunten. Buena parte del contacto de seguimiento desaparece cuando el usuario puede ver el estado por sí mismo, o cuando se le avisa del retraso antes de que lo note. Es más barato que atender la pregunta y mejora la percepción, no la empeora.
3. Autoservicio real. Real quiere decir que el usuario termina la tarea, no que lee un artículo. Un centro de ayuda que explica cómo hacer algo que el usuario no puede hacer solo no reduce contactos: los retrasa y los vuelve más largos, porque llegan con frustración acumulada.
4. Resolver completo la primera vez. Aquí sí manda la operación tercerizada: cerrar el caso entero, incluida la duda siguiente que el usuario todavía no formuló. Depende de la calidad del material de trabajo y de cuánto puede decidir un agente sin escalar, que es un asunto de diseño de niveles de soporte y escalamiento, no de voluntad.
La automatización cruza las cuatro y no es una quinta palanca. Un agente de IA que responde una duda evitable sigue siendo un síntoma automatizado; sirve, pero conviene saber que la causa quedó intacta. La regla de qué automatizar y qué no ya la desarrollamos en automatización con IA en BPO.
El problema no es técnico, es de incentivos
Aquí está el nudo. Si el contrato se paga por hora o por agente, reducir el volumen reduce la facturación del proveedor. Nadie va a trabajar sistemáticamente para cobrar menos, y pedirlo por buena voluntad en la reunión mensual no cambia la aritmética.
Hay maneras de destrabarlo, todas explícitas en el contrato:
- Pagar el análisis de motivos y las recomendaciones como un entregable propio, separado de la atención.
- Comprometer capacidad, no volumen: el proveedor mantiene el equipo dimensionado mientras el volumen baja, y la reducción se traduce en más alcance o en nuevos procesos en lugar de en menos horas.
- Medir por resultado del proceso —casos resueltos, transacciones procesadas— en vez de por tiempo, con las cautelas de cada modelo que ya vimos en modelos de precio en BPO.
Ninguna es gratis y ninguna funciona si se deja implícita. Un contrato por hora con una cláusula de "mejora continua" sin entregable ni pago asociado es una declaración de intenciones.
Lo que no cuenta como reducción
Tres cosas se presentan como reducción de contactos y no lo son. Esconder el canal: quitar el teléfono o enterrar el formulario baja el número y sube el daño. Forzar el desvío al bot sin salida a humano: el contacto no desaparece, se acumula y reaparece peor. Y cerrar casos sin resolver para mejorar el indicador: eso crea contacto repetido, que es el más caro de todos porque se paga dos veces y deteriora la relación con el usuario.
Por eso la reducción se mide junto con la satisfacción y con la tasa de recontacto. Un volumen que baja mientras el recontacto sube no es una mejora, es un traslado.
Cómo lo hace smartBPO
Empezamos por la taxonomía: registramos el motivo por el que el usuario escribió, no la acción de cierre, y la revisamos cada mes para que siga describiendo la realidad. Con eso armamos un reporte de los motivos que más volumen generan, con el texto real de los casos y el área donde nace cada uno, y lo llevamos a la reunión de gobierno como un entregable, no como un comentario. Separamos lo que podemos resolver nosotros —resolución completa, enrutamiento, material de trabajo— de lo que solo el cliente puede arreglar aguas arriba, y lo decimos con esa claridad. Cuando el volumen empieza a bajar, preferimos conversar sobre alcance nuevo antes que sobre menos horas. No prometemos un porcentaje de reducción: proponemos medir el motivo, priorizar dos o tres causas por trimestre y mostrar el efecto junto con el recontacto y la satisfacción, para que la caída se pueda distinguir de un traslado.