App ruta de la tapa con QR: pasaporte y dashboard del organizador

Una app de ruta de la tapa con pasaporte QR cambia el orden de las cosas: el visitante escanea un código físico en el bar, sube la foto de la tapa, una IA valida la imagen y solo entonces vota y suma un sello en su pasaporte digital. Mientras tanto, el organizador no espera un PDF: mira un dashboard que se actualiza en directo con la participación, los canjes, el rendimiento de cada local, el mapa de calor por zona y las horas punta. Este artículo abre TapaPass por dentro desde dos puntos de vista: el recorrido concreto del visitante con el pasaporte y lo que ve exactamente quien gestiona la ruta. Una nota importante de honestidad por delante: todas las cifras de participación que aparecen en demos y capturas son simuladas para ilustrar el funcionamiento; los números reales los generan los vecinos cuando la ruta corre de verdad.

Qué resuelve el pasaporte QR frente al modelo en papel

El pasaporte QR resuelve los tres agujeros del modelo tradicional: el voto sin verificar, el dato que llega tarde y la fidelización que no existe. En una ruta de la tapa clásica repartes papeletas, los bares cuentan votos a mano, alguien transcribe a una hoja de cálculo y semanas después llega un PDF con el ganador. Para entonces la ruta ha terminado, el dato ya no sirve para decidir nada y nadie puede garantizar que un voto correspondiera a alguien que probó la tapa y no a un amigo del cocinero que rellenó veinte papeletas.

El pasaporte digital ataca eso en el origen. Verifica antes de votar, enseña los datos mientras pasan y deja un rastro de sellos que invita a repetir. Lo importante no es la tecnología en sí, sino que invierte la secuencia: el voto se limpia antes de existir, no después, y el organizador tiene información accionable durante el evento, no cuando ya da igual. Si quieres el porqué estratégico para una concejalía, lo desarrollamos en la guía de digitalizar la ruta de la tapa para un ayuntamiento.

La raíz del problema del papel es que mezcla en un mismo gesto dos cosas que deberían estar separadas: el acto de probar la tapa y el acto de votarla. Con papeletas, ambas cosas viven en un trozo de cartón que cualquiera puede rellenar, acumular o falsificar. El pasaporte QR las separa: la presencia física en el local la garantiza el escaneo del código, la prueba de consumo la garantiza la foto, y el voto solo se desbloquea cuando las dos anteriores se han cumplido. Esa separación es lo que convierte un concurso de popularidad manipulable en un certamen con integridad defendible.

Cómo usa el visitante el pasaporte QR: sin instalar nada

El visitante no instala nada de una tienda de aplicaciones: escanea el QR del bar con la cámara del móvil y el pasaporte se abre al instante como PWA, una web app que opcionalmente se añade a la pantalla de inicio con un toque. Esto importa más de lo que parece. En una ruta de fin de semana, cada paso intermedio entre "quiero participar" y "estoy votando" pierde gente. Obligar a descargar una app de tienda (con su búsqueda, su descarga de decenas de megas, sus permisos y su actualización pendiente) hace que una parte del público se rinda antes de empezar.

Sin instalar vs. app de tienda: por qué la PWA gana en un evento

Una app nativa de tienda tiene sentido cuando el usuario la va a usar a diario durante meses. Una ruta de la tapa dura un fin de semana o unas semanas, y el visitante medio interactúa con ella un puñado de veces. Para ese patrón, la fricción de instalar desde la tienda no compensa: el coste de adquisición de un usuario que descarga, registra y configura es altísimo para alguien que va a votar tres tapas y no volver hasta el año que viene. La PWA elimina ese coste de entrada (se abre con el escaneo) y conserva la ventaja de la app instalable (si el usuario engancha, puede fijarla en la pantalla de inicio sin pasar por la tienda).

Hay un matiz que conviene entender bien, porque es donde más se confunde la gente: una PWA no es una "web normal con un atajo". Una vez añadida a la pantalla de inicio, se abre a pantalla completa sin la barra del navegador, guarda en el dispositivo lo necesario para arrancar rápido y puede funcionar con conexión intermitente. Para el visitante, la experiencia es indistinguible de una app; para el organizador, la diferencia es que no hay que mantener dos versiones (iOS y Android), no hay revisión de tienda que retrase un cambio de última hora y no hay porcentaje que se lleve la plataforma. En un evento que se monta en diez días, no depender del ciclo de aprobación de App Store es una ventaja operativa real. Esa misma lógica (web rápida e instalable frente a app de tienda pesada) es la que explicamos al comparar WordPress y Next.js para un proyecto en Tenerife: el pasaporte de TapaPass está construido sobre esa base técnica precisamente para arrancar al instante sin descarga.

