Base de Conocimiento

Tu equipo ya escribió la respuesta. Tres veces

Hay una pregunta que os llega cada semana. Alguien la contestó bien la primera vez, con calma y con detalle, en un correo que ahora está enterrado en su bandeja de enviados. La segunda vez la contestó otra persona, algo peor y con otras palabras. La tercera la contestó el técnico nuevo, y no del todo bien.

Ese es el coste real de no tener base de conocimiento: no es la falta de documentación, es la reescritura permanente de lo que ya se sabe. Y tiene dos facturas. La de dentro, en horas de un equipo que responde en lugar de avanzar. Y la de fuera, en clientes que reciben tres versiones distintas de la misma verdad según quién les atienda.

La Base de Conocimiento es el sitio donde esa respuesta se escribe una vez y se queda. Y lo importante no es el módulo: es de dónde salen los artículos.

Los artículos salen del trabajo, no de un proyecto

Casi todas las bases de conocimiento fracasan igual: alguien decide que hay que documentar, se bloquean dos semanas para redactar, se escriben doce artículos y nunca se vuelve a tocar.

Aquí el mecanismo es otro. Cada incidencia tiene su campo de solución, y una incidencia resuelta se convierte en artículo con un clic, arrastrando esa solución. Es decir: la biblioteca crece con el trabajo que el equipo ya está haciendo, en el momento en que la respuesta acaba de escribirse y está fresca.

Eso cambia la pregunta de gestión. Ya no es «¿cuándo nos sentamos a documentar?», sino «¿esta incidencia que acabo de cerrar merece quedarse?». Y esa decisión cuesta cinco segundos.

Cada artículo, en su sitio

Campo	Para qué sirve
Pregunta	El titular, redactado como lo preguntaría el cliente y no como lo describiría un técnico
Respuesta	El contenido, con el formato y el detalle que haga falta
Categoría	El tema: facturación, instalación, errores conocidos, configuración
Producto o servicio	A qué parte de tu catálogo se refiere
Estado	Si está en borrador, publicada u obsoleta
Número propio	Para citarla en una respuesta o en una incidencia sin ambigüedad

La pregunta redactada en las palabras del cliente merece un momento de atención: un artículo titulado «Procedimiento de reinicialización del módulo de comunicaciones» no lo encuentra nadie. «No consigo conectar el terminal» sí.

Tres estados, y el tercero es el que importa

Borrador es lo que alguien ha empezado y no está revisado. Sirve para que escribir no dependa de tener tiempo de hacerlo perfecto: se deja el esqueleto y se termina después.

Publicada es lo que se puede usar y enseñar sin miedo.

Obsoleta es la que resuelve el problema del que nadie habla. Cuando algo cambia, la tentación es borrar el artículo antiguo, y con él desaparece la explicación de cómo funcionaba antes: justo lo que necesitas cuando un cliente que no ha actualizado llama con el comportamiento viejo. Marcar en lugar de borrar conserva esa historia y a la vez avisa de que no es la respuesta actual.

Ese tercer estado es lo que impide que la biblioteca envejezca en silencio, que es la forma en que mueren casi todas.

Fuera para el cliente, dentro para el equipo

La misma biblioteca sirve a dos públicos, y tú decides qué ve cada uno.

Publicada en el portal de clientes, se convierte en autoservicio: el cliente busca, encuentra y resuelve sin abrir una incidencia ni esperar respuesta. Las preguntas que más se repiten son, por definición, las más fáciles de resolver así, y son las que más volumen quitan al equipo.

Reservada para uso interno, es la respuesta a por qué un técnico nuevo tarda tres meses en ser autónomo. La información existe, pero vive en la cabeza de tres personas y se transmite preguntando. Un artículo sobre un error recurrente convierte esa interrupción al compañero en una búsqueda de treinta segundos.

No todo lo que el equipo necesita saber conviene contarlo fuera, y por eso la decisión de publicar es artículo por artículo.

Por dónde empezar: mira tus propias incidencias

No hay que adivinar qué documentar. El reparto de incidencias por categoría en informes y paneles lo dice directamente.

En casi todas las empresas hay dos o tres categorías que concentran una parte desproporcionada del volumen de soporte. Escribir primero esos artículos —y publicarlos donde el cliente los encuentre antes de escribir— es lo que produce una caída medible de incidencias repetidas en el primer trimestre.

El resto puede esperar. Una biblioteca de cuarenta artículos que resuelven el 70 % de las preguntas reales vale más que trescientos artículos que cubren todo el catálogo y que nadie ha revisado en dos años.

El matiz va en los comentarios

Cada artículo admite comentarios, y ahí es donde acaba lo que no cabe en la respuesta principal: el caso particular en el que no aplica, la versión desde la que cambió el procedimiento, el cliente que lo tiene configurado de otra manera.

Mantener eso separado de la respuesta tiene una ventaja concreta: el artículo sigue siendo corto y utilizable, y el detalle está disponible para quien lo necesite sin estorbar a quien solo quiere resolver.

Un mismo mecanismo para muchos equipos

Lo que te ahorra

Cada respuesta reescrita cuesta el rato de escribirla más el riesgo de escribirla peor que la vez anterior. Multiplicado por las veces que se repite al año, es una cifra que sorprende a cualquiera que la calcule por primera vez.

Y hay un ahorro que no se mide en horas: la respuesta que el cliente encuentra solo, a las once de la noche, sin escribir a nadie. Está incluido en OpenCRM, como el resto de las funcionalidades: sin herramienta de documentación aparte y sin límite de artículos.

Preguntas frecuentes sobre la Base de Conocimiento

Módulos relacionados

• Ticketing e Incidencias: el origen de los artículos, con la conversión de incidencia resuelta a respuesta.
• Portal de Clientes: donde los artículos publicados se convierten en autoservicio.
• Centro Documental: para los ficheros y manuales, que son otra cosa.
• SLA: resolver antes es más fácil cuando la respuesta ya está escrita.
• Informes y paneles: el reparto de incidencias que dice qué artículo escribir primero.