Gestión Multilocal de Restaurantes en Argentina: una sola plataforma

La cadena chica argentina — tres, cuatro locales, equipos diferenciados, un mismo dueño — no vive sin tecnología. Vive con tecnología de la peor clase: una planilla por local, un grupo de WhatsApp para coordinar precios, y capturas de pantalla del cierre del día que el dueño mira en el colectivo. La brecha no es falta de herramientas. Hay decenas de sistemas disponibles. La brecha es de modelo: quién puede ver qué, quién aprueba qué, qué métrica existe a nivel cadena y qué queda en el local. Cuando ese modelo se define mal — o directamente no se define — agregar software empeora el problema en lugar de resolverlo. Lo que sigue es la versión sin humo de cómo se arma bien.

Para el contexto completo sobre qué debería resolver un software de gestión en Argentina antes de encarar la escala multilocal, ese artículo es el punto de partida.

El modelo: una cuenta de dueño, múltiples negocios, roles diferenciados

El error más frecuente en una expansión multilocal no es tecnológico — es conceptual. Se trata a cada local como una "sucursal" del negocio central, cuando en la práctica cada local tiene su propio P&L, su propio equipo, su propio ritmo operativo, y en muchos casos hasta su propia razón social o figura impositiva. Tratarlos como ramas de un árbol único es mentirse.

Una plataforma que funciona para cadenas chicas parte de un modelo de cuentas distinto: el dueño tiene una cuenta de propietario con visibilidad consolidada sobre todos los negocios que posee. Cada negocio es una entidad operativa separada — con su propio menú, su propia configuración de mesas, su propio personal, sus propias ventas. Lo que el dueño ve desde arriba es la síntesis: ingresos totales de la semana, food cost comparado entre locales, personal por turno en cada uno.

Este modelo de cuentas es también lo que habilita agregar un local nuevo sin tocar la configuración de los existentes. El tercer restaurante se suma como entidad propia — no como una copia modificada del primero — y desde el día uno el dueño lo ve junto a los otros dos en su panel.

Qué se centraliza

No todo sube. Pero algunas cosas tienen que vivir arriba obligatoriamente, porque su fuente de verdad tiene que ser única.

Precios maestros con override por local. El precio de una milanesa no puede ser una decisión de cada encargado de turno. Existe un precio de lista que el dueño define, y cada local puede ajustarlo dentro de un rango autorizado — útil para diferencias de zona, costos de alquiler distintos, o estacionalidad. El override queda registrado; el dueño ve la variación.

Contabilidad consolidada. Los ingresos de los cuatro locales tienen que poder verse sumados y también desglosados. La brecha de cobro — la diferencia entre lo facturado y lo efectivamente cobrado — es una métrica de cadena, no de local. Si un local tiene una brecha del 8% y los otros tres del 2%, eso es una señal de gestión o de problema operativo que no aparece si mirás cada local por separado.

Reportes financieros agrupados. El cierre semanal de la cadena — ingresos totales, costo de mercadería, margen bruto, payroll — tiene que poder generarse con un solo movimiento. No debería requerir abrir cuatro reportes y sumar columnas en una planilla.

Política de personal. Los niveles de acceso, las reglas de aprobación de descuentos, y los umbrales de competencias (comps) se definen una vez y se aplican uniformemente. Cada local puede tener sus propios empleados, pero las reglas del juego son las mismas en todos lados.

Para la gestión de reservas centralizada por local, la guía sobre sistema de reservas online en Buenos Aires desarrolla el modelo de disponibilidad por turno que se integra en este esquema.

Qué se queda en cada local

La autonomía operativa del local no es un defecto del modelo — es una necesidad. El gerente del local (GM) tiene que poder tomar decisiones sobre lo que hace al servicio sin esperar aprobación de nadie.

Cocina y flujo de órdenes. Qué está disponible hoy, qué 86 (producto agotado), en qué orden salen los platos. Estas son decisiones de la operación del momento, no de la cadena.

Gestión de mesas. El plano del salón, la asignación por turno, el manejo de listas de espera. Cada local tiene su geometría y su dinámica propia.