El recorrido paso a paso

El recorrido está diseñado para que votar sea fácil pero votar en falso sea imposible. Son cinco pasos encadenados y el orden es deliberado.

1. Escaneo del QR físico. Cada bar participante tiene su propio QR impreso en la mesa o la barra. El visitante lo escanea; el pasaporte se abre ya en el contexto de ese local concreto. Que el QR sea físico y específico de cada establecimiento es la primera barrera anti-fraude: para empezar a votar hay que estar dentro del bar.
2. Foto de la tapa. La app pide subir una foto de la tapa que se está probando. No es decorativo: la imagen es la prueba de consumo. Sin foto, el flujo no avanza.
3. Validación por IA. Antes de habilitar el voto, una IA analiza la imagen para comprobar que es coherente con una tapa real. Solo cuando la validación pasa se desbloquea el siguiente paso. Es la diferencia entre un concurso de popularidad manipulable y un certamen con integridad. El detalle de por qué escaneo presencial más foto validada cierra la puerta al fraude está en el artículo sobre el voto verificado en concursos de tapas.
4. Voto. Con la foto validada, el visitante emite su voto. El dato entra al sistema ya marcado como verificado, así que el ranking se construye solo con votos legítimos. No hay una limpieza manual posterior de "votos sospechosos": la limpieza ocurre antes de que el voto exista.
5. Sello en el pasaporte. Cada visita validada deja un sello en el pasaporte digital. Los sellos se acumulan durante un periodo largo entre rutas y entre municipios distintos. Quien completa una ruta tiene un motivo para volver y para probar la siguiente en otro pueblo. Para el organizador, eso es fidelización del público hostelero a coste cero.

El tiempo total de ese recorrido, una vez el visitante está en la mesa, es de menos de un minuto: escanear, hacer la foto, esperar la validación y tocar votar. Cuanto más corto es el flujo, más gente lo completa, y por eso no hay registro previo, ni formularios largos, ni pasos de configuración. La cuenta del visitante es, por defecto, un identificador anónimo en su propio dispositivo. Esa decisión de diseño (cero registro) no es solo comodidad: es lo que hace que un señor de 70 años que ha entrado a tomar una caña participe igual que un veinteañero, porque no hay nada que aprender más allá de apuntar la cámara a un código.

Cómo se registran los check-ins por dentro

Un check-in es el registro de que un visitante concreto pasó por un establecimiento concreto y completó la verificación. Por dentro es un evento con tres datos mínimos: identificador del pasaporte (anónimo), identificador del establecimiento (el que codifica el QR físico) y sello de tiempo del momento del escaneo. A eso se añade la referencia de la foto validada y el resultado del voto.

La clave de integridad es que el check-in no se graba en el momento de abrir un enlace, sino al superar la validación. Esto evita el patrón más común de fraude en rutas digitales mal montadas: compartir un enlace por WhatsApp y "votar" sin pisar el bar. Como el QR es físico y único por local, y la foto debe pasar la validación, el check-in está anclado al sitio y al acto de consumo.

Qué pasa sin cobertura

El escaneo y la foto se capturan en el dispositivo aunque la conexión sea mala; el check-in se encola en local y se sincroniza en cuanto vuelve la señal, conservando el sello de tiempo del momento real del escaneo, no del envío. Esto es importante en cascos antiguos, sótanos de bares o zonas con saturación de red un sábado por la noche. La regla de diseño es sencilla: un visitante no debe perder un sello por un bache de red puntual. Para zonas con mala cobertura crónica, el establecimiento puede ofrecer su wifi como respaldo, y conviene revisarlo en el piloto interno del día 7.

La diferencia entre conservar el sello de tiempo del escaneo y conservar el del envío parece un detalle técnico menor, pero tiene consecuencias para el dato. Si un grupo de visitantes pasa por un bar a las 21:30 pero la red no se recupera hasta las 22:15, registrar el envío metería 40 check-ins falsos en la franja de las 22:00 y vaciaría la de las 21:00. El mapa de calor por horas quedaría mentido. Anclar el evento al momento real del escaneo mantiene la curva de actividad fiel a lo que pasó, que es justo lo que el organizador necesita para leer la ruta.

