Tu centro de ayuda debe responder preguntas, no listarlas

Help Center

Un usuario quiere cancelar. Escribe «dejen de cobrarme» en el buscador de tu centro de ayuda.

Tu mejor artículo se titula Gestionar tu suscripción. No contiene la palabra «cobrarme». Tampoco «dejen». La búsqueda por palabras clave no devuelve nada, y el usuario abre un ticket de soporte que tu documentación podría haber resuelto.

Así fallan normalmente los centros de ayuda, y no es un problema de contenido. El artículo lo escribiste. Solo que la búsqueda no supo encontrarlo.

Dos vocabularios que no coinciden

Los artículos de ayuda los escribe gente que conoce el producto. Usa los sustantivos del producto: suscripción, asiento, espacio de trabajo, habilitación. Las búsquedas las escribe gente que todavía no conoce el producto. Usa los suyos: plan, usuario, cuenta, acceso.

La búsqueda por palabras clave necesita que esos dos vocabularios coincidan. A menudo no coinciden, y la brecha es mayor justo para los usuarios que más ayuda necesitan: los nuevos.

La búsqueda semántica cierra la brecha

La búsqueda del centro de ayuda de Kookee es semántica. Los artículos se convierten en vectores, la consulta se convierte de la misma forma, y la coincidencia se busca por significado, no por caracteres compartidos:

TypeScript
const results = await kookee.help.search({ query: 'dejen de cobrarme', limit: 5 });

results.forEach((result) => {
  result.title;        // 'Gestionar tu suscripción'
  result.matchedChunk; // el fragmento que coincidió
  result.category;     // { name, slug }
});

En la práctica, matchedChunk es lo que más útil me resulta. No recibes solo el artículo, sino el fragmento que respondió a la consulta, así que tu página de resultados puede mostrar la respuesta ahí mismo en lugar de una lista de enlaces azules que hay que repasar.

Después, quita el buscador del todo

La búsqueda sigue siendo una interfaz en la que el trabajo lo hace el usuario. Formula una consulta, repasa los resultados, abre un artículo y vuelve a repasarlo en busca del párrafo que le sirve.

El widget de chat se salta esos pasos. Responde en lenguaje natural, a partir de tus artículos de ayuda publicados, y cita las fuentes que usó:

tsx
import { KookeeChatWidget } from '@kookee/react/chat';
import '@kookee/react/chat.css';

<KookeeChatWidget
  clientOptions={{ apiKey: 'your-api-key' }}
  title="Ayuda"
  greeting="¡Hola! ¿En qué puedo ayudarte?"
  suggestions={['¿Cómo empiezo?', '¿Qué planes de precios hay?']}
  onSourceClick={(source) => window.open(`/help/${source.slug}`, '_blank')}
/>

Esa es toda la integración. Es una burbuja flotante en cualquier página, admite los temas light, dark o auto y acepta un primaryColor, para que no parezca un producto ajeno pegado al tuyo.

Aquí importa de dónde salen las respuestas. El widget responde a partir de tus artículos y enlaza a ellos. Cuando no sabe algo, eso es un hueco en tu documentación; y onSourceClick, junto con las visitas de cada artículo, te dice qué artículos hacen de verdad el trabajo.

Escribe para la pregunta, no para la función

De todo esto salen dos conclusiones, y las dos tienen que ver con cómo escribes.

La búsqueda semántica compara significados, así que un artículo que empieza planteando el problema del usuario con sus propias palabras aparecerá en los resultados. Uno que empieza con «Este artículo describe la interfaz de gestión de suscripciones» no aparecerá, por bueno que sea el resto.

Y los números te dicen cuándo te has equivocado. Un artículo con mucho tráfico que sigue generando la misma pregunta al soporte no es un artículo que falta. Es un artículo equivocado: la gente lo encuentra y no le ayuda. Y esa es la señal más clara sobre qué corregir que puede darte un centro de ayuda.