Muchas empresas piden un piloto porque no quieren firmar un contrato largo sin evidencia. Es una decisión sensata. El problema es que la mayoría de los pilotos se diseñan como una versión pequeña del servicio final, y eso no es una prueba. Una prueba tiene una pregunta, un criterio para responderla y una fecha en la que se responde.
Sin esos tres elementos, un piloto termina de la peor manera posible: cada parte con una impresión distinta del resultado y nadie con argumentos para cerrar la discusión.
Qué puede probar un piloto y qué no
Un piloto sirve para responder preguntas de ejecución. ¿El proceso se puede transferir con la documentación que existe hoy? ¿La calidad se sostiene cuando el trabajo lo hace alguien de afuera? ¿El equipo del cliente alcanza a resolver dudas al ritmo que la operación necesita? ¿Los tiempos de respuesta se cumplen con la dotación propuesta?
No sirve para responder preguntas de escala. Un piloto de dos personas no dice cómo se comporta una operación de veinte: cambia la supervisión, cambia la manera de repartir el trabajo, cambia el peso de una ausencia. Tampoco sirve para probar precio. En volúmenes pequeños el costo por unidad casi siempre se ve peor, porque la estructura no se reparte entre suficientes transacciones. Si la conversación del piloto gira alrededor de la tarifa, la pregunta está mal planteada; el precio se discute con el modelo de precio del contrato, no con la factura de un mes de prueba.
Un proceso completo, no un pedazo de varios
El error de alcance más frecuente es querer mostrarle al proveedor un poco de todo: algunas llamadas, algo de correo, un rato de back office. Se ve completo y no prueba nada, porque ninguna de las tres partes alcanza a estabilizarse.
Un piloto útil toma un proceso de punta a punta, con sus excepciones incluidas. Si se van a tercerizar solicitudes de servicio, el piloto incluye las que se resuelven fácil y las que se atascan esperando una respuesta de otra área. Esas segundas son las que revelan si el proceso es tercerizable o si en realidad depende de que alguien con diez años en la empresa sepa a quién llamar.
Un criterio práctico para elegir: el proceso con volumen suficiente para tener casos todos los días, con un resultado que se pueda verificar sin ambigüedad y sin ser el más crítico del negocio. El más crítico se transfiere después, cuando ya hay confianza.
La duración se define por ciclos, no por meses
Un piloto tiene que durar lo suficiente para que el equipo pase la curva de aprendizaje y todavía quede tiempo de medir en condiciones normales. En la práctica, eso implica tres tramos: formación y acompañamiento, operación con supervisión cercana, y operación en régimen. Solo el último tramo sirve para decidir.
Cortar el piloto durante la curva de aprendizaje es la forma más común de sacar la conclusión equivocada. Al inicio los tiempos son peores y los errores más frecuentes, no porque el equipo sea malo, sino porque está aprendiendo el criterio del cliente. Extenderlo indefinidamente tiene el problema opuesto: se convierte en un contrato informal, sin la estabilidad de dotación que da un acuerdo firmado, y la rotación empieza a jugar en contra.
Vale la pena también incluir en la ventana algún evento que se repita: un cierre de mes, un pico de campaña, un día de alta demanda. Un piloto que solo vio semanas tranquilas no probó la parte que importa.
El criterio de decisión se escribe antes de arrancar
Esta es la parte que casi nadie hace y la que determina si el piloto sirvió. Antes del primer día, las dos partes acuerdan por escrito qué resultado lleva a continuar, qué resultado lleva a ajustar y qué resultado lleva a no seguir.
Si el criterio de éxito se define después de ver los resultados, el piloto no decidió nada: solo dio material para defender la posición que cada uno ya tenía.
El criterio no tiene que ser un tablero completo. Tres o cuatro cosas bastan, y conviene que incluyan al menos una de calidad, una de cumplimiento de tiempos y una de autonomía: cuánto del trabajo se resolvió sin devolverlo al equipo del cliente. Esa última es la que mejor anticipa cómo se va a sentir la relación a los seis meses.
Lo que el cliente tiene que poner
Un piloto es un compromiso de dos lados y suele fallar por el lado que menos se planea. Antes de arrancar hacen falta accesos a los sistemas con los permisos correctos, una persona designada para responder dudas con tiempo real asignado a eso, el material de proceso que exista aunque esté incompleto, y los criterios con los que hoy se decide cuando un caso es dudoso.
Si esos criterios no están escritos en ninguna parte —lo habitual— el piloto empieza por levantarlos, y eso hay que contarlo como parte del trabajo, no como retraso del proveedor. Sobre qué reunir antes de arrancar escribimos aparte en qué documentar antes de tercerizar un proceso.
Cuatro cosas que vacían un piloto
- Darle solo los casos fáciles. Protege el resultado y no prueba nada. El piloto tiene que ver la mezcla real.
- Dejar el equipo interno haciendo el mismo trabajo en paralelo. Los casos se resuelven dos veces, nadie sabe qué midió y la operación queda peor que antes.
- Cambiar el alcance a mitad de camino. Cada cambio reinicia la curva de aprendizaje. Si es indispensable, se reinicia también la ventana de medición.
- No dedicar tiempo a resolver dudas. Un canal sin nadie del otro lado convierte cada caso dudoso en un caso pendiente.
Del piloto al contrato
Un piloto que salió bien no es un contrato. Al cerrarlo hacen falta tres cosas: pasar a un acuerdo con compromisos de servicio escritos, dimensionar la dotación para el volumen real —no multiplicar el equipo del piloto— y dejar documentado lo que se aprendió durante la prueba, porque es la mejor base de conocimiento disponible.
Ese cierre es, en la práctica, el arranque de la transición. Lo que sigue tiene su propia secuencia, y la describimos en qué pasa en los primeros 90 días.
Cuando el piloto no es el camino
Hay casos en los que pedir un piloto cuesta más de lo que aclara. Procesos con una curva de formación larga, donde ocho semanas apenas alcanzan para entrenar. Operaciones donde el volumen es tan bajo que el piloto no genera casos suficientes para concluir. Procesos con acceso a datos sensibles, donde habilitar accesos temporales implica más control del que justifica una prueba corta.
En esos casos suele funcionar mejor una alternativa: una transferencia por fases con puntos de revisión y una salida acordada en las primeras semanas. Es un compromiso mayor con la misma protección, y evita el peor de los mundos, que es un piloto demasiado corto para aprender y demasiado largo para no desgastar a nadie.
Dónde encaja smartBPO
Cuando arrancamos con un piloto dejamos escrito antes del día uno el alcance exacto, la ventana de medición, quién responde dudas de cada lado y el criterio con el que se va a decidir al final. Medimos por tramos para separar la curva de aprendizaje del régimen normal, y entregamos al cierre lo levantado del proceso, siga o no la relación. Un piloto tiene que dejar una decisión clara; si además deja el proceso mejor documentado de lo que estaba, valió la pena de todos modos.