
El pase del evento en Google Wallet: la credencial que no se pierde
El link se pierde en el chat y en la puerta no hay señal. Lanzamos el pase en Google Wallet: la misma credencial, en el teléfono y sin conexión.
Nueve menos diez, la fila avanza, y alguien está haciendo scroll frenético en WhatsApp buscando un mensaje de hace tres semanas.
Lo encuentra. Toca el link. La página empieza a cargar. Y no carga, porque cuatrocientas personas están todas colgadas de la misma antena en el mismo hall, y porque la sesión del navegador se venció, y porque el teléfono es otro.
No es un problema de software. Es un problema de dónde vive la credencial.
El dolor: un link no es una entrada
Para el asistente, el modelo de "te mandamos el link" tiene tres fallas que solo aparecen en el peor momento:
- Se entierra. Un mensaje de hace tres semanas está veinte conversaciones abajo. Nadie archiva sus mensajes.
- Se vence. Las sesiones caducan, la gente cambia de navegador, alguien abre el link en el navegador interno de otra app y después no lo encuentra.
- Necesita internet. Y el hall de un evento a las nueve de la mañana es, sin exagerar, el peor lugar del mundo para depender de la señal.
Para el organizador, cada uno de esos casos es una persona parada en la puerta que necesita atención humana. Multiplicá eso por el cinco por ciento de una fila de cuatrocientos y ya tenés a alguien del equipo dedicado a resolver credenciales en vez de recibir gente.
Una entrada no debería depender de tener señal. Es el único momento del evento en el que se puede dar por seguro que no la vas a tener.
Qué lanzamos: el mismo QR, en la billetera del teléfono
En su perfil del evento, debajo de su QR, el asistente ahora ve el botón oficial de Google: Agregar a la Billetera de Google. Lo toca y su credencial queda guardada en el teléfono, como cualquier tarjeta de embarque.
Y acá está la decisión que hace que todo esto funcione: el pase lleva exactamente el mismo QR que ya tenía.
No se genera un código nuevo. No se reemite nada. Es el mismo QR de Mi Tarjeta que vive en el portal, byte por byte. Lo que significa que todos los escáneres que ya están en la calle lo leen sin ningún cambio: el de la puerta, los de los stands, el teléfono de otro asistente que quiera conectarse.
Es una regla que nos autoimpusimos desde el primer día y que sigue pagando: un código se emite una vez y nunca se regenera. Cada vez que alguien propone "generemos un código nuevo para esto", la respuesta es no — porque un código nuevo deja muertos todos los que ya se imprimieron, se guardaron o se compartieron.
En el pase el asistente ve el nombre del evento, el logo, el lugar, la fecha y hora, su nombre, el QR, y un link para volver al portal.
Lo que el pase no tiene, a propósito
El pase lleva un solo dato personal: el nombre visible. Nada de teléfono, nada de mail, ningún contador, ninguna otra persona.
Y el código de barras va sin texto alternativo. Es un detalle diminuto con una consecuencia concreta: si lo lleváramos, la URL cruda de la credencial se imprimiría debajo del código, visible en la pantalla de bloqueo del teléfono, a la vista de cualquiera que mire por encima del hombro en la fila.
Sin conexión, que es todo el punto
Un pase guardado en la billetera funciona sin internet. Está en el teléfono, no en un servidor.
Eso convierte el peor escenario —la antena saturada del hall, el sótano sin señal, el roaming apagado del visitante extranjero— en un no-evento. La persona abre la billetera y muestra el código. La puerta escanea. Listo.
Es, de lejos, la razón principal por la que construimos esto.

No manda nada (y por qué eso es una decisión)
Esta llave es sólo la credencial. Por sí sola no envía ninguna notificación. Podríamos haberla usado como un canal de mensajes al teléfono de todos los asistentes, y decidimos explícitamente no hacerlo.
Los avisos al pase guardado existen, pero son una feature aparte, con su propio interruptor y su propio presupuesto. La razón es un límite duro: Google topea los avisos en tres por pase cada 24 horas, y devuelve error en el cuarto. Eso no es un canal de comunicación: es un recurso escaso.
Así que lo tratamos como tal. Cuando el organizador va a mandar un aviso al pase, el panel le muestra cuántos le quedan de los tres del día antes de gastarlo. Y se respetan los horarios de descanso nocturno, con la excepción obvia de un evento en curso.
Un producto que te deja gastar un recurso escaso sin decirte cuánto queda no es un producto: es una trampa. Preferimos que el número esté a la vista.
Los detalles que aprendimos a los golpes
- El logo tardó en aparecer, y la causa fue una redirección. Las reglas de marca de Google dicen, textualmente, que no hay que redirigir a los archivos de imagen. Nuestro dominio raíz redirige a
wwwen todas las rutas, así que el logo apuntado al dominio raíz nunca llegaba. Ahora la URL es absoluta y directa. - Cada llamada a Google tiene cinco segundos de paciencia. Están todas paradas delante de un botón que alguien ya tocó; si Google tarda, preferimos degradar antes que dejar a la persona mirando una pantalla en blanco.
- La hora va sin huso horario, a propósito. Un evento a las 09:00 en Mendoza tiene que leerse 09:00 esté donde esté el teléfono. Un asistente que llegó de otro país no quiere que su credencial le traduzca el horario.
- Tres compuertas, todas cerradas por defecto. El flag global, la llave del evento y las credenciales de Google. Si falta cualquiera, el botón sencillamente no se dibuja. Lo que nunca puede pasar es que el botón exista y la ruta detrás falle: mandar un error a la pantalla de alguien que está peleando por entrar es peor que no ofrecerle el botón.
- Guardar dos veces no crea dos pases. Los identificadores son deterministas, así que el segundo toque resuelve al mismo pase.
Y una honestidad de medición: contamos cuánta gente toca el botón, no cuántos pases se guardaron. La confirmación de guardado ocurre del lado de Google. Cuando decimos "toques", queremos decir toques.
Por qué cambia el evento
Para el asistente, la credencial deja de ser algo que hay que encontrar y pasa a ser algo que tiene. Está en el mismo lugar donde guarda la tarjeta de embarque y la de fidelidad del supermercado — que es, exactamente, donde el cerebro la va a buscar.
Para el organizador, la puerta se hace más rápida y, sobre todo, más previsible. Menos casos raros, menos gente pidiendo ayuda, menos dependencia de una red que el día del evento nunca está a la altura.
Cómo se activa
Hacen falta dos llaves —la global de la plataforma y la del evento— más las credenciales de Google configuradas. Se enciende desde el panel de administración, no desde el panel del organizador: la integración se apoya en una única cuenta de servicio compartida por toda la plataforma, así que si alguna vez hay que cortarla, se corta en un solo lugar y no evento por evento.
¿Organizás un evento donde la puerta importa? Conocé Circli Events o escribinos desde eventos.circli.app.