POS para pizzerías en Perú: tamaños, mitades, extras, cocina y delivery

Tamaños, sabores, mitades y adicionales multiplican combinaciones, mientras delivery y salón compiten por la misma capacidad de cocina. Ese contexto importa porque una función aislada puede verse correcta en una demo y fallar cuando el negocio mezcla canales, personas y decisiones bajo presión. Antes de comparar proveedores, dibuja una operación de principio a fin y marca exactamente dónde hoy se pierde información, se repite una pregunta o se depende de memoria.

En este caso la decisión clave es modelar el pedido con opciones claras y conservar prioridad hasta el despacho. Tradúcela a una prueba observable: usa productos, modalidades y roles parecidos a los del negocio; cambia algo a mitad del flujo y comprueba si todos siguen viendo la misma orden. Una plataforma útil no obliga a reinterpretar lo que el cliente ya eligió ni a crear una segunda versión del pedido para que otra área pueda trabajar.

La secuencia que debes probar es Pedido → Configuración → Cocina → Listo → Asignación → Entrega. Haz varias operaciones casi al mismo tiempo y observa qué parte empieza a exigir coordinación verbal. Si una modificación, un cambio de modalidad o una corrección de cobro obliga a abrir un chat paralelo, anótalo: esa fricción se multiplicará todos los días.

Fuerza también tres excepciones reales: Mitad de pizza mal interpretada, Pedido online reingresado manualmente, Driver asignado antes de tiempo. La recuperación revela si el sistema tiene estados intermedios, permisos claros y trazabilidad suficiente. Un flujo que solo funciona cuando nadie se equivoca no está listo para una operación comercial exigente.

Para una pizzería con salón, recojo y delivery, pide evidencia concreta sobre Tamaños y sabores, Mitades y adicionales, Prioridad de cocina, Delivery y recojo. Después pregunta qué cambia cuando aumentan pedidos, usuarios, productos, comprobantes o locales. La misma función puede ser suficiente hoy y convertirse en un cuello de botella si depende de límites que nadie explicó durante la venta.

Finalmente define una línea base: cuánto tarda hoy el equipo, cuántas correcciones realiza y qué pasos siguen fuera del sistema. No necesitas convertir cada minuto en soles para decidir. Basta medir antes y después con el mismo método para saber si la herramienta realmente simplificó el trabajo que pretendías mejorar.

Prueba “Tamaños y sabores” usando datos que se parezcan a los de una pizzería con salón, recojo y delivery. Empieza en pedido y continúa hasta configuración sin preparar el sistema para que todo salga perfecto. Cambia una condición a mitad del recorrido y revisa si “Mitades y adicionales” sigue teniendo contexto. Incluye también el caso “Mitad de pizza mal interpretada”: si la recuperación exige borrar la operación o crear una segunda versión, todavía existe una debilidad que debes resolver antes de depender del flujo.

Para evaluar “Mitades y adicionales”, observa qué ve la persona que recibe el trabajo después de configuración. No basta con que el dato exista en algún menú; debe aparecer en el momento en que cambia una decisión. Contrástalo con “Prioridad de cocina” y documenta qué sucede ante “Pedido online reingresado manualmente”. Una buena implementación deja una señal comprensible, una autoridad clara para corregir y un historial suficiente para que el siguiente turno no tenga que reconstruir lo ocurrido.

“Prioridad de cocina” merece una prueba de responsabilidad: quién puede modificarlo, quién solo lo consulta y qué parte del flujo se actualiza cuando cambia. Recorre Cocina → Listo con dos roles distintos y verifica que “Delivery y recojo” no dependa de permisos excesivos. Después provoca “Driver asignado antes de tiempo”. Si la única forma de continuar es compartir credenciales, editar datos sin rastro o pedir a una persona concreta que intervenga, el proceso todavía no está preparado para crecer con seguridad.

Con “Delivery y recojo” conviene mirar escala y no solo funcionalidad. Repite Listo → Asignación varias veces, mezcla operaciones normales con “Mitad de pizza mal interpretada” y comprueba si “Tamaños y sabores” conserva velocidad y claridad. Pregunta además qué límite contractual, técnico o de configuración cambia con más volumen. El objetivo no es exigir capacidad infinita; es saber con anticipación cuándo la operación necesitará otro plan, más hardware o una configuración distinta para seguir siendo predecible.

Simula “Mitad de pizza mal interpretada” durante pedido. La prueba termina solo cuando la operación llega otra vez a cocina con un estado coherente. Revisa qué mensaje recibió el equipo, quién tuvo permiso para actuar y cómo quedó afectado “Mitades y adicionales”. Esta disciplina evita aceptar una demo donde el error se resuelve reiniciando, borrando o corrigiendo directamente en base de datos: acciones que no representan una recuperación sostenible para un restaurante en producción.

Cuando ocurra “Pedido online reingresado manualmente”, mide tiempo hasta detección y tiempo hasta resolución por separado. Un problema puede ser fácil de corregir pero difícil de descubrir, y esa demora puede contaminar configuración, listo o “Prioridad de cocina”. Pide que el sistema muestre suficiente evidencia para distinguir causa de síntoma. Si todos ven que algo está mal pero nadie puede explicar por qué, el flujo todavía produce trabajo de investigación que debe formar parte de la evaluación.

Usa “Driver asignado antes de tiempo” como prueba de cambio de turno. Una persona inicia el caso en cocina y otra debe poder terminarlo en asignación sin una explicación verbal privada. Comprueba que “Delivery y recojo” conserve contexto, que las acciones sensibles tengan autor y que los comentarios necesarios queden junto a la operación. La continuidad entre personas es una señal fuerte de que el proceso vive en el sistema y no solamente en la memoria del equipo.

Una pizzería pone a prueba el modelado de variantes porque tamaño, masa, sabores, mitades y extras pueden combinarse de muchas formas. Durante la demo crea una pizza de un sabor, otra mitad y mitad y una tercera con adicionales distintos por lado si el negocio realmente lo ofrece. Observa cómo se calcula el precio y, sobre todo, cómo llega la información a cocina. Una representación excelente para caja pero ilegible para quien prepara no resuelve el flujo completo.

La capacidad de horno introduce una restricción que un POS genérico puede ignorar. No hace falta que el software controle físicamente cada espacio del horno para ser útil, pero sí debe conservar tiempos y estados de preparación que permitan entender por qué una cola crece. Simula varios tamaños entrando juntos y revisa si el equipo puede priorizar una promesa de recojo o delivery sin perder la relación con el pedido original. La prioridad debe poder explicarse, no depender de quién grita primero.

En delivery, la zona y el momento de asignación importan tanto como la dirección. Un pedido puede estar correctamente tomado pero ser poco viable si la dirección está fuera de cobertura o si el repartidor llega mucho antes que el producto. Prueba una dirección normal, una limítrofe y otra que requiera corrección. Si el sistema no detecta el problema hasta después de cocinar, el costo de la validación tardía forma parte de la decisión de compra.

Los combos de pizza, bebida y complemento también afectan inventario. Un combo debería dejar consumo explicable de sus componentes aunque comercialmente se venda como una sola oferta. Pide mostrar cómo se reflejaría un agotado de bebida o un cambio de acompañamiento. El objetivo no es conseguir una configuración perfecta en diez minutos, sino verificar que el modelo puede representar la forma real de vender sin llenar el catálogo de duplicados imposibles de mantener.