Cómo documentar un proceso en 30 minutos (plantilla incluida)

Llevas semanas diciéndote que hay que documentar los procesos. Lo sabes. Tu equipo lo sabe. Y sin embargo, el proceso de onboarding de clientes sigue viviendo en la cabeza de Paula, el proceso de respuesta a soporte depende de que Carlos esté disponible, y el último sprint se perdió media jornada buscando cómo se hacía aquella cosa que alguien hizo en marzo.

Documentar no es burocracia. Es recuperar tiempo.

Lo que vas a aprender en este artículo:

• Por qué documentar un proceso no significa escribir un manual de 10 páginas (y por qué ese miedo es lo que te frena)

• La plantilla de una sola página que usamos en Ebägurin para documentar cualquier proceso en 30 minutos

• Un ejemplo real aplicado: el proceso de respuesta a cliente en menos de 24 horas

• Dónde guardar la documentación para que tu equipo la use de verdad

• Cuándo y cómo actualizar un proceso sin que se convierta en un archivo muerto

Documentar no es escribir un manual. Es resolver un problema.

Cuando le dices a un founder que tiene que documentar sus procesos, la imagen que le viene a la cabeza es un documento Word de 40 páginas con diagramas de flujo, aprobaciones y referencias a normativas ISO. Y tiene razón en tener miedo de eso, porque eso no lo va a leer nadie.

Un proceso bien documentado en una startup de 10 personas cabe en una página. Se lee en dos minutos. Y se ejecuta sin preguntas.

Esa es la diferencia entre documentar y sobredocumentar. El primero resuelve el problema: que cualquier persona de tu equipo pueda hacer esa tarea sin depender de que esté disponible quien la inventó. El segundo crea un problema nuevo: otro archivo que nadie abre.

Lo que suele pasar cuando no se documenta nada es que cada proceso existe en versión oral, pasa de persona a persona con matices distintos, y cuando alguien se va de vacaciones o deja el equipo, el proceso se va con él. A eso lo llamamos deuda operativa, y se acumula silenciosamente hasta que explota en el peor momento posible.

"Cada proceso que no documentas es deuda operativa que pagarás con tiempo, con errores o con personas quemadas."

Si quieres entender mejor la diferencia entre tener procesos y tener burocracia, lo explicamos en profundidad en procesos vs burocracia: por qué documentar no es controlar. Spoiler: un proceso bien diseñado elimina fricción, no la crea.

La plantilla de una página: los cinco campos que importan

Olvida los templates con 15 columnas. Un proceso tiene exactamente cinco elementos. Si no puedes responder estas cinco preguntas sobre una tarea de tu startup, esa tarea no tiene proceso: tiene caos disfrazado de rutina.

Los cinco campos

1. Trigger (disparador) ¿Qué hace que este proceso arranque? Un proceso sin trigger claro no arranca de forma consistente. Puede ser un evento ("cuando un cliente firma el contrato"), una frecuencia ("cada lunes a las 9:00"), una condición ("cuando el ticket lleva más de 4 horas sin respuesta") o una acción de otra persona ("cuando el equipo de ventas marca el deal como cerrado en HubSpot").

2. Pasos La secuencia ordenada de acciones. Numerados, concretos, sin ambigüedad. No "revisar el email del cliente". Sino "abrir la bandeja de soporte en [herramienta], filtrar por etiqueta 'urgente', abrir el ticket más antiguo sin respuesta".

Máximo 8-10 pasos. Si tienes más, probablemente estás documentando dos procesos distintos.

3. Responsable Un nombre, o un rol. No "el equipo". No "quien esté disponible". Un proceso sin responsable único es un proceso que no se hace, o que se hace dos veces, o que no se hace cuando el que "suele hacerlo" está de baja.

La regla del "quién hace qué": si le preguntas a tres personas de tu equipo quién es responsable de esta tarea y te dan tres respuestas distintas, no tienes un proceso. Tienes un problema.

4. Resultado esperado ¿Cómo sabe el responsable que el proceso terminó bien? Un criterio de salida concreto. "El cliente ha recibido respuesta", no. "El ticket está cerrado con estado 'resuelto' y el cliente ha respondido confirmando o ha pasado más de 24h sin réplica", sí.

5. Herramienta Qué herramienta o sistema se usa en cada paso relevante. Esto parece obvio pero no lo es: en startups donde el stack cambia cada seis meses, especificar la herramienta evita que alguien ejecute el proceso con la herramienta antigua porque nadie actualizó la documentación.

La plantilla en formato tabla (cópiala hoy)

Una tabla. Una página. Treinta minutos.

Ejemplo real: proceso de respuesta a cliente en menos de 24 horas

Este es uno de los primeros procesos que documentamos cuando entramos en una startup. El motivo es simple: el tiempo de respuesta a clientes es una de las métricas de experiencia de cliente que más impacto tiene en churn en fases tempranas, y en la mayoría de startups con las que trabajamos no existe como proceso. Existe como intención.

Aquí va el proceso documentado con la plantilla:

