Plantilla de documentación de procesos: cómo documentar un proceso para que se cumpla (2026)

La documentación de procesos es la descripción escrita de cómo fluye un trabajo por su organización, desde el evento que lo inicia hasta el resultado que lo cierra: las etapas en orden, el rol que se encarga de cada una, lo que pasa de un rol al siguiente, lo que deja cada etapa y qué ocurre cuando el camino normal se bloquea. Una plantilla de documentación de procesos es el esqueleto fijo en el que se vuelcan esas palabras, de modo que el décimo proceso se lea como el primero y quien ha leído uno pueda orientarse en todos.

La mayoría de los procesos ya están documentados en algún sitio: en un diagrama de un taller de hace dos años, en una página de wiki que nadie abre, en la cabeza de la única persona que lo hace desde el principio. El problema rara vez es que el documento no exista. Es que no se cumple, y las tres razones son las mismas en todas las organizaciones. Esta guía trata primero el oficio (qué es y qué no es un documento de proceso, el formato estándar, una plantilla que se puede copiar, un ejemplo resuelto), después las tres razones y lo que arregla cada una, dónde viven el documento y su repaso en las herramientas que su equipo ya usa, y qué recibe el compañero que lo lee en otro idioma. Porque un documento de proceso se juzga la mañana en que un nuevo gestor de cuentas, una nueva enfermera o el nuevo administrativo de un distribuidor tiene que pasarle algo a la siguiente persona y no sabe quién es.

Qué es un documento de proceso y qué no es

Tres documentos describen cómo se hace el trabajo a nivel de proceso, y a menudo se confunden entre sí y con los procedimientos que hay debajo:

El mapa es la imagen; el documento de proceso es el texto que hace utilizable la imagen; los SOP son el detalle bajo cada caja. La distinción decide la extensión: un documento de proceso que explica cómo se hace clic en cada paso es un manual que nadie lee, y un mapa de procesos sin texto es una imagen que cada cual interpreta a su manera. El SOP, su plantilla y su ciclo de revisión están en plantilla de SOP y cómo escribir un SOP; esta guía trata del nivel superior: el que dice dónde hacen falta los SOP y quién entrega qué a quién.

Un documento de proceso tampoco es una descripción de cómo se suele hacer el trabajo. Es la forma acordada, con un responsable, una versión y una fecha de revisión; por eso una etapa que nadie sigue es una etapa que cambiar o una conversación que tener, no una frase que dejar ahí.

Qué incluir: el formato estándar

Un documento de proceso utilizable lleva una cabecera y ocho secciones. La mayoría de las plantillas que circulan por internet incluyen el propósito, los pasos y un diagrama, y se quedan ahí; por eso la mayoría de los documentos de proceso se leen una vez y no se vuelven a abrir:

La cabecera: la identidad del documento, cinco campos en una línea: un ID que se pueda citar («PR-HR-02»), una versión («v1.3»), el responsable (una persona con nombre que responde de todo el proceso, no un departamento), la fecha de entrada en vigor y la fecha de la próxima revisión. Un proceso sin fecha de revisión se revisa cuando algo sale mal.

