Mantener al día instrucciones y fuentes

El equipo de soporte de una empresa de suscripciones redacta respuestas con un Project compartido. Las instrucciones dicen que el cliente puede pedir el reembolso dentro de los 30 días. Hace dos semanas la empresa bajó el plazo a 14 días y actualizó la web. Nadie tocó el Project. Desde entonces, cada uno de los ocho agentes corrige a mano la frase del reembolso en casi todos los borradores, y a algunos clientes ya se les prometió un reembolso que no corresponde.

Un Project no se entera solo de que cambió la política. Alguien tiene que contárselo, en el lugar correcto.

Se corrige una vez, en la fuente

Si la regla vieja está en la configuración, corregirla en cada chat o en cada borrador es atacar el síntoma. Claude no “aprende” de las correcciones que los agentes hacen a mano en sus borradores; el próximo chat vuelve a leer la misma instrucción vieja.

La regla:

1. Encontrá dónde vive el dato viejo: las instrucciones del proyecto, uno o varios archivos del conocimiento, o los dos.
2. Corregilo ahí, una sola vez, en todos los lugares donde se repite.
3. Sacá la versión anterior. Si quedan dos políticas cargadas con nombres parecidos, Claude puede responder con cualquiera de las dos.

El objetivo es que el Project sea la fuente única de verdad (single source of truth) del equipo: una sola versión vigente (current version) de cada documento, y ninguna fuente desactualizada (outdated source) esperando que alguien la recupere.

Lo que no arregla el problema

Lo que se propone	Por qué no alcanza
“Si los documentos se contradicen, preferí el más nuevo”	Claude no siempre puede saber cuál es más nuevo, y la versión vieja sigue cargada
Renombrar el archivo viejo como VIEJO_NO_USAR	Sigue en el conocimiento y se puede recuperar igual
Abrir un chat nuevo para cada respuesta	Un chat nuevo del mismo Project lee la misma configuración
Recordarle al equipo que revise la frase antes de mandar	Depende de que nadie se olvide; el error sigue en la fuente
Armar un Project nuevo desde cero	Funciona hoy, pero el año que viene pasa lo mismo si nadie se ocupa

Que no vuelva a pasar

Las fuentes se desactualizan solas; nadie las limpia si no le toca a alguien. Por eso cada Project necesita:

• Un responsable del proyecto (project owner): la persona que actualiza instrucciones y conocimiento. En los proyectos compartidos de Team y Enterprise, solo quienes tienen permiso de edición (can edit) pueden cambiar instrucciones y conocimiento; quienes tienen can view chatean pero no editan. Conviene que ese permiso lo tengan pocas personas, con nombre y apellido.
• Un disparador claro: cada vez que cambia una política, un precio o un procedimiento, el responsable actualiza el Project. Sirve que el área que cambia la política le avise.
• Una revisión periódica (periodic review), por ejemplo trimestral: repasar la lista de archivos, sacar duplicados y versiones viejas, releer las instrucciones.
• Una prueba después de cada cambio: unas pocas preguntas fijas cuya respuesta correcta se conoce (“¿cuántos días hay para pedir un reembolso?”) para confirmar que el Project responde con el dato nuevo.

Las trampas típicas

• Que cada agente siga corrigiendo a mano “hasta que Claude aprenda”.
• Subir la política nueva sin sacar la vieja.
• Resolver el conflicto con una instrucción en vez de limpiar las fuentes.
• Arreglar el caso puntual y no definir quién se ocupa la próxima vez.
• Darle permiso de edición a todo el equipo “para que cualquiera lo arregle”.

En el examen

Si el escenario dice que cambió una política y el Project sigue con el dato viejo, la primera acción es corregir la configuración (instrucciones y archivos que repitan el dato). Si hay dos versiones cargadas, la respuesta saca la vieja; si además pregunta cómo evitar que se repita, suma un responsable que revise las fuentes cuando cambia una política. Descartá los parches: instrucciones de “preferí lo nuevo”, renombres, chats nuevos y recordatorios al equipo.