Anti-fraude sin fricción para el visitante honesto

La verificación protege la integridad sin penalizar a quien juega limpio. El visitante honesto no nota la capa anti-fraude: escanea, hace una foto que iba a hacer igualmente y vota. El que intenta inflar votos se topa con tres barreras encadenadas (presencia física, prueba fotográfica, validación) que hacen que el coste de hacer trampa supere con creces el beneficio. Esa asimetría (fácil para el legítimo, caro para el tramposo) es el objetivo de diseño de todo el flujo.

Pensemos cómo intentaría hacer trampa alguien decidido a inflar los votos de su bar. Tendría que estar físicamente en el local para escanear su QR (primera barrera), tendría que hacer una foto distinta de una tapa real que pase la validación por cada voto (segunda y tercera), y aun así el sistema verá decenas de check-ins desde el mismo dispositivo o en un patrón anómalo. Cada voto extra cuesta tiempo, presencia y una foto creíble; el rendimiento de la trampa cae en picado mientras el riesgo de que cante en los datos sube. Frente a eso, en el modelo de papeletas, falsificar cien votos cuesta un bolígrafo y diez minutos. La verificación no hace imposible la trampa en términos absolutos (nada lo hace), pero la encarece hasta el punto de que deja de merecer la pena, que en seguridad es exactamente el objetivo realista.

Qué muestra el dashboard del organizador

El dashboard es un cuadro de mando vivo, no un informe. Mientras los visitantes recorren la ruta, el equipo del organizador mira un panel que se actualiza con pocos segundos de retraso. Estos son los bloques que de verdad mueven decisiones.

Participación en directo

El bloque de participación responde a la pregunta básica del organizador: ¿está arrancando la ruta o se está enfriando? Muestra los visitantes activos y los check-ins por hora, de manera que el sábado a mediodía se puede saber si el ritmo es el esperado o si hace falta empujar comunicación. En el modelo en papel esta pregunta no tenía respuesta hasta semanas después; aquí se contesta en cualquier momento del evento.

Ranking de tapas en tiempo real

El podio se mueve solo según entran votos verificados. Para los bares es transparente (ven su posición evolucionar) y para el organizador es defendible ante quien pregunte, porque cada voto del ranking ha pasado por la verificación. No hay un cierre manual opaco: el ranking es la suma de votos legítimos hasta el segundo en que se mira. Esto resuelve uno de los conflictos más típicos de las rutas: el bar que pierde y sospecha del recuento. Cuando cada voto está anclado a un escaneo presencial y una foto, el resultado no se discute con "cuéntalos otra vez", se discute con un dato trazable.

Rendimiento por local

Esta es la tabla que más se infrautiliza y más vale. Por cada establecimiento muestra check-ins, votos y conversión (qué porcentaje de quienes escanean acaban votando). Permite distinguir el bar que arrastra mucho público pero convierte poco del que tiene poco tráfico pero a todos les encanta su tapa. Cruzado con el mapa de calor, dibuja qué locales generan vida en su zona y cuáles quedan descolgados, una lectura clave para repartir mejor los establecimientos en la siguiente edición.

La columna de conversión escaneo→voto es la que más matices da. Un bar con muchos check-ins pero conversión baja está atrayendo gente que escanea y se va sin votar: puede ser que la tapa no convenza, que el flujo se atasque ahí o que el local sea un punto de paso. Un bar con pocos check-ins pero conversión casi total tiene un producto que enamora a quien llega, y el problema es de tráfico, no de tapa: quizás está mal ubicado o poco comunicado. Son dos diagnósticos opuestos que el conteo de papeletas jamás distinguiría, porque la papeleta solo cuenta votos, no la gente que pasó y no votó.

Mapa de calor por zona y horas punta

El mapa de calor traduce los check-ins a geografía: qué barrios concentran actividad y cuáles quedan flojos. Combinado con la distribución por franja horaria, dice no solo dónde sino cuándo se mueve la gente. Para una concejalía de Festejos eso es información directamente accionable: dónde poner un photocall, en qué zona reforzar la comunicación el domingo, qué franja conviene animar con música o actividad. Son decisiones que antes se tomaban a ciegas y que ahora se apoyan en el comportamiento real del público.