1. Propósito y resultado. Una o dos frases: qué entrega este proceso, a quién y cómo es lo bueno, con un número si lo hay. «Una persona recién contratada tiene cuentas, equipo, un plan y un compañero de referencia asignado el primer día, y una revisión a los 30 días antes del día 30.»
2. Disparador y estado final. El evento que inicia el proceso y el resultado que lo cierra. «Empieza cuando el contrato firmado llega a la carpeta de RR. HH.; termina cuando se registra la revisión de los 30 días.» Todo lo que hay entre esas dos frases es el proceso; todo lo que queda fuera es otro documento. Si el proceso no tiene un final claro, son dos procesos.
3. Alcance. Cuándo se aplica este proceso y cuándo no, citando por ID los procesos vecinos. «Empleados con contrato con nosotros, en cualquier país. No: colaboradores externos (PR-HR-04); no: traslados internos (PR-HR-06).»
4. Roles. Cada rol que aparece en las etapas, con aquello de lo que se encarga; roles, no nombres, para que el documento sobreviva a una contratación. Uno de ellos es el responsable del proceso, que responde de todo el flujo, incluidos los traspasos que nadie tiene asignados por defecto.
5. Etapas y traspasos. El corazón del documento: las etapas en orden, cada una con el rol que la ejecuta, lo que llega (la entrada), lo que sale y dónde se registra (la salida), a quién va y el plazo. El traspaso se escribe de forma explícita («a: TI, el día −5») porque el traspaso es donde fallan los procesos: ambas partes creen que lo tiene la otra.
6. Excepciones y escalado. Las ramas fuera del camino ideal: qué ocurre cuando el permiso se retrasa, falla la verificación de crédito o el responsable está ausente. Cada excepción nombra un rol o una persona que decide, nunca «preguntar a alguien». La última línea cubre lo que no se previó: «Todo lo que no figure aquí: decide el responsable del proceso y el caso se plantea en la próxima revisión.»
7. Medidas. Dos o tres números que vigila el responsable: tiempo de ciclo desde el disparador hasta el estado final, casos por mes, proporción que pasó por una excepción. No es un panel; son los números que avisan al responsable de que el proceso se desvía antes de que alguien se queje.
8. Documentos relacionados e historial de revisiones. Los SOP de cada etapa, la política que el proceso aplica, el enlace al mapa; después una línea por versión: fecha, qué cambió, quién lo aprobó. El historial es lo que evita que se reintroduzca el mismo error bajo un nuevo número de versión.

Lo que se queda fuera: la justificación de cada regla (tarea de la política), el detalle clic a clic de una etapa (tarea del SOP) y todo aquello sobre lo que una persona no podría actuar. «Valoramos una incorporación fluida» es un sentimiento, no una etapa.

Cómo documentar un proceso para que se cumpla

Tres razones explican casi todos los documentos de proceso que no se cumplen, y cada una tiene un arreglo que pertenece a la redacción, no a una supervisión posterior.

Primera razón: describe el proceso como se diseñó, no como se ejecuta. El documento se escribió en un taller por quienes gestionan el trabajo, y quienes lo hacen tienen otra versión: con la hoja de cálculo paralela y el compañero al que se llama en la etapa 3. El arreglo es mapearlo a partir de evidencias antes de escribir. Siga tres casos reales desde el disparador hasta el estado final y anote lo que ocurrió de verdad: los correos, los mensajes, los formularios, las esperas. Si el proceso vive en un chat de grupo (pedidos de distribuidores que llegan por WhatsApp, cambios de turno acordados en un grupo de Telegram), el chat es la evidencia, y el repaso empieza por su historial: lo que ofrece Export chat y dónde se queda corto está en cómo exportar un chat de WhatsApp. Donde los tres casos difieren está la razón de que el documento exista; decida para cada diferencia si es una etapa que corregir en el texto o una conversación que tener con el equipo.

Segunda razón: nadie encuentra la versión vigente. El documento está en una carpeta con otros cuarenta, hay una copia en el escritorio de alguien, una tercera versión en la wiki, y quien lo necesita un martes por la mañana se lo pregunta a un compañero. El arreglo es publicar donde el equipo ya lee, con la cabecera visible. Un solo lugar, la versión vigente primero, el nombre del responsable y la fecha de revisión arriba, de modo que «¿sigue siendo correcto esto?» lo responda la cabecera y no preguntar por ahí. Y las etapas se escriben como traspasos entre roles, para que cada persona encuentre su etapa y las dos contiguas en menos de un minuto.

Tercera razón: cambió y a quienes les cambió la etapa nunca se les avisó. Una revisión movió la verificación de crédito antes de la preparación del pedido, o añadió un paso para quienes se reubican, y el documento se actualizó, pero el almacén y los responsables de contratación siguieron haciendo lo de antes. El arreglo es repasar el proceso con quienes lo ejecutan y comunicar cada cambio con las líneas que cambiaron. El repaso es una reunión: el responsable y una persona por rol, la versión vigente en la pantalla de todos, cada etapa leída en voz alta por quien la hace, cada traspaso confirmado por ambas partes. Lo que cambia el repaso se convierte en una nueva versión con una línea en el historial, y las tres líneas que cambiaron llegan a las personas cuyas etapas afectan, en el lugar donde ya leen, ese mismo día. Una decisión que cambia una regla y no una etapa pasa también al registro de decisiones, con el ID del proceso en la entrada.

