Las reservas deportivas se están volviendo un problema de distribución

Última actualización: septiembre 2026 · Por Matías Fuster, CEO de Solcre

En resumen. La reserva ya no es el último paso de un funnel que controla el club. Interfaces como Google Search, Maps y ChatGPT están absorbiendo la transacción misma, así que el inventario de un club compite por si las plataformas externas pueden leerlo y reservarlo, y no solo por lo bien que convierte su propio sitio web. Para los equipos que construyen software de reservas, eso convierte la superficie de integración en algo que necesita tanta atención de diseño como las pantallas.

¿Qué es el problema de distribución en las reservas deportivas?

El problema de distribución en las reservas deportivas es la distancia entre que una cancha esté libre y que se pueda reservar desde donde el jugador expresó la intención. Cuando el descubrimiento y la transacción ocurren dentro de un buscador, un mapa o un asistente de IA, la disponibilidad que existe solo dentro de la interfaz del club no se puede vender ahí. La disponibilidad pasa a ser una forma de distribución.

Por qué el descubrimiento se está acercando a la transacción

Google ya permite reservar ciertos servicios y actividades de fitness directamente desde Search y Maps a través de proveedores de reservas, una función que documenta bajo Reserve with Google. ChatGPT puede mostrar disponibilidad de restaurantes en tiempo real de proveedores como OpenTable, Resy y Yelp, y en las experiencias habilitadas puede llevar al usuario directo al flujo de reserva. Cuando la intención es alta, la distancia entre encontrar y reservar se achica.

El cambio de comportamiento va más allá de los restaurantes. En lugar de preguntar "¿Qué clubes deportivos hay cerca?", un usuario puede plantear la intención completa de una vez:

"Buscame una cancha techada a menos de 15 minutos, mañana después de las 19, para cuatro jugadores, por menos de 60 dólares."

La búsqueda conversacional es solo la parte visible. El cambio está en lo que la interfaz puede hacer después de responder. Si entiende disponibilidad, precio, ubicación y reglas de reserva, el descubrimiento se convierte en una transacción.

Cómo está cambiando el funnel de reservas

Funnel tradicional

• Recorrido: Búsqueda, sitio web, sistema de reservas, reserva.
• Dónde empieza la intención: En un buscador, y después en un destino que controla el club.
• En qué compite el club: En lo bien que convierte su sitio web.
• Costo de no ser legible: Menos tráfico.

Funnel emergente

• Recorrido: Intención, disponibilidad, reserva.
• Dónde empieza la intención: En Google, un mapa, un marketplace, una app deportiva o un asistente de IA.
• En qué compite el club: En si las plataformas externas pueden leer y reservar su inventario.
• Costo de no ser legible: Una cancha libre que el jugador no ve.

Una cancha que técnicamente está disponible pero que ninguna plataforma externa puede leer es, desde el punto de vista del jugador, casi invisible.

Por qué esto se vuelve una decisión de producto

El software de reservas solía ser operativo. Manejaba agendas, membresías, pagos y ocupación de canchas después de que el cliente ya había encontrado el club. Cuando ese inventario puede aparecer en el momento del descubrimiento, el mismo software decide dónde es visible el inventario, qué usuarios pueden acceder a él, cuánta fricción hay entre un usuario y la compra, si las plataformas externas pueden entender la disponibilidad y si la demanda se puede rastrear hasta su origen. Son preguntas de crecimiento tanto como operativas.

En el SaaS vertical, un producto de reservas se definió casi siempre por su interfaz de usuario, y las APIs, los webhooks y los esquemas de datos se especificaban una vez resuelta la experiencia principal. Ese enfoque hoy está al revés. Cuando Google, un asistente de IA, un agregador tipo marketplace o una app de un partner pueden consumir el inventario, esos sistemas son usuarios de la plataforma en el mismo sentido que los jugadores. Un backlog que solo pregunta qué hace el jugador dentro de la interfaz se está perdiendo la mitad del producto.

Qué tiene que exponer una plataforma de reservas para poder reservarse desde afuera

