Todo equipo de soporte tiene, escondido en la cabeza de algunos, el conocimiento que resuelve el 80% de los tickets. La Base de Conocimiento existe para sacar ese conocimiento de la memoria individual y ponerlo a disposición de todos — operadores y clientes.

En esta guía, entenderá cómo funciona la KB del Portal Nyverra ITSM: la diferencia entre artículos internos y la base pública, la estructura de categorías, la búsqueda con filtros (facets) y sugerencia de título, el ciclo de feedback y los indicadores de calidad que muestran qué revisar.

Interfaz del módulo en el Portal Nyverra ITSM.

Por qué KB: el efecto en el indicador

Una base bien cuidada produce tres efectos medibles en el service desk:

• Resuelve en el primer contacto: el técnico responde rápido consultando el procedimiento correcto.
• Deflection: el cliente resuelve por sí mismo en la KB pública y ni siquiera abre el ticket.
• Estandarización: todos siguen la misma solución, reduciendo variación y error.

Lo contrario también es cierto: una KB desactualizada aleja a los usuarios y se convierte en costo. Por eso el módulo no es solo “publicar artículo” — es gestionar conocimiento.

Dos bases en una

El Portal separa dos públicos en el mismo sistema de artículos:

Base	Quién accede	Para qué
KB interna	Equipo autenticado (permiso KB_VIEW)	Procedimientos operativos, runbooks, contexto técnico
KB pública	Visitante, sin login	Autoservicio del cliente (paso a paso, “cómo hago X”)

Un mismo acervo alimenta a ambos: el artículo marcado como público aparece al visitante; los demás quedan restringidos al equipo.

Quién lo usa

Perfil	Uso
Cualquier usuario autenticado	Consultar la KB interna
Editor / administrador	Crear categorías y artículos en Gestionar KB
Visitante	Consultar la KB pública (sin login)

Las funcionalidades del módulo

Categorías y artículos

Los artículos se organizan por categorías (p. ej.: Red, Correo electrónico, Sistemas, Accesos). Los artículos son de texto enriquecido, con imágenes, listas, tablas y fragmentos de código. Un artículo bien estructurado tiene título objetivo, contexto breve y la solución en pasos — un tema por artículo.

Búsqueda con facets y sugerencia de título

La búsqueda va más allá del texto libre: ofrece facets (filtros por categoría y etiquetas), ordenación por relevancia y sugerencia de título mientras el usuario escribe. Esto reduce la frustración del “no encontré nada” — gran causa de tickets evitables.

Feedback del lector

Cada artículo puede recibir la marcación “útil / no útil” y comentarios. El equipo responde al feedback mediante la administración. El retorno del lector es el termómetro más honesto de la calidad del artículo.

Analíticas y calidad de la búsqueda

El Portal expone métricas de acceso y una visión de calidad de la búsqueda (consultas sin resultado, términos problemáticos). Esto permite actuar con datos: crear el artículo que falta, corregir el título que nadie encuentra, ajustar sinónimos.

Publicación y visibilidad

Al crear/editar, el editor define la visibilidad (interna o pública). Si el proceso de la empresa lo exige, el artículo puede pasar por aprobación antes de quedar visible al público. El artículo público solo aparece al visitante después de publicado/aprobado.

Cómo usar: paso a paso

1. Estructura las categorías antes de escribir en volumen (Rehaz por dominio: Red, Correo electrónico, Aplicaciones, Accesos).
2. Escribe por tarea: síntoma → causa → solución en pasos.
3. Define la visibilidad y somete a aprobación cuando sea necesario.
4. Vincula en la respuesta al ticket: en el trámite, referencia o pega el enlace del artículo.
5. Verifica en WhatsApp: los bots pueden sugerir artículos de la KB durante la conversación, cuando esté configurado.
6. Haz seguimiento del feedback y las analíticas: revisa lo que tiene nota baja y lo que genera búsqueda sin resultado.

Reglas de negocio

