# Dejar a alguien de soporte trabajando con Claude > **Para qué es esto.** El plan para sentarse una hora con alguien del área de soporte > —que no programa— y dejarlo trabajando con Claude en serio: tiquetes, correos, > planificación, y preguntas sobre los sistemas. > > Se escribió para **Erick Pineda, gerente de soporte** (13-ago-2026), pero sirve igual > para el siguiente. Lo hace Manuel, que es quien puede habilitar conectores. > > Antes de esto, que lea [`GUIA-CLAUDE-PARA-TODOS.md`](GUIA-CLAUDE-PARA-TODOS.md) — la > sección «Si usás Claude en el navegador». Son cinco minutos y evita la mitad de las > preguntas. --- ## Lo primero: qué va a poder hacer y qué no Conviene decírselo de entrada, para que no descubra los límites chocándose. | Lo que pide | ¿Se puede hoy? | |---|---| | Redactar el tiquete y dejarlo listo | **Sí** | | **Crear** el tiquete en Freshdesk desde el chat | **No todavía** — ver el final | | Redactar correos a clientes y al equipo | **Sí**, y los deja en borrador | | Preguntar cómo funciona un módulo del sistema | **Sí**, con el conocimiento cargado | | Preguntar por el código de los repositorios | **Sí**, si se habilita GitHub | | Armar una planificación, un proyecto, una agenda | **Sí** | | Analizar la carga de la mesa y proponer mejoras | **Sí**, pegándole los datos | | **Leer** los tiquetes de Freshdesk solo | **No todavía** | **La regla para él, en una línea:** Claude le prepara todo, y **el último clic lo da él**. Eso no es una limitación temporal a lamentar — es el diseño: nada sale a un cliente ni se cierra sin que una persona lo mire. --- ## Paso 1 — Lo que Manuel habilita antes de sentarse (15 minutos) En **claude.ai → organización de MacroBase → Settings → Connectors**. Cada conector se habilita para la organización, y después **cada persona hace su propio acceso**: Erick va a ver únicamente lo que su cuenta de Google ya le deja ver. | Conector | Para qué lo va a usar Erick | |---|---| | **Gmail** | Redactar correos a clientes y al equipo, y dejarlos **en borrador**. Leer un hilo para resumirlo. | | **Google Calendar** | Armar su semana, agendar seguimientos, ver dónde entra una reunión. | | **Google Drive** | Manuales, actas, documentos de proyecto. | | **GitHub** *(verificar que esté en el catálogo)* | Preguntar qué hace un módulo, buscar dónde se resuelve algo, leer un cambio. **Sólo lectura.** | ⚠️ **Freshdesk no está.** El del catálogo se llama **Freshservice** y es otro producto de Freshworks: **no ve estos tiquetes**. No habilitarlo pensando que sirve. ### Son dos puertas, y la segunda no la podés abrir vos Habilitar el conector **no le conecta la cuenta a nadie**. Sólo dice «en MacroBase se permite usar Gmail». Después **cada persona autoriza la suya**, desde su propia sesión, con su usuario de Google. Por eso **no podés comprobarlo desde tu cuenta**: Claude va a ver exactamente lo que el Google Workspace de esa persona le deje ver, ni más ni menos. Si ella no tiene acceso a un buzón, su Claude tampoco. **La comprobación es parte de la sesión de abajo**, en la pantalla de él y escribiendo él: | Que escriba | Qué comprueba | |---|---| | *«buscá el último correo que me mandó [un cliente] y resumímelo en tres líneas»* | Gmail | | *«¿qué tengo mañana en la agenda?»* | Calendar | | *«buscá el manual de [algo] en mi Drive»* | Drive | Dos minutos, y sirven doble: comprueban el conector **y** le enseñan cómo se pide. **Si algo falla, el lugar del problema es distinto según el síntoma:** - **No le aparece el conector para conectarlo** → falta habilitarlo en la organización. Se arregla en tu Settings → Connectors. - **Lo conecta pero no encuentra nada** → es permiso de Google Workspace, no de Claude. Ahí el problema está del otro lado. --- ## Paso 2 — Crear su Proyecto (20 minutos, con él presente) Un **Proyecto** es lo que hace que no tenga que explicar el contexto cada vez. Sin esto, cada conversación arranca de cero y él termina copiando y pegando lo mismo todos los días. **Uno solo para empezar.** No tres. Cuando se le quede corto, se parte. En **Proyectos → Crear**, nombre: **Soporte MacroBase**. ### 2a. Instrucciones del proyecto Esto va en «Instrucciones». Es el texto que Claude lee antes de cada respuesta: ``` Trabajo en MacroBase como gerente de soporte. No programo. Cómo quiero que me respondas: - En español, sin términos técnicos. Si tenés que usar uno, explicámelo la primera vez. - Directo: primero qué hacer, después el porqué si hace falta. - Si algo no lo sabés o no lo podés verificar, decímelo. Prefiero un "no sé" a una respuesta que suena bien y está mal. - Si lo que te pido depende de un dato que no tenés, pedímelo antes de responder, no después. Cuando redactes algo que va a un cliente: - Cortés y concreto, sin prometer fechas que yo no te di. - Dejámelo como borrador para que yo lo revise. Nunca lo mandes solo. Cuando redactes un tiquete de Freshdesk, dame siempre estos campos: - Asunto (una línea, que se entienda sin abrir) - Descripción real (qué pasa, desde cuándo, a quién le pasa) - Cliente - Tipo: Incidente / Problema / Desarrollo / Pregunta / Seguimiento - Prioridad, y por qué esa - Cómo reproducirlo, paso a paso - Qué se necesita para poder trabajarlo (archivo, captura, usuario) Reglas de la casa que quiero que respetes: - Nada se cierra sin el visto bueno del cliente. - Antes de que yo lo pase a programación, decime si con lo que hay alcanza para reproducir el problema. Si el reporte ya trae una captura o un dato que lo deja claro, no me pidas más por cumplir; si de verdad falta algo, decime exactamente qué. - Si el problema aparece en una carga masiva o importación, hay que pedir el archivo exacto que falla: sin él no se reproduce. ``` ### 2b. Conocimiento del proyecto Esto va en «Conocimiento». **Sin esto el Proyecto no sirve de mucho**: son los archivos que Claude va a tener siempre a mano. ⚠️ **Ojo con `REGLAS-EQUIPO.md`: no lo subas.** Ese archivo dice, en sus primeras líneas, que es la **fuente única** y que las reglas **no se copian a ningún lado**. Subirlo al Conocimiento crea exactamente eso: una copia que se congela el día que se sube y que en un mes va a contradecir al original sin que nadie se entere. - **Si habilitaste GitHub**, no hace falta copiarlo: pedile *«leé `REGLAS-EQUIPO.md` del repo mbinv»* y lo lee del original, siempre al día. Ésa es la forma correcta. - **Si no**, y hace falta igual, subilo sabiendo que es una foto: ponele la fecha en el nombre y volvé a subirlo cuando las reglas cambien. Sí conviene subir: 1. **`GUIA-CLAUDE-PARA-TODOS.md`** — para que Claude sepa qué le puede pedir a él. Cambia poco y no es normativa. Y estos dos, de [`conocimiento-soporte/`](conocimiento-soporte/), que se hicieron para esto: 2. **[`estados-y-campos-freshdesk.md`](conocimiento-soporte/estados-y-campos-freshdesk.md)** — qué significa cada estado **acá**, por qué el tipo decide el plazo, y qué campos son obligatorios. Sin esto, Claude sugiere mover tiquetes a estados que en MacroBase quieren decir otra cosa. 3. **[`clientes-y-sitios.md`](conocimiento-soporte/clientes-y-sitios.md)** — qué sitio le corresponde a cada cliente. Es lo que programación necesita y lo que más se pierde cuando el reporte llega por WhatsApp. > **Y decíselo explícito:** las conversaciones que abra **fuera** del Proyecto no ven nada > de esto. Tiene que entrar por Proyectos → Soporte MacroBase y trabajar ahí adentro. --- ## Paso 3 — Las cinco cosas que va a pedir, con la forma de pedirlas (20 minutos) Esta es la parte que hay que hacer **con él, escribiendo él**. No alcanza con mostrárselo. ### 1. Armar un tiquete a partir de un reporte confuso > *«Un cliente me escribió esto: [pega el correo o el WhatsApp]. Armame el tiquete con > todos los campos. Si falta algo para poder trabajarlo, decime qué le tengo que pedir > antes de abrirlo.»* Lo que gana: deja de abrir tiquetes que programación devuelve por incompletos. **La parte de «qué falta» es la que más vale** — es la que hoy se descubre tres días después. ### 2. Escribirle a un cliente > *«Escribile a [cliente] que su problema quedó resuelto y va en la próxima > actualización. Que no suene a que fue culpa de él. Dejámelo en borrador.»* Claude lo deja **en borrador en su Gmail**. Él lo lee y lo manda. Nunca sale solo. ### 3. Entender un módulo sin molestar a programación > *«¿Cómo funciona el cuadre de caja en el Back Office? Explicámelo como para > explicárselo a un cliente, sin términos técnicos.»* Con GitHub habilitado puede ir más lejos: *«buscá en el repositorio mbinv dónde se calcula el costo promedio y decime en palabras simples qué hace»*. ### 4. Planificar la semana > *«Estos son mis tiquetes abiertos: [pega la lista]. Armame el orden de la semana > considerando que los urgentes de cliente van primero y que el martes tengo la reunión de > Scaling Up. Decime cuáles no voy a alcanzar, para avisar antes.»* **Lo último es lo importante**: avisar antes de incumplir vale más que cumplir justo. ### 5. Mirar la operación con distancia > *«Estos son los tiquetes de la mesa del último mes: [pega el export]. Decime qué patrón > ves: qué se repite, qué tipo de reporte llega mal, y qué tres cosas cambiarías para que > entren menos tiquetes evitables.»* Acá es donde un gerente de soporte le saca más provecho, y es lo que ningún panel le da. --- ## Paso 4 — Lo que NO debe hacer (5 minutos, pero decirlo) - **No mandar nada a un cliente sin leerlo.** Claude redacta bien y se equivoca con seguridad: puede afirmar una causa que no verificó. - **No pedirle que cierre tiquetes**, ni siquiera cuando pueda. Nada se cierra sin el visto bueno del cliente — esa es regla de la casa, no del sistema. - **No pegar datos de clientes que no hagan falta.** Para entender un problema no se necesita la base de datos entera. - **No instalar nada.** Todo lo suyo es en el navegador. Si algún correo le pide correr un instalador, no era para él. --- ## Lo que queda bloqueado, y de qué depende **Crear y leer tiquetes de Freshdesk desde el chat.** No hay conector oficial. Hay uno propio escrito y probado — tiquete [#23057](https://macrobase.freshdesk.com/a/tickets/23057), repo `mcp-freshdesk` — pero está **sin desplegar**, y a propósito: espera una decisión de Manuel entre dos formas de identidad. | Forma de identidad | Cómo se ve en Freshdesk | Qué cuesta | |---|---|---| | **Una de servicio** | todo queda a nombre del mismo agente | Rápido. **Pero se pierde la traza por persona**, que es justo lo que necesitan los KPIs automáticos | | **Una por agente** | cada quien firma lo suyo | La traza queda intacta. Bastante más trabajo, sin implementar | Mientras tanto **hay una vía que funciona hoy**: Freshdesk abre tiquete con cualquier correo que llegue a soporte. Con Gmail habilitado, Claude le deja el correo en borrador, él lo manda, y el tiquete nace. ⚠️ **Con una trampa que hay que decirle:** los tiquetes que nacen por correo **entran sin tipo**, y por eso caen en la política de soporte —4 horas— y nacen vencidos. Si usa esa vía, que **clasifique el tiquete apenas entre**. Y algo más, que ya está resuelto por diseño: ese conector **nunca va a poder cerrar, resolver ni borrar tiquetes.** No es un olvido — es para que «nunca `Cerrado` sin el visto bueno del cliente» deje de ser una regla que hay que recordar y pase a ser imposible.