La secuencia, entonces: elegir un proceso con un inicio y un final claros; seguir tres casos reales; redactar primero las etapas, en la plantilla, con los traspasos explícitos; completar las excepciones con lo que mostraron los casos; repasarlo con una persona por rol; publicarlo donde lee el equipo, con el responsable y la fecha de revisión en la cabecera; poner la fecha de revisión en el calendario. El documento que resulta se cumple porque es veraz, localizable y comunicado: las tres propiedades que la plantilla por sí sola no puede darle.

Una plantilla de documentación de procesos

[ID del proceso] — [Nombre del proceso]
Versión: [n.n] · Responsable: [nombre, rol] · En vigor: [fecha] · Próxima revisión: [fecha]

1. Propósito y resultado
[Una o dos frases: qué entrega este proceso, a quién y cómo es lo bueno, con un número si lo hay.]

2. Disparador y estado final
Empieza cuando: [el evento] · Termina cuando: [el resultado que ya existe]

3. Alcance
Cubre: [casos, sedes, clientes, países] · No cubre: [lo que gestiona otro proceso, con su ID]

4. Roles
Responsable del proceso: [la persona que responde de todo el flujo]
[Rol] — [de qué se encarga en este proceso]
[Rol] — [de qué se encarga en este proceso]

5. Etapas y traspasos
5.1 [Etapa] — [rol] — entra: [lo que llega] — sale: [lo que sale, dónde se registra] — a: [siguiente rol] — en: [plazo]
5.2 [Etapa] — [rol] — entra: … — sale: … — a: … — en: …
5.3 [Etapa] — [rol] — entra: … — sale: … — a: … — en: …

6. Excepciones y escalado
Si [condición]: [qué ocurre, quién decide]
Si [condición]: [qué ocurre, quién decide]
Todo lo que no figure aquí: decide [rol]; el caso se plantea en la próxima revisión.

7. Medidas
[Dos o tres números que vigila el responsable (tiempo de ciclo, casos por mes, proporción que pasó por una excepción) y dónde se consultan.]

8. Documentos relacionados e historial de revisiones
SOP: [IDs, uno por etapa donde haga falta] · Aplica: [política] · Mapa: [enlace al diagrama]
v[n.n] — [fecha] — [qué cambió] — aprobada por [nombre]
v[n.n] — [fecha] — [qué cambió] — aprobada por [nombre]

La plantilla es texto plano con etiquetas en negrita, de modo que se pega en un archivo de Word, un Google Doc, una página de wiki, un canvas de Slack o una nota de chat sin reformatear. Las dos secciones que más a menudo se dejan en blanco son los traspasos («a quién, para cuándo») y la fecha de revisión; son las dos que deciden si, dentro de un año, el proceso se sigue ejecutando como dice el documento.

Un ejemplo resuelto: incorporar a una persona recién contratada, desde el contrato firmado hasta el día 30

Una empresa de sesenta personas con contrataciones en tres países; el proceso atraviesa cuatro roles y termina cuando se registra la revisión de los 30 días.

PR-HR-02 — Incorporación de una persona recién contratada
Versión: 1.3 · Responsable: Responsable de operaciones, Inés M. · En vigor: 1 oct 2026 · Próxima revisión: 1 abr 2027

1. Propósito y resultado — Una persona recién contratada tiene cuentas operativas, equipo, un plan del primer mes y un compañero de referencia asignado el primer día, y una revisión registrada a los 30 días antes del día 30, en el país en que empiece.
2. Disparador y estado final — Empieza cuando: el contrato firmado llega a la carpeta de RR. HH. Termina cuando: la revisión de los 30 días queda registrada en el expediente de la persona.
3. Alcance — Empleados con contrato con nosotros, en cualquier país, en oficina o en remoto. No: colaboradores externos (PR-HR-04); traslados internos (PR-HR-06).
4. Roles — Responsable del proceso: responsable de operaciones. RR. HH.: el expediente, los documentos, la nómina, el pack de bienvenida. TI: cuentas, equipo, accesos. Responsable de contratación: el plan, el compañero de referencia, los seguimientos. Finanzas: alta en nómina.

