El lunes en que dos redactores del mismo equipo entregaron dos voces de marca distintas
Ambos usaron Claude, ambos siguieron el mismo brief. Uno pegó el manual de marca al principio del chat; el otro confió en que 'ya lo sabía'. La diferencia entre los dos textos explica por qué existen los Projects.
Dos textos, un mismo brief, dos voces distintas
Un equipo de contenido pequeño recibe cada semana el mismo tipo de encargo: redactar el boletín de la marca con un tono cercano pero nunca informal, sin promesas de resultados garantizados, y cerrando siempre con una pregunta abierta al lector. Dos personas del equipo usan Claude para escribirlo. Una pega el manual de tono al principio de cada conversación nueva. La otra, con prisa esa semana, lo omite porque cree que "ya lo tiene interiorizado". El resultado, publicado el mismo día, son dos textos que cualquier lector habitual de la marca distinguiría sin esfuerzo: uno suena a la marca; el otro suena a un asistente de IA genérico con buena ortografía.
Ninguno de los dos se equivocó en el contenido. El problema es más simple y, precisamente por eso, más fácil de pasar por alto: Claude no recuerda nada entre conversaciones sueltas. Cada chat nuevo empieza exactamente en blanco, sin memoria del brief de la semana pasada ni de las correcciones que se hicieron entonces. Pegar el manual "de memoria" no es un atajo válido — es, literalmente, la diferencia entre que el modelo tenga el contexto correcto o no lo tenga en absoluto.
La función que resuelve esto y que casi nadie configura bien
Existe una función pensada exactamente para este problema y que muy pocos equipos aprovechan de verdad: los Projects de Claude. Un Project no es solo una carpeta para ordenar conversaciones — es un espacio con contexto persistente donde se puede cargar el manual de marca, ejemplos de contenido ya aprobado, las audiencias objetivo y una guía de estilo, y ese contexto se aplica automáticamente a cada conversación nueva dentro del Project, sin que nadie tenga que volver a pegarlo ni confiar en su memoria.
No se trata de subir todo el histórico de la marca sin criterio. Los equipos que consiguen mejores resultados cargan cuatro documentos concretos: el manual de tono con ejemplos explícitos de "así sí" y "así no", entre tres y cinco piezas ya publicadas que representen el estándar de calidad esperado, una ficha de audiencias con su lenguaje y objeciones típicas, y una lista corta de afirmaciones prohibidas. Cargar más que esto no mejora el resultado — lo diluye: un Project sobrecargado de documentos genéricos obliga al modelo a filtrar más ruido antes de encontrar lo relevante, y eso se nota en respuestas menos precisas.
El ángulo que casi nadie usa: pedir secuencias completas, no piezas sueltas
Aquí está la parte que la mayoría de guías sobre "Claude para marketing" no explican bien. Cuando se pide contenido pieza por pieza — un email hoy, otro mañana, en chats distintos —, el modelo no tiene forma de recordar qué ya dijo, y es habitual que dos emails de la misma secuencia repitan el mismo gancho o la misma llamada a la acción sin que nadie lo note hasta la revisión final.
La técnica que sí funciona es pedir la secuencia entera en una sola conversación: cinco emails para un lanzamiento, con un objetivo distinto asignado a cada uno — abrir la necesidad, presentar el producto, resolver una objeción, aportar prueba social, cerrar con urgencia real. Al mantener toda la secuencia en el mismo contexto, Claude sí puede variar el gancho y escalar el valor de la propuesta de un email a otro, algo prácticamente imposible cuando cada pieza se redacta en un chat aislado.
De brief a batería de contenido en una sola sesión
Con un Project ya configurado, un flujo realista es: pegar el brief de campaña, pedir primero un artículo largo de referencia, y después pedir explícitamente que ese mismo texto se reconvierta en formatos derivados — publicaciones para redes, un resumen para newsletter, una versión corta para anuncio — todo dentro de la misma conversación. Como el contexto de marca ya está cargado y el texto original permanece a la vista, el resultado mantiene una voz consistente entre formatos sin repetir instrucciones de tono en cada petición.
Esto no sustituye la revisión humana. Claude no conoce datos internos de rendimiento de campaña ni resultados reales de conversión, así que cualquier cifra o afirmación de resultado que aparezca en el texto final debe verificarse contra los datos reales del equipo, no darse por buena porque "suena bien" en el borrador.
Lo que un Project no arregla
Un Project no convierte a Claude en sustituto del equipo de marketing: sigue haciendo falta alguien que apruebe el mensaje final, que conozca el contexto legal de cada afirmación y que decida qué piezas se publican de verdad. Tampoco es una solución mágica si el manual de marca que se carga es ambiguo — si el propio equipo no tiene claro su tono de voz, cargarlo en un Project solo traslada esa ambigüedad al contenido generado, ahora con apariencia de consistencia. Y los documentos cargados no se actualizan solos: si el manual cambia, hay que subir la versión nueva, o Claude seguirá aplicando reglas antiguas sin que nadie lo note hasta que alguien compare dos textos y note la grieta.
Por qué importa hoy
La diferencia entre los dos boletines de aquel lunes no estaba en la habilidad de quien escribió el prompt, sino en si existía o no un Project bien configurado detrás. Es la parte menos vistosa de trabajar con IA generativa — configurar contexto una vez, en lugar de confiar en la memoria cada semana — pero es la que explica por qué algunos equipos logran consistencia de marca real y otros siguen generando piezas sueltas que hay que reescribir a mano antes de publicar.