Cómo crear una wiki de equipo que la gente use de verdad

Por qué la mayoría de las wikis de equipo mueren en un año

Una wiki muere en un orden previsible. Alguien la monta con entusiasmo y un árbol de carpetas profundo. El árbol tiene ramas vacías desde el primer día, así que la gente deja de fiarse. Las páginas nuevas se crean en el nivel superior porque nadie encuentra el sitio correcto. A los tres meses hay dos páginas sobre el mismo tema, y una está mal. Alguien busca, da con la equivocada y, a partir de ahí, pregunta en el chat.

Cada etapa tiene una causa contra la que puedes diseñar:

• Estructura vacía. Carpetas creadas antes que el contenido. Solución: crea una sección solo cuando tenga tres páginas listas para entrar.
• Sin responsable. Una página de la que nadie se ocupa se desvía hasta quedar mal. Solución: un nombre por página, visible en la página.
• Páginas duplicadas. Causadas por una búsqueda floja y la falta de una regla de nombres. Solución: una convención de nombres y una fusión semanal de cinco minutos.
• Contenido caducado. La página era correcta en enero. Solución: fecha de revisión en cada página y una limpieza trimestral.
• Una búsqueda que lista en vez de responder. Quien pregunta "cuál es nuestra política de reembolsos" no quiere nueve documentos que contengan la palabra reembolso. Solución: una herramienta con buena búsqueda y títulos escritos como la pregunta que hace la gente.

Una estructura de wiki para un equipo pequeño

Cuatro secciones de primer nivel cubren casi todo lo que necesita un equipo de quince o menos. Resiste la tentación de añadir una quinta hasta que una de estas desborde.

El manual es lo que menos cambia y lo primero que lee una persona nueva. "Cómo trabajamos" es el manual de operaciones. Los runbooks son las páginas que te salvan a las dos de la madrugada. Las decisiones son la memoria de la empresa, y la sección que más equipos se saltan. Tenemos una plantilla de registro de decisiones que encaja en la cuarta sección.

Dentro de cada sección, no anides más de tres niveles: sección, tema, página. "Runbooks / Infraestructura / Rotar la contraseña de la base de datos" está bien. Más profundo significa que la gente creará un duplicado arriba antes que encontrar la rama correcta.

Titular las páginas como preguntas o verbos

Titula los runbooks con un verbo: "Desplegar la API", "Reembolsar a un cliente", "Rotar una clave de API". Titula las páginas del manual y de cómo trabajamos con la pregunta que hace la gente: "¿Cómo pido vacaciones?", "¿Qué gastos cubrimos?", "¿Cuándo hacemos la daily?". El título es lo primero que la búsqueda compara, y la gente busca con las palabras que usaría para preguntar a un compañero.

Reglas de responsabilidad que mantienen viva la wiki

La estructura es la parte fácil. Estas tres reglas son las que mantienen una wiki correcta después del primer mes.

1. Un responsable por página, con nombre en la página. No un equipo, no un rol: una persona. Cuando se va, sus páginas se traspasan en la lista de salida. Una página sin responsable se archiva, no se deja a la deriva.
2. Una fecha de revisión en cada página. Las páginas del manual tienen doce meses, las de cómo trabajamos seis, los runbooks tres. El responsable confirma que la página sigue siendo correcta o la corrige. Una página con la revisión vencida muestra un aviso visible, y un informe mensual lista las páginas atrasadas por responsable.
3. Quien encuentra el error lo corrige. Si sigues un runbook y el paso cuatro está mal, corriges el paso cuatro antes de terminar. Es la regla que más cambia la trayectoria de una wiki, y la que hay que decir en voz alta en la incorporación, porque la gente nueva da por hecho que no tiene permiso.

Cómo crear la wiki en siete pasos

1. Elige la herramienta y deja de evaluar. La herramienta importa menos que las reglas de responsabilidad. Elige una que anide páginas, cuya búsqueda funcione sobre el contenido, que muestre quién editó qué y cuándo, y que exporte a Markdown para que puedas irte. La tabla de abajo compara cuatro.
2. Escribe tú las primeras veinte páginas antes de invitar a nadie. Una wiki vacía parece algo que ignorar. Las primeras veinte suelen ser: diez páginas de manual, cinco de cómo trabajamos, tres runbooks para los procedimientos que más miedo dan y dos decisiones tomadas este trimestre.
3. Mueve, no reescribas. La mayoría de estas páginas ya existen en hilos de chat, Google Docs y la cabeza de alguien. Pégalas con fecha y responsable. Pule después.
4. Asigna responsables y fechas de revisión a todas las páginas de una sentada.
5. Anuncia las reglas, no la wiki. El anuncio son tres líneas: dónde está la wiki, la regla de "arregla lo que encuentres", y que las respuestas en el chat a preguntas recurrentes se sustituirán por un enlace a la página.
6. Responde las preguntas del chat con enlaces durante un mes. Cuando alguien pregunte "¿cómo paso el gasto de un vuelo?", responde con el enlace; si no hay página, escríbela en cinco minutos y manda el enlace. Al cabo de un mes, la gente busca primero.
7. Haz una limpieza trimestral. Treinta minutos, todo el equipo: archivar lo muerto, fusionar duplicados, confirmar revisiones vencidas. Mantén el número de páginas bajo. Una buena wiki de equipo pequeño tiene entre 80 y 200 páginas, no 2.000.

El problema de la búsqueda, y por qué los usuarios de Confluence se quejan

