Todo conectado y automatizado

Esta semana Claude lee en Barner las graduaciones de los pedidos de gafas y propone qué lente pedir. Antes de fiarnos lo comparamos con 1.033 gafas decididas a mano: coincidió en el 88%. Ese caso, con todo el detalle, va al final.

Esta edición va de conectar Claude a los programas que ya usas: qué es un conector, las tres formas de hacerlo y en qué orden las pruebo, y qué acceso le doy y cuál no.

Claude sabe muchísimo de lo que hay en internet. De tu negocio, tal cual lo instalas, no tiene ni idea: no sabe si usas Gmail, Slack, Google Sheets, Shopify u Odoo (nuestro ERP), ni qué hay dentro. Mientras no llegue a tus datos te toca copiar y pegar, y si copias y pegas, no automatizas nada.

Un conector es lo que deja a Claude leer y escribir en un programa que ya pagas. Con Gmail conectado le preguntas qué tienes pendiente esta semana y te contesta leyendo tu correo (si has configurado bien tu memoria infinita, que comentaremos en otra newsletter). Es la diferencia entre un chat y un equipo.

Hay tres maneras de conectar Claude con un programa. Yo las pruebo en este orden y bajo un peldaño solo cuando el de arriba no llega.

1. Conector nativo. Claude ya lo trae: Gmail, Calendar, Drive, Slack. Un clic.

2. MCP. Una conexión ya hecha que publica la propia herramienta: la añades en Claude y Claude sabe qué le puede pedir. Le interesa a la herramienta tanto como a ti: si Beehiiv (desde donde enviamos la newsletter diaria de Digital Brain) está conectado a Claude, se ahorra montar los informes que yo le pediría, que quizá son distintos de los que pediría otra newsletter: tendrán sus parecidos y sus diferencias.

3. API propia, o Apps Script si es cosa de Google. Una API es la puerta por la que un programa deja que otro le pida cosas; Apps Script es donde Google te deja escribir programas pequeños que tocan tu Gmail o tus hojas. Cuando no hay conector ni MCP, te montas tú el programa que habla con esa puerta. Y "montar" hoy es pedírselo a Claude.

Mi desviación: cada vez me voy más directo a la API, porque puedo ser mucho más concreto y preciso en lo que le pido. Me gusta más que el MCP.

Se activa en Personalizar, Conectores. Eliges el programa, haces login o te autentificas según te lo pida, le das a permitir y ya está. En la ficha del conector ves la lista de herramientas que le da a Claude, y en su configuración decides, por grupos o una a una, qué puede hacer sin preguntar, qué te pide aprobación (la manita) y qué nunca.

En Gmail hay algo nuevo desde que lo expliqué en mayo: entonces el conector no enviaba, te dejaba el borrador y lo mandabas tú. Hoy puede enviar, responder y reenviar. Yo tengo las de lectura en libre y las 23 de escritura y borrado, enviar incluido, con aprobación: redacta, me lo enseña, y no sale nada sin mi clic.

Las rutinas que corren en mi Mac con Claude Code sí usan ese conector: el resumen de la mañana sale por ahí. Pero lo que tiene que salir aunque mi ordenador esté apagado no puede depender de él. El conector ya me ha fallado dos días enteros en agosto, con cero conectores en las tres pasadas de la newsletter diaria. Por eso el envío de las rutinas del servidor va por otra puerta: un Apps Script que vive dentro de mi cuenta de Google (en Barner, además, correo directo por SMTP para facturas, fletes y reportes con adjunto). El Apps Script no lo escribí yo. Esto es lo que le dicté a Claude en mayo, tal cual:

Te devuelve un código, lo pegas en script.google.com, en el menú Implementar eliges "aplicación web" y te da una dirección, una URL. Esa URL es la que le pasas a Claude para que envíe. Trátala como una contraseña: quien la tenga puede mandar correos desde tu cuenta.

Beehiiv es desde donde enviamos la newsletter diaria de Digital Brain, y tiene MCP oficial. Se añade en Conectores, "añadir conector personalizado": pegas la URL que te da Beehiiv, le pones nombre y metes la clave API, que es una contraseña larga para programas y sale de los ajustes de tu cuenta de Beehiiv.

Cuando lo expliqué en mayo, ese MCP solo leía: cuántas newsletters se han enviado, cuánta gente abrió cada una, cuántos hicieron clic en el sponsor. Con eso monté la gráfica de aperturas por edición sin entrar en Beehiiv ni una vez. Las newsletters las escribíamos y subíamos nosotros.

Desde junio también escribe, y hoy el borrador de la newsletter diaria de noticias de Digital Brain lo crea Claude directamente en Beehiiv. Lo que hacía una persona copiando y pegando bloques ahora lo hace la conexión, y esa persona revisa.

Y el truco que uso muchísimo. Un MCP carga todas sus funciones cada vez que lo llamas. Si trae 30 y tú siempre usas la misma, Claude se lee las 30 antes de contestar, y eso se descuenta de tu límite de uso. Lo que hago: la sesión normal con el MCP y, al acabar, le digo:

