Tercerizar un proceso que solo vive en la cabeza de alguien no es tercerizar: es mudar una dependencia de un escritorio a otro edificio. El proveedor recibe una caja negra, la abre a fuerza de preguntas, y las primeras semanas se van en reconstruir lo que nunca se escribió. La transición se siente lenta y torpe, y casi siempre la culpa se reparte mal: no es que el equipo nuevo no entienda, es que nunca hubo un documento que entender.
Documentar antes de tercerizar no es burocracia. Es lo que convierte "cómo lo hace Marta" en "cómo se hace el proceso". Esa diferencia decide si la operación arranca en semanas o en meses, y es lo primero que conviene tener listo, incluso antes de pedir una cotización.
Por qué la documentación decide la transición
Cuando un proceso está documentado, la transición tiene contra qué comparar: el proveedor ejecuta, mide lo que hace contra lo que estaba escrito y ajusta la diferencia. Cuando no lo está, la transición se convierte en un ejercicio de arqueología —desenterrar el conocimiento a base de preguntas sueltas— y el arranque hereda todos los vacíos de golpe. La documentación no acelera la transición porque sí; la acelera porque elimina la etapa de adivinar (qué pasa en los primeros 90 días de una transición a BPO).
Qué documentar, y en qué orden
No todo pesa lo mismo. Estos son los siete bloques que de verdad cambian el arranque, ordenados por lo que más duele cuando falta.
1. El objetivo, no solo los pasos
Un instructivo dice qué botones apretar. No dice para qué. Y sin el para qué, la primera excepción deja al equipo paralizado, porque no tiene con qué decidir. Documentar el objetivo del proceso —qué problema resuelve y qué cuenta como resolverlo bien— es lo que permite que alguien nuevo actúe con criterio cuando el caso se sale del molde, en lugar de escalar todo o inventar.
2. El flujo normal y las excepciones
El flujo normal es la parte fácil de escribir y la que menos problemas da: si el caso es típico, casi cualquiera lo resuelve leyendo el paso a paso. El día uno se rompe en las excepciones. Documenta las que ya conoces, pero sobre todo deja escrito qué se hace cuando aparece una que no está en la lista: a quién se le pregunta y en cuánto tiempo. Un proceso sin ruta para lo inesperado convierte cada rareza en un cuello de botella.
3. Las reglas de decisión
Todo proceso tiene puntos donde alguien decide: aprobar o rechazar, escalar o resolver, esperar o actuar. Esas reglas suelen vivir en la cabeza de quien lleva años haciéndolo, y se sienten "obvias" solo porque las repitió mil veces. Escribir el criterio —no el resultado de un caso, sino la regla que lo produjo— es lo que permite que otra persona decida igual sin tener esos mil casos encima.
4. Los sistemas, accesos y credenciales
Qué herramientas toca el proceso, en qué orden, con qué permisos y quién los otorga. Un proceso puede estar perfectamente documentado y detenerse el día uno porque nadie pidió los accesos con tiempo, o porque el permiso lo da un área que ni siquiera sabía del proyecto. Esto no es un detalle técnico menor: es la causa más tonta y más frecuente de un arranque trabado.
5. Los puntos de contacto y el escalamiento
Con quién habla el proceso hacia adentro y hacia afuera, y a quién se escala cuando algo no se puede resolver en el nivel donde entró. Un mapa de escalamiento con nombres de rol —no de personas— y tiempos esperados evita que cada excepción termine como un correo perdido esperando una respuesta que nadie sabe que debe dar.
6. El tratamiento de datos personales
Si el proceso toca datos personales —y casi todos lo hacen—, hay que dejar por escrito qué datos se tratan, con qué finalidad y bajo qué límites. En Colombia, la Ley 1581 distingue entre el responsable del tratamiento —normalmente el cliente, dueño de la relación con el titular— y el encargado, que trata los datos por cuenta del responsable y bajo sus instrucciones, que suele ser el proveedor. Esa distinción cambia obligaciones y responsabilidades, y conviene dejarla clara antes de mover un solo registro. Es un encuadre general, no asesoría legal: cada caso concreto debe revisarse con el área jurídica.
7. Cómo se sabe que salió bien
La definición de "hecho correctamente" es la que más se da por sentada y la que más se interpreta distinto. Si no está escrita, el proveedor optimiza lo que puede medir y el cliente reclama lo que imaginaba, y ninguno de los dos está equivocado desde su lado. Definir qué es calidad —y cómo se comprueba, idealmente sobre una muestra auditada y no sobre autorreporte— es lo que después permite firmar un compromiso de servicio que se pueda cumplir (cómo escribir un SLA que se cumpla).
El error opuesto: documentar de más
Sobredocumentar también falla, y de forma más silenciosa. Un manual de doscientas páginas que nadie mantiene envejece peor que no tener nada, porque da una falsa sensación de control: todos creen que la respuesta está "en el documento" hasta que alguien la busca y descubre que describe una versión del proceso que ya no existe. La regla práctica es documentar lo que se repite y lo que cuesta caro equivocarse. Lo raro y de bajo riesgo puede aprenderse sobre la marcha; escribirlo con el mismo detalle que el núcleo solo diluye lo que importa.
La documentación es un entregable vivo
El proceso cambia: aparecen casos nuevos, cambian las reglas, se ajusta una herramienta. Un documento que se escribió una vez y se archivó deja de describir la realidad a los pocos meses, y a partir de ahí engaña más de lo que ayuda. Por eso parte de la transición no es solo entregar la documentación, sino acordar quién la mantiene y con qué frecuencia se revisa. La documentación viva es la que refleja cómo se hace el proceso hoy, no cómo se hacía el día que se firmó el contrato.
Cómo lo trabaja smartBPO
Antes de tomar un proceso lo levantamos con quien hoy lo ejecuta: objetivo, flujo normal, excepciones, reglas de decisión, sistemas y accesos, escalamiento y definición de calidad, y dejamos claro el tratamiento de datos antes de mover un registro. No prometemos una transición instantánea ni un manual perfecto desde el primer día; proponemos entender el proceso lo suficiente para ejecutarlo sin adivinar, y mantener esa documentación al día a medida que la operación la corrige. Un proceso bien documentado no garantiza que la transición sea fácil, pero una transición sin documentar casi garantiza que sea difícil.