Alicante · AtrapaEsaRedProyecto demostrativo · cliente ficticio
Brasa Mansa: una aplicación que cruza reservas, turnos y pedidos en un restaurante
Una aplicación de ejemplo para que un restaurante vea en una sola pantalla cuánta gente viene a cada servicio, qué personal falta y qué pedido cierra antes.
Este es un caso ficticio. El restaurante, las personas, los proveedores, las cifras y los datos de Brasa Mansa están inventados. Lo que sí puedes hacer es abrir la aplicación y probarla.
En la demo los precios, los consumos y las reglas son inventados. No es un registro de jornada, no gestiona nóminas y no sustituye a la información de alérgenos de la carta.
- Abrir la demo (se abre en una pestaña nueva)
Se abre sin registro y sin dejar datos. Se usa entera desde el móvil.
- Te la enseño en 20 minutos (se abre en una pestaña nueva)
Te la enseño yo, con tu negocio en mente.
Un restaurante de brasa inventado, en Alcoy, cierra el pedido de carne del fin de semana el jueves a las 12:00, cuando todavía no ha entrado ni la mitad de las reservas del sábado. Las reservas, los turnos del equipo y los pedidos a proveedores viven cada uno en su sitio y nadie los cruza. Esta aplicación de ejemplo los junta en una sola pantalla, y puedes abrirla y probarla.
La demo en capturas
Seis capturas de la demo, en ordenador y en móvil. Las puedes ver con tus propios ojos abriendo la demo.
En ordenador
1. Toda la semana en una pantalla: lo que viene, quién trabaja y qué falta. 
2. Un servicio por dentro: la previsión, el equipo y el género, juntos. 
3. El pedido se calcula con los cubiertos previstos, y la decisión final es de quien pide. 
4. La reserva del cliente llega sola a la sala y a la cocina, con sus alergias.
En el móvil
5. El cliente reserva desde el móvil, sin cuenta, y avisa de sus alergias. 
6. Cada persona del equipo ve solo sus turnos y lo que necesita saber.
Qué cambiaría en tu caso
Tu restaurante no trabaja como Brasa Mansa, y tu aplicación tampoco sería como esta.
Puede que tu problema no esté en cruzar reservas, turnos y pedidos. Quizá sean los menús de grupo y sus señales, los eventos, el reparto a domicilio, dos locales que comparten personal o una barra que funciona distinto que el comedor. Entonces la aplicación se construiría alrededor de eso: otras pantallas, otros perfiles y otras palabras.
Si no tienes un restaurante, puede que reconozcas el mismo problema con otra forma: una previsión de la que dependen a la vez el personal y las compras. Le pasa a un obrador, a un cáterin, a un hotel pequeño o a una tienda con temporada.
En tu caso cambiaría:
El centro de la aplicación. Aquí es el servicio. En tu caso puede ser el evento, la ruta, la habitación o el pedido.
Las reglas. Aquí hace falta una persona en sala cada 16 cubiertos. Las tuyas son las que ya aplicas, aunque nunca las hayas escrito.
Los perfiles y lo que ve cada uno. Los tuyos, con sus permisos.
Quién entra y quién no. Aquí el comensal solo reserva y el proveedor no entra. Puede que en tu caso sea distinto.
Dónde se usa. Aquí, en una tableta de pie. En tu caso puede ser un móvil en una furgoneta o un ordenador en una oficina.
Lo que entra en la primera versión y lo que se deja para después.
Los datos que ya tienes y si es viable importarlos.
La imagen. La de tu negocio, no la de esta demo.
Por eso el trabajo empieza entendiendo cómo trabajáis, no eligiendo funciones de una lista.
El negocio ficticio
Brasa Mansa · Restaurante es un restaurante inventado, en Alcoy (Alicante): una casa de comidas a la brasa, con carnes, verduras y pescado hechos a fuego lento sobre leña y carbón. Es un solo local, independiente. La localidad existe; el restaurante, no.
Abre de miércoles a domingo: comidas los cinco días y cenas de jueves a sábado. Son 8 servicios a la semana. Un servicio es cada comida o cada cena de un día concreto; «la cena del sábado» es un servicio.
El tamaño del restaurante
- Aforo de 64 plazas: 44 en el comedor (12 mesas) y 20 en la terraza (5 mesas).
- Un equipo de 13 personas: la propietaria y gerente, la jefa de sala, el jefe de cocina, 5 personas en sala, 4 en cocina y 1 en office (limpieza de vajilla y cocina).
- Unas 110 reservas a la semana, que entran por teléfono, WhatsApp, mensajes de Instagram y en persona.
- Unos 430 cubiertos a la semana. Un cubierto es cada persona que come.
- 8 proveedores habituales: carnicería, pescadería, fruta y verdura, panadería, lácteos y huevos, bebidas, bodega, y leña y carbón.
El dato que explica el problema: el pedido de carne del fin de semana se cierra el jueves a las 12:00, cuando todavía no ha entrado ni la mitad de las reservas del sábado.
Su problema
Así trabaja Brasa Mansa antes de la aplicación:
- Las reservas están en una libreta junto al teléfono, más los mensajes de WhatsApp e Instagram que contesta quien puede. A veces una mesa se da dos veces; otras, un grupo grande aparece en la libreta el mismo día.
- El cuadrante es una foto en un grupo de mensajería. El cuadrante es la tabla de quién trabaja cada día. Los cambios se negocian en el chat y la foto se queda vieja. Nadie sabe seguro cuál es la versión buena.
- Los pedidos se hacen de memoria, por teléfono o por audio, cada uno antes de la hora límite de su proveedor. Si el jefe de cocina libra ese día, el pedido sale tarde o no sale.
- Nadie cruza las tres cosas. Un grupo de 14 para el sábado debería avisar a la sala de que falta una persona y a la cocina de que hay que pedir más carne antes del jueves. Hoy eso depende de que alguien se acuerde.
- Se pide de más o de menos. De más, el género se estropea. De menos, se retiran platos de la carta en mitad del servicio.
- Todo depende de tres cabezas: la propietaria, la jefa de sala y el jefe de cocina.
Qué necesitaba
Lo que la primera versión debía resolver:
- Un único libro de reservas, que se pueda consultar y tocar desde la entrada.
- Saber cuántos cubiertos se esperan en cada servicio: los reservados más los que suelen venir sin reserva.
- Que el cuadrante avise cuando un servicio se queda corto de gente.
- Que cada persona vea su semana y pida un cambio sin pasar por el chat.
- Ver qué pedidos cierran hoy y a qué hora.
- Que cada pedido salga con una cantidad propuesta según los cubiertos previstos, y que la decisión final siga siendo de quien pide.
- Anotar lo que llega y lo que falta al recibir el género.
- Que cada persona vea solo lo que necesita.
- Que el comensal reserve desde la web, sin cuenta, y avise de sus alergias, que llegan escritas a la sala y a la cocina.
Lo que se dejó para fases posteriores: cobro de señal a grupos, conexión con el programa de caja, inventario, carta y alérgenos, y avisos automáticos por mensajería.
Dejar cosas fuera es parte del caso: una primera versión útil resuelve lo urgente y puede crecer por fases.
Decisiones de diseño
| Decisión | Por qué |
|---|---|
| El centro de la aplicación es el servicio, no la reserva, el turno ni el pedido | Las tres cosas dependen de la misma pregunta: cuánta gente viene a esta comida o a esta cena. Tres herramientas separadas no se la hacen entre sí. |
| Una sola cifra de previsión, y se ve de dónde sale | Reservados más habituales sin reserva. Quien manda puede corregirla. Una cifra que nadie entiende no se usa. |
| El personal necesario sale de la previsión, con una regla que pone el restaurante | La aplicación no decide cuánta gente hace falta: aplica el criterio de la casa y avisa cuando no se cumple. |
| El pedido se propone, no se envía solo | La cantidad final depende de cosas que la aplicación no sabe: lo que queda en cámara, un plato fuera de carta. La decisión sigue siendo de quien pide. |
| Los pedidos se ordenan por hora límite | Lo que importa es qué cierra antes, no el orden alfabético de los proveedores. |
| Fondo oscuro | La tableta está en la entrada de un comedor a media luz. Una pantalla blanca deslumbra a quien la usa y se ve desde las mesas. |
| Botones grandes y pocas acciones por pantalla | Se usa de pie, con prisa y a veces con una mano ocupada. |
| El comensal entra solo para reservar, sin cuenta | Reservar es lo único que necesita. Así la reserva y sus alergias llegan escritas a la sala y a la cocina, sin pasar por la libreta ni por quien coge el teléfono. |
| El proveedor tampoco entra | Recibe el pedido como hasta ahora, en un mensaje. No se le pide que aprenda nada. |
| Un cambio de turno no vale hasta que lo aprueba su jefe | Acaba con la negociación en el chat y con las dos versiones del cuadrante. |
| Nombres para sentar; teléfonos solo para quien llama | Cada perfil ve lo que necesita para su tarea. |
| Estados con palabra e icono, y un solo rojo para lo que falta | Se entiende de un vistazo y sin depender del color. |
| La marca es la de Brasa Mansa | Enseña la personalización visual: la aplicación se siente del restaurante. |
| Caja, cobros, inventario, carta y nóminas quedan fuera | Una primera versión útil resuelve lo urgente. Lo demás se valora por fases. |
Instalación en móvil y tableta
En un proyecto real, la aplicación se puede instalar en el móvil o en la tableta: aparece como un icono más en la pantalla de inicio y se abre a pantalla completa, sin pasar por App Store ni Google Play.
- Abrir la demo (se abre en una pestaña nueva)
Se abre sin registro y sin dejar datos. Se usa entera desde el móvil.
- Te la enseño en 20 minutos (se abre en una pestaña nueva)
Te la enseño yo, con tu negocio en mente.
Otro proyecto demostrativo
Congreso del comercio local
Mostrador
A tres semanas del congreso, 30 ponentes y 12 patrocinadores tienen cosas pendientes y nadie ve cuáles: están repartidas entre tres hojas de cálculo y el correo de dos personas.
Ver el caso Mostrador
Asesoría de autónomos y pequeñas empresas
Cuarto Creciente
Cada trimestre hay que reunir unas 560 entregas de 140 clientes para presentar 318 trámites en 20 días, y nadie sabe cuántas faltan sin abrir tres hojas y cinco bandejas de correo.
Ver el caso Cuarto Creciente
Empresa de reformas
Tendel Reformas
El presupuesto está en una hoja, los partes en un talonario y los extras de palabra: solo se juntan el día de la factura, cuando ya no se puede corregir nada.
Ver el caso Tendel Reformas
Fisioterapia y estética
Almez
85 bonos vivos apuntados en tarjetas de cartón: nadie sabe cuántas sesiones quedan sin buscar la tarjeta, y los bonos caducan sin aviso.
Ver el caso Almez