5. Etapas y traspasos
5.1 Abrir el expediente — RR. HH. — entra: el contrato firmado — sale: el registro de incorporación con fecha de inicio, país, responsable e idioma; el pack de bienvenida enviado en el idioma de la persona — a: TI y el responsable de contratación — en: dos días laborables desde la firma
5.2 Cuentas y equipo — TI — entra: el registro — sale: cuentas creadas, portátil enviado a la dirección de la persona, accesos según el perfil del rol; confirmación en el registro — a: RR. HH. — en: cinco días laborables antes de la fecha de inicio
5.3 Documentos y nómina — RR. HH. y después finanzas — entra: el registro, los documentos de la persona (permiso o registro donde el país lo exija) — sale: la persona dada de alta en nómina, documentos en el expediente — a: el responsable de contratación — en: la fecha de inicio
5.4 El primer mes, planificado — responsable de contratación — entra: el registro — sale: un plan a 30 días en el expediente, un compañero de referencia asignado, la primera semana en el calendario de la persona, la llamada de bienvenida con el equipo reservada — a: la persona, el primer día — en: el día anterior al inicio
5.5 Primer día — responsable de contratación y compañero de referencia — entra: el plan — sale: la llamada de bienvenida realizada, el plan repasado, las dudas de la persona anotadas en el canal del equipo — a: la persona — en: el final del primer día
5.6 Seguimientos — responsable de contratación — entra: el plan, las dudas anotadas — sale: un seguimiento al día 7 y otro al día 30, la revisión de los 30 días registrada en el expediente — a: RR. HH., para cerrar el registro — en: el día 30

6. Excepciones — Permiso o registro sin resolver en la fecha de inicio: la persona empieza con las tareas que el responsable marque como permitidas sin ello; RR. HH. se encarga del seguimiento y la fecha se anota en el registro. Portátil no entregado el día −2: TI envía uno de préstamo del stock de la oficina; se avisa al responsable de operaciones ese mismo día. Contratación en un país donde no hemos contratado antes: la etapa 5.3 se detiene; el responsable de operaciones decide la vía del empleador de registro en tres días laborables (PR-HR-05).
7. Medidas — Días laborables desde la firma hasta tener las cuentas listas (objetivo ≤ 7); proporción de contrataciones con revisión de 30 días registrada antes del día 30 (objetivo 100 %); dudas anotadas en la primera semana, leídas en la revisión trimestral para ver qué etapa sigue generándolas.
8. Relacionados — SOP-IT-03 «Nuevas cuentas y accesos»; SOP-HR-08 «Alta en nómina por país»; Política de incorporación §2; mapa: el diagrama de calles en la carpeta de RR. HH.
v1.3 — 1 oct 2026 — el pack de bienvenida se envía ahora en el idioma de la persona; se añade el seguimiento del día 7 — aprobada por Inés M.
v1.2 — 3 jun 2026 — el envío del portátil se adelanta a cinco días antes del inicio tras dos entregas tardías — aprobada por Inés M.

Fíjese en lo que hace el ejemplo. Cada etapa nombra el rol, lo que llega, lo que sale y dónde se registra, quién lo recibe después y para cuándo, de modo que un traspaso que no se produjo se ve como un hueco en el registro y no como una sorpresa el primer día. Cada excepción nombra quién decide. Las medidas son tres números, no un panel. Y el historial explica por qué las etapas son como son: la etapa 5.2 tiene su fecha porque dos portátiles llegaron tarde, y el seguimiento del día 7 existe porque la revisión del día 30 seguía encontrando dudas que debieron resolverse en la primera semana.

Un segundo ejemplo, más breve: la forma de un proceso de ventas para un exportador con distribuidores:

