A continuación podrá ver algunas aplicaciones prácticas del módulo de Business Intelligence, que le serán de utilidad para realizar un seguimiento de la tendencia de su negocio.
¶ Detectar bajadas de reservas
Uno de los indicadores que es conveniente monitorizar es la tendencia de reservas. En este aspecto, puede ser útil mirar las reservas por agencia y por proveedor.
¶ 1. Bajada de reservas de una agencia
Para detectar una bajada de reservas de una agencia debemos montar el cubo Nombre de Empresa - Bookings de la siguiente forma:
Como se puede ver, tenemos la agencia02 que aumenta las reservas, la agencia05 que las baja, y la agencia03 que las mantiene.
Para poder analizar la agencia 05, realizamos la siguiente vista del cubo de bookings, fijando la agencia05 y desglosando la agencia en los diferentes proveedores con la siguiente captura de pantalla:
Otras medidas que ayudan a analizar la perdida es el %MarkUp, mediante el cual podríamos ver si, al aumentar precios, hemos hecho nuestro producto menos atractivo, causando la bajada de reservas. Sin embargo, donde debe indagarse más es en el cubo de estadísticas, ya que es donde se puede ver si una bajada de reservas es debida a problemas técnicos, aparición de errores…
¶ 2. Bajada de reservas de un proveedor
Para detectar una bajada de reservas de un proveedor, debemos montar el cubo Nombre de Empresa - Bookings de la siguiente forma.
Como se puede ver tenemos el proveedor 1 que aumenta las reservas en cambio el proveedor 4 las baja.
Aquí, desglosamos por proveedor la agencia que ha tenido las pérdidas para saber si es algo generalizado o algo especifico de una agencia.
En este caso se puede ver como la bajada de reservas del proveeedor 4 se centra en una bajada de reservas de la agencia 3 hacía ese proveedor.
¶ Detectar variaciones de tráfico de una agencia
El tráfico recibido por parte de una agencia se puede analizar desde el cubo Nombre de Empresa - Statistics History Client. Para detectar si ha habido una variación del tráfico que envía una agencia se debe ver un evolutivo del tráfico enviado por cada agencia durante los últimos días:
En este caso, si se compara el día 03/10 con los días anteriores se ve cómo:
- Agencia 1, 3 y 4: tienen aproximadamente el mismo tráfico que los días anteriores;
- Agencia 2: envía sólo el 50% del tráfico que los días anteriores;
- Agencia 5: es una nueva conexión en el sistema ya que anteriormente no enviaba tráfico;
- Agencia 6: el día 03/10 no envió tráfico. Pero, si nos fijamos el mismo día de la semana anterior (el 26/09), tampoco envió tráfico por lo que esto parece ser su tendencia habitual.
Para la agencia 2, que es la que más ha reducido el tráfico, se recomienda mostrar las horas para saber a qué se debe la bajada de tráfico.
En este caso en concreto, se puede ver cómo la agencia deja de enviar tráfico a las 12h. Si ésta no ha sido una desconexión programada, se debería contactar con Agencia 2 para saber si ha habido algún problema.
Por otra parte, este mismo cubo permite monitorizar los tipos de peticiones que envía cada agencia (Availability, Cancellation Policy o Bookings, entre otros).
¶ Monitorizar el data transfer
El análisis del consumo de data se realiza desde el cubo Nombre de Empresa - Statistics History Client usando las métricas que se encuentran en la carpeta Size. La más usada es Size GB Response, aunque también se pueden usar otras métricas.
Si se desea monitorizar la data consumida por cada una de las agencias, se puede mostrar también el campo Agencia:
Además, puede verse en qué zonas ha consumido más tráfico una agencia durante un período concreto.
Los GB de una agencia están directamente relacionados con el producto que se le está devolviendo. Por este motivo, una variación en los GB consumidos por una agencia está directamente relacionada con:
- Tráfico de la agencia: si la agencia peticiona más (incrementa el tráfico) posiblemente le estemos devolviendo más producto;
- Time out configurado: cuanto mayor sea el time out, más producto se le estará retornando;
- Plantilla de agencia: cuanto mayor sea la plantilla, más hoteles van a peticionar la agencia y, en la mayoría de los casos, es equivalente a más producto retornado;
- Forma de peticionar de una agencia: cada agencia solicita diferente tipo de información para realizar una reserva. Por ejemplo, pueden solicitar sólo la habitación más barata, todos los tipos de régimen, fotos del hotel… Estas diferentes formas de peticionar tienen un impacto directo en los GB de un cliente.
¶ Errores más comunes
¶ 1. Errores de configuración
Cuando haya un error de configuración de los parámetros de una agencia, se podrá ver en el cubo Nombre de Empresa - Statistics History Client. Para detectarlos, se deben bajar las dimensiones Request type y Error, ya que de esta manera se podrá determinar en qué paso de la petición se ha producido la anomalía.
Algunos de los errores de configuración más frecuentes son:
-
Invalid IP: este error aparece cuando alguna agencia está enviando tráfico a través de una IP que no está correctamente configurada en el sistema. Para solucionarlo, se debe identificar cuál es la IP que está dando el error (bajando el campo IP).
Para solucionar el error, se recomienda contactar con la agencia o integrador que esté asociado a esa IP para verificar que es suya y, si es posible, solicitar algún log de la respuesta que le devolvemos a través de esta IP.
Posteriormente, se deberá contactar con el PM o el equipo de XML (xml@ejuniper.com) para que se realice la configuración adecuada para la IP que da el error.
-
Invalid nationality: en este caso, se está devolviendo este error ya que hay alguna (o algunas) agencias que están peticionando una nacionalidad que no les tenemos permitidas. Para ver más detalles del error, se recomienda bajar la agencia para saber cuál es la que peticiona desde una nacionalidad no permitida.
Por ejemplo: si tenemos la agencia Juniper en un grupo de agencias que no permitimos reservar desde España, cuando la agencia Juniper peticione desde España se va a devolver este error.
-
Invalid currency code: igual que en el caso anterior, hay alguna agencia que nos peticiona con una moneda con la que no le permitimos reservar.
-
Invalid customer: alguna agencia a la que le tenemos denegado el acceso nos está enviando tráfico.
Por ejemplo: si se desactiva la agencia Juniper pero ésta sigue enviando tráfico, el tráfico recibido se va a registrar con el error Invalid customer.
¶ 2. Errores de Cambios de Precio en Políticas de Cancelación o en Reserva
Supongamos que una determinada agencia nos reclama que le estamos dando muchos errores en políticas de cancelación. En muchas ocasiones, se trata de un error de cambios de precio.
Esto es debido, normalmente, a que ha habido un cambio de tarifa por parte del proveedor, pero su sistema tecnológico no lo ha actualizado en las peticiones de disponibilidad (Availability). Se trata de un problema que conviene atender ya que suele generar malestar a las agencias a las que damos los cambio de precio y puede entorpecer las relaciones comerciales.
Para identificar estos errores podemos ir al cubo de cambio de precio, y ver cuáles están siendo los proveedores y hoteles que están creando el conflicto.
Para ello , arrastramos al recuadro de valores las medidas Changes y Requests, situamos en filas el campo Fecha, y los campos Module y Product Code en el recuadro de columnas, mientras que filtraremos en el campo Customer = [Agencia deseada]. Adicionamente podemos filtrar por Interface, si queremos desglosar los errores por interfaz XML o Web, por canal, etc.
En este caso, vemos que de todos los proveedores conectados, solamente uno está dando cambios de precio. Habría que verificar desde el cubo de bookings si éste proveedor está generando reservas con esta agencia. A partir de aquí, pueden darse distintos casos:
- Si el proveedor conflictivo no está generando reservas, y la relación comercial con la agencia afectada puede ponerse en riesgo debido a este tema, la solución más drástica podría ser desconectar al proveedor.
- En muchos casos, el proveedor que está dando los problemas a la vez genera reservas y la solución no es tan fácil, ya que no es conveniente desconectar al proveedor.
En este caso, sería menos invasivo bloquear los hoteles afectados a día de hoy. No tiene sentido, sin embargo, bloquear hoteles que han dado errores de cambio de precio en días pasados pero que ya no dan errores.
¶ Información sobre los hoteles peticionados
Para poder analizar las peticiones por hotel se usan los cubos Nombre de Empresa - Statistics Hotel y Nombre de Empresa - Statistics Hotel Client.
Se pueden seleccionar diferentes vistas en función de cuál sea el objetivo del análisis.
¶ 1. Hoteles peticionados a un proveedor
Si se quiere ver el total de hoteles peticionados a un proveedor concreto (en este caso al producto propio) puede usarse la siguiente vista:
¶ 2. Hoteles con respuesta correcta o errónea
Si se quiere ver el número de peticiones correctas y erróneas que ha devuelto un proveedor concreto en un día concreto, puede usarse la siguiente vista:
¶ 3. Hoteles que una agencia peticiona a los proveedores
Esta información puede también analizarse por agencia, por lo que podría verse cuáles son los hoteles que una agencia determinada peticiona a qué proveedores.
¶ 4. Peticiones por fechas
Puede ser útil analizar la disponibilidad del proveedor por fechas. Por ejemplo, si vemos un hotel con un alto porcentaje de peticiones KO, se puede ver si es sólo en determinadas fechas o es generalizado. En caso de ser en determinadas fechas, es probable que sea por temas de contratos y, mediante este informe, se puede alertar que se están peticionando hoteles sin tarifas.
