Blog · Operaciones
Toda planilla operativa es un sistema de la misma forma en que una torre de Jenga es un edificio. Acá tenés cómo darte cuenta cuando la tuya está a una pieza mal sacada de derrumbarse — y qué hacer antes de que pase.
La mayoría de las pymes corre su operación en una planilla por mucho más tiempo del que deberían. La transición de 'esta planilla funciona' a 'esta planilla es el riesgo más grande de la operación' pasa de a poco, hasta que pasa de golpe. Las tres señales de que cruzaste la línea: (1) más de una persona la edita por día y tuviste al menos un merge conflict / sobrescritura este trimestre; (2) más del 30% del tiempo del equipo en ese proceso se gasta arreglando la planilla en vez de hacer el trabajo real; (3) no podés contestar 'quién cambió qué y cuándo' sin investigación forense. Si dos son verdad, dejaste de tener una planilla — tenés una aplicación sin documentar y sin backup.
Una planilla que corre tu operación es casi siempre la herramienta más barata que vas a lamentar haber dejado. Costo mensual: $0. Costo de cambiar: se siente enorme. Entonces nadie cambia hasta que algo se rompe, y cuando se rompe, sale caro: un error de payroll, un deal perdido, una fecha regulatoria que se pasa, un cliente cobrado dos veces, un inventario mal contado.
El costo escondido tiene cuatro buckets que casi nunca aparecen en la línea de SaaS del presupuesto:
Abajo están las tres señales diagnósticas que usamos con clientes. Si dos son verdad, la opción "no hacer nada" ya no es más barata — solo está costando en otra línea.
Varias personas editan la planilla el mismo día, y al menos una vez en los últimos 90 días alguien sobrescribió los cambios de otra persona. Quizás tenés un mensaje de Slack que dice algo tipo: "¿quién borró la fila de totales??".
Por qué importa: Google Sheets y Excel manejan ediciones concurrentes con last-write-wins. Eso está bien para documentos. Es un desastre silencioso para sistemas de registro. Cuanto más continúa, más tu equipo arma protocolos informales alrededor de la herramienta ("nadie toque la planilla entre 9 y 10am mientras Maria concilia") que funcionan como parches de compatibilidad para un software que nunca debió ser un sistema.
Más de 2 editores diarios + un "sí" en las filas 2–3 = señal #1 confirmada.
Más del 30% del tiempo que tu equipo gasta en este proceso se va en la planilla misma, no en el trabajo real que la planilla supuestamente debería soportar. La planilla se convirtió en su propio trabajo.
Qué significa "mantenimiento" en la práctica:
Preguntale al equipo dueño del proceso: "si no tuvieras que tocar la planilla para nada, ¿cuántas horas/sem te llevaría este proceso?" Después preguntale: "¿cuántas horas/sem le dedicás ahora realmente?" El delta dividido por el segundo número es tu ratio de mantenimiento. Si es >30%, señal #2 confirmada.
Números reales que hemos visto en pymes: un equipo de 6 personas de sales ops gastaba 14 horas/sem combinadas solo manteniendo consistente una planilla de tracking de leads. A $45/h cargado, son $32.760/año de payroll yendo a plomería de planillas.
No podés contestar "quién cambió qué y cuándo" sin investigación forense. El historial de versiones muestra ediciones a nivel celda pero no te dice qué evento de negocio las disparó. "La celda B14 cambió de 12.500 a 14.300 el martes a las 14:47" no es lo mismo que "Diego actualizó el valor del deal después de que el rep negoció un aumento".
Esto se vuelve un problema real apenas tenés que:
Google Sheets guarda historial por 30 días por default. El de Excel depende de la config de OneDrive. Ninguno te dice por qué cambió algo — solo que cambió. En el momento que el "por qué" importa, la planilla es el sistema equivocado.
¿Una señal en aislamiento? Probablemente manejable. ¿Dos señales en simultáneo? Cruzaste la línea. Las interacciones que compundean son las que matan operaciones:
Si querés un auto-diagnóstico guiado, el árbol de decisión Planilla o Software recorre seis preguntas y te da un veredicto en 2 minutos.
El error más caro acá es saltar directo de planilla a software a medida cuando una herramienta más liviana hubiera servido. El reemplazo correcto depende de cuán estable está el proceso. Procesos estables pueden ir directo a custom; procesos que todavía están cambiando deberían pasar primero por low-code.
Si querés estimar el costo de build específico para tu proceso, la calculadora de presupuesto te da un rango. O leé cuánto cuesta realmente un proyecto de automatización en 2026 para entender la cuenta de fondo.
La mayoría de las migraciones fallidas de planilla a sistema fallan por las mismas cuatro razones. Ninguna es sobre tecnología.
Cuando (a) una sola persona la administra día a día, (b) el ratio de mantenimiento está por debajo del 15%, (c) no necesitás audit trail más allá del historial de versiones, y (d) el proceso rara vez cambia. Muchas operaciones viven en planillas para siempre y está perfecto. El problema no es la planilla — es correr una operación sobre una que ya se está quebrando bajo uso multi-persona, alto volumen y necesidad de auditoría.
Tres tests rápidos. (1) ¿Podés describir tu proceso en los primitivos de Airtable (vistas + registros + automatizaciones)? Si sí, Airtable te alcanza. (2) ¿Necesitás lógica de proceso que Airtable no expresa limpio (aprobaciones multi-paso con branching, cálculos complejos, integraciones con herramientas no-estándar)? Si sí, lo vas a superar. (3) ¿Estás arriba de 30 usuarios o 50K registros? Estás pegando la zona de incomodidad de Airtable — custom o Retool son más costo-efectivos pasada esa escala.
A Airtable o Notion: 1–3 días la migración en sí, más 2–4 semanas de correr en paralelo antes de cortar. A una herramienta interna Retool/Bubble: 2–4 semanas de build + 2–4 semanas en paralelo. A una aplicación a medida: 5–8 semanas de build + 4–6 semanas en paralelo. El período en paralelo no es negociable — es donde encontrás los casos borde que la planilla estaba manejando silenciosamente.
Ayuda pero no elimina el problema. El co-authoring de Microsoft 365 reduce sobrescrituras accidentales y te da mejor historial de versiones. Pero igual no te da audit trail a nivel registro atado a eventos de negocio, control de acceso por roles a nivel fila, reglas de validación enforced server-side, ni la capacidad de exponer solo un subset de data a usuarios específicos. Si solo tenés la señal #1 (concurrencia) y no las #2 ni #3, Excel/Sheets moderno usualmente alcanza.
Hacé la cuenta del costo escondido honestamente primero. Un 'mantenedor de planillas' dedicado a $45/h cargado × 20 horas/sem = $46.800/año — todos los años, para siempre. Una migración a Airtable cuesta $1.000–$3.000 una vez y ~$2.500/año de licencias. Un reemplazo custom cuesta $14.000–$30.000 una vez y ~$3.000/año de hosting. Incluso el camino más caro recupera la inversión en el año 2. La respuesta 'contratemos alguien' casi nunca gana la cuenta si la hacés honestamente.
No sabemos — pero la regla de 2 de 3 está diseñada para auto-administrarse. Si podés responder honestamente las preguntas diagnósticas (edición multi-persona diaria + una sobrescritura en los últimos 90 días + >30% ratio de mantenimiento + ceguera de auditoría), ya tenés tu respuesta. Si querés una segunda opinión, el árbol de decisión Planilla o Software en /resources recorre seis preguntas y te da un veredicto en 2 minutos.
Blog
Contanos qué hace el proceso y cuánta gente lo toca. Volvemos con un camino — Airtable, Retool o custom — y un número. Sin venta agresiva si low-code es la respuesta correcta.
Contanos tu problema →
