CRM: yo entiendo que quieren que vayamos volcando la BBDD que generemos en esta próxima edición a su base de datos interna, verdad??? Con lo que el sistema debería tener un CRM.
Carga de datos de ediciones anteriores: ¿qué tipos de datos se deben cargar y en qué formato?
Back-office: cuando hablamos de reservas, ¿cuánto tiempo tiene que estar disponible la reserva?
Compatibilidad de canales de venta. Entendemos que con canales de venta se refieren a los distintos puntos de venta que venderán entradas del festival. ¿?
Si con canales de venta estamos hablando de distintos softwares que venderán entradas del festival, esta venta debería ser vía cupos de entrada asignados mediante bloqueos determinados para cada software distinto. ¿?
Entradas: incluir elementos informativos/publicitarios en función del perfil del comprador. Podemos hacerlo en el mail de confirmación, pero no en nuestra entrada.
Comparativa plurianual ¿estaríamos hablando de comparar con ediciones anteriores al 2021?
Gestión y control de accesos: ¿nos confirman por favor si podríamos generar un código de acceso ¿X¿ ligado a las acreditaciones (prensa, VIP, etc.)? Sería el mismo código para todas y ellos deberían imprimir las acreditaciones con el código que les digamos.
Usuarios: ¿cómo se gestiona esta zona en el caso de usuarios internos y externos? ¿previamente se carga un archivo con usuarios ya registrados? Es decir, ¿cómo sabemos cuándo activemos la web de venta que un usuario x es un usuario externo?
Publicada
02/de des./2020
contestada
03/de des./2020
CRM: el punto 5.7 del pliego técnico describe dos conceptos. Por un lado la BBDD del sistema y las características que debería incluir y, por otro lado, el CRM, el cual se entiende como un software que se alimenta de la BBDD, ordenando la información de la BBDD en una disposición determinada y cuyas características describimos en el mismo punto. En el punto 2 del pliego técnico, se indica que se deberá realizar una migración de datos de ediciones anteriores que deberá integrarse en la BBDD del licitador para poder hacer uso de ella. Respecto a los datos y el formato, el punto 10 del pliego (Calendario), da más datos sobre ello.
Back-office - reservas: el tiempo de disponibilidad de la reserva será a convenir en función de las condiciones de cada edición y/o tipo de reserva. No obstante, es un aspecto que se hablará con el licitador al detalle antes de poner en marcha la venta para poder consensuar criterios.
Canales de venta: el punto 3 del pliego técnico especifica los distintos canales de venta que podremos disponer en el festival. La 2a pregunta respecto a este tema, entiendo que hace referencia a los canales de venta externos. El apartado C del punto 3 explica de qué manera seria conveniente realizar este tipo de ventas.
Entradas: esta posibilidad creemos que es más conveniente incluirla dentro del diseño de la entrada electrónica. Es decir, el diseño de la entrada digital, debería tener un patrón flexible para incrustación de información, promociones, etc. en función del comprador. En caso de no ser posible, cabría ver las posibilidades que ofrece la solución.
Comparativa plurianual: Correcto, se trataría de comparar datos del año en curso respecto a ediciones anteriores.
Gestión y control de accesos: habría que estudiar la propuesta. Generalmente, hay un cupo restringido para este tipo de entrada, cuya confirmación de asistencia se realiza en un promedio de las 48h anteriores al espectáculo. El cupo varía en función del aforo del espectáculo, por lo que el sistema propuesto debería permitir un control y gestión por parte del personal del festival para poder activar el código de acceso a el/los espectáculo/s en concreto.
Usuarios: el punto 6 describe los distintos tipos de usuarios. Los perfiles y permisos de cada usuario se definirían en las primeras fases del proyecto, antes de la configuración de la venta.