Canjes de recompensa

Cuando la ruta incluye un pasaporte con premio (completar X sellos da derecho a un sorteo o a una recompensa), el panel muestra los canjes: cuántos visitantes han alcanzado el umbral y cuántos han reclamado. Esto cierra el círculo de la fidelización, porque permite medir si el incentivo funciona y dimensionar el premio sin sustos. Es importante remarcar que las cifras de canjes que aparezcan en una demo son ilustrativas: hasta que tu ruta corra, no hay números reales que enseñar. El sorteo, además, hereda la integridad del resto del sistema: solo entran al bombo los votantes verificados, así que el premio no se lo puede llevar quien nunca pisó un bar.

Recorrido UX concreto: de la mesa del bar al panel del ayuntamiento

Para ver cómo encajan las dos caras del sistema, este es un recorrido concreto, contado como escenario ilustrativo (no como datos de un evento real).

Un visitante entra en un bar de la ruta un sábado a las 13:30. Ve el QR en la mesa, lo escanea y el pasaporte se abre directamente en la ficha de ese local. Hace la foto de la tapa, la sube y en un par de segundos la validación confirma la imagen. Vota, recibe el sello y la app le muestra cuántos sellos lleva y cuántos le faltan para el premio. Todo en menos de un minuto, sin haberse descargado nada ni haber dado su nombre.

En ese mismo instante, en el panel del organizador, el contador de participación suma un check-in, el ranking de esa tapa se ajusta, la conversión de ese local se recalcula, el mapa de calor de esa zona se intensifica un punto y la franja de las 13:00-14:00 gana actividad. Si el organizador estaba mirando el panel, ha visto el efecto del visitante sin que medie ninguna persona transcribiendo nada. Multiplicado por muchos visitantes a lo largo del fin de semana, el panel deja de ser una foto fija y pasa a contar la ruta según ocurre.

La lectura de fondo de esta tabla es que cada acción del visitante es, a la vez, una experiencia para él y un dato para el organizador, sin intermediario. En el modelo de papel, entre el gesto del visitante y el dato del organizador hay siempre una persona contando, una hoja de cálculo y un retraso de días. Aquí ese hueco desaparece: el dato nace ya verificado y limpio en el mismo segundo que el gesto. Esa es la diferencia que justifica todo el montaje.

Datos y privacidad: RGPD desde el primer día

El pasaporte está pensado para recoger el mínimo dato personal posible. Por defecto el visitante vota y sella con un identificador anónimo en su propio dispositivo: no se le pide nombre, email ni teléfono para participar. Solo se solicitan datos de contacto si decide entrar en un sorteo o recibir un premio, y siempre con consentimiento explícito y finalidad clara. Esta minimización no es solo buena práctica de RGPD; reduce también la superficie de riesgo y el trabajo de cumplimiento del organizador.

En cuanto a alojamiento, la plataforma está en servidores propios (self-hosted) dentro de la Unión Europea, con un acuerdo de tratamiento de datos (DPA) firmable y sin cookies de tracking publicitario. Para un responsable de contratación pública, eso simplifica el encaje con el RGPD desde el primer día y evita la transferencia de datos de ciudadanos a terceros países.

Conviene recordar que la responsabilidad del tratamiento recae en el organizador como responsable y en el proveedor como encargado; el DPA es la pieza que reparte y documenta esas obligaciones. Para un ayuntamiento, exigir DPA, ubicación de datos en la UE y portabilidad en el pliego es lo razonable. Hay además una ventaja jurídica práctica en la minimización: si el voto es anónimo y solo el ganador del sorteo deja datos de contacto, el volumen de datos personales que un ayuntamiento maneja en toda la ruta se reduce a una lista corta de participantes en el sorteo, no a un censo de todo el que probó una tapa. Menos dato significa menos obligación, menos riesgo de brecha y un encaje más sencillo con el principio de proporcionalidad que el RGPD exige a las administraciones.

Accesibilidad: que lo use todo el mundo, no solo nativos digitales

La accesibilidad no es un extra: en un evento público determina cuánta gente puede participar de verdad. El primer factor accesible es el propio diseño del flujo: tres acciones (escanear, foto, votar), sin registro ni menús, es lo que más ayuda a quien no se maneja con el móvil. Cada paso eliminado es una persona menos que se queda fuera.

