Por qué un sistema de reservas es más difícil de lo que parece

Mostrar horarios libres es la parte fácil. Lo difícil aparece con clientes reales: dos personas que reservan el mismo horario a la vez, zonas horarias que corren los horarios, el momento en que el cliente recibe la invitación y pasa a ser el público, y decidir si un conflicto bloquea o solo avisa.

Un sistema de reservas parece una de esas cosas que ya están resueltas. Muestras los horarios libres, el cliente elige uno, queda agendado. Se hizo mil veces.

Después lo pones a funcionar en un negocio real y aparecen los problemas que no estaban en el dibujo. Estos son cuatro que nos tocaron. Ninguno se ve hasta que te pasa, y tres de los cuatro no producen ningún mensaje de error.

1. El error que la pantalla escondía

Encontramos algo incómodo revisando cómo se consultaban los horarios: la parte del sistema que mostraba la disponibilidad y la que guardaba la reserva no estaban mirando exactamente los mismos datos.

El resultado es el peor de los posibles. La pantalla ocultaba correctamente un horario que estaba ocupado, pero si una reserva llegaba por otro camino, se creaba igual, encima. Sin error, sin advertencia, sin nada raro en pantalla.

Por eso nunca se reportó. Un sistema que se cae molesta, pero avisa. Un sistema que guarda dos reservas en el mismo horario no avisa nada: se entera la recepcionista cuando tiene dos personas paradas en el mostrador a la misma hora, y para entonces ya no sabe si fue un error del software o de alguien.

La lección es general y la usamos desde entonces: cuando un sistema lee y escribe los mismos datos por caminos distintos, tarde o temprano los dos caminos dejan de estar de acuerdo. No alcanza con que la pantalla se vea bien. La pantalla se veía bien.

2. Las zonas horarias no son un problema de formato

Este es el que más subestima todo el mundo, nosotros incluidos.

La intuición dice que una zona horaria es una cuestión de presentación: guardas la hora y la muestras corrida según quién mire. No funciona así en una agenda, porque en una agenda la hora define cosas: qué día es, si la reserva entra en el horario de atención, si choca con otra.

Un caso concreto: si alguien define un bloque de trabajo desde una zona horaria y la sede está en otra, ese bloque puede caer en un día de calendario distinto para cada uno. Entonces buscar en la base "los bloques de ese día" directamente no sirve, porque el bloque que te interesa está guardado con la fecha de al lado. Hay que mirar también el día anterior y el siguiente, y evaluar cada regla por el instante real en que ocurre.

De aquí salieron dos reglas que aplicamos a todo lo que tenga fechas:

• La hora que elige el cliente no es un dato confiable. El navegador dice en qué momento cree que está; el horario que se reserva lo decide el servidor. Si aceptas la fecha y la hora que manda el browser, importas su zona horaria sin saberlo.
• Cuando agregas el campo de zona horaria a datos que ya existen, "vacío" tiene que seguir significando lo que significaba antes. En nuestro caso, vacío quiere decir "se interpreta en la zona de la sede". Si lo hubiéramos tratado como "sin dato", el día que salió la actualización se habrían movido todos los bloques que ya estaban cargados. Nadie lo habría relacionado con el deploy.

3. Cuando el cliente recibe la invitación, cambia quién es el público

Un pedido que suena inofensivo: que además de agendarse, al cliente le llegue la invitación al calendario.

Lo que ese pedido cambia no es el envío. Cambia quién puede leer el evento. Hasta ese momento la cita era un registro interno: tenía el título que usa el equipo, las notas internas, el nombre del despacho, los nombres de las otras partes involucradas. Todo eso pasó a ser algo que un tercero abre en su teléfono.

Tres cosas que descubrimos ahí, y las tres son contraintuitivas:

Omitir no es borrar. Cuando actualizas un evento que ya existe en Google Calendar, los campos que no mandas se quedan como estaban. Así que no alcanza con dejar de mandar las notas internas: hay que mandarlas explícitamente vacías, o el invitado abre el evento y lee lo que había antes.

Por defecto, los invitados se ven entre sí. Viene así de fábrica y no es neutro: en un estudio jurídico eso significa que una parte ve a la contraparte en la lista de invitados. Hay que apagarlo a propósito.

Mover un evento no es borrarlo y crearlo de nuevo. Parece equivalente y no lo es: al invitado se le borra el evento de su calendario y le llega una invitación nueva, como si fuera otra cita. Hay una operación de "mover" que conserva el evento y sus invitados, y hay que usar esa.

La regla con la que quedamos, y que hoy aplicamos a cualquier cosa que salga hacia afuera: nada llega al tercero salvo que lo hayas declarado público a propósito. No alcanza con que un campo "normalmente no sea sensible".

4. "¿Bloqueo o aviso?" no es una pregunta técnica

Cuando dos cosas chocan en la agenda, el sistema tiene que hacer algo. Y la respuesta correcta depende del negocio, no del software.

Una clínica quiere que se bloquee: si el consultorio está ocupado, está ocupado, y no hay caso en que convenga permitirlo. Un estudio jurídico, en cambio, a veces necesita agendar dos cosas a la misma hora sabiendo perfectamente por qué, y una prohibición dura lo obliga a trabajar por fuera del sistema — que es la peor forma de perder una agenda.

Así que no lo decidimos nosotros. Es una configuración con tres respuestas posibles: bloquear, permitir, o avisar y dejar seguir — que rechaza la operación pero devuelve la opción de "agendar igual", con el conflicto a la vista.

La generalización vale para cualquier automatización: cuando una regla cambia de negocio en negocio, es configuración, no código. Y si el sistema te obliga a trabajar por afuera aunque sea de vez en cuando, dejaste de tener una agenda confiable.

Lo que aprendimos

• Los peores errores no son los que fallan ruidosamente. Un sistema que se cae avisa. Uno que guarda mal, no.
• Una hora sin zona horaria es un dato incompleto, y el navegador del cliente no es la fuente de verdad.
• Cuando entra un tercero a mirar, todo lo que no declaraste privado es público.
• Las reglas que cambian de negocio en negocio se configuran, no se programan.

Ninguna de las cuatro es una lección sobre reservas, en realidad. Son las mismas cuatro que aparecen cada vez que un proceso que se hacía a mano pasa a hacerlo un sistema.

¿Estás agendando a mano?

Si tu negocio todavía coordina citas por WhatsApp, Excel o cuaderno, podemos mirar juntos cómo sería ordenarlo. El diagnóstico es gratis y sale de una conversación corta.

Te contactaremos pronto.