Airtable no te da un cuadro de mando. Te da tablas, vistas y una herramienta llamada Interfaces que llega hasta cierto punto y ahí se detiene.
Un cuadro de mando responde tres preguntas: cómo vamos, contra qué lo comparo, y qué hago hoy al respecto. Las vistas de Airtable responden la primera. Las otras dos las tienes que construir.
Este es el método que sigo, con las decisiones que tomé en siete sistemas que hoy corren en producción. Al final está el criterio de cuándo Airtable no es la respuesta.
Las capturas que verás son todas del mismo sistema —el de contratación de Exposure Digital Marketing— y salen de su demo pública: usuario de prueba y nombres inventados. Los demás sistemas corren con datos reales de cliente y por eso no se fotografían.
Si quieres el esquema y no el método, contesta cinco preguntas en el armador de la estructura del cuadro de mando y te devuelve las tablas, los campos y las vistas listos para copiar en tu base. Es gratis y no pide cuenta.
Paso 1: elige la métrica que manda
Un cuadro de mando con treinta indicadores no se lee. Se abre el primer lunes y nunca más.
En Carshix —una financiera de préstamos con garantía vehicular— el tablero tiene tres números: rotación de capital (días entre desembolso y cierre), porcentaje de capital atorado, y edad promedio de la cartera. Nada más. El negocio es capital que sale, trabaja y regresa; si esos tres están sanos, el negocio está sano.
Así se ve el principio aplicado en el sistema de contratación de Exposure Digital Marketing: cuatro números arriba —candidatos, entrevistas en curso, contratados, vacantes abiertas— y debajo el detalle. Nadie tiene que abrir Airtable para saber cómo va la operación.
La pregunta que hay que contestar antes de abrir Airtable: si solo pudieras ver un número mañana en la mañana, ¿cuál sería? Ese es el centro del tablero. Los demás son contexto.
Paso 2: modela las tablas antes de pensar en la vista
Un cuadro de mando sobre tablas mal relacionadas miente con seguridad y confianza. Es peor que no tenerlo.
El caso más grande que he construido es el de ImpactaVC, su programa Modo Fundraising: veintisiete tablas relacionadas entre sí —postulaciones, founders, startups, pagos, cupones, clases, misiones, asistencias, reglas de automatización— más un CMS público que alimenta el sitio del programa desde las mismas tablas.
Ninguna de esas tablas nació para el tablero. Nacieron para que la operación funcionara. El tablero salió después, casi solo, porque los datos ya estaban bien relacionados.
El error común va al revés: armar la vista bonita sobre una tabla plana que en realidad son tres tablas mal fusionadas. En Colectivo23 rediseñamos exactamente eso —nominaciones duplicadas, personas sin relación con los eventos a los que asistían, ciclo de vida de miembros movido a mano. Antes de cualquier dashboard hubo un rediseño relacional.
Paso 3: congela una base de comparación
Un número sin contra qué compararse no es un cuadro de mando. Es un número.
“Cartera de 4.2 millones” no dice nada. “Cartera de 4.2 millones, 380 mil más que la semana pasada” es información con la que alguien decide algo.
Airtable no guarda historia por sí solo: cuando un registro cambia, el valor anterior desaparece. Si quieres deltas, alguien tiene que fotografiar el estado.
En Carshix eso es un script que corre diario con GitHub Actions y escribe un snapshot en una tabla aparte. El tablero compara el estado de hoy contra el snapshot de hace seis días o más, y de ahí salen los deltas de semana contra semana. Sin ese paso, el tablero solo sabría decir “así vamos hoy”, que es justo lo que no ayuda a decidir.
Paso 4: usa Field IDs, nunca nombres de columna
Esta es la que más caro cuesta aprender, y la aprendí dos veces.
Cuando conectas código a Airtable, la tentación es referirte a las columnas por su nombre: Status, Nombre, Fecha de cierre. Funciona el primer día.
Después alguien del equipo del cliente le agrega un emoji al nombre de la tabla, o cambia “Wage” por “Monthly Salary” porque suena mejor. Airtable no avisa. Tu backend truena con un 403, y truena en silencio: la vista se queda vacía o muestra ceros, sin error visible para quien la está mirando.
Los identificadores internos —fld… para campos, tbl… para tablas— no cambian nunca, aunque renombren todo. La regla en el código de ImpactaVC quedó escrita así: usamos IDs en lugar de nombres porque el equipo a veces renombra tablas y un nombre obsoleto rompe todo el backend en silencio.
Llegué a la misma conclusión, por separado y con meses de diferencia, en el sistema de recursos humanos de Exposure Digital Marketing. Ahí además hay un script que valida el esquema completo contra la base real: si alguien movió un campo, eso se detecta antes de que falle el lunes en producción.
Dos proyectos sin relación, la misma cicatriz. Si te llevas una sola cosa de este artículo, que sea esta.
Paso 5: decide dónde vive la vista
Aquí es donde la mayoría de los artículos sobre este tema terminan y donde empieza lo útil. Hay tres opciones y cada una tiene un punto de quiebre. La pregunta que decide no es cuál se ve mejor, sino quién va a mirar el tablero.
Vistas nativas de Airtable. Agrupar, filtrar, campos calculados. Gratis y ya las tienes. Suficientes cuando quien mira el tablero es la misma persona que edita los datos. Se caen cuando necesitas mostrar algo sin dar acceso a la base completa.
Interfaces de Airtable. El constructor visual de tableros dentro del producto. Bueno para un tablero interno de equipo, sin escribir código. Se cae en tres puntos: no controla permisos con precisión, no lleva tu marca, y no puede mostrarle a cada cliente solo lo suyo.
Una capa propia encima. Airtable se queda como base de datos y la vista la construyes tú. Es lo que hago cuando el tablero lo ve alguien fuera del equipo.
El caso que lo explica mejor es el de Exposure Digital Marketing: una agencia que necesitaba que cada uno de sus clientes viera su propio calendario de contenido, aprobara sus publicaciones y no viera ni por accidente las de otro cliente. Multi-tenant, con la marca de la agencia. Eso en Interfaces no existe. El flujo quedó así: la revisión creativa pasa por Frame.io, Airtable es la fuente de verdad, la capa propia muestra el calendario y recoge aprobaciones, y de ahí sale la publicación.
Los mismos registros de Airtable, en dos vistas distintas según lo que la persona necesita hacer. Como tablero, para mover a alguien de etapa arrastrando su tarjeta:
Y como lista, para buscar y filtrar cuando lo que necesitas es encontrar a alguien:
Ninguna de las dos vistas existe en Airtable. Las tablas sí; la forma de mirarlas es la capa propia.
El mismo criterio aplicó en myCashless, donde el ERP interno maneja cotizaciones, corporativos y socios de crecimiento sobre Airtable, con webhooks que mantienen todo sincronizado. Y aplicó en el sistema de contratación de Exposure, que reemplazó un motor de tareas programadas en Python: Airtable es la fuente de verdad de los candidatos, la vista es propia.
Paso 6: cierra el ciclo con alertas
Un cuadro de mando que nadie abre el lunes no sirve, por bonito que esté. La diferencia entre un tablero y un sistema es que el sistema te busca a ti.
En Carshix hay cinco disparadores definidos: cuando la edad promedio de la cartera cruza un umbral, cuando una operación se acerca a su ventana de salida, y otros tres del mismo tipo. Están expuestos en un endpoint que un orquestador de automatizaciones consulta y convierte en mensajes.
El tablero muestra el estado. La alerta provoca la acción. Sin el segundo, el primero es decoración.
Cuándo Airtable no es la respuesta
Airtable es excelente hasta un punto y conviene saber cuál es.
Si el flujo cruza más de dos herramientas, el motor de automatizaciones se queda corto y esa parte conviene moverla a una herramienta de orquestación dedicada.
Si necesitas cruces sobre millones de filas, drill-downs pesados o modelado analítico, esto no es lo tuyo: ahí va una base de datos real y una herramienta de inteligencia de negocios. Airtable no está construido para ese volumen.
Y si el dato de verdad vive en otro sistema —tu ERP, tu pasarela de pagos, tu CRM—, Airtable como fuente de verdad te va a doler. Ahí sirve como capa de operación encima, no como origen.
En Short Form Media la relación fue justamente esa: un portal que audita los flujos de trabajo de la agencia leyendo Airtable en modo solo lectura, sin escribir nunca. Airtable era una fuente entre varias, no la única.
El resumen
Los seis pasos, en orden: elige la métrica que manda, modela las tablas antes de la vista, congela una base de comparación, usa Field IDs en el código, decide dónde vive la vista según quién la ve, y cierra el ciclo con alertas.
Los siete sistemas de arriba —ImpactaVC, Carshix, Exposure Digital Marketing en sus dos frentes, myCashless, Colectivo23 y Short Form Media— comparten los seis pasos y difieren en el paso 5, que es donde el negocio de cada quien decide.
El recorrido completo de uno de ellos, del panel de métricas a la ficha de una persona:
Tres de ellos están documentados completos, con el problema, lo que se construyó y en qué terminó: ImpactaVC, Exposure DM y Colectivo23.
Si tu caso es un tablero interno para tu equipo, empieza por Interfaces y no contrates a nadie. Si el tablero lo va a ver un cliente, si necesitas que cada quien vea solo lo suyo, o si el lunes en la mañana quieres que el sistema te busque en vez de que tú lo busques, ahí entra construir la capa propia: Dashboards Operativos, en tu dominio y con el código a tu nombre.