Sobre eso se construye el resto: contraste de texto suficiente para leerse a pleno sol en una terraza, botones grandes pensados para el dedo y no para el ratón, compatibilidad con el zoom del sistema operativo y con lectores de pantalla, y mensajes claros en cada paso ("haz una foto de la tapa", "validando", "voto registrado"). Para personas mayores o con poca soltura, el establecimiento puede ayudar con el escaneo, y el organizador puede mantener una vía en papel para casos puntuales sin que eso rompa el cómputo digital de la ruta.

Hay un argumento de accesibilidad que las administraciones a veces pasan por alto y que conviene poner sobre la mesa: una ruta de la tapa es un servicio público con dinero público, así que excluir a una parte de la ciudadanía por la herramienta no es solo un fallo de producto, es un problema de equidad. Por eso la regla de no romper nunca la vía en papel residual es importante. El objetivo no es forzar a todo el mundo a usar el móvil, sino que el grueso del cómputo sea digital (para ganar la integridad y los datos) sin dejar fuera a quien no puede o no quiere usar un smartphone. Mantener una papeleta de cortesía para casos puntuales cuesta muy poco y blinda al organizador frente a la crítica fácil de "habéis dejado fuera a los mayores".

Sin cobertura, picos de tráfico y otros casos límite

Ninguna ruta ocurre en condiciones de laboratorio, así que vale la pena enumerar los casos límite y cómo se manejan, porque son las preguntas que de verdad surgen el día del evento.

• Sin cobertura en el bar. El escaneo y la foto se capturan en local; el check-in se encola y sincroniza al recuperar señal, con el sello de tiempo correcto. Wifi del local como respaldo en zonas problemáticas.
• Pico de tráfico simultáneo. El sistema absorbe muchos check-ins concurrentes sin que el visitante note espera; la validación de la foto ocurre en segundos aun en hora punta.
• Móvil del visitante sin batería o muy antiguo. Al ser PWA, funciona en navegadores estándar sin exigir hardware reciente; el peso de carga es bajo.
• QR dañado o despegado. Conviene plastificar los QR y tener reimpresiones de repuesto; el organizador puede regenerar el código de un local desde la plataforma si hiciera falta.
• Visitante sin smartphone. El bar puede ayudar con un dispositivo, o el organizador mantiene una vía en papel residual; lo importante es no excluir, pero el grueso del cómputo es digital.

Estos casos se detectan precisamente en el piloto interno del día 7, antes de abrir la ruta al público. Por eso el calendario reserva ese ensayo: no es burocracia, es la oportunidad de cazar el QR mal pegado o la mesa sin cobertura antes de que afecte a un visitante real. El piloto interno tiene un valor añadido que suele subestimarse: sirve para entrenar a los hosteleros. Un camarero que ha visto cómo un compañero escanea, fotografía y vota durante el ensayo es capaz de ayudar a un cliente despistado el día de la ruta, y ese pequeño detalle (que el bar sepa explicar el flujo en diez segundos) mueve la participación más que cualquier cartel.

Puesta en marcha en 10 días

El calendario es corto y concreto, contado desde la firma. La tecnología rara vez es el cuello de botella; lo son la coordinación con los bares y la impresión de los QR.

• Día 1: kick-off y cierre del listado de establecimientos.
• Día 3: branding del municipio aplicado a la plataforma.
• Día 5: QR impresos y repartidos.
• Día 7: piloto interno (prueba de cobertura, QR y flujo completo).
• Día 10: ruta pública en marcha.

Diez días desde la firma hasta tener la ruta funcionando de cara al ciudadano. El consejo práctico es cerrar pronto el listado de bares: cada día que se retrasa la confirmación de establecimientos es un día menos para imprimir y colocar QR con margen. Vale la pena entender por qué la tecnología no es el problema: el sistema ya está construido y probado, así que lo que se hace en estos diez días no es desarrollar software, sino configurarlo para tu municipio (cargar los locales, aplicar la imagen institucional, generar los QR e imprimirlos). Esa es la razón de que un plazo tan corto sea realista y no una promesa de vendedor: no se programa nada nuevo, se parametriza algo que ya funciona.

La demostración para Tacoronte