Una skill son las instrucciones escritas una vez, lo de la edición anterior. No siempre se puede. Cuando se puede, el resultado es una skill de 100 líneas frente a un MCP de 30 funciones cargado entero. Mismo resultado, mucho menos gasto de tu límite.

El Sponsor Tracker es un Google Sheet donde llevamos qué sponsor va en cada newsletter. Cada mañana a las ocho un proceso automático apunta la newsletter del día anterior en su fila y va actualizando las métricas del sponsor los días siguientes. La última vez que lo enseñé, un sponsor llevaba casi 400 clics únicos y yo lo leí en la hoja sin haber entrado en ninguna herramienta. Antes era entrar, clicar, buscar el link, copiar.

Escribe en la hoja por Apps Script. Le pasas a Claude el ID del Sheet y las columnas, le dices qué quieres que pase, te da el script y lo pegas en Extensiones, Apps Script, implementar.

Y Odoo, el ERP de Barner, va por API. La tienda B2B para distribuidores y agentes lee el catálogo, el stock y los clientes que pueden entrar, y escribe pedidos y poco más. Los precios no los toca. ¿Por qué? Para que nadie me rompa nada, principalmente.

Drive no. Es un clic y no lo doy. Barner factura unos cuantos millones de euros y no quiero darle todavía a un programa informático el acceso a todos los documentos. Si quiero que vea algo, lo descargo y lo pongo en la carpeta del proyecto. Llamadme paranoico.

El 2FA de seguridad en el móvil, nunca en el mismo correo. Google Authenticator, o SMS al teléfono. Si el código de LinkedIn te llega por email y le das a un programa acceso a ese email, quien entre ahí entra en todo.

Escritura después de lectura. Empieza en solo lectura, mira cómo lo usa, y sube permisos cuando lo hayas comprobado.

Un MCP no te da acceso a todo. El de Beehiiv estuvo meses solo leyendo. Mira qué funciones expone antes de contar con él.

Cada conector encendido ocupa parte de lo que Claude puede leer en una conversación, antes de que tú escribas nada. Los que no uses, apagados.

Lo que tiene que salir con el ordenador apagado no depende de un conector. Un conector vive en tu sesión; una rutina del servidor necesita su propia puerta.

Apps Script es más lento que una API o un MCP. Para una hoja que se mira cada mañana da igual.

Lo que hay hoy entre Claude y Barner o Digital Brain, con lo que hace cada conexión. Es la lista entera; no hace falta tener ni la mitad.

Barner vende gafas graduadas. Cada pedido con graduación caía en un Google Sheet, y ahí una persona decidía a mano qué lente pedir al laboratorio: el índice y tipo de lente según la necesidad de nuestro cliente, el estado con colores, y la ficha que va dentro de la caja. Todo eso vivía en la cabeza de una persona y en los colores de una hoja. El día que esa persona falta, nadie más sabe pedir.

Esto empezó como una skill programada: cada hora cogía las graduaciones de la app con la que las captamos en Shopify y las ponía en ese Google Sheet. Ha avanzado a que el Sheet ya no decide. Los estados, la lente y las incidencias se cambian en el panel y se guardan en una base de datos con su historial; la hoja sigue recibiendo los pedidos nuevos, el panel la lee cada hora y le reescribe lo que cambia.

Desde el 9 de septiembre lo puede hacer quien tenga acceso al panel, desde una página de nuestro panel interno montada en dos días. Es todo puerta 3. A cada gafa le aplica la guía del laboratorio pasada a reglas y propone qué lente pedir según la necesidad del cliente. Pregunta a Shopify por API si el pedido ya se envió, guarda cada cambio con quién lo hizo, lee con Claude por API la graduación de la foto que sube el cliente, e imprime las fichas para la caja y la lista de picking en el orden del almacén.

Antes de darle la llave lo pasamos contra 1.033 gafas decididas a mano. Acuerdo del 88%. Y en lo que no coincidía apareció algo que no sabíamos: en un tipo de lente se estaba pidiendo, en 39 de 43 casos, una distinta de la que dice la guía del laboratorio (la lente que tocaba de la misma calidad, pero a otro proveedor). Hasta ahora nadie se había dado cuenta. Ahí manda la guía.

La decisión de que el Sheet ya no mande la tomamos el segundo día, por esto: el panel refrescaba cada hora y la hoja se seguía tocando a mano, y eso dejaba hasta 59 minutos en los que alguien podía pedir una lente de un pedido ya cancelado. Cuando dos sitios pueden decir cosas distintas, uno tiene que mandar.

Lo que no está hecho. El pedido al laboratorio no sale solo todavía: tenemos un script que genera el pedido en el formato de su web, pendiente de cargar su listado de lentes y formas para engancharlo al panel. El correo al cliente preguntando si quiere las lentes para lejos o para cerca sigue saliendo por una automatización aparte a las 11:00, y jubilarla es el paso tres. Y el primer día el refresco horario no corrió: estaba programado en un minuto que nuestro lanzador de tareas nunca mira. Nada hecho en dos días es robusto; se va haciendo robusto a base de esto.

¿Qué proceso de tu empresa vive hoy en la cabeza de una sola persona y en los colores de una hoja? Respóndeme con el nombre del proceso y te digo por cuál de las tres puertas entraría yo.