La queja sobre la búsqueda en wikis es casi siempre la misma: buscar una frase devuelve una lista larga de páginas que contienen las palabras, ordenadas de una forma que nadie entiende, con la página correcta en la segunda pantalla. Confluence es la herramienta que más se nombra en esta queja, en parte porque es la más extendida y en parte porque los sitios grandes de Confluence acumulan años de adjuntos, espacios personales y páginas archivadas que se posicionan junto a la respuesta actual.

Para ser justos con Atlassian, su documentación de soporte no establece ningún límite de búsqueda en ningún plan de Confluence Cloud. Lo que sí dice, a octubre de 2026, es que el plan Free cubre hasta 10 usuarios con 2 GB de almacenamiento, y que las funciones de IA, incluida Rovo, aparecen en Standard y superiores, con cuotas de uso mayores en Premium. Así que en un sitio Free de Confluence la búsqueda es la clásica por palabras clave; la capa de respuestas con IA es de pago.

Tres cosas reducen el problema sea cual sea la herramienta:

• Menos páginas. La búsqueda funciona mejor sobre 150 páginas vigentes que sobre 3.000 de las que 2.850 están caducadas. La limpieza trimestral es una mejora de la búsqueda.
• Títulos con las palabras que la gente busca. Una página llamada "Política PTO v3 final" no la encontrará quien escribe "cómo pido vacaciones".
• Búsqueda tipo pregunta. El enfoque más reciente es responder la pregunta a partir de las páginas, con cita, en vez de listar las páginas. Slite, Nuclino y Atrix hacen una versión de esto; Confluence lo hace con Rovo en los planes de pago.

Herramientas para una wiki de equipo pequeño, a octubre de 2026

Notas sobre las cifras. La página de Slite muestra Basic a 10 $ y Pro a 20 $ por miembro al mes con facturación anual, sin plan gratuito y con prueba de 14 días sin tarjeta. Nuclino lista Free, Starter y Business con facturación anual hasta un 25 % más barata, pero no pudimos verificar sus precios por usuario en la página, así que no los imprimimos; Starter incluye elementos ilimitados e historial de versiones de 30 días, y Business añade la IA Sidekick e historial ilimitado. Los precios de Confluence Cloud varían según el periodo de facturación y la región y no eran legibles en la página de Atlassian cuando lo comprobamos, así que confírmalos directamente.

Dónde encaja Atrix

Atrix es una opción, y el argumento honesto a su favor es que la wiki es una pestaña de un espacio que también contiene trabajo, chat, calendario, clientes y contratación, de modo que un runbook puede enlazar a la incidencia de la que salió y una página de decisión al trato que la motivó. Las páginas se anidan en árbol, una página puede ser una base de datos (útil para la sección de decisiones: una fila por decisión, con columnas de estado y fecha), varias personas pueden editar una página a la vez con cursores visibles, cada página conserva historial de versiones y comentarios, y todo el espacio se exporta como un ZIP de Markdown. El cuadro de búsqueda responde a una pregunta a través de páginas, tareas y mensajes y cita de dónde sale la respuesta; esa misma capacidad de preguntar al espacio está expuesta a Claude, ChatGPT y Cursor mediante el servidor MCP, así que puedes consultar tu wiki desde la herramienta en la que ya estás.

Los límites: no hay plan gratuito, Builder está dimensionado para cinco asientos, no hay importador de exportaciones de Notion o Confluence más allá de archivos Markdown, Word y Excel, y si solo quieres una wiki, Slite o Nuclino serán más sencillos. La página de documentos y pizarras detalla lo que las páginas pueden y no pueden hacer. Si lo estás sopesando frente a Notion, la comparativa con Notion y la lista de alternativas a Notion cubren las diferencias en detalle.

Preguntas frecuentes

¿Qué debe contener una wiki de empresa?

Cuatro cosas: un manual (salario, vacaciones, gastos, equipo, valores), un manual operativo de cómo trabaja y entrega el equipo, runbooks para cada procedimiento que alguien pueda tener que seguir bajo presión, y un registro de decisiones. La documentación de producto y la ayuda para clientes van en otro sitio.

¿Cómo se estructura una wiki interna para un equipo pequeño?

Cuatro secciones de primer nivel, cada una con temas, cada tema con páginas: tres niveles, no más. Crea una sección solo cuando tenga tres o más páginas listas. Mantén el total por debajo de 200 páginas archivando sin miedo.

¿Quién debe ser responsable de la wiki del equipo?

Cada página tiene un responsable con nombre; la wiki en conjunto tiene una persona que dirige la limpieza trimestral y el informe mensual de revisiones vencidas. En un equipo de menos de quince suele ser un fundador o quien lleva operaciones. La responsabilidad de una página pasa a otra persona en la lista de salida.

¿Cada cuánto hay que revisar las páginas de la wiki?

Las del manual cada año, las de cómo trabajamos cada seis meses, los runbooks cada tres meses o cuando cambie el procedimiento. Las decisiones nunca se editan a posteriori; una decisión revertida recibe una página nueva que enlaza a la antigua.

¿Es Confluence una buena opción para la wiki de un equipo pequeño?

Funciona, y el plan Free cubre hasta 10 usuarios con 2 GB de almacenamiento a octubre de 2026. La queja habitual es la calidad de la búsqueda en sitios grandes, y la capa de búsqueda con IA (Rovo) está en los planes de pago. Para un equipo de menos de quince que no use ya Jira, una herramienta más ligera suele montarse más rápido.

Siguiente paso

Empieza con la estructura de arriba y las primeras veinte páginas. Si quieres la wiki junto al resto del trabajo del equipo, la página de documentos y pizarras muestra páginas anidadas, bases de datos y edición en vivo, y la comparativa con Notion explica qué implica mover una wiki.

Fuentes

Comprobado en octubre de 2026: precios de Slite, precios de Nuclino, Atlassian: planes de Confluence Cloud.