• Los horarios libres tienen que existir como un recurso que un sistema externo pueda consultar, no solo como píxeles en una vista de calendario. Una plataforma que solo puede mostrar la disponibilidad en su propia interfaz queda, por arquitectura, afuera de la capa de distribución que se está formando a su alrededor.
• Una reserva que empieza fuera de la app igual tiene que atribuirse, validarse contra conflictos y confirmarse, y el sistema no puede asumir que una persona recorrió un flujo para crearla. Los casos borde se multiplican cuando el punto de entrada está fuera del producto, y resolverlos es trabajo de diseño.
• Cada canal falla distinto. Cuando una reserva empieza en una interfaz conversacional y se cae en el pago, el usuario frustrado no está dentro de la app. Está en la interfaz que usaba cuando la intención era alta, y ahí es donde cae la culpa. La superficie de falla es más amplia y más difícil de ver.

Cómo definir el alcance de un producto de reservas pensado para distribución

Un operador que pide un sistema de reservas muchas veces necesita una API de reservas con un panel para el operador, donde la web app es un canal de entrega entre varios y no la definición del producto. Hacer esa pregunta al definir el alcance, y diseñar el modelo de datos en función de la respuesta, es lo que separa a una plataforma que puede participar de la capa de distribución que se está formando de una que va a haber que reconstruir el día que el operador pregunte por qué su inventario no aparece en ningún lado.

El trabajo de product owner siempre consistió en representar el uso futuro por encima de la comodidad presente. En tecnología deportiva, ese uso futuro llega cada vez más por canales que el operador no controla.

De los nueve proyectos de producto digital que Solcre arrancó en 2026, ocho llegaron con un MCP server ya incluido en el alcance definido. Si se cuentan todos los productos digitales que cotizamos este año, confirmados o no, alrededor de tres de cada cuatro lo tenían en los requerimientos. La decisión que describe esta sección ahora nos llega desde el lado del cliente: sus requerimientos incluyen los flujos de sus usuarios y lo que un agente externo va a poder hacer con el sistema.

Hacia dónde va esto

Las plataformas deportivas más valiosas podrían terminar siendo capas de distribución de inventario deportivo más que gestores de reservas. La ventaja sería para quien haga que ese inventario sea más fácil de encontrar, entender y reservar desde cualquier lado: buscadores hoy, marketplaces y apps de partners mañana, y después agentes de IA actuando en nombre de los usuarios. Para el jugador, reservar podría dejar de empezar abriendo una app y empezar diciendo qué quiere jugar.

Preguntas frecuentes

¿Hoy se puede reservar un club deportivo directamente desde Google o desde un asistente de IA?

Google permite reservar ciertos servicios y actividades de fitness desde Search y Maps a través de proveedores de reservas. ChatGPT muestra disponibilidad de restaurantes en tiempo real de proveedores como OpenTable, Resy y Yelp, y en las experiencias habilitadas lleva al usuario al flujo de reserva. El mecanismo existe, y hasta dónde llega en el deporte depende de qué proveedores de reservas expongan su inventario.

¿Esto significa que el sitio web del club deja de importar?

No. Significa que el sitio deja de ser el único lugar donde puede ocurrir la reserva. La competitividad digital de un club depende de lo bien que convierte su sitio y de si su inventario se puede descubrir y reservar en otros lados.

¿Cuál es la diferencia entre un sistema de reservas y una API de reservas?

Un sistema de reservas suele definirse como una interfaz: flujos para el jugador y un back office para el operador. Una API de reservas trata la disponibilidad como un recurso que cualquier canal autorizado puede consultar y sobre el que puede transaccionar, y la web app es uno de esos canales.

¿Quién es responsable de esta decisión dentro de un equipo de software?

El product owner, al momento de definir el alcance. Modelar la disponibilidad como un recurso consultable define el modelo de datos, y agregarlo después es una reconstrucción, no una funcionalidad nueva.

Fuentes y lecturas recomendadas

• Google, Reserve with Google
• Google Business Profile Help, Set up bookings through a provider
• OpenAI Help Center, ChatGPT Search, restaurant reservations