PR-SA-01 — Del pedido a la entrega · Responsable: Responsable de exportación · Empieza cuando: llega el pedido de un distribuidor · Termina cuando: se confirma la entrega y se envía la factura
1. Revisión del pedido — responsable de la cuenta — entra: el pedido — sale: pedido confirmado en el sistema, o una consulta de vuelta al distribuidor — a: finanzas — en: un día laborable
2. Verificación de crédito — finanzas — entra: el pedido confirmado — sale: liberado, o retenido con un motivo — a: almacén — en: un día laborable
3. Preparación y embalaje — almacén — entra: el pedido liberado — sale: embalado, con la lista de embalaje — a: logística — en: tres días laborables
4. Documentos y envío — logística — entra: el pedido embalado — sale: el envío reservado, los documentos del destino adjuntos, seguimiento en el sistema — a: finanzas y el responsable de la cuenta — en: un día laborable
5. Factura y confirmación — finanzas y después el responsable de la cuenta — entra: el envío — sale: factura enviada; entrega confirmada con el distribuidor y registrada — Si el crédito está retenido: el responsable de la cuenta llama al distribuidor en un día laborable; el responsable de exportación decide entre liberar o exigir pago anticipado.

Doce líneas, y tanto un nuevo administrativo del distribuidor como una persona nueva en el almacén saben de quién están esperando respuesta.

Dónde viven el documento de proceso y su repaso en las herramientas que ya usa

El documento en sí vive donde viven los documentos del equipo: un archivo de Word en una biblioteca compartida, un Google Doc, una página de wiki, un canvas en un canal. El repaso es una reunión, y cada plataforma tiene un lugar para lo que el repaso deja; cada una se detiene en un punto distinto. Solo comportamiento documentado, tomado de las páginas de los propios proveedores, con el mes en que se comprobó cada página:

Dos cosas son iguales en todas partes. El documento de proceso es un archivo en el único idioma en que se escribió, y el compañero que lee otro idioma lee ese o una copia que alguien hizo; y lo que cambió el repaso llega al documento solo cuando una persona lo teclea después, en ese mismo idioma. La traducción que documentan estas suites pertenece a la llamada, no al documento: Microsoft documenta subtítulos traducidos en directo en las reuniones de Teams cuando el organizador tiene una licencia de Teams Premium o de Microsoft 365 Copilot, y Google documenta subtítulos traducidos en Meet en los planes de Workspace que lo admiten (ambos comprobados en agosto de 2026); qué cubre cada uno y dónde se detiene cada uno está en traducción en vivo en Microsoft Teams y traducción en vivo en Google Meet. El proceso que el nuevo administrativo abre el martes, y el repaso que lo cambió, son objetos distintos de esos subtítulos, y se leen en el idioma en que se escribieron.

Cómo el proceso, su repaso y su historial siguen siendo legibles para cada miembro

InterMIND es un espacio de comunicación donde el trabajo de un equipo vive en un canal, así que el documento de proceso terminado tiene un hogar evidente: el canal del equipo que ejecuta el proceso, un canal para las personas de RR. HH., TI, finanzas y los responsables de contratación que se encargan cada una de una etapa. Publicado como nota (un mensaje de texto enriquecido con encabezados y listas numeradas, que se edita después desde su propio menú), cada miembro lo lee en su propio idioma con el original a un clic, y fijado para que la versión vigente sea lo primero que encuentre un compañero nuevo; con el historial de ediciones activado, la redacción anterior de una etapa modificada aparece sobre el texto actual como una diferencia palabra por palabra con su marca de tiempo. Subido como archivo (un PDF o un documento de Word), incluye, en todos los planes, un resumen de IA en el idioma del lector con cada punto enlazado al párrafo del que procede, de modo que la lectura de una página existe antes de que nadie la haya escrito; en los planes de pago, el propio archivo se abre traducido al idioma del lector (30 idiomas para documentos). Si la copia maestra permanece en una herramienta de documentos, sus actualizaciones llegan al canal por correo: el anfitrión del canal le asigna una dirección propia, y un mensaje enviado ahí aparece como un mensaje normal con el remitente identificado y los adjuntos conservados.

