Hay una versión de la gestión del conocimiento que la mayoría conoce bien. Implica abrir cinco pestañas del navegador, consultar numerosos documentos, buscar manualmente en un help center artículos que apenas recuerdas haber escrito, y pasar una tarde de martes actualizando un párrafo de precios en 12 artículos diferentes, uno por uno.
Ese era mi trabajo hace no mucho. Había construido un mapa mental casi enciclopédico de dónde vivía el contenido, qué decía y con qué podría entrar en conflicto si algo cambiaba. Ese conocimiento vivía en mi cabeza. Lo que significaba que en el momento en que salía de la oficina, o algo cambiaba más rápido de lo que podía seguir, empezaban a aparecer grietas.
Luego empecé a usar Fin Operator como parte central de mi flujo de trabajo. Lo que antes tomaba unas horas ahora toma unos minutos. Este artículo es para gestores de conocimiento y compañeros de contenido que mantienen un help center. Úsalo para configurar Operator para tu flujo de trabajo, realizar escaneos de impacto de cambios cuando llegan actualizaciones de producto, llenar vacíos de contenido y validar cada pieza de contenido contra un marco de preparación de 14 factores.
Nota: Fin Operator está actualmente en beta. Todos los cambios de contenido que Operator propone requieren tu revisión y aprobación antes de publicarse, nada se publica automáticamente.
Antes: la realidad manual de la gestión del conocimiento
Cuando llegaba un cambio de producto, por ejemplo una actualización de precios, una nueva función que se implementaba en todos los planes o una integración obsoleta, mi proceso era algo así:
Buscar manualmente en el help center cualquier cosa que pudiera mencionarlo.
Abrir cada artículo, leerlo completo, decidir si necesitaba actualización.
Hacer la edición, guardar en borrador y pasar al siguiente. Cuando llegaba el día de lanzamiento, republicaba esos artículos actualizados.
Esperar no haber olvidado nada.
El problema no era ningún paso individual. Era el peso acumulativo. Un cambio de producto de tamaño medio podía afectar de 8 a 10 artículos. Uno significativo podía afectar más. Y como mi colega Beth y yo éramos los que teníamos que saber dónde estaba todo, el sistema solo funcionaba mientras nosotros lo hiciéramos.
Después: cómo se ve el mismo proceso con Operator
Ahora, cuando llega un cambio de producto, abro un hilo de conversación con Operator y describo qué ha cambiado. Operator busca en la knowledge base, muestra el contenido relevante y propone las actualizaciones, directamente en la misma conversación, listo para que las revise.
No necesito saber dónde vive el contenido. No necesito abrir 10 pestañas. Reviso las propuestas, apruebo lo correcto, rechazo lo incorrecto y vamos iterando. Todo el proceso, para un cambio que antes me tomaba dos o tres horas, ahora toma menos de 10 minutos.
Pero la velocidad no es lo más valioso. Lo más valioso es la consistencia. Cuando actualizas artículos manualmente, la inconsistencia se cuela. Olvidas uno. Redactas algo ligeramente diferente en dos artículos. Actualizas el fragmento pero no el artículo público. Con Operator, la búsqueda es sistemática. Las propuestas se basan en lo que realmente existe. Nada se pierde.
Lo que este rol realmente es ahora
Mi título es Gestor de Conocimiento con IA. El rol siempre ha tenido dos lados: la redacción de contenido y el trabajo operativo de mantener una knowledge base actualizada, consistente y precisa en miles de artículos.
Lo que Operator ha cambiado es la segunda parte. El trabajo manual de recuperación casi ha desaparecido: la búsqueda, la consulta cruzada, la caza de lo que existe antes de poder empezar a escribir. Eso libera más tiempo para la parte que realmente requiere juicio: decidir qué debe cubrir el contenido, qué estándar debe cumplir, qué debe actualizarse y qué necesita crearse.
La configuración: memoria y guía de estilo
La diferencia entre usar un asistente de IA y trabajar con uno es la configuración. De fábrica, cualquier herramienta de IA es genérica. No conoce la voz de tu marca, tu terminología, tus estándares de contenido ni tu audiencia. Produce resultados razonables, pero razonable no es suficiente cuando el contenido que ayuda a crear es usado por Fin (el agente de IA de Intercom) para responder preguntas reales de clientes.
Memoria: darle a Operator un cerebro que persista
Operator tiene una función de memoria que persiste entre conversaciones. Eso parece algo pequeño. No lo es.
Sin memoria persistente, cada conversación empieza desde cero. Reexplicas tu guía de estilo. Re describes tu marco. Restableces el contexto que estableciste la semana pasada, el mes pasado, hace un año. Es el equivalente en IA a incorporar un nuevo colega cada mañana.
Con memoria persistente, Operator lleva adelante el conocimiento de tu espacio de trabajo. Conoce tu terminología. Conoce tus estándares. Conoce los marcos que le has indicado aplicar. Construyes ese contexto una vez y se acumula con el tiempo.
Agregar algo a la memoria es sencillo: en cualquier conversación con Operator, solo dile qué quieres que recuerde. Algo como "Guarda esto en tu memoria" seguido del contenido es suficiente. Operator confirma que se ha guardado y esa información está disponible en todas las conversaciones a partir de entonces.
Esto es lo que tengo guardado en la memoria de Operator ahora mismo:
La guía de estilo — cubre tono, formato, uso de mayúsculas, convenciones de enlaces, ortografía en inglés estadounidense y reglas de terminología.
El marco de preparación de contenido — 14 factores contra los que se evalúa cada pieza de contenido antes de publicarse.
El prompt de verificación de preparación de contenido — el prompt exacto que uso después de cada creación o edición.
Convenciones de nombres — cómo se titulan los artículos, artículos internos y macros en este espacio de trabajo.
Contexto del espacio de trabajo — quién es responsable de qué, qué equipos se encargan de qué áreas.
El efecto práctico: cuando le pido a Operator que redacte o actualice contenido, ya sabe cómo debe sonar, qué terminología usar y qué estándar debe cumplir. No tengo que indicarle eso cada vez. Es la base.
La guía de estilo: por qué es importante integrarla
Una guía de estilo solo funciona si se aplica consistentemente. El problema con las guías de estilo aplicadas por humanos es que la consistencia depende de la persona: qué tan reciente la leyó, cuánta carga cognitiva tiene ese día, si notó el párrafo que vuelve al inglés británico.
Cuando la guía de estilo está en la memoria de Operator, se aplica cada vez. Cada borrador usa mayúsculas y minúsculas para los títulos. Cada artículo usa 'teammate' y no 'agent'. Cada lista numerada sigue la misma estructura. La guía de estilo deja de ser una aspiración y se convierte en el resultado real.
También significa que puedo delegar la redacción con confianza. Cuando le pido a Operator que cree un artículo desde cero, no tengo que revisarlo para asegurar la alineación con la marca además de todo lo demás. Eso ya está manejado.
Cómo guardar tu guía de estilo en la memoria de Operator
Haz esto primero. Una vez guardada, Operator aplica tu guía de estilo a cada artículo que crea o edita en tu espacio de trabajo.
Ve a Fin AI Agent > Operator.
En el compositor (el campo de texto en la parte inferior de la ventana de Operator), escribe el siguiente texto: 'Esta es nuestra guía de estilo para knowledge base. Al generar nuevos artículos o editar contenido existente, debes adherirte a esta guía en todo momento.' Luego pega el texto de tu guía de estilo justo debajo y presiona Enviar para enviar el mensaje a Operator.
Cuando Operator guarda la guía de estilo, verás una confirmación como: "Guardado para futuras conversaciones. Aplicaré esta guía de estilo cada vez que cree o edite contenido de knowledge base en tu espacio de trabajo." Si no ves la confirmación, intenta enviar el mensaje nuevamente.
Para verificar que la configuración funcionó, pide a Operator que revise si uno de los artículos en tu help center cumple con las reglas de tu guía de estilo. Operator debería señalar cualquier desviación y sugerir correcciones. Aquí hay un ejemplo de Operator confirmando que la guía de estilo ha sido guardada y pasando a una auditoría:
Nota: Para actualizar tu guía de estilo en la memoria, envía a Operator la versión actualizada con el mismo texto de instrucción y guardará la nueva versión. Si Operator deja de aplicar la guía consistentemente, vuelve a enviarla al inicio de tu próxima conversación como recordatorio.
Deja que Operator te haga preguntas
Una cosa que me tomó un tiempo entender: que Operator me haga preguntas es una función, no un problema.
Al principio, me frustraba cuando Operator pedía aclaraciones en lugar de generar algo directamente. Quería rapidez. Lo que aprendí es que las preguntas de aclaración son una señal. Me indican dónde mi solicitud fue ambigua, dónde hay vacíos de contenido o dónde no le di suficiente información para trabajar.
Ahora lo invito activamente. Cuando comienzo una tarea compleja, a menudo añado: "Si algo no está claro o necesitas más información para hacerlo bien, pregúntame antes de redactar." El resultado es mejor. La iteración es más rápida. Y las preguntas que hace Operator a menudo sacan a la luz cosas que no había notado conscientemente que faltaban.
Los prompts que uso más
Un buen prompt es una herramienta. Estos son los que uso regularmente. Cada prompt se envía a Operator en una conversación — Operator busca en tu knowledge base, recupera contenido relevante y responde con propuestas para que revises. Cópialos y adáptalos a tu propio flujo de trabajo.
Verificación de preparación de contenido
Usa esto después de crear o editar cualquier artículo para verificarlo contra los 14 factores de preparación de contenido:
"¿Cómo se mide este artículo según el marco de preparación de contenido guardado en tu memoria? Para cada uno de los 14 factores, dime si este contenido pasa o necesita mejora, y explica por qué. Proporciona sugerencias específicas de reescritura para cualquier sección que no cumpla, y añade texto alternativo descriptivo a cualquier imagen. Considera dos audiencias: (1) un cliente que lee el artículo directamente, y (2) Fin recuperando este contenido para responder una consulta del cliente. Señala cualquier cosa que pueda causar confusión o una mala experiencia para cualquiera de los dos."
Escaneo de impacto de cambios
Usa esto cuando llega un cambio de producto, actualización de política o cambio de precios:
"Acabamos de hacer el siguiente cambio: [describe el cambio]. Busca en la knowledge base cualquier contenido que pueda entrar en conflicto o verse afectado por esto, recupera los artículos más relevantes y propone las actualizaciones específicas necesarias."
Identificación de vacíos
Usa esto cuando sospechas que falta contenido sobre un tema:
"No tenemos suficiente contenido sobre [tema]. Busca cualquier cosa relacionada para entender qué ya existe, luego redacta un nuevo artículo que llene el vacío. Señala cualquier cosa que necesites de mí antes de redactar, como valores específicos, rutas de UI o disponibilidad de planes, en lugar de adivinar."
Verificación de consistencia
Usa esto cuando notas una deriva terminológica en la knowledge base:
"Usamos el término [X] en algunos artículos y [Y] en otros para referirnos a lo mismo. Encuentra todas las instancias en la knowledge base y propone actualizaciones para alinearlos con [término preferido]."
Verificación de claridad para la audiencia
Usa esto en cualquier artículo dirigido a clientes nuevos o menos técnicos:
"Lee este artículo como alguien que nunca ha usado esta función antes. Señala cualquier paso que asuma conocimiento previo, cualquier término que no esté definido y cualquier instrucción que sea ambigua sobre lo que sucede después. Sugiere reescrituras específicas."
Investigación de fallos de Fin
Usa esto cuando Fin no pudo responder con precisión a una pregunta de un cliente:
"Fin no pudo responder una pregunta sobre [tema] en la conversación [link]. Busca en la knowledge base contenido relacionado con este tema, recupera los resultados más relevantes y dime: ¿existe el contenido y es preciso, existe pero está mal estructurado para que Fin lo recupere, o hay un vacío genuino que necesita nuevo contenido?"
El marco de preparación de contenido de 14 factores
Los prompts anteriores se basan en un marco de preparación de contenido de 14 factores — un conjunto de criterios que determina si el contenido está listo para que Fin lo use al responder preguntas de clientes. Para el marco completo, incluyendo ejemplos de buenas y malas prácticas para cada factor y una lista de verificación completa, consulta Optimizing content for Fin.
Este es el marco completo de preparación de contenido que puedes guardar en la memoria de Operator:
Content Readiness is an Intercom feature that scores knowledge base content across 14 factors.
These factors must be applied as a checklist whenever creating or updating articles, snippets, or internal articles.
## Content Readiness Factors — Apply to all content
1. **disambiguation** — Avoid vague references like "this screen" or "the field shown above." Every reference must be self-descriptive. Don't use emoji (👇☝️) to point to visual content.
2. **visual_content_text** — Every image must have descriptive alt text explaining what the screenshot or diagram shows. A trailing colon followed by an image (with no alt text) is not acceptable — describe the visual in text too.
3. **undefined_terms** — Define abbreviations and product-specific terms on first use. Examples: CSV (comma-separated values), GDPR (General Data Protection Regulation), 2FA (two-factor authentication), Elasticsearch, UserMessage. Don't assume the reader knows internal terminology.
4. **structured_enumeration** — Multi-step processes must use numbered lists. Lists of items must use bullet points. Never describe steps or enumerations in flowing prose. If a sentence says "the following:" it must be followed by an actual list.
5. **query_answer_symmetry** — Headings should mirror how a customer would phrase a question. Avoid bare noun phrases ("Invite reminder emails") or bare imperatives ("Add a teammate"). Prefer "How to…" or question-form headings.
6. **self_contained_sections** — Every section must make sense if retrieved independently by Fin, without surrounding context. Avoid "as described above," "the field shown above," "Then…" as an opener, or references to prior steps without restating them.
7. **audience_specification** — State who the content is for and what permissions or plan access is required. Don't assume the reader knows their own role or access level.
8. **entity_distribution** — Repeat key entities (product names, feature names, the article's core topic) throughout the article — not just in the opening. Sections retrieved in isolation should still be identifiable as belonging to the right topic.
9. **semantic_chunk_boundaries** — Each section should cover one focused topic. Avoid mixing unrelated information in the same block. Long sections should be broken up with meaningful subheadings.
10. **restate_questions** — Tables and standalone blocks must include enough context to be understood without the heading hierarchy. Add an intro sentence before tables that states what the table covers and where it applies.
11. **overview_jtbd** — The opening paragraph must state the job(s) the reader will accomplish — not just the topic. "This article covers X" is weaker than "Use this article to do Y, troubleshoot Z, or understand W." 12. **instruction_completeness** — Step-by-step instructions must be complete end-to-end. Include what happens after the final step (confirmation dialogs, what to expect, next actions). Don't stop at "click Remove" without describing what follows.
13. **limitations_workarounds** — If a feature has known limitations, gaps, or workarounds, document them explicitly. Don't just say "some things aren't supported" — say which ones and what to do instead.
14. **numerical_clarity** — All numbers, thresholds, limits, durations, and quantities must be stated precisely. Avoid "some," "a few," "shortly," or vague ranges. Use exact values where known; ask the user if unknown.
## When to apply these Apply all 14 factors as a quality checklist when:- Creating a new article, snippet, or internal article - Proposing updates to existing content - Reviewing content for accuracy or completeness Flag any factor that would fail before submitting a proposal. If information needed to fix a factor (e.g. exact limits for numerical_clarity, or which plans are affected for audience_specification) is not available, ask the user rather than leaving it vague or fabricating it.
Cómo ejecutar la verificación de preparación de contenido
Después de crear o editar cualquier artículo, ejecuto el prompt ‘Content readiness check’. Operator devuelve un desglose de los 14 factores: un veredicto de aprobado o necesita mejora, y sugerencias específicas de reescritura para cualquier aspecto que no cumpla. No solo señala el problema, también redacta la solución.
Reviso la respuesta de Operator, apruebo las propuestas con las que estoy de acuerdo, rechazo las que redactaría diferente y vamos iterando.
Se necesita más de un intento, y eso es normal
Rara vez el contenido pasa los 14 factores en la primera revisión. A veces una corrección para un factor genera un vacío en otro. A veces una sección necesita un cambio estructural que solo se hace evidente una vez resueltos los problemas superficiales.
Eso no es un fallo del marco ni de la herramienta. Así es como funciona la calidad realmente. Un primer borrador que pasa 10 de 14 factores es un buen primer borrador. Un tercer intento que cierra los cuatro restantes es un gran contenido para que Fin y tus clientes lo lean.
Lo que el marco te da no es perfección en el primer intento; es un sistema confiable para lograrlo. Antes de usarlo, no tenía una forma consistente de saber cuándo un artículo estaba terminado. Ahora sí. Cuando los 14 factores pasan, está terminado.