Por qué una hoja con “cupos” todavía puede fallar

Una cifra de capacidad no basta cuando las solicitudes llegan por varios canales o cuando el mismo recurso participa en más de una salida. La sobreventa puede ocurrir aunque el número de pasajeros parezca correcto: quizá el vehículo ya está asignado, el guía no está disponible o una consulta fue contada como confirmada.

• Fuentes separadas: WhatsApp, correo, formulario y hoja no descuentan del mismo inventario.
• Estados ambiguos: solicitud, apartado y confirmado significan cosas distintas para cada persona.
• Capacidad incompleta: se cuentan pasajeros, pero no el recurso realmente limitante.
• Cambios tardíos: cancelaciones o aumentos de pasajeros no actualizan la salida central.
• Salidas mal definidas: se vende el tour genérico sin asociarlo a fecha y hora exactas.

El modelo mínimo: tour, salida y reserva

Un tour describe el producto. Una salida representa una ejecución con fecha, hora, estado y capacidad. Una reserva registra a las personas asociadas a esa salida y su condición actual. Mantener esa separación permite cerrar una salida sin borrar el tour, modificar capacidad para una fecha concreta y preparar el manifiesto correcto.

La disponibilidad que se comunica al cliente debe salir de la misma salida donde se registrará su reserva.

Regla operativa recomendada

Definí los estados antes de abrir otro canal

Elegí pocos estados y escribí qué permite cada uno. Un ejemplo sencillo:

• Solicitud: llegó una intención, pero todavía no descuenta como confirmada según la política.
• Pendiente: el equipo está validando pago, disponibilidad o condición necesaria.
• Confirmada: cumple la regla del negocio y ocupa cupo.
• Cancelada: deja de ocupar cupo según la política aplicada.
• Atendida o cerrada: la salida ya se ejecutó y queda como historial.

Los nombres pueden cambiar. Lo importante es que dos personas no interpreten el mismo estado de manera opuesta y que el cálculo de cupo use una definición conocida.

Controlá capacidad y recursos por separado

Primero calculá el cupo de personas: capacidad de la salida menos reservas que realmente ocupan espacio. Después revisá recursos compartidos. Un bote de 12 plazas no resuelve una salida si ese bote ya está comprometido; un vehículo disponible tampoco alcanza si falta guía para la franja.

Protocolo de confirmación en seis pasos

1. Recibir la solicitud y asociarla al tour, fecha y hora correctos.
2. Consultar la salida central, no una captura ni una cifra enviada anteriormente.
3. Validar pasajeros y cualquier recurso limitante.
4. Aplicar la condición comercial definida por el negocio.
5. Cambiar el estado y registrar la reserva en la misma fuente.
6. Responder al cliente con el estado real: solicitud recibida, pendiente o confirmada.

Ejemplo ficticio: Operador Bahía

Operador Bahía es un escenario inventado. Ofrece una salida de mañana y otra de tarde con el mismo vehículo. La salida de la mañana todavía tiene espacio para dos personas, pero el vehículo necesita margen entre recorridos. El equipo registra ambas salidas, asigna el recurso y evita prometer un horario que hace imposible la siguiente operación.

Cuando llega una solicitud web para cuatro personas, no se etiqueta como confirmada solo porque el formulario fue enviado. Primero se revisan cupo, recurso y condición comercial. El cliente recibe un mensaje preciso y el manifiesto final incluye únicamente reservas en el estado definido para operar.

Rutina antes de cada salida

• Revisar reservas nuevas, canceladas o modificadas desde el último corte.
• Confirmar capacidad y recurso asignado.
• Resolver solicitudes pendientes que puedan cambiar el cupo.
• Generar o revisar el manifiesto con los datos estrictamente necesarios.
• Comunicar a operación una sola versión de la lista y registrar cambios posteriores.

Qué debe mostrar una demostración de software

Pedí crear una salida, modificar su capacidad, agregar una reserva, cambiar su estado, cancelar y revisar el manifiesto. Si existe un widget público, comprobá si presenta disponibilidad, recibe solicitudes o confirma automáticamente. Son flujos distintos y deben nombrarse con precisión.

Cuándo este proceso no alcanza

Si un canal externo confirma reservas por su cuenta, la integración y la sincronización deben validarse de manera específica. Pagos, reglas de inventario y disponibilidad en tiempo real no se pueden asumir para todos los canales. Una operación con cupos sujetos a clima, permisos o decisiones de último minuto necesita además un protocolo humano de cierre.

Preguntas frecuentes

¿Solicitud y reserva son lo mismo?

No deberían serlo si todavía falta validar capacidad, pago u otra condición. Nombrar el estado con precisión evita prometer algo que la operación aún no confirmó.

¿El cupo disponible evita todas las sobreventas?

Solo si todas las reservas relevantes descuentan de la misma salida y si los recursos limitantes se controlan. Una cifra aislada puede estar correcta y la operación seguir siendo inviable.

¿Tours Tico Online procesa pagos?

El alcance de pagos e integraciones se valida para cada implementación. Esta guía no promete un medio de pago universal ni confirmación automática.

Autoría, método y fuentes

Preparado y revisado por Isaac, Tico Online. El modelo se contrastó con la demostración y el flujo real de Tours Tico Online. Ejemplos y captura usan datos demo. Última revisión editorial: 3 de septiembre de 2026.