La forma más honesta de enseñar TapaPass no es con cifras inventadas, sino dejando que el cliente lo toque. Para la propuesta al Ayuntamiento de Tacoronte se preparó una demostración cargada con datos reales del municipio: los 14 establecimientos que participaron en la II Ruta de la Tapa de la Cebolla de Guayonje, con una tapa acompañada de bebida por 4 € y un sorteo final de tres cenas para dos personas entre los participantes. Esos datos (número de locales, formato y precio de la tapa, mecánica del sorteo) proceden de la nota de prensa oficial del Ayuntamiento de Tacoronte, no de una estimación.

La demo coloca esos 14 locales sobre el callejero real de Tacoronte, con su barrio y su ubicación, de modo que un concejal puede abrirla y recorrerla como lo haría un vecino: ver la ruta, el mapa, escanear, votar y coleccionar sellos. Lo que no es real, y se dice por delante, es la participación: las cifras de votos, comentarios y rankings que aparecen en la demo son datos simulados para ilustrar cómo se ve el panel en marcha. No representan un evento ejecutado ni un ranking oficial de establecimientos. En producción, esos números los generan los vecinos al votar; al firmar, se sustituyen los datos simulados por los reales de la siguiente edición y se aplica la imagen institucional del municipio con un dominio propio del tipo rutadelatapa.tacoronte.es.

Esta forma de presentar el producto (demo navegable con el marco real del cliente, participación marcada como simulada) es deliberada. Una ruta de la tapa mueve dinero público y la integridad del dato es el argumento central de la herramienta; sería incoherente venderla con cifras de participación fabricadas. El valor que se enseña no es "mira cuánta gente participó" (eso aún no ha pasado), sino "mira cómo se vería tu ruta y qué tendrías delante en el panel cuando ocurra". La III Ruta de la Cebolla de Guayonje podría ser la primera que el municipio cierre sabiendo, con datos verificados, qué funcionó y por qué.

Cuánto cuesta y cómo se contrata

El modelo de precios está pensado para encajar en la contratación pública sin fricciones. Los importes son orientativos y la tramitación concreta depende de cada convocatoria; conviene confirmar siempre los umbrales vigentes del contrato menor.

• Piloto: 4.999 €. Por debajo de 5.000 €, lo que facilita la adjudicación directa como contrato menor. Factura por FACe.
• Anual: 14.900 €. Dentro del umbral del contrato menor de servicios, por debajo de 15.000 €.
• Enterprise: desde 24.000 €. Marca blanca, dominio propio, SLA y soporte multi-distrito.

El piloto es la puerta de entrada lógica: una edición completa, riesgo bajo y tramitación administrativa sencilla. Si funciona, el salto al modelo anual es natural. El desglose completo de qué incluye cada tramo y cómo se calcula está en el artículo sobre cuánto cuesta digitalizar la ruta de la tapa. Una nota sobre los umbrales: los importes del contrato menor en el sector público están fijados por la ley de contratos vigente y pueden cambiar, así que el "por debajo de 5.000" y "por debajo de 15.000" son referencias prácticas, no garantías legales; el técnico de contratación del ayuntamiento debe verificar el umbral aplicable en el momento de la adjudicación. El diseño de precios busca caer cómodamente dentro de esos límites para que la tramitación sea ágil, pero la última palabra la tiene siempre la intervención municipal.

Pasaporte QR frente a un formulario online de votación

Es tentador pensar que un formulario online (un Google Forms o similar con un enlace) resuelve lo mismo más barato. No lo hace, y la razón es estructural: un formulario recoge respuestas; el pasaporte QR recoge actos de consumo verificados. La diferencia se nota en cuanto alguien quiere hacer trampa o en cuanto el organizador necesita un dato a tiempo.

Un formulario con enlace se comparte por WhatsApp y lo rellena cualquiera desde el sofá, sin pisar el bar. No hay foto, no hay validación, no hay anclaje al establecimiento. El conteo llega cuando el organizador descarga la hoja y la procesa, normalmente al acabar. Y no hay sellos ni continuidad: terminado el formulario, terminada la relación con el visitante. El pasaporte cierra esos tres flancos a la vez.

