Pruebe más que el botón de cambiar fechas
La demo de un PMS debe mostrar más que editar fechas. Compruebe disponibilidad de la nueva noche, número actualizado, tratamiento del precio y momento de confirmación. Pida escenarios no disponibles y pendientes además del exitoso. Utilice registros ficticios en un entorno separado de canales vivos y comunicación con huéspedes. Son preguntas de evaluación, no capacidades atribuidas a un producto. La guía pública OPERA Cloud 26.2 describe una pantalla de confirmación de disponibilidad al cambiar fechas. Airbnb indica que una solicitud estándar del anfitrión deja la reserva igual si el huésped rechaza o no responde; también documenta excepciones según tipo de reserva. Son procesos diferentes. Editar en un PMS no prueba cambios automáticos en todos los canales ni una ruta universal de aprobación.
Un archivo pequeño y completo para la demo
Empiece con llegada ficticia el 16 de octubre y salida el 18: dos noches. Primero amplíe salida al 19: tres noches. Después suponga que no hay habitación adecuada para la noche adicional. Finalmente suponga disponibilidad con aceptación externa pendiente. Ninguna fecha corresponde a una reserva real. Declare tipo de habitación, ocupantes y supuestos de precio para relacionar resultados con entradas. El proveedor debe confirmar que la demostración no activa reservas, canales o mensajes reales. Las notificaciones son vistas previas sin destinatario real. Compare fechas, habitación e importe iniciales y finales. Solo complete el escenario si su resultado se puede comprobar. Si requiere conexión real no disponible, registre la falta de evidencia y el método separado que propone el proveedor. No marque una función no vista como demostrada.
Disponibilidad, precio y confirmación
Seleccionar una fecha no demuestra disponibilidad. Pregunte dónde se verifica la noche adicional, qué sucede si falta y si se conserva la reserva existente. Examine importe original y nuevo, explicación por noche y condiciones mantenidas o reconsideradas. Los productos no tienen que compartir un método de recalcular precios. Un número sin explicación no debe aceptarse solo porque aparece en pantalla. Pida comportamiento visible explicado, sin inventar otro cálculo. Distinga solicitud, cambio aceptado y operación fallida. No generalice el proceso estándar de Airbnb a todos los canales; excepciones y tipos tienen reglas propias. Pregunte cuándo se declara completado, qué fechas siguen vigentes mientras está pendiente y qué ve el usuario ante rechazo externo. Cuando el entorno seguro lo permita, pida un resultado de rechazo visible, no solamente una explicación verbal.
Decidir según la evidencia
Anote demostrado, parcialmente demostrado o no demostrado en cada escenario. La ampliación exitosa debe mostrar fechas, tres noches e importe explicable. La falta de disponibilidad debe mostrar conflicto sin parecer confirmada. El cambio pendiente debe separar estado vigente y solicitud incompleta. Son criterios propuestos, no pantallas ni métodos técnicos obligatorios. Separe comportamiento del producto y alcance de canales. Una demo local no prueba un resultado igual en canales vivos. Compare alcance documentado, escenarios mostrados y preguntas abiertas. No incorpore accesos ni reservas reales de clientes al trabajo editorial. Si falta evidencia adicional, conserve la incertidumbre en la decisión. Una demo útil explica cambios exitosos y fallidos con claridad.