Como ya sabemos un mismo producto puede tener distintos tipos de usuarios con necesidades completamente distintas. En algunos casos, se convierten en diferentes ramas verticales del negocio, con desarrollos completamente independientes, y otras veces se personaliza o se realizan desarrollos especiales.
En nuestro caso, usando el proceso de compra tenemos 2 perfiles principales clientes y agentes de viajes.
Para entender un poco mejor el contexto, hace 2 años teníamos la siguiente situación:
- Los agentes estaban trabajando con un proceso de reservas muy antiguo, el cual tenía todas las funcionalidades que necesitaban, pero que visualmente era completamente distinto al que usaban los clientes, con una imagen de marca completamente desfasada de la actual (hacía unos años se había cambiado la imagen corporativa de la empresa). Este sistema, debido a otras prioridades, no recibía apenas mantenimiento ni soporte.
- Los clientes realizaban las reservas con un sistema más moderno, que no cumplía con las nuevas necesidades de desarrollo. Recibía soporte dado que era el proceso principal de venta, pero no el adecuado.
Es decir, teníamos 2 sistemas completamente distintos que si se quería seguir introduciendo mejoras, o arreglar errores que pudieran surgir, había que mantener de forma independiente, realizando 2 veces el trabajo. Esto, era insostenible.
Por ello, durante 2 años se ha cambiado la tecnología del proceso de reserva, con la idea de separar y abstraer toda la parte de presentación del motor de reservas (integración con mayoristas, algoritmo de precios, cobros…)
El objetivo era claro, trabajar ambas partes del sistema de una forma más flexible e independiente, con diferentes tecnologías, equipos, y más posibilidades de testeo y personalización.
Como todo gran proyecto, teníamos ciertas restricciones, siendo la más condicionante el número de personas trabajando en el proyecto. Por ello, no podíamos ir a la velocidad deseada (y todos sabemos que 9 mujeres no hacen 1 hijo en 1 mes), teniendo que priorizar ciertos aspectos del mismo, con lo que dividimos las distintas funcionalidades en releases en base a su prioridad.
Priorizando el desarrollo de las mismas funcionalidades
Agentes y clientes compartían las funcionalidades básicas, que básicamente se dividían en 3 grandes grupos:
- Lanzar una búsqueda y ver resultados, ya sea esta de localidad o de alojamiento.
- Poder seleccionar un alojamiento, ver características, precios…
- Elegir una opción y realizar la compra.
Por ello, nos centramos en realizar las partes comunes, antes de avanzar en las específicas propias de los agentes.
Solo realizar estos 3 proceso, requería un gran trabajo, ya que se dividían en muchas funcionalidades, como por ejemplo, el poder filtrar u ordenar los miles de resultados que te salen en una búsqueda de alojamiento en Madrid.
Como imagináis, poder poner en el mercado una primera versión funcional costó varios meses, no saliendo al inicio con el proceso completo, sino con una sola de las partes (la que se pensaba más sencilla), que podía además ser usada por el antiguo sistema y por otras líneas de negocio. En este post te cuento más sobre ello.
Una vez que completamos el proceso completo con un nivel adecuado en base a las necesidades de los clientes, y viendo con los datos que la conversión era gracias a las mejores introducidas mucho mejor que con el sistema anterior, parte del equipo se centró en desarrollar las funcionalidades propias del personal interno.
En el siguiente post continuaremos con ello, gracias!
Todos los derechos son de Centraldereservas.com. Queda prohibida totalmente la reproducción parcial o total del contenido.