Plantilla de proceso operativo: documenta cualquier flujo de tu empresa en 30 minutos

Tu equipo lleva meses haciendo lo mismo de formas distintas. Cada vez que alguien nuevo entra, alguien veterano le explica cómo funciona todo. Cada vez que ese veterano no está, las cosas se hacen mal o no se hacen. Y cada vez que preguntas "¿cómo gestionamos X?", la respuesta es una combinación de memoria, intuición y suerte.

Eso no es operar. Es sobrevivir.

La solución no es escribir un manual de 40 páginas que nadie va a leer. Es tener un formato simple, consistente y rápido de rellenar que cualquier persona del equipo pueda usar para capturar cómo funciona cualquier proceso en menos de 30 minutos.

Eso es exactamente lo que vas a encontrar aquí.

Lo que vas a aprender en este artículo:

• Por qué documentar un proceso no requiere más de 30 minutos si tienes la estructura correcta

• Los cinco campos que necesita cualquier plantilla de proceso operativo para ser útil de verdad

• Un ejemplo concreto de cómo aplicar la plantilla a un proceso real: respuesta a cliente en menos de 24 horas

• Cómo hacer que la documentación no muera en una carpeta que nadie vuelve a abrir

Documentar no es escribir una novela

Cuando un founder escucha "documentar procesos", lo primero que visualiza es tiempo que no tiene. Imagina a alguien sentado durante horas redactando procedimientos corporativos que suenan a ISO 9001 y que nadie va a leer jamás.

Esa imagen es el problema.

"Un buen proceso cabe en una página. Si no cabe, no es un proceso: es un obstáculo."

En Ebägurin, lo primero que hacemos cuando entramos en una startup es distinguir entre documentar para controlar y documentar para funcionar. La burocracia nace cuando alguien confunde los dos. Un SOP (Standard Operating Procedure, o procedimiento operativo estándar) bien diseñado no tiene que ser extenso: tiene que ser claro, tiene que decirle a quien lo lee exactamente qué hacer, quién lo hace y qué resultado se espera.

Si el documento que produces requiere media hora de lectura para entenderse, no has documentado un proceso. Has creado fricción.

La buena noticia es que documentar bien es más una cuestión de estructura que de tiempo. Con el formato correcto, cualquier proceso de tu startup puede quedar capturado en 30 minutos o menos. El truco está en saber qué campos rellenar y cuáles ignorar.

Si quieres entender en profundidad por qué la mayoría de equipos confunden documentar con controlar, y cómo evitar ese error desde el principio, tienes una lectura directa en el artículo sobre procesos vs. burocracia en startups.

La plantilla: cinco campos que capturan cualquier proceso

La plantilla que usamos en Ebägurin tiene cinco campos. Ni más ni menos. Cada campo tiene un propósito concreto y juntos forman la imagen completa de cómo funciona un proceso.

Campo 1: Trigger (qué lo activa)

El trigger es la condición que pone en marcha el proceso. Sin un trigger claro, el proceso no existe: existe una intención.

Un trigger puede ser:

• Un evento externo ("el cliente envía un mensaje de soporte")

• Un momento temporal ("cada lunes a las 9:00")

• Una acción interna ("se cierra una oportunidad en el CRM")

• Un umbral alcanzado ("el MRR cae más de un 5% respecto al mes anterior")

Si tu equipo no sabe exactamente cuándo empieza un proceso, lo empezará cuando le parezca. Y eso produce inconsistencia.

Campo 2: Pasos (qué se hace y en qué orden)

Aquí va la secuencia de acciones. El formato ideal es una lista numerada, no párrafos. Máximo 8-10 pasos. Si tienes más, el proceso tiene sub-procesos y hay que dividirlo.

Cada paso debe ser una acción concreta, con verbo: "Abrir el ticket en HubSpot", "Enviar email de confirmación usando la plantilla X", "Actualizar el campo de estado a 'En revisión'". No "gestionar la incidencia". No "coordinar con el equipo".

La ambigüedad en los pasos es la razón por la que dos personas del mismo equipo hacen lo mismo de formas completamente distintas.

Campo 3: Responsable (quién hace qué)

Cada paso tiene un responsable. No "el equipo de soporte". Una persona o un rol concreto.

Si en tu startup de 12 personas tienes tres personas que podrían hacer algo, ninguna lo hace con consistencia. La ambigüedad de responsabilidad es uno de los patrones que vemos en casi todas las startups antes de sistematizar: cuando le preguntas a tres personas del equipo quién es responsable de un proceso concreto, obtienes tres respuestas distintas. O ninguna.

En equipos pequeños, el responsable puede ser el mismo para todos los pasos. En procesos más complejos que cruzan funciones (ventas con soporte, producto con operaciones), es donde esta columna se vuelve crítica.

Campo 4: Resultado esperado (cómo sabes que salió bien)

Este es el campo que más equipos omiten y el que más falta hace.

El resultado esperado es el criterio de éxito del proceso. ¿Qué tiene que haber ocurrido para que el proceso esté completo y bien hecho?

Ejemplos:

• "El cliente ha recibido respuesta en menos de 24 horas y el ticket está cerrado o escalado"

• "La oportunidad en HubSpot está actualizada con el siguiente paso y fecha"

• "El informe semanal está en el canal #métricas de Slack antes del lunes a las 10:00"