¿Esto soluciona todos los problemas de soporte de tu startup? No. Pero sí garantiza que el proceso ocurra, que ocurra igual independientemente de quién esté disponible, y que cuando algo falle se pueda identificar en qué paso ocurrió el fallo.

Eso es lo que hace un proceso documentado: convierte una intención en un sistema.

Dónde guardar la documentación para que tu equipo la use de verdad

La documentación que nadie encuentra no existe.

Esto suena obvio, pero hemos visto procesos perfectamente documentados en una carpeta de Google Drive que nadie sabe que existe, en un PDF adjunto a un email de hace dos años, o en una página de Notion que está tres niveles de profundidad por debajo de la home de la wiki del equipo.

La regla es simple: el proceso tiene que estar a un máximo de dos clics del lugar donde se ejecuta.

Para startups en fase pre-seed o seed (2-15 personas): Notion es la opción más sensata. No porque sea perfecta, sino porque tu equipo ya la usa, tiene una curva de aprendizaje baja y permite estructurar la wiki operativa sin necesidad de un sistema más complejo. Cuesta entre 0 € (plan gratuito, suficiente hasta 10 páginas colaborativas) y unos 8-10 € por persona al mes en el plan Team.

La estructura que funciona:

Notion > Wiki Operativa > Procesos
  ├── Ventas
  │     ├── Proceso de cualificación de leads
  │     └── Proceso de cierre de contrato
  ├── Soporte
  │     ├── Proceso de respuesta en 24h ← aquí estaría el ejemplo de arriba
  │     └── Proceso de escalado de incidencias
  ├── Onboarding de clientes
  └── Operaciones internas

Una base de datos en Notion con los procesos como páginas individuales, etiquetadas por área y con campo "Responsable" y "Última actualización" visibles desde la vista de tabla, funciona mucho mejor que una carpeta de páginas anidadas sin estructura.

Para startups en fase Series A (15-50 personas): Notion empieza a quedarse corto cuando hay más de 20 personas editando la wiki y los procesos se cruzan entre departamentos. En ese punto, tiene sentido evaluar herramientas más robustas como Confluence (a partir de unos 5,75 € por usuario al mes) o seguir en Notion pero con una arquitectura de permisos y plantillas mucho más estricta.

"El stack perfecto no existe. Existe el stack que tu equipo usa de verdad."

Lo que no funciona, independientemente de la herramienta: crear un repositorio de procesos que nadie actualiza y que solo el founder conoce. Un proceso documentado tiene que tener un propietario que lo mantiene vivo.

Cuándo actualizar un proceso (y cómo evitar que quede obsoleto)

Un proceso documentado que no se actualiza es peor que no tener proceso. Porque da una falsa sensación de control y lleva a errores que nadie puede detectar porque "estaban siguiendo el proceso".

La regla de actualización que usamos en Ebägurin es esta: un proceso se revisa en tres momentos.

1. Cuando cambia la herramienta. Si pasáis de gestionar soporte en Gmail compartido a Intercom, el proceso de respuesta a 24h tiene que actualizarse el mismo día. No la semana siguiente.

2. Cuando el proceso falla de forma repetida. Si en tres ocasiones el resultado esperado no se cumple siguiendo los pasos tal y como están documentados, el proceso está mal documentado (o mal diseñado). La respuesta no es "hay que tener más cuidado". La respuesta es revisar el proceso.

3. Revisión trimestral mínima. En una startup early-stage, los procesos cambian cada pocos meses. Cada quarter, el responsable de cada proceso tiene que abrirlo y confirmar que sigue siendo válido. Si lo es, actualiza la fecha. Si no lo es, lo corrige.

El campo "Última actualización" de la plantilla no es decorativo. Es el indicador de salud de tu documentación.

Si vas a profundizar en cómo construir la estructura operativa completa de tu startup más allá de los procesos individuales, la guía de operaciones para startups de 2 a 50 personas cubre el mapa completo: métricas, roles, herramientas y el momento en el que cada pieza tiene que entrar.

Los tres errores más comunes al documentar procesos en una startup

Error 1: Documentar cómo se hace, no cómo debería hacerse. Si el proceso actual es caótico, documentarlo tal cual es documentar el caos. Antes de escribir la plantilla, pregunta: ¿este proceso funciona? Si no funciona, primero arréglalo, luego documéntalo.

Error 2: Documentar todo a la vez. "Vamos a documentar todos nuestros procesos este mes" es una declaración de intenciones que termina en nada. Documenta primero los procesos que se repiten más y que más duelen cuando fallan. Los de onboarding de clientes, de soporte, de cierre de ventas. Los demás pueden esperar.

Error 3: No asignar propietario. Un proceso sin propietario no se actualiza. No se ejecuta de forma consistente. Y cuando algo falla, nadie sabe de quién es el problema. Cada proceso tiene que tener una persona responsable de que se cumpla y de que esté actualizado.

Si llevas meses sabiendo que necesitas documentar los procesos pero sin tiempo para montarlo desde cero, ahí es donde entramos. En un diagnóstico de 1-2 semanas mapeamos qué procesos críticos tienes, cuáles faltan y cuáles están generando más fricción, y salimos con un plan concreto para montarlos. Agendar una llamada →