El formulario puede valer para una encuesta interna sin consecuencias. Para un certamen con ganador, premio y dinero público de por medio, la integridad del voto no es opcional, y ahí el formulario se queda corto. Hay además un coste oculto del formulario que no aparece en la tabla: el trabajo humano de limpiar y defender el resultado. Cuando los votos no están verificados, alguien tiene que revisar a mano la hoja buscando duplicados, votos masivos desde el mismo origen o respuestas sospechosas, y aun así el ganador siempre puede ser impugnado por un bar descontento. Ese tiempo de limpieza y esa exposición a la impugnación son justo lo que el pasaporte elimina al verificar antes de votar.

Qué pedir en el pliego si eres un ayuntamiento

Si vas a contratar una solución de ruta de la tapa digital, conviene fijar por escrito en el pliego o en la propuesta unos mínimos que protegen al ayuntamiento y evitan sorpresas. Estos son los puntos que un responsable de contratación debería exigir.

• Propiedad y portabilidad del dato. Export en CSV/JSON a demanda y export completo al finalizar, sin lock-in.
• Ubicación de los datos en la UE y DPA firmable entre las partes.
• Verificación del voto documentada, no un simple formulario: escaneo presencial, prueba de consumo y validación.
• Accesibilidad: flujo sin registro, contraste, compatibilidad con lectores de pantalla, vía alternativa en papel.
• Plan de contingencia sin cobertura y reimpresión de QR.
• Calendario de despliegue cerrado (aquí, 10 días) con piloto interno antes de abrir al público.
• Encaje administrativo: importe dentro del contrato menor y facturación por FACe.
• Honestidad sobre los datos de demo. Que el proveedor diga por escrito qué cifras de su presentación son reales y cuáles son simuladas. Es una señal de fiabilidad: quien marca claramente sus datos de ejemplo como ilustrativos no te venderá luego un informe inflado.

Pedir estos puntos por escrito no encarece nada y separa una solución seria de un formulario maquillado. Si el proveedor no puede comprometerse a la portabilidad del dato o a la ubicación en la UE, es una señal de alarma para una administración pública. Y si presenta cifras de participación de "otros pilotos" sin poder enseñar el export o la captura del panel de aquel evento, conviene pedírselas: en este terreno, un número sin traza vale lo mismo que una papeleta sin verificar.

Por qué el pasaporte y el dashboard se necesitan mutuamente

El pasaporte sin dashboard sería una app de votación bonita; el dashboard sin pasaporte sería un panel alimentado con datos sin verificar. El valor está en la cadena completa: cada acción del visitante en su pasaporte es un dato verificado que llega limpio al panel del organizador en segundos. El visitante gana facilidad y un incentivo para repetir; el organizador gana integridad del voto y capacidad de decidir durante la ruta.

Esa es la diferencia de fondo con un formulario online con buena cara. El formulario recoge respuestas; el pasaporte QR recoge actos de consumo verificados, y el dashboard los convierte en decisiones a tiempo. Verificar antes, decidir con datos en directo y dejar que el visitante acumule sellos que le hagan volver: ese es el modelo, montado en diez días y empaquetado dentro del contrato menor. La pieza que lo cierra todo es la honestidad del dato: un sistema cuyo único argumento es la integridad no puede permitirse presentar cifras infladas, y por eso lo que se enseña antes de firmar es la herramienta funcionando, no resultados que aún no existen.

¿Quieres ver el pasaporte y el panel del organizador funcionando? Echa un vistazo a la página de TapaPass o escríbenos desde contacto para montar un piloto en tu municipio. WhatsApp directo: +34 680 762 331.

Preguntas frecuentes

¿El visitante tiene que instalar una app de la tienda para usar el pasaporte QR?

No. El pasaporte funciona como PWA (web app): se abre al escanear el QR del bar con la cámara del móvil, sin pasar por App Store ni Google Play. Si el visitante quiere, puede añadirla a la pantalla de inicio con un toque y entonces se comporta como una app instalada. La PWA evita la fricción de descargar, actualizar y conceder permisos, que es justo lo que hace abandonar a la gente en una ruta de fin de semana.

¿Cómo se registra un check-in cuando alguien visita un bar?

Un check-in se registra cuando el visitante escanea el QR físico de ese local, sube la foto de la tapa y la validación por IA confirma la imagen. Solo entonces el sistema graba el evento con su sello de tiempo, el identificador del establecimiento y el del pasaporte. Como el QR es específico de cada bar, el check-in está atado al lugar: para registrarlo hay que estar dentro del establecimiento.

