PLIEGO DE PRESCRIPCIONES TÉCNICAS DEL CONTRATO DE SERVICIOS DEL SISTEMA DE VENTAS DE LOCALIDADES Y ABONOS DEL TEATRO DE LA MAESTRANZA
PLIEGO DE PRESCRIPCIONES TÉCNICAS DEL CONTRATO DE SERVICIOS DEL SISTEMA DE VENTAS DE LOCALIDADES Y ABONOS DEL TEATRO DE LA MAESTRANZA
CLÁUSULA 1. OBJETO
El objeto de esta licitació n es la contratació n del sistema de venta de abonos, localidades, visitas y otros extras asociados a los eventos y actos que tienen lugar en Teatro de la Maestranza y Xxxxx xxx Xxxxxx S.A. (Teatro de la Maestranza) ya sea como
organizador, como colaborador o como consecuencia de la cesión de uso de sus espacios.
Específicamente, tambié n se incluye dentro del objeto:
- El mantenimiento de la herramienta durante toda la duració n del contrato.
- Los desarrollos de la herramienta que sean necesarios a requerimiento del Teatro de la Maestranza durante toda la duració n del contrato.
CLÁUSULA 2. OBLIGACIONES DEL ADJUDICATARIO
2.1. El licitador que resulte adjudicatario, pondrá a disposició n del Teatro de la Maestranza un sistema que permita las ventas y el control y seguimiento de estas.
2.2. Xxxxxxx disponer de un responsable del servicio que esté al frente del servicio prestado en el Teatro de la Maestranza, que conozca el servicio y que pueda resolver en todo momento las posibles incidencias que surjan. Este hará el seguimiento del servicio y gestió n global del equipo y tendrá la má xima disponibilidad para ser
contactado por el equipo del Teatro de la Maestranza.
Esta persona tendrá que conocer todas las necesidades y estar siempre informado.
2.3. Transmitirá a su personal la informació n del Teatro de la Maestranza que este le facilitará , y velará por su buen cumplimiento. Como ayuda debe disponer de un sistema de gestió n de incidencias y consultas donde se pueda abrir un ticket en cualquier momento, y donde se puedan seguir las acciones y respuestas asociadas a esta.
2.4. El adjudicatario será el responsable de tener operativo el sistema de venta 24 horas al día los siete días de la semana los 365 días al año. Cualquier paro de servicio por motivos de mantenimiento tendrá que ser planificado y justificado, y se tendrá que programar en horas de baja actividad.
CLÁUSULA 3. GLOSARIO
Temporada, turno, título y funció n:
El Teatro de la Maestranza organiza sus eventos con estos cuatro conceptos:
Temporada: Es el periodo que va desde 1 de septiembre a 31 xx xxxxxx. Cada temporada se compone de todos los eventos que organiza el Teatro de la Maestranza.
Título: Agrupa todas las funciones de un mismo espectá culo. Funció n: Es cada una de las representaciones que se hacen de un título.
Turno: Es una agrupació n de funciones de diferentes títulos dentro de una misma temporada. La definició n de los 14 turnos se realiza por parte del Teatro de la Maestranza antes de empezar la temporada.
Entrada individual, abono, abono flexible y paquete:
La venta de localidades se centra en estos productos:
Entrada individual: Es una entrada para una persona para asistir a una funció x.
Xxxxx: Es una entrada individual para asistir a todas las funciones de un turno en una misma localidad.
Paquete: Es la compra de una entrada individual para varias funciones segú n criterios de promoció n que marca en cada momento el Teatro de la Maestranza.
Abono flexible: Es un paquete con una definició n particular y que toma categoría de abono.
Otros: tarifas planas, extras, cheques-regalos, paquetes combinados de extra y localidad, visitas, donaciones,...
CLÁUSULA 4. DESCRIPCIÓN DEL SERVICIO
El sistema de venta de localidades y abonos debe tener en cuenta la organizació n de espectá culos del Teatro de la Maestranza por su gestió n, de forma que se pueda trabajar con las agrupaciones pertinentes en cualquier momento.
La aplicació n tiene que integrar la venta anticipada de entradas por Internet, dispositivos móviles y otros canales, así como la reserva, emisió n y venta presencial en taquillas y
el registro de todos los movimientos derivados de la adquisició n de una entrada como cambios de día, liberaciones, etc.; las utilidades de gestió n de bases de datos de los clientes; la gestió n de informes, y el control de acceso en los recintos, segú n las especificaciones té cnicas definidas en este pliegue.
− Asimismo, tiene que permitir la compra y gestió n de los abonos que se ofrecen por parte del Teatro de la Maestranza y del propio abonado.
− Tiene que ser una aplicació n de ticketing y CRM para la venta y gestió n de la relació n con los clientes del Teatro de la Maestranza.
− Tiene que ser flexible y permitir la configuració n de forma autó noma de todas las modalidades de venta, así como de todos sus aspectos, e incluir todas las herramientas necesarias para la gestió n de los aforos, creació n y configuració n de recintos, espacios, temporadas, turnos y eventos.
− Igualmente tiene que disponer de un sistema de impresió n de entradas en
casa (print at home) por medio de có digos xx xxxxxx o có digos QR, así como de sistema de entradas en el mó vil (mobile ticket).
− Tambié n tiene que incluir un CRM que permita gestionar todos los datos de la relació n con los clientes, y donde se integren los datos de registro, ventas y e-mail, y que permita todo tipo de segmentaciones y la integració n con un gestor de mailing que nos facilite la comunicació n con los propios clientes.
− La base de datos tiene que permitir la importació n y exportació n de datos,
tanto de clientes como de ventas, y tiene que disponer de una interfaz de
comunicació n con otros sistemas como puede ser un BI o la herramienta de contabilidad.
− Los datos tienen que ser analizables mediante consultas e informes flexibles, con selecció n autó noma de los campos a incluir y de los filtros a aplicar sobre estos campos.
− El sistema tiene que permitir la integració n de herramientas de e-mail marketing que permita realizar campañas segmentadas de todas las direcciones recogidas en la base de datos CRM.
− La herramienta tiene que ser usable en backoffice, y amable y sencilla de uso para el cliente final.
CLÁUSULA 5. CONDICIONES GENERALES DEL SERVICIO
5.1 Idioma: La interfaz web por venta de localidades en castellano, inglé s, italiano, francé s, alemá n y ruso. La aplicació n de taquillas tiene que estar disponible en castellano e inglé s.
5.2. Navegador: La interfaz web tiene que permitir la gestió n con cualquier navegador xxx xxxxxxx: Internet explorer, Google Chrome, Firefox, Opera, Safari, así como la adaptació n a cualquier dispositivo (tiene que ser responsivo): PC's, Smartphone, tablets...
5.3 Unicidad de los datos: Todos los canales tienen que funcionar de forma integrada y sincronizada con acceso por parte de todos los usuarios a toda la informació n en tiempo real.
5.4 Vista del aforo: Todos los canales tienen que permitir la venta, simultá neamente y desde un ú nico plan xx xxxx, de entradas individuales, abonos (fijas o flexibles) y paquetes, con acceso a los diferentes precios, descuentos y precios promocionales que se definan. En el mismo plan, debe verse la leyenda de precios por zona así como tambié n el sumatorio de las entradas seleccionadas.
5.5 Visualización 3D: El sistema tiene que soportar la integració n de herramientas que permitan la visualizació n en 3D desde cada butaca del aforo.
5.6 El sistema tiene que poder soportar picos de venta y proporcionar un servicio sin degradació n en las é pocas de mayor actividad.
5.7 Base de datos: El sistema tiene que permitir el almacenaje de los datos de los clientes y abonados, así como su gestió n y explotació n a efectos estadístico y de marketing, permitiendo hacer consultas con selecció n de los campos y los criterios de filtraje.
Los datos será n propiedad del Teatro de la Maestranza y así tiene que constar en el momento en que el cliente introduzca los datos. Su acceso estará limitado al personal autorizado por el Teatro de la Maestranza mediante la definició n de permisos de acceso. La recogida de datos incorporará todos los mecanismos de seguridad con el fin de garantizar su confidencialidad, la propiedad por parte del Teatro de la Maestranza y el
uso exclusivo por parte del personal expresamente autorizado.
En general, el sistema tiene que permitir cumplir con todos los requisitos recogidos, y que sean de aplicació n, en la LOPD (Ley Orgá nica 3/2018, de 5 de diciembre).
Igualmente, tendrá que prever el correcto cumplimiento de los requisitos recogidos y que sean de aplicació n del Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 xx xxxxx de 2016 relativo a la protecció n de las personas físicas en aquello relativo al tratamiento de datos personales y a la libre circulació n de estos datos y por lo que se deroga la Directiva 95/46/CE (Reglamento general de protecció n de datos).
5.8 Gestión de la informació n: El sistema tiene que facilitar al Teatro de la Maestranza la gestió n y la toma de decisiones mediante la posibilidad de obtener la informació n necesaria, en tiempo real y mediante la selecció n y combinació n de variables, de todo el proceso. La propuesta detallará las funcionalidades y prestaciones de esta utilidad.
En concreto, tiene que permitir:
a) Crear consultas e informes con autonomía para escoger los campos a incluir y los criterios a aplicar para hacer la selecció n de registros y la posibilidad tanto de visualizació n por pantalla como de exportació n a formatos tipo excel, .csv o similares de
forma que permitan la explotació n y utilizació n de la informació n. Tener acceso a informació n de temporadas pasadas.
b) Aportar soluciones que permitan la segmentació n de los clientes de forma autó noma y usable.
c) Exportar informes y consultas (por ejemplo en formato .xls o .csv).
d) Permitir la exportació n de datos a travé s de una API a otras aplicaciones.
e) Permitir la importació n de ficheros de datos procedentes xx xxxxxxx externas en la plataforma
5.9 Control de accesos: La aplicació n tiene que permitir la gestió n centralizada de los accesos mediante los dispositivos de control de entradas del Teatro de la Maestranza. La herramienta tiene que permitir la visualizació n en tiempo real de la ocupació n y la asistencia final real, la actualizació n de los datos en tiempo real (entradas vendidas o
anuladas de ú ltima hora) y la incorporació n al sistema de entradas vendidas con otros
sistemas. Tiene que permitir ver el detalle de los espectadores que han accedido a una
funció n en concreto, con un buscador de los asistentes (por có digo xx xxxxxx, nombre, localidad...) así como tambié n detalle de los posibles errores en el control de acceso, ya sea de entrada en el recinto como de salida. Posibilidad de visualizació n por pantalla o CSV.
5.10 Puntos de venta y promotores externos: La aplicació n tiene que permitir gestionar el trabajo de los puntos de venta y los promotores externos con las limitaciones de acciones, eventos y acceso a datos pertinentes en cada caso.
5.11 Formació n: El adjudicatario se hará cargo de la formació n del personal de taquillas, de administració n y de gestió n y de comunicació n. Esta formació n se hará en las dependencias del Teatro de la Maestranza. También será a cargo del adjudicatario la formació n necesaria en caso de cambios, modificaciones, ampliaciones y actualizaciones del sistema. El licitador hará constar en la propuesta el programa de formació n.
5.12 Impresión de entradas: Las entradas, tanto de taquillas como de print at home tendrá n que poder imprimirse con impresoras lá ser. Las reimpresiones se podrá n hacer a travé s del có digo xx xxxxxx, el identificador de compra o por asiento. Las reimpresiones podrá n ser parciales o total de una compra.
CLÁUSULA 6. ESPECIFICACIONES TÉCNICAS – FUNCIONALIDADES
6.1 Aforos.
a) Sectorizació n por á reas, zonas y localidades.
b) Aforos numerados, no numerados y mixtas (zonas numeradas y zonas no
numeradas).
c) Creació n autó noma de recintos no numerados.
d) Xxxxxxxx n a demanda al sistema contratado de recintos numerados, sin límite de espacios a crear.
e) Capacidad para reconfigurar espacios, mediante ampliaciones o reducciones xx xxxx y/o aforo, cierre de zonas, etc. configurada a tiempo real para usuarios del sistema.
f) Gestió n de zonas de forma autó noma.
g) Selecció n mú ltiple de butacas con facilidad.
h) Posibilidad de configurar los asientos individual o masivamente con la
informació n con respecto a: puerta, boca, visibilidad, vídeo, foto, lá mpara, visibilidad vertido, sobretitulado...
i) Las localidades deben tener la posibilidad de asociar la visibilidad 3D.
j) Los aforos tienen que seguir la jerarquía de los eventos de manera que en un momento dado se puedan hacer modificaciones en todas las funciones que pertenezcan a una temporada, a un turno, a un título o a una funció n individual.
k) Se tiene que poder definir el estado de cada una de las localidades (activa,
inactiva, venta solo en taquilla...).
6.2 Eventos
Los eventos siguen la jerarquía descrita, y se tienen que poder configurar y modificar individual o masivamente segú n los diferentes criterios de agrupació n que tenemos (temporada, turno y título).
Los eventos tienen características como el día y hora de inicio de la funció n, la imagen, el periodo de venta (que tiene que ser configurable segú n el canal) el grupo de tarifas, la liberació n de reservas...
De los eventos se tiene que poder:
a) Categorizar por gé nero y por atributos personalizables.
b) Decidir (o poder programar) cuá ndo iniciar y cerrar la venta de un espectá culo en funció n del canal de venta, de manera que los datos por un canal puedan ser diferentes que por otro. El inicio y final tiene que poder configurarse tanto en días y horas absolutas como con relativos al día y hora del inicio del espectá culo.
c) Fijar la fecha y hora a partir de las cuales los eventos será n visibles en los canales de venta (taquilla, Internet, puntos de venta...) así como tambié n la fecha
y hora que dejará n de ser visibles.
d) Fijar, tambié n en valor absoluto o relativo, el momento en el que las reservas se ponen en venta de manera automá tica.
e) Permitir la venta de productos asociados al espectá culo, como programas de mano, copas de cava o tickets de parking con diferentes tipos de IVA.
f) Fijar sus fees en funció n del canal de venta y del espectá culo tanto con un valor absoluto como con un porcentaje.
g) Modificar la url del acontecimiento para hacerlo má s amigable.
6.3 Venta de entradas en taquilla
La venta de entradas en taquilla se tiene que hacer a partir del aforo de vista ú nica, tal y como se está trabajando actualmente. En la aplicació n de taquilla se tienen que poder diferenciar claramente los diferentes estados de una localidad (vendida por entradas, ocupada por un abono vendida como paquete, reservada, libre, bloqueada...). Se tiene que poder ver claramente la localidad que se está seleccionando en aquella venta.
Se tiene que poder vender en una sola operació n los diferentes productos que tenemos, y se tiene que poder asignar la venta de cada producto a un cliente diferente (que se tiene que poder beneficiar de sus características y tarifas particulares). En la misma transacció n, se tiene que poder vender dos entradas juntamente con tarifas o
descuentos diferentes.
Se tienen que poder comprar varias entradas a la vez, ya sea pinchando encima o arrastrando la selecció n (por una selecció n mayor de entradas).
En caso de que sea un cliente nuevo, el sistema tiene que ser capaz de permitir dar de alta a este cliente y asignarle el tipo de cliente, dentro del proceso de compra. Tambié n se tiene que dar la posibilidad de hacer una venta sin asociarla a ningú n cliente.
El pago de la compra se tiene que poder hacer con todas las variantes que existen actualmente, y se tiene que poder cobrar tal y como el cliente nos indique (por ejemplo, si el cliente quiere pagar parte de la compra con una tarjeta de cré dito, otra parte con otra tarjeta y el resto en metá lico y/o con un cheque regalo).
Se tiene que poder enviar de manera automá tica el correo electró nico de la compra al cliente.
6.4 Venta de entradas por puntos de venta
Los puntos de venta tienen que poder vender los productos por los que se les dé permiso, con las tarifas específicas del punto, las formas de pago permitidas y sus condiciones específicas.
Los puntos de venta tienen que ser capaces de ver sus ventas y reservas sin tener acceso al resto de datos. En los casos en los que así lo determine el Teatro de la Maestranza, un punto de venta tiene que ser capaz de ver todas las ventas relacionadas
con una funció n determinada y los clientes implicados.
Los puntos de venta tienen que poder ser terminales operados por personal del punto de venta y puntos de venta que sean otras aplicaciones de venta. En este segundo caso el sistema debe tener una manera de comunicar estas aplicaciones de venta con tiempo real de manera que se trabaje siempre con un solo aforo, que es el del sistema del Teatro de la Maestranza.
Se tiene que poder cargar comisiones y fees específicas por los puntos de venta. 6.5 Venta de entradas para la web
Un usuario tiene que ser capaz de entrar en la web con cualquier navegador y hacer una compra. En este caso, dentro del proceso de compra, el usuario tiene que identificarse, y en caso de que no tenga usuario tiene que poder registrarse. El identificador ú nico del usuario de la web tiene que ser su direcció n de correo electró nico.
La informació n pedida a cada usuario tiene que ser configurable desde la aplicació n, tanto con respecto a la visibilidad o no de los diferentes campos en los diferentes formatos a travé s de los que el cliente se pueda conectar (ordenador, smartphone) como con respecto a la obligatoriedad de los campos. Será necesario avisar al usuario de sus
derechos sobre sus datos, tanto en el caso de ventas del Teatro de la Maestranza como
de otros promotores. En el caso de los promotores se tendrá que informar al usuario de que los datos tambié n pueden ser cedidos al promotor.
La aplicació n de venta por la web debe tener características parecidas en venta por taquilla en relació n con la vista ú nica del aforo (sin dividir la vista por sectores) y combinació n de diferentes productos y espectá culos, aunque la informació n que puede ver al usuario de la web en este caso es solo sobre si la butaca está libre u ocupada.
Por el contrario, la forma de pago en la web siempre será la de tarjeta de cré dito o el cheque regalo, y se pueden combinar los dos tipos de pago.
La aplicació n estará integrada con las pasarelas de pago con las que se opere y tiene que permitir realizar la compra de las entradas y su cobro a travé s de TPV virtual para la venta por canales.
El pago se podrá realizar mediante cualquier tarjeta financiera, nacional o internacional. El sistema tiene que poder discriminar varios TPV en funció n del promotor de los espectá culos.
El cobro mediante tarjeta tiene que garantizar que la emisió n de localidades no se efectú e hasta que el importe no haya sido cargado en la cuenta del cliente.
Una vez finalizada la compra, el cliente recibirá un e-mail de confirmació n de la compra. Las entradas adquiridas por la web será n entregadas:
a) En formato pdf para ser imprimido (sistema print at home).
b) En el telé fono mó vil (con có digo legible desde los dispositivos de control de acceso).
c) En formato passbook para dispositivos Apple.
Tambié n tiene que permitir enviar entradas como regalo programando la fecha y la hora entrega, y tambié n la posibilidad de incluir una dedicatoria
Este canal tambié n tiene que permitir ventas a precio cero, es decir, la expedició n de invitaciones que no pasen ni por el TPV virtual ni por el cheque regalo.
Se tiene que permitir la venta de localidades asignadas a una empresa vendedora y una organizadora diferentes, con los correspondientes CIF's. La aplicació n tiene que permitir la creació n de tantas empresas como sea necesario.
La web tiene que ser personalizable por el Teatro de la Maestranza, permitiendo una imagen muy parecida a la que utiliza el propio Teatro en su pá gina web. En caso de que el Teatro de la Maestranza cambie su imagen corporativa y/o su pá gina web, la parte de la aplicació n propuesta, tendrá que poder cambiarse en consecuencia.
El Teatro de la Maestranza tiene que poder hacer cambios en los textos que se muestran en la pá gina de venta y en los mensajes, todo en los correspondientes idiomas (castellano, inglé s, francé s, italiano, ruso y alemá n).
El Teatro de la Maestranza debe tener la posibilidad de hacer la trazabilidad de la navegació n de los visitantes en la pá gina web con una cuenta de Google analitycs o similar.
6.6 Abonos
Los abonos se definen como un grupo de entradas que pertenecen a una temporada. Hay dos tipos de abonos, los fijos y los flexibles.
6.6.1. Abonos Fijos
Los abonos fijos se caracterizan por estar definidos por el teatro, y sus titulares tienen la misma butaca para todos los eventos asignados a este abono.
Los abonos fijos se renuevan, automá ticamente, anualmente, siendo sus formas de pago la tarjeta de cré dito, la domiciliació n bancaria (esta puede ser fraccionada) o la emisió n de la correspondiente factura e invitació n.
La renovació n automá tica del abono debe tener en cuenta tanto la localidad como el turno del abonado, así como tambié n la tarifa asignada y antigü edad.
Cada abono tiene su antigü edad, lo que permite aplicar tarifas má s ventajosas. Esta antigü edad se mantiene en diferentes casos como es la renovació n anual, cambio de localidad, cambio de turno, cambio de butaca, cambio a abono flexible durante un tiempo y que vuelva al abono de butaca fija.
El sistema tiene que permitir la automatizació n de las tarifas de los abonos en funció n de la antigü edad y de los criterios marcados por el Teatro, permitiendo cambiar la política de precios segú n las necesidades del Teatro.
Para poder realizar eficientemente la renovació n, el sistema tiene que ser capaz de crear ficheros XML con formato SEPA de manera tal que se pueda enviar a la entidad bancaria por el cobro de los recibos generados durante la renovació n. Asimismo, el sistema tiene
que ser capaz de recibir la respuesta de la entidad bancaria y marcar en el sistema tanto los que no han tenido ningú n tipo como los que sí la han tenido.
Igualmente, el sistema tiene que permitir la notificació n automá tica de peticiones de creació n de nuevas tarjetas físicas de abono cada vez que haya una nueva alta vía integració n de la plataforma con el proveedor que el Teatro disponga que se tiene que encargar de esta producció n de tarjetas.
6.6.2. Abonos flexibles
Estos abonos se caracterizan porque está n compuestos por funciones que escogen a los propios abonados tanto en días de las funciones como en las localidades por cada una de las funciones, que puede ser diferente. El teatro en este caso define unos pará metros de tipo y nú mero de eventos para que una compra de localidades pueda ser considerada un abono flexible.
Estos paquetes de entradas (abonos flexibles) generan antigü edad igual que los abonos de butaca fija.
Los abonos flexibles se pueden renovar anualmente o cambiar por abonos de butaca fija, manteniendo la antigü edad en ambos casos.
Igualmente, el sistema tiene que permitir la notificació n automá tica de peticiones de creació n de nuevas tarjetas físicas de abono cada vez que haya una nueva alta vía integració n de la plataforma con el proveedor que el Teatro de la Maestranza disponga que se tiene que encargar de esta producció n de tarjetas.
6.6.3. Funcionalidades propias de la gestió n de abonos
− El abonado tiene que poder gestionar su abono por Internet, y puede cambiar de día si no puede asistir, liberar entradas, recuperar entradas si estas no se han vendido o ceder la entrada.
− La liberació n de la localidad con recompensa se tiene que configurar por cada tipología de turno (temporada) cuá ntas funciones del abono y cuá ndo se pueden poner en venta para que pueda ser adquirida por otro usuario y en caso de que estas localidades se vendan se recompensa el abonado con un % determinado por el Teatro. Se tiene que poder configurar el porcentaje qué se devuelve al abonado que ha puesto su localidad a disposició x xxx xxxxxxx en el caso de que se venda, así como contemplar que el abonado recupere su localidad siempre que esta todavía no se haya vendido. El abonado puede escoger la
devolució n inmediata (ingreso en cuenta corriente) o devolució n futura (a
descontar del abono de la pró xima temporada). Ademá s se contabiliza la ganancia producida por el asiento libre al venderse la localidad por segunda vez. Tambié n se envía de manera automá tica un e-mail al abonado cuando pone su entrada a la venta y cuando se vende.
− Servicio de renuncia de acontecimiento del abono configurable, permitiendo retornar al abonado una serie de funciones de su abono durante un periodo
definido y que compense el 100% del valor del acontecimiento reduciendo el precio del abono.
− Imprimir una entrada de un acontecimiento del abono: En este caso el carné de abono deja de ser la entrada vá lida por aquel acontecimiento y la entrada imprimida pasa a ser la vá lida.
− Tiene que permitir ceder la entrada.
− Cambio de entradas entre sesiones de diferentes turnos. El abonado tiene que poder cambiar la localidad de un acontecimiento de su abono por otra localidad del mismo título. En este caso el abonado tendrá que pagar la diferencia en caso de que la butaca destino sea má s cara que la butaca de origen. En caso de igual o menor precio no habrá ninguna compensació n econó mica.
− Cá lculo de la ganancia por cambio de localidad provocada cuando un abono cambia la entrada de una sesió n por otra má s barata, entendiendo que el Teatro no devuelve la diferencia de precio.
− El sistema tambié n tiene que permitir cambiar entre sesiones de diferentes turnos sin cambio de precio aunque esté n valorados con un precio diferente.
− Cambio de abono: Durante el periodo definido por el Teatro, el abonado tiene
que poder cambiar su abono por otro sin perder su antigü edad.
− Baja de abono: este es otro de los trá mites que tiene que estar disponible por el abonado desde su zona de gestió n de los abonos
− Renovar abono: este trá mite tiene que estar disponible por el abonado desde su zona de gestió n de los abonos.
− Se tiene que poder cambiar la titularidad del abono, transferir el abono.
− Tiene que permitir gestionar duplicados de tarjetas de abonos.
− Tiene que permitir cambiar la tarifa de un abono sin tener que anular y volver a vender el abono.
− Tiene que ser posible la gestió n del pago de má s de un abono de titulares diferentes por parte de un solo abonado.
− Ademá s de las funcionalidades de la gestió n del abono referidas, el abonado tiene que poder modificar é l mismo por Internet cualquiera de los datos de contacto de su ficha cliente que hayan sufrido alguna variació n.
6.7 Paquetes de eventos
Los paquetes son grupos de eventos que pueden ser definidos como:
− Paquetes cerrados: es un conjunto de localidades por diferentes espectá culos concretos. El cliente no puede escoger la composició n del paquete.
− Paquetes abiertos: en este caso el cliente puede escoger los eventos dentro de
un grupo de eventos propuestos. Se tiene que poder definir en este caso el nú mero de eventos mínimo y má ximo que se tienen que comprar para considerarlo dentro del paquete.
− Paquetes mixtos: son paquetes abiertos pero que tienen ciertos eventos fijos.
Con la compra de paquetes se tiene que poder:
− Comprar entradas adicionales a los paquetes, al mismo precio o a un precio diferente segú n lo marque el Teatro de la Maestranza.
− Añadir gastos de gestió n, por entrada o por paquete.
− La definició n de paquetes tiene que permitir hacer condiciones sobre grupos de eventos, de manera
− que un paquete puede estar hecho con uno o varios eventos de un grupo de ellos má s uno o varios eventos de otro grupo.
− Definir el canal y el periodo de venta por cada canal.
− Se tiene que poder “ir” a la compra del paquete directamente con una url concreta, que tiene que poder definir el Teatro.
− Imprimir una sola entrada por todos los eventos de un paquete (tal y como si fuera un abono) o imprimir una entrada diferente por cada entrada del paquete.
− Integrar funciones de diferentes temporadas, en el mismo paquete. Una vez comprado el paquete, el cliente tiene que poder hacer las siguientes gestiones:
− Cambio de localidad: tenemos que tener la posibilidad de definir el tipo de cambio de localidad que queremos permitir, por otra localidad cualquiera del paquete (con cobro de diferencia en caso de que sea de un precio superior) o por una localidad de la misma á rea de precio, o del mismo título.
− Renovació n: se tiene que poder renovar un paquete de una temporada a la otra
como si fuera un abono flexible.
6.8 Portal del usuario
El usuario registrado tiene que disponer de un espacio donde poder gestionar sus entradas y abonos. Desde este punto, el usuario tiene que poder gestionar sus datos,
consultar sus compras, imprimir sus entradas, y consultar el saldo y el có digo de sus cheques regalo.
6.9 Venta de Extras
El programa tiene que permitir la venta de extras, ya sea junto con entradas concretas o aparte.
Se tiene que poder configurar el sistema para que, durante el proceso de venta de entradas, se sugiera la venta de algunos extras determinados asociados a aquellos acontecimientos o título.
Los extras deben tener control de stock y se tienen que configurar para vender en cualquiera de los canales y puntos de venta del Teatro.
Los extras tambié n tienen que poder asociarse a una empresa (CIF) diferente en cada caso, así como un IVA diferente.
Los extras tienen que disponer de control de acceso.
La configuració n de paquetes con extras tambié n tiene que ser una opció n.
Un caso especial de extra es el cheque regalo.
Tarifa plana: paquete multiespectá culo intercambiable por un nú mero determinado de funciones. Se tiene que poder definir el tiempo a partir del cual es intercambiable y se tiene que poder limitar a un uso má ximo de entradas por funció n.
6.9.1 Cheque regalo
El cheque regalo es una tarjeta con un valor en euros por la compra de productos del Teatro de la Maestranza, entradas o paquetes. Este cheque debe tener fecha de caducidad configurable por parte del propio Teatro. Esta fecha de caducidad tiene que poder ser relativa (en el momento de la compra) o absoluta.
Las compras se podrá n realizar utilizando uno o varios cheques regalo junto con cualquier otra forma de pago que permita el canal (tarjeta por la web o tarjeta y metá lico en taquillas).
El cheque regalo se tiene que poder comprar por cualquier valor a taquillas y en la web se tiene que poder comprar por valores predeterminados.
Se tiene que poder generar una tarjeta en las taquillas que represente el cheque regalo con un có digo identificativo que se pueda interpretar tanto con caracteres como con có digo xx xxxxxx.
Para la adquisició n por Internet hace falta que se pueda imprimir un cheque regalo en formato “print at home” específico.
En el á rea del cliente se tiene que poder consultar en todo momento el saldo restante del cheque, y en la ficha del cliente tiene que constar esta compra y el saldo restante.
El programa debe tener los listados específicos con el fin de poder gestionar y hacer un seguimiento de los cheques regalo, así como una herramienta para buscar el propietario y el histó rico de un cheque regalo.
6.10 Entradas (Formatos y diseño)
Las entradas tienen que poder tener varios formatos: Taquilla (Entrada tradicional imprimible en impresora lá ser), Print at home (Entrada que imprime el cliente en un Din A4), mó vil (por smartphones), passbook (iPhones).
Cada formado tiene que ser activable y diseñable individualmente en funció n del acontecimiento y de la funció n. Los diseños tienen que poder ser modificados por los propios usuarios del Teatro.
Las entradas tienen que permitir imá genes y textos, y presentarse en funció n del idioma escogido, tanto por lo que respecta al texto como a la imagen (que podría contener texto).
En las entradas se tiene que poder incluir un có digo xx xxxxxx en formato EAN13 o Code 128 (longitud 13 o 14 dígitos) así como un có digo QR si se desea.
Las mismas características que por las entradas a eventos tienen que poder tener los resguardos de las compras de extras (formados, canales...).
6.11 Software de taquillas
El programa que se utiliza en taquillas o en el backoffice tiene que permitir las gestiones que habitualmente se hacen con las entradas:
− Anulació n de entradas: el operador tiene que poder anular la compra de entradas, y en el caso de venta por TPV virtual, se tiene que poder hacer la devolució n del importe en la misma tarjeta que se ha utilizado para hacer el pago.
− Tambié n tiene que permitir la anulació n masiva de una funció n.
− Posibilidad de escoger si se devuelven o no los fees en caso de anulació n.
− Permisió n de escoger el estado en que se queda la entrada que se anula (disponible por taquillas o por todos los canales).
− Cambio de entradas: se tiene que permitir el cambio de entradas sin tener que anular la venta y hacer una nueva venta. En caso de diferencia de precio se tiene que poder facturar la diferencia en caso de que la nueva entrada sea m á s cara o devolver o no en caso de que sea má s barata.
− Regulació n de compra: en caso necesario se tiene que poder modificar los datos
de una compra, como por ejemplo la asignació n a un cliente concreto o el punto de venta por el que se ha realizado. El sistema tiene que mantener una trazabilidad sobre todas las transacciones, y sobre todo sobre estas.
− Reserva de entradas: estas se tienen que realizar con el mismo procedimiento que las compras, pero a diferencia de las compras las reservas no se pagan totalmente, aunque deben tener la posibilidad de cobrarse parcialmente.
− Las reservas se tienen que poder modificar sin necesidad de anularse y volver a crearse. Tambié n tienen que poder tener una fecha de caducidad, que libere las localidades en caso de que no se haya hecho ningú n pago a cuenta.
− Las reservas se tienen que poder convertir o anular en parte o en su totalidad.
− En el aforo (plano) debe mostrarte el historial de cada butaca al seleccionar la butaca en aquella funció n. Desde allí tambié n tiene que permitir ir a la ficha del cliente directamente.
− El sistema debe tener maneras de informar a los interesados y a los administradores (correos y listados) de las fechas de caducidad de las reservas.
− Las reservas deben tener un identificador para que se puedan localizar de manera sencilla.
− El sistema te tiene que avisar cuando entras en una ficha de un abonado y este tiene recibos devueltos.
− Se tiene que poder visualizar el estado de los recibos (pagado, pendiente, devuelto).
6.12 Tarifas y descuentos
El sistema tiene que permitir la creació n de un nú mero ilimitado de tarifas y descuentos. Los descuentos tienen que poder ser valores concretos o porcentajes sobre el valor de la tarifa.
La gestió n de las tarifas y descuentos debe tener las siguientes características:
• Total autonomía para la creació n de las tarifas y descuentos.
• Posibilidad de creació n de invitaciones (tarifa cero o gratuita).
• Posibilidad de limitar a una cantidad mínima de entradas la aplicació n de una tarifa a una venta (tarifas para grupos).
• Posibilidad de limitar la cantidad má xima que un cliente puede comprar con una tarifa, tanto por espectá culo como por título.
• Opció n a añadir comisió n de gestió n u otras comisiones en funció n del canal y/o la forma de pago y en funció n de la tarifa y/o descuento.
• Gestió n autó noma con configuració n de periodo de validez.
• Gestió n de compra miń ima y má xima de entradas por espectá culo, tarifa y/o canal.
• Se tienen que poder definir grupos de tarifas y descuentos, de manera que
categorizando los espectá culos se pueda asignar un grupo de tarifas a varios espectá culos.
• Permitir descuentos por porcentaje o por valor absoluto.
• Descuentos por có digos. Creació n autó noma de có digos, carga de có digos externos en el sistema.
• Descuentos para terceros con conexió n automatizada (Cadena Ser o COPE, por ejemplo).
• Descuentos asociados a zonas.
• Las tarifas/descuentos se tienen que poder utilizar en funció n de las características del cliente, de manera que segú n el tipo de cliente se puedan utilizar unas tarifas/descuentos o no.
• Tiene que haber una funcionalidad por la carga de tarifas masiva. Normalmente esta funcionalidad se utilizaría en el momento de configurar la temporada donde tenemos mucha diversidad de tarifas
• y grupos de precios. Esta carga se tiene que poder hacer a partir de una hoja de Excel.
• Tiene que existir la posibilidad de hacer una compra con una tarifa especial por Internet, pero que requiera el paso por taquilla para verificar las condiciones (presentació n de algú n documento, por ejemplo) y poderla imprimir.
• Se tienen que poder crear tarifas específicas para grupos de usuarios que se puedan aplicar a este despué s de su validació n.
• Posibilidad de creació n de tarifas/descuentos aplicables a partir de có digos promocionales que se tienen que introducir en el momento de la utilizació n. Estos có digos promocionales tienen que poder cargarse en el sistema de forma masiva (introducció n de muchos có digos a travé s de un fichero .csv, por ejemplo) o pueden ser có digos ú nicos que se puedan utilizar solo un cierto nú mero a veces.
• Precios diná micos, son modificaciones a la tarifa en funció n de la ocupació n de la
zona por un espectá culo, de manera que a má s ocupació n má s sube el precio de la entrada. Los incrementos se tienen que poder hacer de forma absoluta o porcentual,
y se tienen que poder definir tantos tramos de ocupació n por zona como se quiera, cada uno con su correspondiente incremento.
• Tiene que permitir enviar entradas como regalo programando fecha y hora entrega, incluyendo una dedicatoria.
• Posibilidad de indicar si la aplicació n de una tarifa implica que tenga o no un fee.
• Permisió n de carga de tarifas de abonos y entradas de forma automatizada mediante ficheros
• Posibilidad de insertar Símbolos y/o imá genes en el diseño del ticket (segú n la tarifa).
6.13. Formas de Pago
Las formas de pago que se tienen que aceptar son:
− TPV Virtual: El sistema tiene que poder configurarse para otros TPV distintos de los que trabaja actualmente el Teatro de la Maestranza. Tambié n tiene que permitir la creació n de diferentes TPV por el cobro de diferentes espectá culos y/o extras.
− Domiciliació n bancaria: los datos bancarios tienen que poder figurar en la ficha del cliente con el fin de poder hacer cobros puntuales o masivos como las renovaciones de abonos, de manera que el sistema sea capaz de utilizar estos
datos para preparar los ficheros que se tienen que enviar a las entidades bancarias.
− Cheque regalo: Ya comentado en su propio apartado.
− Paypal: El sistema tiene que permitir esta pasarela de pago.
− Efectivo.
− Datá fonos (tarjetas de cré dito y xxx xxxx).
− Tarifa plana.
− Pago condicionado a la emisió n de la correspondiente factura.
− Las formas de pago tambié n tienen que permitir el cargo de una comisió n por su utilizació n, ya sea con valor absoluto o relativo.
6.14 CRM
Debido a que el Teatro de la Maestranza no dispone actualmente de una herramienta especifica de CRM, el sistema de ticketing nos tiene que permitir hacer segmentaciones en funció n de los comportamientos y los datos de que disponemos de nuestros clientes.
La base de datos de clientes y todo su contenido será propiedad del Teatro de la Maestranza.
Dentro de la ficha de un cliente se tienen que reflejar todos los datos de compra y asistencia, así como los datos personales del cliente y las que decida el Teatro de la Maestranza que son de interé s, o sea, tiene que haber la posibilidad de añadir campos no previstos en un principio.
La ficha del cliente tiene que recoger tanto los datos relativos a la temporada en curso como el histó rico de aquel cliente con todas las operaciones y movimientos realizados en temporadas pasadas.
El sistema tiene que estar integrado la herramienta de mailing que utiliza el Teatro de la Maestranza. Esta integració n tiene que permitir exportar los resultados de las segmentaciones hechas en el sistema, dar de baja envíos a los usuarios que así lo pidan desmarcando la casilla de consentimiento pertinente y visualizar el rating, los clics y otras estadísticas dentro de la ficha del cliente dentro del propio sistema.
Los clientes tienen que poder ser clasificados y etiquetados con mú ltiples valores, permitiendo así, no solo segmentaciones para hacer mailings sino tambié n para utilizar en funcionalidades como permisos para utilizar determinados tipos de tarifas y descuentos.
El formulario de registro tiene que ser totalmente personalizable por el Teatro de la Maestranza, determinando campos opcionales y campos obligatorios. Tambié n se tiene que permitir el registro con las credenciales de Facebook.
Al finalizar una compra, el sistema tendría que permitir, de forma fá cil para el cliente, la comunicació n a las redes sociales (Twitter, Facebook, Google+, LinkedIn) o a sistemas de mensajería (Whatsapp, correo electró nico) de su compra. Estos mensajes tienen que ser preconfigurables por el Teatro de la Maestranza (textos e imá genes).
Igualmente, el sistema tendrá que permitir la configuració n y envío automá tico de mensajes informativos y/o de agradecimiento una vez finalizada la operació n de compra.
Los textos relacionados con la Ley de protecció n de datos tienen que poder ser creados por el Teatro de la Maestranza.
Tiene que existir la posibilidad de importar datos de un sistema externo, como puede ser gené ricamente de un fichero .csv.
Es necesaria la existencia de una forma de comunicar los datos de la base de datos a otros sistemas como pueden ser un sistema de CRM externo o un sistema de BI.
6.15 Listados e informes
El sistema tiene que proporcionar toda la información que el teatro necesita de manera prá ctica y sencilla. Todos los listados tienen que poder salir en pantalla, en formato imprimible y en formato excel o .csv.
Los listados tienen que proporcionar la informació n desglosada o agrupada por espectá culo, día de venta, canal de venta, forma de pago, grupo de clientes y origen de la venta (es muy importante saber si la cantidad proviene de la compra de entradas o de la parte proporcional de un abono).
Los listados tienen que poder ser asignados para su utilizació n a perfiles y usuarios diferentes, y tambié n la informació n que podrá n ver estos usuarios tiene que ser configurable. Por ejemplo, un usuario que trabaja con un determinado tipo de espectá culo solo podrá ver la informació n de venta y/o de clientes de estos espectá culos.
Se tienen que poder obtener listados de:
a) Xxxxxx y abonados.
− Seleccionables por temporadas y turnos, incluyendo el histó rico de temporadas pasadas
− Filtrables por el tipo de abono, el estado de pago del abono y el origen de los abonos (nuevos, renovados o renovados con cambios).
− Filtrables por campos identificativos del abono como la zona, la tarifa o los descuentos aplicados.
− Con posibilidad de identificar los abonos liberados y los motivos de la liberació n.
− Con filtros de rangos temporales que permitan la selecció n por fecha de creació n o de baja de los abonos.
− Los listados tienen que permitir incluir todos los campos relacionados con el cliente (nombre y apellidos, e- mail, direcció n postal, telé fonos, sexo, edad, idioma de comunicació n, nú mero de cuenta...) y con su abono (fecha de creació n, zona, puerta y butaca, tarifa de compra, descuentos, forma de pago...).
− Listados de localidades liberadas, con posibilidad de saber si estas localidades
se han revendido o quedan libres, y del tipo de devolució n que generan para el abonado.
b) Ventas de abonos; ventas de entradas fuera de abono y ventas totales teniendo en cuenta los abonos y las entradas fuera de abono.
c)
− Posibilidad de obtener el detalle de todas las operaciones realizadas (compras, anulaciones,
− cambios de día, reimpresiones de entradas, liberaciones...).
− Capacidad de obtener listados resú menes de operaciones agregadas por espectá culos y funciones.
− Filtros de selecció n temporal de las operaciones: por fechas, temporadas (incluyendo el histó rico
− de temporadas anteriores), espectá culos o funciones.
− Posibilidad de filtrar por el estado de la venta (todos los movimientos,
operaciones de cancelació n de entradas, entradas vigentes).
− Filtros por tarifas, descuentos, formas de pago o segmentos de clientes, canal
de venta... Identificació n del nú mero de reservas existentes para cada funció n y del importe comprometido. Cuantificació n de las ganancias derivadas del cambio de localidades, de la liberació n de butacas y del incremento de precios por precio xxxxx xxxx.
Capacidad de calcular ingresos con y sin gastos de gestió n.
Capacidad de calcular la base imponible, de acuerdo con el tipo de IVA vigente
en cada momento, de los ingresos por cada uno de sus componentes: venta de
entradas, gastos de gestió n, descuentos y ganancias por cambios de localidad, liberació n y precios diná micos.
− Listado de ventas no finalizadas.
− Listado de ventas por usuario.
d) Cierre de caja.
e) Listado de venta de extras.
f) Cheques regalos.
g) Listado de reservas.
h) Listado de ventas de paquetes.
i) Listado de tarjetas regalo y monedero.
j) Listados de control de asistencia a las funciones.
k) Listados de funciones liberadas. En este listado tiene que salir el nú mero de cuenta del abonado.
l) Listados de clientes (registros ú nicos, independientemente del nú mero de operaciones asociadas a estos registros). Filtrables por los campos relacionados con:
− Sus datos personales y de contacto (sexo, edad, direcció n, CP, país, idioma, aceptació n de recibir comunicaciones, correo electró nico...).
− Su comportamiento de compra: compra de abonos, de entradas fuera de abono,
selecció n por temporadas, títulos o funciones concretas, compra de extras, selecció n por nú mero de entradas o importes de compra, canales de venta, tarifas y descuentos, selecció n por fechas de operació n...
− Posibilidad de combinació n mú ltiple de los diferentes criterios de segmentació n: todos los campos seleccionados, algunos de los campos seleccionados,
combinaciones I, O, NO.
6.16 Usuarios de la aplicación
El teatro tiene muchos usuarios diferentes, con diferentes perfiles, por lo que el sistema tiene que permitir la creació n de diferentes perfiles de usuario donde los permisos se puedan dar tanto por funcionalidades como por datos.
Es decir, se tiene que poder definir qué acciones tiene que poder hacer un usuario (venta, reserva, consulta....) y sobre qué elementos tiene que poder hacerlo (unos espectá culos en concreto o un grupo de usuarios).
En caso de que un usuario no recuerde la palabra de paso la tiene que poder recuperar autó nomamente con la funció n de “recuperar palabra de paso” que tiene que estar en la pá gina de validació n de usuario.
Los usuarios y sus palabras de paso tienen que poder tener fechas de caducidad.
6.17 Control de accesos
La aplicació n tiene que permitir la gestió n centralizada de los accesos del pú blico a los eventos, tanto con los equipos está ticos del Teatro de la Maestranza como con lectores móviles como las PDAs o los smartphones.
El sistema tiene que facilitar la informació n en tiempo real de las lecturas realizadas por los turnos y ser capaz de mostrar gráficamente la asistencia de pú blico, de manera tal que en cualquier momento se pueda ver a simple vista qué localidades está n libres y cuá les ocupadas.
El sistema tiene que permitir tambié n la introducció n de có digos “externos” por el control de eventos que tambié n disponen de có digos propios.
El sistema tiene que poder funcionar en modo “off-line”, de manera que la caída de la conexió n con Internet no represente el fallo total del sistema.
6.18 Entorno de pruebas
Es importante que el sistema disponga de un entorno de test donde se hagan las pruebas de los nuevos desarrollos y se puedan probar nuevas funcionalidades o simplemente funcionalidades no utilizadas habitualmente y que se quieren probar.
Este entorno tiene que poder cargarse en cualquier momento con una copia de los datos reales de producció n.
CLÁUSULA 7. MANTENIMIENTO, SOPORTE Y ATENCIÓN A INCIDENCIAS
7.1 Mantenimiento y actualizaciones
El mantenimiento y las actualizaciones del sistema se realizará n sin paradas del servicio. En caso contrario, tendrá n que notificarse previamente al Teatro de la Maestranza y realizarse en horarios no comerciales o en periodos de baja actividad siempre que sea posible.
7.2 Definiciones
En el presente documento, el té rmino “disponibilidad del servicio” se aplica al porcentaje de tiempo sobre un mes concreto (entendiendo meses naturales y días de 24 horas) en que el servicio de venta de localidades ha estado disponible para el acceso por terceras partes, segú n medidas realizadas. Se entiende que el servicio está disponible si las
siguientes condiciones se cumplen al mismo tiempo:
a) Es posible realizar una transacció n de compra de abonos/paquetes/entradas al sistema;
b) Las landing pages albergadas a los sistemas del servicio son accesibles a terceras partes;
El té rmino “disponibilidad de los datos” se refiere a la garantía de disponer de al menos una copia de seguridad diaria de los datos de los clientes con una antigü edad no superior a los 14 días contados a partir del día actual. En té rminos generales se intentará disponer de al menos una copia diaria de los ú ltimos 21 días naturales contadosa partir del día actual.
El té rmino “borrado accidental de datos” se refiere a la ocurrencia de un acontecimiento que ocasione una pé rdida parcial o completa de los datos de los usuarios del servicio. El té rmino “cuota mensual” se refiere exclusivamente al importe de la cuota pagada por el Teatro de la Maestranza por mes por el servicio.
Los té rminos “corte de servicio” o “indisponibilidad del servicio” corresponden a una instancia en la que los servicios objeto de garantía no responden a una petició n del sistema de supervisió n durante un periodo continuado de como mínimo 15 minutos.
El té rmino “pé rdida de datos” corresponde a la imposibilidad de recuperar una copia de los datos del cliente con una antigü edad no superior a los 14 días en caso “de borrado accidental de los datos” actuales de los usuarios.
7.3 Disponibilidad del servicio
Para el cá lculo del tiempo de disponibilidad de servicio se excluirá n aquellos periodos de tiempos comprendidos en tareas de mantenimiento programado.
7.3.1 Objetivo:
El objetivo es conseguir un nivel de disponibilidad del servicio el m á s pró ximo posible al100% y conseguir una disponibilidad de los datos del 100%.
Se pide al proveedor del servicio una disponibilidad del servicio del 99,95%. Se tendrá n en cuenta los siguientes datos:
- Periodo de medició n: mensual
- Pará metro de medició n: % de disponibilidad de los servicios - Valor objetivo: >= 99,95
%
Tabla de Nivel de servicio y compensació n: NIVEL DE SERVICIO COMPENSACIÓN*
> = 99,95% No aplicable 99,00% – 99,95 % 5% de la cuota
95,00% – 99,00% 30% de la cuota
< 95,00% 60% de la cuota
* Sobre la cuota mensual del servicio.
La indisponibilidad del servicio causada por uno de los siguientes casos queda fuera de esta garantía:
- Mantenimientos programados.
- En caso de que el incidente sea causado por un problema en las aplicaciones propias del Teatro de la Maestranza.
7.4 Tiempo de Respuesta ante Incidentes
Se considera un incidente aquel que implica una interrupció n o degradació n del servicio ofrecido por la plataforma. El proveedor tiene que garantizar la resolució n de incidentes 24 horas al día, 365 días al año. Al recibir el incidente del sistema de monitorizació n, el proveedor revisará el problema, diagnosticará la causa si su naturaleza lo permite y si es posible restaurará el servicio.
Objetivo de nivel de servicio: el tiempo en que el proveedor empezará a realizar el diagnó stico del incidente; este dependerá del nivel de criticidad del incidente.
Los incidentes se catalogan en 3 niveles de criticidad:
• Xxxxx 0:
- Plataforma: incidentes que suponen una pé rdida total del servicio o una degradació n grave; se considera una degradació n grave de servicio, para los elementos en clú ster de disponibilidad, la pé rdida de servicio del 50% o má s de los nodos participantes del clú ster.
- Software: incidentes que suponen pé rdida total del servicio o degradació n grave, acusado por errores (bugs) del software.
• Xxxxx 0:
- Plataforma: incidentes que suponen una degradació n de servicio inferior al 50% de la potencia total, considerá ndose para eso la pé rdida de servicio en un nú mero de nodos inferior al 50% para un grupo de servicio en clú ster dentro de la plataforma, excluyé ndose las plataformas de preproducció n cuando estas no está n en arquitecturas redundadas de alta disponibilidad.
- Software: incidentes debidos a un uso correcto de la aplicació n, segú n las políticas de uso, y que suponen una degradació n grave del servicio.
• Xxxxx 0:
- Son todos aquellos incidentes que no entran en las clasificaciones anteriores, así como los sistemas de preproducció n, pruebas y desarrollo, cuando estos no han sido implementados en alta disponibilidad y tratados, a efectos de SLA, como equipos de misió n crítica.
A efectos de soporte 24 x 7, se atenderá n solo incidencias de nivel 1 y 2.
Los tiempos de respuesta y la diagnosis del incidente se tendrá n que hacer segú n los siguientes criterios y en funció n del nivel del incidente.
Tiempo de respuesta | Diagnosis | |
Xxxxx 0 | Inferior a 10 minutos | Primer diagnóstico en máximo de 90 minutos |
Xxxxx 0 | 90 minutos o menos en horario laboral | 180 minutos o menos fuera de horario laboral |
Xxxxx 0 | 180 minutos o menos en horario laboral | No asistencia fuera de horario laboral |
Si el proveedor no consiguiera alcanzar el objetivo anterior, el Teatro de la Maestranza podrá reclamar una compensació n segú n lo establecido en la siguiente tabla:
- Periodo de medició n: Mensual
- Pará metro de medició n: % de disponibilidad de los servicios
- Valor objetivo: >= 90,00 %
Tabla de Nivel de servicio y compensació n: NIVEL DE SERVICIO COMPENSACIÓN*
> = 90,00% | No aplicable |
80,00% – 90,00% | 10% |
70,00% – 80,00% | 20% |
< 70,00% | 30% |
* Sobre la cuota mensual del servicio
CLÁUSULA 8. GESTIÓN INCIDENCIAS EN EL SERVICIO Y PENALIZACIONES
Se considerará incidencia cuando una determinada funcionalidad o nuevo desarrollo no funcione de la forma correcta. En el momento en que se produzca una incidencia, el Teatro de la Maestranza abrirá un ticket exponiendo la problemá tica con el fin de proceder a su resolució n por parte de la empresa adjudicataria. Las incidencias se
clasificará n segú n su gravedad:
1. Gravedad alta. Incidencias relacionadas con la venta de entradas.
2. Gravedad media. Incidencias relacionadas con la gestió n de tareas de back office.
3. Gravedad media-baja. Incidencias relacionadas con la generació n de listados.
En todos los casos, una vez abierto el ticket la empresa adjudicataria tendrá que dar una primera respuesta en un má ximo de 20 minutos y la resolució n de la incidencia tendrá que ser, desde el momento en que se haya abierto el ticket, de:
1. Gravedad alta. Má ximo 60 minutos.
2. Gravedad media. Entre 3 y 6 horas.
3. Gravedad media-baja. Má ximo 12 horas.
En el caso de no cumplir estos periodos de tiempo para la resolució n, se considerará incidencia no resuelta en tiempo y por lo tanto será susceptible de penalizació n.
Las penalizaciones se aplicará n de acuerdo con:
1 incidencia no resuelta en tiempo | 5% descuento sobre la factura de aquel mes |
2 incidencias no resueltas en tiempo | 10% descuento sobre la factura de aquel mes |
3 incidencias no resueltas en tiempo | 15% descuento sobre la factura de aquel mes |
A partir de 10 incidencias no resueltas en tiempo, acumuladas en la misma temporada | Teatro de la Maestranza se reserva el derecho de rescindir el contrato |
CLÁUSULA 9. BOLSA DE HORAS DESARROLLOS
Bolsa de horas ordinarias
El nú mero de horas destinadas a las prestaciones de desarrollos de la herramienta a requerimiento del Teatro de la Maestranza se fijan en 10 horas mensuales durante toda
la duració n del contrato. En caso de no consumir la bolsa de horas mensuales, estas se acumulará n en la bolsa de horas del mes siguiente.
Bolsa de horas extraordinarias
En caso de agotar esta previsió n, se utilizará la bolsa de horas extraordinarias, que se pagará n al precio/hora que el licitador haya ofrecido en la propuesta econó mica. La bolsa de horas extraordinarias se estima en un má ximo 100 horas anuales.
Los desarrollos que se ejecuten durante la vigencia del contrato se considerará n como confidenciales, y no pueden ser objeto, ni total ni parcialmente, de publicació n, copia, utilizació n, cesió n o venta en terceros. Por lo tanto, el adjudicatario tendrá que guardar secreto respecto de los desarrollos relacionados con el objeto del contrato. El deber de confidencialidad subsiste durante los cinco (5) años siguientes a la extinció n del contrato.