Horarios del personal de turno. El GM arma el horario de su equipo dentro de los rangos que define la política central. Puede ajustar por demanda, eventos, o bajas de último momento.

Decisiones operativas del día. Un descuento puntual por un problema con un plato, un cambio en la disposición de mesas para un evento privado, una excepción de horario. El GM tiene autonomía sobre estas cosas porque está en el piso y tiene el contexto.

Lo que el sistema hace es registrar todo — incluyendo las excepciones. El dueño puede ver las decisiones del GM, no para micromanagear, sino para detectar patrones. Si el GM del local de Palermo hace voids cinco veces por semana y el de San Telmo hace uno, eso merece una conversación.

RBAC — quién ve qué, quién cobra qué, quién aprueba qué

El control de acceso basado en roles (RBAC) es la columna vertebral del modelo multilocal. Sin él, tenés dos opciones malas: dar acceso total a todos (no escalable, no seguro) o restringir tanto que el sistema se vuelve inútil para el equipo operativo.

Un RBAC bien implementado en un contexto multilocal tiene esta lógica:

El dueño ve todos los locales, todos los reportes, toda la contabilidad. Puede modificar precios maestros, crear negocios nuevos, y ver el panel consolidado. No necesita login por local — ve todo desde una sola vista.

El gerente de local (GM) ve su local. Puede ver reportes de ventas y personal de su restaurante, aprobar voids hasta cierto monto, y gestionar el personal de su equipo. No ve los otros locales ni la contabilidad consolidada de la cadena.

El mozo ve sus mesas. Puede tomar pedidos, procesar pagos, y emitir descuentos menores sin aprobación (si la política lo permite). No ve los reportes de ventas ni el inventario.

Los voids requieren aprobación del GM. Si un mozo necesita anular un plato después de que la comanda salió a cocina, eso no puede hacerse en silencio. La aprobación del GM es el registro de que el void fue legítimo.

Las comps superan el umbral, van al dueño. Un GM puede autorizar una comida de cortesía hasta $X. Por encima de ese umbral, la aprobación sube al dueño. No porque no se confíe en el GM — sino porque los números grandes merecen visibilidad.

La gestión granular de roles y permisos en Payverge implementa exactamente este modelo: roles por local, reglas de aprobación configurables, y un log de auditoría que el dueño puede revisar en cualquier momento.

Migrar sin parar el servicio

El riesgo más grande de una migración mal planificada no es técnico — es que el equipo pierda confianza en el sistema en los primeros días y vuelva a los métodos anteriores. Para que eso no pase, la migración tiene que ser por etapas, con un local piloto antes de tocar los demás.

Etapa 1 — Piloto (semanas 1 y 2). Elegí el local más estable operativamente, no el más grande. Configurá el sistema completo para ese local: menú, mesas, personal, roles. El resto de los locales sigue operando como siempre. El objetivo de estas dos semanas no es perfección — es familiaridad del equipo con el flujo y detección de fricciones antes de escalar.

Etapa 2 — Operación dual (semanas 3 y 4). El local piloto opera con el sistema nuevo. Los otros locales todavía están en el sistema anterior. El dueño ya empieza a ver la diferencia: el piloto tiene datos limpios, el resto sigue con capturas de WhatsApp. Esa diferencia es el mejor argumento interno para acelerar la migración.

Etapa 3 — Corte por local. Una vez que el piloto está estable, los locales restantes se incorporan de a uno — no todos juntos. Cada incorporación toma una semana: carga del menú, alta del personal, configuración de roles, y dos o tres días de acompañamiento antes de declarar el corte. El local anterior se desactiva solo cuando el nuevo está andando sin problemas.

Qué no hacer. No migrar todos los locales el mismo fin de semana. No eliminar el sistema anterior antes de que el nuevo tenga dos semanas de operación limpia. No asumir que el equipo va a aprender solo — el onboarding tiene que ser presencial, con el mozo real haciendo el flujo completo antes del primer turno en producción.

El resultado al final de seis a ocho semanas es una cadena donde el dueño tiene visibilidad real, el GM tiene autonomía sobre su local, y el mozo tiene una herramienta que no lo frena. Sin planillas. Sin capturas de WhatsApp. Sin sumar columnas los lunes.