¿Qué métricas muestra el dashboard del organizador?

Participación viva, ranking de tapas por votos verificados, rendimiento por local (check-ins, votos y conversión), mapa de calor por zona, distribución por franja horaria y canjes de recompensa cuando hay premio. Todo se actualiza con pocos segundos de retraso, así que se ve la ruta mientras ocurre.

¿Qué pasa si el bar no tiene cobertura o el móvil se queda sin datos?

El escaneo y la foto se capturan en local aunque la conexión sea mala; el check-in se encola y sincroniza al volver la señal, con el sello de tiempo del momento real del escaneo. Para zonas con mala cobertura crónica, el bar puede ofrecer su wifi como respaldo. El objetivo es que nadie pierda un sello por un bache de red puntual.

¿Qué datos personales recoge el pasaporte y dónde se guardan?

Por defecto funciona con un identificador anónimo en el dispositivo: no exige nombre, email ni teléfono para votar. Solo se piden datos de contacto si el visitante participa en un sorteo o recibe un premio, con consentimiento explícito. Los datos se alojan en servidores propios en la Unión Europea, con DPA firmable y sin cookies de tracking.

¿El dashboard sirve para decidir durante la ruta o solo para el informe final?

Para ambas cosas, pero su valor real está en decidir durante la ruta. Como participación y mapa de calor se actualizan en directo, el organizador puede reforzar comunicación en una zona floja el mismo día, avisar a un bar saturado o ajustar horarios según dónde se concentra la gente. El informe final se exporta después.

¿Es accesible para personas mayores o con poca soltura con el móvil?

El flujo está reducido a tres acciones (escanear, foto, votar) sin registro ni menús, lo que más ayuda a quien no es nativo digital. Cumple contraste suficiente, botones grandes y compatibilidad con zoom y lectores de pantalla. Para quien no use móvil, el bar puede ayudar con el escaneo y el organizador puede mantener una vía en papel para casos puntuales.

¿Quién es el dueño de los datos de la ruta?

El organizador. Puede exportar los datos en CSV cuando quiera y, si no renueva, recibe un export completo en CSV y JSON. Sin lock-in. Para una contratación pública conviene exigir por escrito en el pliego la propiedad del dato y la portabilidad.

¿Se puede saber qué bar arrastra público y cuál no rinde?

Sí, esa es la lectura de la tabla de rendimiento por local: check-ins, votos y conversión de cada establecimiento. Cruzado con el mapa de calor por zona, muestra qué locales generan tráfico y cuáles quedan descolgados. Es información para repartir mejor los establecimientos en la próxima edición, no para señalar a nadie en público.

¿El pasaporte funciona entre rutas de municipios distintos?

Está pensado para acumular sellos durante un periodo largo entre rutas y municipios distintos, de modo que quien participa en una ruta tiene incentivo para repetir en otra y en otro pueblo. Cada organizador ve los datos de su propia ruta; la continuidad del pasaporte es del visitante.

¿Cuánto se tarda en tener la ruta con pasaporte QR funcionando?

Alrededor de 10 días desde la firma: kick-off el día 1, branding hacia el día 3, QR impresos el día 5, piloto interno el día 7 y ruta pública el día 10. El cuello de botella suele ser la coordinación con los bares y la impresión de los QR, no la tecnología.

¿Los datos del dashboard de ejemplo son de eventos reales?

No. Las cifras de participación, votos o canjes de demos y capturas son simuladas para ilustrar el panel, no resultados de un evento concreto. La demo de Tacoronte se cargó con los 14 establecimientos reales de la II Ruta de la Tapa de la Cebolla de Guayonje sobre el callejero del municipio, pero su participación y rankings son datos simulados. En producción, los números los generan los vecinos al votar. Cualquier cifra de participación en una presentación es un escenario ilustrativo hasta que tu ruta genere sus datos.

¿Qué pasa con los datos de la ruta cuando termina la edición?

Se quedan con el organizador. Puedes exportarlos en CSV o JSON cuando quieras y, al cerrar la edición, dispones del informe ejecutivo con los KPIs del evento. Esos datos sirven para la rendición de cuentas de la partida que financió la ruta y para planificar la siguiente edición con criterio, no de memoria. Sin esa traza, cada año se empieza de cero.