El repaso parte de ese canal. Durante la llamada, la versión vigente se pone en la pantalla de todos junto a los mosaicos de vídeo con Share to conference (una nota, o un documento de Google Docs u OneDrive enlazado en el chat), y cada participante se desplaza por él de forma independiente y lo lee en su propio idioma; una nota compartida la edita en directo quien la comparte mientras la sala ve cómo toma forma el traspaso modificado. Cuando termina la llamada, el resumen se redacta a partir de la propia reunión (un resumen, los puntos marcados como acordados, abiertos o en disputa, los action items con responsables, cada línea con su marca de tiempo) y los documentos compartidos durante la sesión aportan sus resúmenes junto a lo que se dijo. Llega por correo, como mensaje en el canal y como enlace en el evento del calendario, y cada miembro con sesión iniciada lo lee en su propio idioma: el registro se traduce por lector, no se escribe una sola vez en el idioma que la sala usó. Cualquier miembro puede editarlo, cada edición conserva autor e historial de revisiones, y el canal guarda el resumen de cada sesión pasada, de modo que el repaso que produjo la v1.3 está a un clic de la nota que es la v1.3. El asistente propio de un miembro (Claude, ChatGPT, Copilot o Gemini, conectado mediante el conector MCP) busca en resúmenes, transcripciones, chats y el texto de los archivos compartidos con una sola pregunta, «¿por qué el portátil se envía cinco días antes de la fecha de inicio?», y lee el propio documento; esto funciona en las organizaciones con las funciones de IA activadas. Puesto junto a la tabla anterior, la diferencia es una simple constatación de hechos: los subtítulos que documentan esas suites traducen la llamada mientras transcurre; aquí el proceso, su repaso y su historial son un único registro, leído por cada miembro en su propio idioma.

Quienes participan en un proceso no siempre son empleados. El administrativo de pedidos de un distribuidor, un proveedor de nóminas en otro país, un colaborador externo que se encarga de una etapa: un miembro externo del canal se une por correo con una cuenta gratuita y lee el proceso y su historial como todos los demás; una persona sin cuenta es invitada a una sola reunión: se une al repaso por enlace, desde un teléfono, sin coste, lo escucha en directo en su propio idioma y no recibe ningún registro después. El anfitrión proporciona el espacio y, en un plan de pago, paga solo por los miembros activos en los últimos 28 días: quienes se unieron a una reunión, escribieron en un chat o consultaron al asistente; los miembros que dejan de participar conservan su acceso sin coste.

• Abrir un resumen completo — un registro real generado por el mismo código que escribe los suyos.
• Probar la demo en vivo — sin registro; hable y escuche la sala traducida para cada oyente.

La documentación de procesos como oficio sobrevive a cualquier herramienta: alguien tiene que seguir tres casos reales, escribir las etapas como traspasos que una segunda persona pueda comprobar y repasar el conjunto con una persona por rol. Lo que no tiene por qué sobrevivir es el segundo trabajo: mantener a mano una copia traducida de cada versión y volver a teclear lo que el repaso cambió, en un solo idioma, para personas que leen en otros.

Preguntas frecuentes

¿Qué es la documentación de procesos?

La documentación de procesos es la descripción escrita de cómo fluye un trabajo por una organización desde el evento que lo inicia hasta el resultado que lo cierra: las etapas en orden, el rol que se encarga de cada una, lo que pasa de un rol al siguiente, lo que deja cada etapa, las excepciones fuera del camino normal y quién las decide, y los pocos números que vigila el responsable. Se sitúa entre el mapa de procesos (el diagrama) y los SOP que describen cómo se hace cada etapa paso a paso.

¿Qué debe incluir la documentación de procesos?

Una cabecera con el ID, la versión, el responsable, la fecha de entrada en vigor y la fecha de la próxima revisión; el propósito y el resultado; el disparador y el estado final; el alcance, incluido lo que el proceso no cubre; los roles, con un responsable del proceso con nombre; las etapas en orden, cada una con el rol, la entrada, la salida y dónde se registra, el siguiente rol y el plazo; excepciones y escalado con un decisor para cada una; dos o tres medidas; y los SOP relacionados, la política que aplica y un historial de revisiones.

¿Cómo se documenta un proceso paso a paso?

