POS para restaurante fine dining: guía de elección
En una demostración perfecta, el vendedor conoce cada botón y utiliza una mesa sin modificaciones, una cuenta simple y una conexión estable. Tu operación real tiene cursos que se adelantan, alergias que requieren protocolo, cambios de asiento, una botella de cava privada, depósitos, cortesías y una red que puede fallar durante el cobro.
Elegir el POS de un restaurante fine dining exige cambiar el método: no preguntes cuántas funciones tiene; entrega un RFP, obliga a ejecutar tus escenarios y acepta el sistema solo cuando la evidencia cumple criterios definidos.
Este artículo es un procedimiento de selección, no un ranking de marcas. La comparación fine dining vs casual define cómo cambia el modelo de servicio; la guía de software por precio calcula el costo total. Aquí construimos la prueba.
Respuesta corta
- Convierte el servicio en requisitos y datos antes de pedir demos.
- Distingue criterios de descarte, puntuables y contractuales.
- Haz que todos ejecuten el mismo guion con las mismas excepciones.
- Exige evidencia de integración, seguridad, continuidad y exportación.
- Pilota con criterios de aceptación y un rollback practicado.
- No atribuyas a Kavasoft ni al POS integraciones que no se demostraron.
Forma un equipo de decisión que represente el servicio
El proyecto no pertenece solo a gerencia o sistemas. Nombra un responsable final y un representante por flujo:
- sala: mesas, posiciones, modificaciones, cursos y cuenta;
- cocina: estaciones, tiempos, reenvíos, alergias y contingencia;
- bar o sommellerie: añadas, copas, descorche e inventario;
- caja y finanzas: pagos, propina, devoluciones, cierre y conciliación;
- administración: menú, recetas, compras, permisos y reportes;
- privacidad o jurídico: datos de comensales, contrato y proveedores;
- tecnología: red, dispositivos, identidades, integraciones y soporte.
Cada persona aporta cinco casos frecuentes, tres excepciones costosas y un fallo que ya haya ocurrido. Reúne tickets anonimizados, diagramas, tiempos y bitácoras. Así el RFP sale de evidencia propia, no de una lista genérica descargada.
Separa tres tipos de requisito
Criterios de descarte
Si fallan, no sigues evaluando. Ejemplos: facturación o fiscalización requerida en tu jurisdicción; compatibilidad con el procesador contratado; exportación mínima; operación en los dispositivos aprobados; segregación de roles; o capacidad demostrada para enviar y retener cursos.
No declares “offline obligatorio” sin especificar el resultado. Define si necesitas abrir mesa, capturar, imprimir, cobrar, cerrar o sincronizar, durante cuánto tiempo y con qué límites.
Criterios puntuables
Permiten comparar experiencia y costo: pasos para modificar, velocidad de entrenamiento, claridad de cocina, flexibilidad de reportes, administración multiárea, observabilidad, soporte y costo total. Establece escala y evidencia antes de conocer al proveedor.
Compromisos contractuales
No se resuelven con una demo: alcance, precio, niveles de servicio, mantenimiento, seguridad, ubicación y retorno de datos, cambios, subencargados, soporte, implementación, aceptación, cancelación y salida. Lo que sea decisivo debe aparecer en orden, anexo o contrato aplicable.
Estructura de un RFP útil
Un documento breve y específico obtiene mejores respuestas que cien preguntas de sí/no.
1. Contexto operativo
Describe país, concepto, horarios, sedes, asientos, estaciones, cubiertos por franja, cantidad de cajas y dispositivos, menú, canales y fechas restringidas. Añade el crecimiento probable sin prometer una apertura.
2. Alcance funcional
Incluye mesa, asientos, cursos, modificadores, cuentas, pagos, depósitos, cocina, bar, inventario, recetas, reportes, permisos y auditoría. Para cada uno escribe un resultado observable.
3. Interfaces y datos
Lista reservaciones, adquirencia, facturación, contabilidad, nómina, delivery, inventario y cava. Identifica sistema de registro, campos, dirección, frecuencia y dueño. “API disponible” no equivale a integración lista.
4. Operación técnica
Documenta red, sistemas operativos, dispositivos, impresoras, KDS, conectividad secundaria, monitoreo, actualizaciones, modo degradado, respaldo y recuperación. Pide una matriz de responsabilidades.
5. Implementación y servicio
Solicita equipo, entregables, dependencias, capacitación por rol, soporte de salida en vivo, severidades, horarios, escalamiento, idioma y criterios de aceptación. No impongas “treinta días” si migración, fiscalización o hardware requieren otro plazo.
6. Comercial y salida
Pide precio por sede, caja, pantalla, usuario y módulo; hardware, pagos, integración, servicio profesional, impuestos y renovación. Incluye formato de exportación, asistencia, borrado, continuidad y costo de terminación.
Guion de demostración: seis pruebas que revelan el producto
Entrega datos ficticios al proveedor y evita que cambie el orden. Graba solo con autorización y sin información real de clientes.
Prueba 1: servicio por cursos
Abre una mesa de cuatro con menú degustación y maridaje. Asigna asiento, captura todos los cursos, retén el segundo y libera el primero. Adelanta un plato para una persona, cambia el ritmo del resto y revisa qué ve cada estación.
Aceptación: cocina recibe información íntegra una sola vez; sala ve estado; la edición conserva autor y hora; el cierre no pierde el vínculo entre asiento, curso y artículo.
Prueba 2: modificación compleja
Cambia una preparación, retira un ingrediente, agrega una guarnición y marca una restricción que activa el protocolo interno. Después sustituye el plato cuando la cocina no puede garantizar la preparación.
Aceptación: la instrucción crítica se distingue de una preferencia, llega a la estación correcta, requiere las confirmaciones definidas y queda auditada. El POS no debe presentar una inferencia automática como garantía de seguridad alimentaria.
Prueba 3: botella propia y cava privada
Registra una botella vendida por el restaurante, luego un descorche y después el retiro de una botella de un miembro. Separa inventarios y cargos. Corrige el miembro antes de confirmar y revisa el historial.
Aceptación: el POS maneja venta y descorche según alcance; la herramienta especializada registra propietario, movimiento y evidencia cuando aplica; la integración, si existe, evita doble descuento y conserva identificadores. Si no existe integración, el procedimiento manual tiene folio y reconciliación.
Prueba 4: división y corrección de cuenta
Divide alimentos por asiento, vinos entre dos personas, aplica un depósito y registra una cortesía autorizada. Mueve un artículo después del primer intento de pago y completa con dos formas.
Aceptación: no duplica cargos, respeta permisos, conserva el depósito, calcula según la configuración aprobada y deja rastro de anulaciones y descuentos.
Prueba 5: interrupción de red
Con un entorno seguro, corta la dependencia acordada. Intenta consultar mesas, capturar, enviar, cobrar y cerrar. Restablece, sincroniza y busca duplicados o conflictos.
Aceptación: el equipo entiende el estado; solo funcionan las capacidades documentadas; la cola es visible; la reconciliación identifica pendientes y no crea órdenes o pagos dobles. La guía de uptime y continuidad amplía esta prueba.
Prueba 6: cierre y auditoría
Haz un cierre con efectivo, tarjetas, propina, depósito, devolución, comp y pedido pendiente. Exporta ventas, impuestos, pagos y bitácora. Rastrea una cifra desde reporte hasta transacción.
Aceptación: totales cuadran con los casos; diferencias quedan explicadas; exportación tiene identificadores reutilizables y no depende de copiar pantallas.
Matriz de evidencia y puntuación
No permitas respuestas “sí” sin prueba. Usa cuatro niveles:
| Resultado | Evidencia | Tratamiento |
|---|---|---|
| Cumple | Ejecutado en demo o piloto y documentado | Puntúa completo |
| Cumple con configuración | Pasos, responsable, plazo y costo definidos | Puntúa según esfuerzo |
| Depende de tercero | Contrato, versión, soporte y prueba del tercero | Riesgo y costo separados |
| No demostrado | Promesa verbal, roadmap o respuesta ambigua | No cuenta como disponible |
Para cada requisito registra propietario, severidad, resultado, captura o reporte, versión probada, brecha, acción, costo y condición contractual. Un roadmap puede ser interesante, pero no debe superar una función disponible y probada.
Evita porcentajes de peso copiados. Si una función sostiene seguridad, fiscalización o continuidad, conviértela en descarte. Para lo demás, pondera según volumen, frecuencia e impacto de tu operación.
Contrato de integración: más que una API
Para cada conexión crea un anexo técnico-operativo:
- sistema de registro de cada dato;
- identificador compartido;
- campos obligatorios y traducción de estados;
- frecuencia, latencia y ventana de mantenimiento;
- autenticación, permisos y rotación de credenciales;
- reintentos, idempotencia y manejo de duplicados;
- cola de errores, alerta, dueño y tiempo de atención;
- reconciliación y corrección;
- versiones, cambios y pruebas;
- soporte entre proveedores;
- costo, terminación y exportación.
Una API abierta no confirma que Kavasoft u otro sistema tenga un conector listo. Tampoco garantiza que el proveedor del POS apoye la integración. Exige una prueba punta a punta y una responsabilidad clara cuando dos compañías participan.
Seguridad de pagos y datos personales
PCI DSS no es una medalla genérica del POS. El PCI Security Standards Council explica que el estándar establece requisitos técnicos y operativos base para proteger datos de cuentas de pago y alcanza a entidades que almacenan, procesan o transmiten esos datos, así como a quienes pueden impactar su entorno.
Pide un diagrama del flujo de tarjeta y confirma con adquirente y asesor competente el alcance de validación del comercio. Prefiere reducir exposición: terminales y soluciones aprobadas, tokenización cuando corresponda, ningún dato sensible en notas, segmentación de red, cuentas individuales, privilegio mínimo, MFA administrativo, registros, parches y procedimiento de incidentes.
Para datos de comensales, revisa aviso, finalidad, base aplicable, consentimiento cuando corresponda, acceso, conservación, derechos y proveedores. En México, consulta la LFPDPPP vigente. Notas de salud o alergias pueden ser sensibles; minimízalas y obtén asesoría jurídica para su tratamiento. El restaurante no traslada toda su responsabilidad por contratar un SaaS.
Prueba también:
- alta, baja y cambio de rol de una persona;
- aprobación de descuento, comp, devolución y reapertura;
- exportación masiva y quién puede ejecutarla;
- bloqueo o borrado remoto de dispositivo;
- registro de acceso y edición;
- respuesta ante credencial comprometida.
Migración: define qué se mueve y qué se archiva
No todo dato histórico merece entrar al nuevo POS. Clasifica:
- operativo al arranque: menú, precios, impuestos, mesas, roles y dispositivos;
- necesario para continuidad: saldos, depósitos, gift cards, órdenes abiertas y referencias;
- histórico consultable: ventas, recetas o reportes que pueden quedar en archivo controlado;
- datos personales: solo lo necesario, exacto y permitido;
- dato obsoleto o duplicado: corregir, conservar según obligación o eliminar de forma procedente.
Haz conteos y totales antes y después. Muestrea artículos, precios, impuestos, permisos y clientes ficticios. Conserva trazabilidad de transformaciones. La migración “terminó” cuando los controles cuadran, no cuando el archivo se cargó.
Piloto y aceptación sin poner en riesgo la operación
El piloto debe abarcar un menú, estación, turno o local representativo, con plan autorizado de reversa. No pruebes solo en capacitación: simula picos y después opera en condiciones controladas.
Define de antemano:
- criterios funcionales por escenario;
- rendimiento y tiempo máximo aceptable por paso;
- incidencias críticas, mayores y menores;
- exactitud de reportes y conciliación;
- tasa tolerable de registros pendientes, idealmente cero para pagos duplicados;
- capacitación por rol y cobertura de turnos;
- evidencia de exportación y restauración;
- responsable que firma cada resultado.
No existe una duración universal. El piloto termina cuando cubre suficientes ciclos y excepciones para respaldar la decisión. Si falla un criterio de descarte, corrige y repite; no lo compenses con más funciones.
Go-live y rollback
El cambio requiere ventana, responsables, inventario de dispositivos, contactos, monitoreo y criterios de aborto. Congela cambios de menú durante la transición cuando sea viable. Confirma que caja, cocina, pagos, impuestos e integraciones usan la versión probada.
El rollback no significa mantener dos sistemas escribiendo datos indefinidamente. Define punto de decisión, sistema autorizado, captura durante contingencia y reconciliación. Practícalo. Conserva el sistema anterior solo en la medida contractualmente permitida y con accesos controlados.
Después del arranque revisa diariamente órdenes, pagos, impuestos, anulaciones, colas, integraciones y atajos manuales. Cierra brechas antes de añadir módulos.
Papel de Kavasoft en la selección
Kavasoft puede complementar el POS cuando el restaurante opera cavas privadas y necesita inventario por miembro, movimientos, fotografías y trazabilidad. No lo presentes como función nativa del POS ni prometas sincronización automática sin evidencia.
Incluye el caso de botella propia en el RFP. Define qué sistema crea el identificador, qué evento origina el movimiento, quién confirma, cómo se evita doble descuento y cómo se reconcilia sin conexión. Pide que cualquier integración aparezca en alcance, precio, soporte y criterio de aceptación.
Un POS adecuado no es el más famoso ni el que gana una tabla. Es el que supera tus escenarios, protege datos y pagos, entrega evidencia operativa y permite salir sin perder control.
Conoce el alcance de Kavasoft para cavas privadas
