El problema real no es guardar la reserva
Casi cualquier herramienta guarda una reserva. Una planilla lo hace. Lo que no hace una planilla es acompañar el recorrido: cuando la consulta se convierte en cotización, alguien copia los datos a otro archivo; cuando se confirma, a otro; cuando se emite el voucher, los vuelve a escribir.
Cada copia es una versión de la verdad. Y el día que el pasajero llama porque el voucher dice otra cosa que la factura, hay que reconstruir cuál era la buena.
Los estados por los que pasa una reserva
En un sistema, todo esto es el mismo registro cambiando de estado. Eso es lo que permite ver el historial completo de una reserva sin buscar en cuatro lugares:
| Estado | Qué pasó | Qué se puede hacer |
|---|---|---|
| Consulta | Alguien preguntó | Armar una cotización |
| Cotización | Se mandó un precio | Reenviarla, ajustarla, confirmarla |
| Reservada | El cliente confirmó | Cargar pasajeros, pedir cupo al proveedor |
| Con seña | Pagó una parte | Ver el saldo, emitir factura |
| Pagada | Está al día | Emitir el voucher |
| Operada | El viaje pasó | Cerrar la cuenta con el proveedor |
| Cancelada | No se hizo | Nota de crédito, devolución |
Deslizá la tabla para ver el resto →
Lo que tiene que resolver
Mirando la operación diaria, estas son las piezas que hacen la diferencia:
La cotización es la venta
En turismo se compite por velocidad de respuesta. El cliente que pide tres presupuestos compra casi siempre al primero que le contesta con algo presentable.
Lo que acelera una cotización no es escribir más rápido: es no tener que armar el precio de cero. Si los servicios y las tarifas están cargados, la cotización se arma eligiendo, y el precio sale con el markup aplicado. Si cada presupuesto se calcula en una planilla aparte, el tiempo se va ahí y además cada uno sale con un criterio distinto.
Y después, que se convierta
Una cotización aceptada tiene que pasar a reserva sin volver a cargar nada. Si para confirmar hay que crear un registro nuevo y copiar los datos, el sistema está haciendo el trabajo de la planilla con más pasos.
Los pasajeros, que es donde se nota
Es la parte que los sistemas genéricos no tienen, y la que más tiempo come. Una reserva no es «un cliente»: es un titular y un grupo de pasajeros, cada uno con su documento, su fecha de nacimiento y a veces su requerimiento particular.
En un contingente de 45 personas, la diferencia entre cargarlos una vez y cargarlos cuatro —cotización, reserva, voucher, factura— son horas. Y cada repetición es una oportunidad de que un apellido quede mal escrito en el lugar donde más importa: el documento que presenta en el aeropuerto.
Un detalle que casi nadie mira en una demo y después pesa todos los días: a quién pertenece el cupo. Si una salida la venden varios paquetes, el cupo es de la salida, no del paquete. Un sistema que los confunde deja vender de más.
Del voucher a la factura
El voucher es lo que el pasajero presenta, así que tiene que salir con los datos de la reserva: nombres como figuran en el documento, fechas, servicios incluidos y los datos del proveedor que lo va a atender.
Y la factura tiene que salir del mismo lado. Si la reserva vive en un sistema y la facturación en otro, vuelve el problema del principio: dos versiones del mismo importe. En Argentina la emisión es directa contra ARCA; para el resto de la región todavía no, y está explicado en la página de facturación electrónica.