Sin este campo, el proceso puede ejecutarse y nadie sabe si se hizo bien. Con este campo, cualquier persona del equipo puede autoevaluar su trabajo sin necesitar que alguien lo revise.

Campo 5: Herramienta (dónde ocurre)

El último campo es el más simple: qué herramienta o sistema se usa en cada paso. HubSpot, Notion, Gmail, Slack, Google Sheets, WhatsApp Business.

Esto parece obvio, pero no lo es cuando el equipo tiene 8 herramientas distintas y nadie ha decidido formalmente dónde vive cada tipo de información. Documentar la herramienta en la plantilla fuerza esa decisión y elimina la ambigüedad de "¿lo meto en Notion o en el CRM?".

Cómo se ve la plantilla completa

Aquí tienes el formato limpio, listo para copiar:

Pasos:

Tienes la versión en Notion y en Google Docs disponible para descargarte la plantilla de proceso operativo directamente.

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

Vamos a aplicar la plantilla a uno de los procesos más comunes y más mal gestionados en startups early-stage: la respuesta al cliente cuando llega una incidencia o consulta.

En la mayoría de startups con las que trabajamos antes de sistematizar, este proceso es invisible. Alguien lo ve, alguien lo responde, a veces se escala, a veces no. El cliente a veces espera dos horas y a veces espera tres días. No hay consistencia porque no hay proceso.

Este es el aspecto que toma con la plantilla:

Nombre del proceso: Respuesta a consulta o incidencia de cliente

Trigger: El cliente envía un mensaje por email, WhatsApp Business o el chat de la plataforma con una consulta o incidencia.

Responsable principal: Customer Success (o el rol equivalente en tu equipo)

Resultado esperado: El cliente recibe una respuesta en menos de 24 horas laborables. La consulta queda registrada y resuelta o escalada con fecha de resolución prevista.

Última revisión: [fecha]

Este proceso cabe en una página. Se puede explicar en 5 minutos. Cualquier persona nueva en el equipo puede ejecutarlo el primer día.

Y produce un resultado consistente: el cliente siempre sabe que su mensaje se recibió, siempre recibe respuesta en menos de 24 horas y el equipo tiene visibilidad de todo lo que ocurre en soporte.

Eso es lo que separa crecer de escalar.

Cómo hacer que la documentación no muera en una carpeta

El mayor problema con la documentación de procesos no es crearla. Es que tres meses después nadie la ha vuelto a mirar y ha quedado obsoleta.

Para que la documentación esté viva, necesitas tres cosas:

Un lugar único donde viven todos los procesos. No en el Drive de alguien, no en un canal de Slack, no en el correo. Un sistema de referencia central. En la mayoría de startups en fase seed o pre-series A, Notion cumple bien este papel. Para equipos de más de 20 personas con flujos más complejos, puede ser el momento de evaluar herramientas más especializadas, pero hasta entonces Notion con una estructura de carpetas clara es más que suficiente.

Una fecha de revisión en cada proceso. Ves ese campo "Última revisión" en la plantilla. No es decorativo. Cada proceso tiene una cadencia de revisión: mensual para procesos que cambian rápido (como los de onboarding de clientes cuando estás iterando el producto), trimestral para los más estables. Si nadie revisa, el proceso caduca sin que nadie lo sepa.

El hábito de actualizar antes de quejarse. Cuando alguien del equipo ejecuta un proceso y se da cuenta de que un paso ya no encaja, la norma es simple: actualiza la plantilla. No "lo digo en la siguiente reunión" ni "ya lo veré". Dos minutos, actualización hecha. Este hábito es lo que distingue a los equipos que tienen documentación útil de los que tienen documentación arqueológica.

"La documentación no es un proyecto. Es una práctica. Si no la tratas como parte del trabajo, muere sola."

Los errores más comunes al usar esta plantilla

Antes de que la apliques, conviene saber dónde suele atascarse la gente:

Documentar el proceso ideal en vez del proceso real. La plantilla debe describir cómo se hace la cosa hoy, no cómo crees que debería hacerse idealmente. Primero captura la realidad. Luego mejora.

Hacer los pasos demasiado granulares. "Abrir el ordenador", "hacer clic en Chrome" no son pasos útiles. Los pasos tienen que ser acciones con significado operativo real. Si tienes que explicar cómo usar la herramienta en el propio proceso, lo que necesitas es un tutorial de onboarding, no una plantilla de proceso.

No asignar responsable a cada paso. "El equipo" no es un responsable. Una persona o un rol concreto sí. Si hay duda sobre quién hace qué, el proceso no está bien definido todavía.

Documentar todo a la vez en un sprint de un día. Esto no funciona. La documentación que se fuerza en un día de "vamos a documentar todo" suele ser superficial y no se mantiene. La forma que funciona es documentar un proceso cada vez que lo ejecutas, justo después de haberlo hecho. La memoria está fresca, los detalles son precisos.

Si tu startup lleva meses operando con procesos que viven solo en la cabeza de tu equipo, esto no se resuelve solo. El momento natural para sistematizar es antes de que el caos se instale, no después. Si quieres que revisemos contigo qué procesos hay que documentar primero y cómo montarlo, empezamos con un diagnóstico operativo express de 1-2 semanas.

Hablemos sobre tu startup →