Elija un proceso con un disparador y un estado final claros. Siga tres casos reales de principio a fin y anote lo que ocurrió de verdad, incluidas las ramas. Redacte primero las etapas, en la plantilla, cada una como un traspaso: rol, entrada, salida, siguiente rol, plazo. Añada las excepciones que revelaron los casos, con quién decide cada una. Complete el propósito, el alcance, los roles y la cabecera. Repase el documento con una persona por rol, cada una leyendo en voz alta su propia etapa y confirmando los traspasos. Publíquelo donde el equipo ya lee, con el responsable y la fecha de revisión visibles, y ponga la fecha de revisión en el calendario.

¿Cuál es la diferencia entre la documentación de procesos y un SOP?

La documentación de procesos describe cómo fluye el trabajo entre roles y equipos (etapas, traspasos, lo que deja cada etapa) a razón de una página por proceso. Un SOP describe cómo hace una de esas etapas un rol, paso a paso, hasta el resultado que produce cada paso. El documento de proceso dice dónde hacen falta los SOP y quién entrega qué a quién; un SOP le dice a una persona qué hacer el martes por la mañana. Escribir un SOP para un proceso completo entre equipos produce un manual que nadie abre; escribir un documento de proceso con el detalle de un SOP produce lo mismo.

¿Cuáles son ejemplos de documentación de procesos?

Cualquier flujo recurrente que cruza roles y tiene un inicio y un final claros: incorporar a una persona recién contratada desde el contrato firmado hasta el día 30; un pedido de un distribuidor hasta una entrega confirmada y una factura; una reclamación de un cliente desde la recepción hasta el cierre; un paciente desde la derivación hasta la primera cita; un producto nuevo desde el briefing aprobado hasta su alta en el catálogo; el cierre de mes desde las hojas de horas hasta las facturas enviadas. El ejemplo resuelto de esta guía es la incorporación de una persona contratada (seis etapas entre cuatro roles, tres excepciones, un historial de tres versiones), seguido de un ejemplo más breve de pedido a entrega.

¿Existe una plantilla de documentación de procesos en Word o Google Docs?

La plantilla de esta guía es texto plano con etiquetas en negrita, de modo que se pega en un documento de Word, un Google Doc, una página de wiki, un canvas de Slack o una nota de chat sin reformatear. El formato importa más que el archivo: lo que contenga el documento necesita la cabecera con el responsable y la fecha de revisión, el disparador y el estado final, etapas escritas como traspasos entre roles con un plazo, un decisor con nombre para cada excepción y un historial de revisiones, y tiene que vivir donde ya leen quienes ejecutan el proceso.

¿Quién debe escribir la documentación de procesos?

El responsable del proceso (una persona con nombre que responde de todo el flujo, normalmente el responsable del área por la que pasa la mayor parte del proceso), con una persona de cada rol que asume una etapa. El responsable lleva la pluma y la fecha de revisión; quienes hacen las etapas son coautores, porque un documento escrito sobre ellos en lugar de con ellos describe el proceso como se diseñó mientras el real vive en sus cabezas. Una persona recién llegada es quien lo pone a prueba: si encuentra su etapa y las dos contiguas en menos de un minuto, el documento funciona.

¿Con qué frecuencia debe actualizarse la documentación de procesos?

En la fecha de revisión de su cabecera (cada seis o doce meses es lo habitual, con menos intervalo si el proceso está regulado) y antes si ocurre una de estas cuatro cosas: falló un traspaso y nadie era responsable, cambió una herramienta o un formulario del que depende una etapa, cambió la regla que el proceso aplica, o se movieron las medidas. Cada actualización es una nueva versión con una línea en el historial que dice qué cambió y quién lo aprobó; la versión antigua se conserva, y a las personas cuyas etapas cambiaron se les avisa, con las líneas que cambiaron, ese mismo día.

Fuentes: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). Páginas de notas de reunión y plantillas de Microsoft, Google y Slack comprobadas en octubre de 2026; la página del resumen de reuniones de Zoom y las páginas de subtítulos de Teams y Meet, comprobadas en agosto de 2026. Los proveedores cambian con el tiempo sus planes, funciones y listas de idiomas; consulte sus páginas para conocer el estado actual.