Regla	Explicación
Publicación	El artículo público solo aparece después de publicado/aprobado.
Permiso	Editar exige permisos de creación/edición; ver la lista interna exige KB_VIEW.
Búsqueda	La calidad depende del índice (Elasticsearch) — el admin reindexa si es necesario.
Ciclo de vida	Los artículos tienen revisión; el conocimiento obsoleto debe ser actualizado o retirado.

Buenas prácticas

• Título con las palabras del cliente, no con jerga interna.
• Un artículo, una tarea. Evita el “super-artículo” que nadie lee hasta el final.
• Revisa lo que tiene nota baja y lo que aparece en búsquedas sin resultado.
• Cierra el ciclo del feedback: responde al lector y actualiza el artículo.
• Aprovecha lo que la operación ya escribe en los trámites internos — muy buen contenido nace allí.

Errores comunes

Situación	Qué hacer
KB “fantasma”, sin actualización	Define responsables y revisión periódica.
Artículo genérico (“el problema puede ser X o Y”)	Escribe procedimiento; el técnico necesita pasos, no posibilidades.
Publicar todo como interno	Lo que el cliente puede resolver por sí mismo debe ir a la KB pública.
Ignorar la búsqueda sin resultado	Es el mapa de lo que falta documentar.

Preguntas frecuentes

¿El cliente ve la KB interna?
No. Solo los artículos marcados como públicos aparecen sin iniciar sesión.

¿Necesito aprobar el artículo antes de publicar?
Depende del proceso configurado; la aprobación garantiza calidad antes de la exposición al cliente.

¿La KB ayuda a reducir tickets?
Sí — es la principal palanca de deflection: el cliente resuelve por sí mismo en la base pública.

Automatice mediante API

La KB interna y la pública tienen endpoints REST propios (por ejemplo, /api/kb/admin/articles, /api/kb/analytics y, en el lado público, /api/public/kb/articles y /api/public/kb/articles/search). Referencia en developer.nyverra.com.

Escenarios de uso: la KB en acción

1. Autoservicio que evita el ticket. El cliente busca “restablecer contraseña”, encuentra el artículo público y resuelve por sí mismo. El ticket que no llega es el más barato de todos. Medir ese deflection es lo que justifica la inversión continua en la base.

2. Primera atención más rápida. El técnico abre el artículo vinculado al tipo de ticket, aplica el procedimiento y cierra en minutos — en lugar de redescubrir la solución. Los artículos vinculados a las categorías transforman el conocimiento en tiempo ahorrado.

3. Onboarding de equipo. Un nuevo operador consulta la KB y reduce la dependencia de los veteranos. El conocimiento sale de la cabeza de unos pocos y se convierte en capacidad del equipo.

4. Soporte en WhatsApp. Los bots pueden sugerir artículos de la KB durante la conversación, resolviendo sin abrir ticket.

Cómo medir la salud de la KB

Indicador	Qué revela
Artículos por categoría (cobertura)	Dónde falta contenido
Búsquedas sin resultado	Qué documentar a continuación
% “útil” por artículo	Calidad percibida
Tiempo desde la última revisión	Conocimiento obsoleto
Visualizaciones de artículos públicos	Deflection en acción

Las búsquedas sin resultado y las notas bajas son el mapa de lo que revisar. Una base saludable no es la más grande — es la más usada y confiable.

Gobernanza del conocimiento

El conocimiento es un activo, y los activos necesitan dueño. Define responsables por dominio (Red, Correo electrónico, Sistemas), un ciclo de revisión y criterios claros de publicación (interno vs público, aprobación). Sin gobernanza, la KB se infla con artículos duplicados y desactualizados — y los usuarios dejan de confiar en ella, que es el peor escenario posible.

Conclusión

La Base de Conocimiento es el activo que hace que el service desk se vuelva más inteligente con cada atención. Con categorías consistentes, búsqueda eficaz, feedback tratado y una KB pública de autoservicio, el Portal Nyverra ITSM reduce tickets repetidos y profesionaliza la experiencia del cliente.