Base de conocimiento que si se usa: estructura, articulos evergreen y ciclos de revision

La base de conocimiento es una de esas inversiones que todos los equipos de soporte quieren hacer y pocos logran sostener. La razon no es falta de voluntad, es falta de estructura.

Por que mueren las bases de conocimiento

Patron tipico: se lanza con 30 articulos entusiastas, los primeros 2 meses alguien actualiza cosas, a los 6 meses nadie sabe cuales articulos siguen vigentes, a los 12 meses el equipo prefiere preguntar en Slack que buscar ahi.

Las causas son consistentes:

• Sin responsables por articulo
• Sin ciclo de revision definido
• Articulos demasiado largos que nadie lee
• Contenido con fechas y versiones que caducan rapido
• Sin metrica de uso para priorizar mantenimiento

Estructura que funciona

Categorias maximas 8. Mas que eso y el usuario se pierde. Ejemplo para mesa de servicio B2B:

1. Accesos y cuentas
2. Configuracion inicial
3. Problemas comunes y soluciones
4. Integraciones
5. Facturacion
6. Procedimientos internos (solo agentes)
7. Troubleshooting tecnico
8. Preguntas frecuentes de negocio

Articulos cortos. Maximo 500 palabras. Si necesita mas, son dos articulos relacionados.

Formato consistente: titulo claro, problema en 1 linea, solucion en pasos, articulos relacionados. Sin prologos, sin introducciones largas.

Articulos evergreen

Los articulos que duran son los que:

• Resuelven un problema estructural, no una version especifica
• No tienen fechas en el cuerpo (ni en titulo)
• Hacen referencia a conceptos, no a versiones de software
• Incluyen "ultima revision" como metadato, no en el texto

Mal: "Como configurar SMTP en Freshdesk v2024 (septiembre)" Bien: "Como configurar SMTP en Freshdesk"

Mal: "En la nueva version del panel, ir a..." Bien: "En el panel de administracion, ir a..."

Responsables por articulo

Cada articulo tiene un duenno. No el equipo, una persona. Si esa persona deja la empresa, se reasigna antes de su salida.

El duenno es responsable de:

• Que el articulo siga siendo correcto
• Responder si alguien reporta que esta desactualizado
• Revisarlo cada ciclo sin esperar recordatorio

Ciclos de revision

Revision trimestral. Cada articulo se revisa cada 3 meses. No todos el mismo dia — se distribuye.

Proceso:

1. Sistema notifica al duenno que toca revision
2. Duenno tiene 2 semanas para: confirmar vigencia, actualizar o proponer retiro
3. Si no responde, el articulo se marca como "revision pendiente" visible al lector
4. Si pasan 30 dias, se archiva automaticamente

Revision disparada. Cuando un cambio de sistema afecta varios articulos, se disparan revisiones fuera de ciclo.

Metricas de utilidad

Sin metricas, no hay manera de priorizar mantenimiento. Las que importan:

• Vistas por articulo (mensual). Los top 20 merecen mas atencion.
• Tasa de "fue util" vs "no fue util". Los de <60% utilidad necesitan rework.
• Tickets que referenciaron el articulo (si la herramienta lo soporta).
• Articulos sin vistas en 6 meses. Candidatos a archivar.

Freshdesk y Freshservice dan estas metricas out-of-the-box.

Gobierno ligero

Un responsable de knowledge base dedica 2-3 horas a la semana a:

• Revisar articulos con baja utilidad
• Detectar gaps (tickets repetidos sin articulo que los cubra)
• Coordinar revisiones trimestrales
• Revisar propuestas de nuevos articulos

No es un rol full-time. Pero si no tiene duenno, no va a pasar.

Como arrancar

Semana 1-2: definir categorias y responsables.

Semana 3-6: escribir los 20 articulos que cubren el 80% de tickets recurrentes. Usar tickets reales como fuente.

Mes 2-3: lanzar a clientes, medir uso, ajustar.

Mes 4+: crecer basado en gaps reales, no en lista teorica de lo que deberia existir.

Una base de conocimiento con 50 articulos bien mantenidos vale mas que una con 500 desactualizados. La calidad se nota inmediatamente en CSAT y en tickets desviados.