Políticas y protocolos
      Volver al inicio
      1. Base de Conocimiento
      2. Manuales y Artículos
      3. Políticas y protocolos

      Continuidad de Negocio

      El artículo evidencia que myHotel cuenta con planes de continuidad de negocios documentados, que siguen protocolos diseñados para garantizar la seguridad de la información y la continuidad del negocio para sus clientes.

      Extracto

      Este documento tiene por objetivo evidenciar que myHotel posee planes de continuidad de negocios establecidos, que siguen ciertos protocolos documentados, y que las políticas de trato de información alrededor de los protocolos están hechos de tal forma que garantizan la 1) seguridad de la información, y 2) la continuidad del negocio para los clientes.

       

      Esta documentación se dividirá en seis partes:

      1. Medidas de contingencia
      2. Riesgos y controles
      3. Tipos de escenarios cubiertos
      4. Planes de contingencia ante desastres
      5. Antecedentes de continuidad del negocio
      6. Proceso de soporte e incidencias

      1.- MEDIDAS DE CONTINGENCIA

       

      El primer antecedente a entender es que myHotel tiene su infraestructura tecnológica alojada en la nube, en un único proveedor cloud llamado “Amazon Web Services” (de aquí en adelante AWS). Es importante denotar esto porque dentro del servicio del proveedor AWS existe una serie de medidas que se dividen de manera diferente en las distintas capas de la infraestructura de las aplicaciones, pero que todas apuntan a tener respaldada la información y la configuración de cada una de las partes.

      Para poder explicar esto mejor, es importante entender las distintas capas de la aplicación para luego explicar las medidas de recuperación por cada una de ellas:

       

       

      • Base de Datos MySQL Aurora

      Esta primera capa, y probablemente la más importante de todas para efectos de esta documentación, es la que contiene almacenada toda la información con la que operan los productos myHotel. 

      1. Réplica: existe una réplica de la información de la BBDD de manera constante en el tiempo, instantánea, que asegura que la información no esté guardada en un solo lugar, sino que en dos. 
      2. Multi Zona A-Z: la base de datos está replicada en múltiples zonas de disponibilidad a nivel mundial, lo cual genera un respaldo de toda la información de la base de datos de manera global. Esto permite tener un grado de seguridad contra desastres mundiales muy potente, al resguardarnos que si una, o varias zonas en el mundo, se caen a nivel de AWS, aún tendremos todas las otras zonas para poder recuperar la información.
      3. Snapshots: hay un concepto que AWS le llama “snapshots” que consiste en una copia de la información de la base de datos hasta cierta fecha. myHotel tiene configurados snapshots por cada hora, en un rango de fechas de los “últimos 30 días”. Esto permite que en caso de perderse información (por cualquier motivo) dentro de 7 días, myHotel es capaz de recuperar lo que había hasta ese momento dado.

       

      Dado los puntos a, b y c, myHotel tiene la capacidad absoluta de recuperar la información de la base de datos ante casi cualquier evento al tener respaldado hasta 7 días absolutamente todo, distribuido de manera mundial, y hasta con una copia en tiempo real en una máquina diferente.

       

      • Capa de Caché

      Con la finalidad de entregar un mejor servicio y más eficiente, se implementó una capa de caché con REDIS utilizando el producto de AWS “Elasticache”. Esto nos permite almacenar información “estática” o de baja tasa de modificación (como las estructuras de las encuestas) o también consultas complejas de realizar (heavy queies). Finalmente se mantienen los resultados en memoría durante un tiempo definido (según caso) para evitar tener que consultar eso a la base de datos y de esa manera usar su capacidad para procesos que realmente lo requieran. Adicionalmente tiene una mejora en rendimiento considerable con respecto a consultarlas en la base de datos.

       

      • Back-end (orientado en microservicios)

      Esta segunda capa es donde está toda la lógica de negocios de los productos de myHotel. Para esta capa se utiliza un application load balancer, quien a través de rutas definidas envía el tráfico entrante al microservicio que corresponda. Cada microservicio se encuesta alojado en un servicio llamado Elastic Beanstalk que finalmente administra una “receta” de máquinas que se montan sobre instancias EC2, controla sus actualizaciones, parches de seguridad, distribución de carga y escalado horizontal (en caso de mucho tráfico, cada microservicio agrega máquinas iguales utilizando la receta para poder entregar un servicio de calidad en momentos de mucho estrés).

      En términos de la información almacenada, no existe información guardada de los clientes en esta capa, sólo a nivel de base de datos. Solamente transitan a través de esta capa la información. Lo que sí se almacena son los códigos de las aplicaciones de myHotel, los cuales están respaldados de las siguientes maneras:

      • Repositorios: son los lugares en donde están guardados los códigos. Estos son de carácter privado, y están alojados en un repositorio Git privado. Este proveedor te permite ir a todas las versiones de los códigos que hayan existido desde que estás operando con ellos, y myHotel empezó a operar con ellos desde el 2016.
      • versiones: cada microservicio lleva un registro y respaldo de cada deploy que se realiza en el y, en caso de ser necesario, permite hacer rollback de estos en sólo unos segundos. Además, estas versiones son las que utiliza la receta para escalar horizontalmente o reemplazar instancias que deban ser parchadas o reemplazadas sin afectar el servicio.

       

      • API Gateway

      Esta capa es clave para el monitoreo de tráfico y seguridad de las APIS, ya que controla el acceso a estos con metodologías de seguridad propias, además de controlar tasas de consumo por segundo/minuto/hora, protegiendo así las capas más profundas de la infraestructura

      Esta herramienta de AWS es quien define mediante qué rutas se comunicarán la capa de front-end y el back-end. Nos permite mapear qué endpoints queremos exponer y cuales queremos dejar para uso interno, además podemos llevar un registro de los deploys realizados y volver a una versión específica en sólo unos segundos.

       

      • Front-end en S3 con Cloudfront – Angular

      La capa de front-end de myHotel está alojada en unos buckets que se llaman “S3” en AWS, los cuales están replicados de manera instantánea en todas las regiones del mundo en donde AWS tiene presencia (así lo tiene configurado myHotel). Cada vez que se sube una versión diferente del aplicativo alojado en el bucket queda un registro de esa versión en AWS la cual es recuperable. Se guardan todas las versiones históricas desde que se opera con AWS, que en el caso de myHotel es desde el 2015.

      Además de esto, al igual que el código del back-end, el código del front-end está alojado en un repositorio Git privado y por ende hereda todos los mismos beneficios de recuperación y versionamiento mencionados en el punto 2. Repositorios de esta sección del documento.



      2.- RIESGOS Y CONTROLES

       

      Esta sección busca enumerar todos los puntos de interacción entre software que puedan generar alguna interrupción a la continuidad del negocio, y listar las medidas respectivas en cada uno de ellos para entender las alternativas de contingencia por cada software. Además, se mencionan los riesgos asociados a la interacción entre el software y empleados de myHotel que pueden tener acceso a información de clientes, y de qué manera los procesos garantizan una correcta seguridad de la información.

       

      Riesgos software de proveedores

      • Amazon Web Services (AWS)

      Este proveedor es quien se encarga de alojar toda la infraestructura del software propio de myHotel en la nube, convirtiéndo así en pieza clave a analizar sus riesgos para la continuidad del negocio. 

      AWS ha demostrado año tras año tener un promedio de disponibilidad de sus servicios sobre el 99.9%, y muchos de los productos contratados por myHotel en AWS tienen 100%. Finalmente, esta disponibilidad se traspasa directamente a myHotel, prometiendo así una disponibilidad de servicios sobre un 99.9%. 

       

      • Mailjet by Sinch

      Esta empresa brinda los servicios de envío de correos que están dentro de muchos de los productos de myHotel, por ejemplo, los envíos de correos a huéspedes, las alertas de encuestas, los avisos de Fidelity Desk, entre muchos. Esta empresa ha tenido una disponibilidad promedio de sus servicios en los últimos 3 años de un 100%, es decir, nunca ha presentado bajas en las entregas de correos.

       

      • Hubspot

      Este software es el encargado de recibir todas las solicitudes de soporte de cara a los clientes, tanto los tickets por correo, como los tickets generados desde la plataforma misma. Este proveedor es de clase mundial y basa su infraestructura en nuestro proveedor común AWS, por lo que los riesgos de baja de la disponibilidad de sus servicios a lo menos los mismos de AWS, entendiendo que ellos también tienen medidas de contingencia en caso de que AWS se caiga.

      Como software alternativo myHotel posee licencia en JIRA Service Desk, un software similar en términos de los servicios que entrega de ticketing para manejar los casos de soporte. En el caso de un eventual desastre, se activa este software en vez de Hubspot.

       

      • Lexalytics

      Este software es el encargado de hacer los procesamientos de análisis semántico de los comentarios creados en myHotel, como también de las reseñas recopiladas en los diferentes canales. Es importante notar que, si bien Lexalytics es parte de los servicios que entrega myHotel indirectamente, no existen mayores riesgos a que este proveedor se caiga temporalmente ya que la inmediatez de los resultados igual tiene un rango de alrededor de 10 minutos en escenarios normales, por lo que da tiempo a reaccionar cuando esto llegue a ocurrir.



      Controles de acceso a la información de clientes

      En myHotel existen empleados con diferentes accesos a la información de clientes según necesite por cada área y/o cargo. En definitiva, podemos dividir el acceso a la información de los clientes en dos grandes categorías:

      1. Directo a BBDD: en esta categoría sólo tienen acceso los empleados myHotel del área TI (desarrollo) que tengan acceso a “PROD”, que sólo son los jefes de área quienes suben actualizaciones a este ambiente productivo. Esta llave que decodifica la información está guardada en un lugar seguro en la cuenta raíz de AWS a la cual sólo el CTO de la empresa tiene acceso, garantizando así que no se pueda filtrar la información directa desde la BBDD de ningún cliente por parte de empleados myHotel del área TI.

      Para el caso en que algún empleado del área TI sea desvinculado, generalmente no hay mayores cambios que hacer ya que sólo tienen acceso a la base de datos de desarrollo, y todo el resto de los accesos son controlados por el Administrador de Google Suite, por lo que en pocos clicks se quita acceso a todo lo que él o ella tiene, garantizando así también que en el proceso de salida de la empresa no haya fugas de información.

      1. Reportería “Customizada”: a esta categoría tienen acceso diferentes personas de diferentes áreas de la empresa, que se utiliza para poder obtener reportes de usabilidad y de performance de los clientes para un correcto seguimiento del funcionamiento de los productos contratados y así entregar un servicio a la medida para cada uno y de manera personalizada. myHotel aprovecha las economías de ámbito de Google Suite, y utiliza Google Sheets para conectarse por script a las bases de datos, y luego generar reportes a le medida para diferentes áreas, que ellos pueden autogestionar el contenido según parámetros tales como fecha inicio, fecha fin, tipos de clientes, etc.… 

      La información contenida en estos reportes nunca tiene información sensible como nombres de pasajeros, teléfonos, correos, ni nada que sea personal de cada uno de los huéspedes. Los reportes contienen información agrupada de varios clientes, y/o muestran números generales con respecto al rendimiento de la herramienta.

      Finalmente, como Google Sheets tiene por defecto un criterio de permisos que podemos autogestionar desde el Admin, cada vez que hay empleados que sean desvinculados, inmediatamente perderán el acceso a estos reportes desde la desactivación de esa cuenta desde Google Suite.

       

      3.- TIPOS DE ESCENARIOS CUBIERTOS

       

      • Escenarios de desastres tipo COVID-19 (pandemias)

      Por el lado de los empleados, la empresa está capacitada para operar 100% remoto, por lo que en caso de que una pandemia aparezca, o bien un rebrote de COVID-19 en el futuro, myHotel está operando en su normalidad de manera remota, entregando a todos y cada uno de sus trabajadores las herramientas necesarias para poder desempeñar sus tareas.

      Por el lado de la continuidad de los servicios de software, estamos protegidos por todos los frentes mencionados en la sección Riesgos y Controles, teniendo alternativas para cada uno de los proveedores y así tener plan B de las diferentes funcionalidades principales.

       

      • Escenarios de desastre de proveedores clave

      Tal y como se menciona en la sección Riesgos y Controles, estamos preparados para cambiar de proveedores clave apenas exista algún desastre o baja del servicio de alguno de ellos. Cabe mencionar que el proveedor más importante es Amazon Web Services, y en el caso de su caída global sería un hecho que afecte a un gran porcentaje de la población mundial ya que se estima que ellos alojan sobre el 70% de las infraestructuras tecnológicas de las empresas, por lo que sería un caso muy perjudicial para muchos. Es ese mismo riesgo que es compartido por muchos, y a la vez fuerza a AWS a ser el proveedor N°1 contemplando todos los posibles escenarios catastróficos, replicando sus infraestructuras en múltiples zonas, teniendo sistemas de Snapshots constantes, y muchísimas otras medidas de los más altos estándares mundiales.

       

      • Escenarios de reducción de personal

      Una posibilidad de que se afecten los estándares de los servicios entregados por myHotel es que exista una reducción de personal. Cabe destacar que myHotel, al pasar por la pandemia de COVID-19, se forzó a un caso similar en que se redujo mas del 50% de sus empleados, y durante todo el 2020 la empresa ha sabido reorganizarse para poder atender a todos sus clientes de igual manera. En otras palabras, la pandemia obligó a myHotel a reinventar muchos procesos y estructuras internas, y se optimizó el uso de recursos, estando en capacidades de atender a inclusive más clientes que antes con menos del 50% de personas, lo que habla de una organización muy robusta ante escenarios adversos. 

      Dado que los responsables de declarar estados de desastre y ejecutar el plan son ambos el CEO y CTO de la empresa, en estricto rigor es sólo necesario que ellos dos estén presentes en la empresa en un escenario de desastre dado que son los encargados de responder y liderar. La reducción de personal en otras áreas como Customer Success, u Onboarding, o el Área TI, no son críticas para poder llevar a cabo todos los planes de contingencia.

       

      • Escenarios de ciberataques 

      Existen innumerables posibilidades de cómo se puede hacer un ciberataque a una empresa de Software Web como myHotel. En general la podemos desglosar en 2 potenciales consecuencias de un ciberataque:

      1. Filtración de información de clientes: como lo mencionamos en otras secciones, la Base de Datos está muy bien protegida y su información de encuesta encriptada para proteger la información. Además, toda la interacción que existe con los usuarios de la plataforma es a través de protocolos de seguridad (conexiones vía SSL, control de acceso a redes, uso de tokens de usuarios, etc), y la información va encriptada en tokens de seguridad que nos entrega Spring Security desde la capa del back-end, entregando un nivel más alto de seguridad. La posibilidad de que roben información de un usuario válido, y a través de él descarguen reportes de un cliente es responsabilidad de cada uno de nuestros clientes el resguardar sus credenciales, y cambiar contraseñas en caso de que identifiquen un robo. Todo eso se puede autogestionar desde la plataforma, transformando a myHotel en un “procesador” de información como lo es bajo la regulación internacional GDPR, a la cual myHotel es compatible.

       

      1. Parálisis del servicio ofrecido: los ciberataques también buscan derrotar al sistema objetivo (que sería la web myHotel) a través de múltiples formas, dentro de ellas, la fuerza bruta es la más utilizada. Tenemos plenamente identificado todos los puntos críticos donde podrían aprovecharse de algún endpoint u otro mecanismo para intentar sobrecargar el sistema y que así se “caiga”, y cada uno de esos puntos tiene múltiples medidas de seguridad para poder consumirlos, siendo restricciones por IP, dominio y VPC interno de AWS las más comunes, garantizando así que sólo entidades “conocidas” serán quienes interactúen en el intercambio de información. 

      myHotel ha sufrido intentos de ciberataques, muchos de ellos desde el continente Asiático (China y Japón), y no han podido quebrantar la seguridad. Y, además, la infraestructura de AWS ha demostrado ser sólida en sus configuraciones de Security Groups que nos garantizan que están identificados sólo un grupo específico de máquinas que pueden hablar entre ellos, y nadie más, protegiéndonos así contra los ataques de fuerza bruta que son muy comunes. 



      • Escenarios de pérdida de información almacenadas

      Como se menciona en el primer punto de este documento, myHotel posee una serie de medidas de contingencia a nivel de las distintas capas para poder recuperar la información. En general se puede recuperar hasta al menos 7 días hacia atrás en cualquier tiempo dado, por lo que si se identifica a tiempo se puede recuperar sin ningún problema.

       

      4.- PLANES DE CONTINGENCIA ANTE DESASTRES

       

      El procedimiento ante desastres contempla muchas aristas que abordaremos una a una en esta sección con el fin de dejar en evidencia un plan aterrizado de continuidad del negocio en caso de que existan desastres, de diferentes índoles. A continuación, se revisan todos estos puntos en orden según lo que se debe hacer en caso de un desastre que comprometa la continuidad del negocio:

       

      A. Activación de Plan de Contingencia

       

      “En el evento de un desastre que comprometa cualquiera de los puntos mencionados en el N°2 de esta sección, Sebastian Giacoman, CEO de myHotel, deberá declarar un estado de ‘desastre’ en la empresa, y luego, él mismo deberá tomar la decisión de activar las fases de recuperación según las prioridades mencionadas en el N°2 de esta sección según sea el caso de desastre.”

       

      B. Prioridades de recuperación de funcionalidades del negocio

       

      Antes de poder ejecutar el plan de contingencia es necesario tener definido un set de prioridades de las diferentes funcionalidades del negocio a recuperar en caso de que exista un desastre. Generalmente en estos casos no ocurre un desastre que englobe toda la infraestructura de un negocio, sino más bien algunos de ellos, y generalmente es sólo uno. Para recuperar la continuidad del negocio, se debe proceder según este orden de prioridades de recuperación:

      1. Email, archivos compartidos, y soluciones de teleconferencia compartidos entre todos los empleados de la empresa: myHotel tiene esto alojado en Google Suite, por lo cual se acoge a los Acuerdos de Niveles de Servicio de Google, los cuales prometen un uptime mayor a 99.9%, con la promesa de que toda la información está replicada en múltiples data centers a nivel global para poder recuperarlo.
      2. CRM de Clientes: esto está alojado en un único proveedor llamado Hubspot el cual tiene Acuerdos de Niveles de Servicio y Recuperación similares a Google, en el sentido de que la información está muy distribuida mundialmente y es posible recuperar la información en caso de desastres.
      3. Software Cloud de Infraestructura Tecnológica: en este caso AWS, explicado en la primera sección de este documento, en donde se detallan todas las capas a verificar su recuperación, y todas las medidas que hay en cada una de ellas para asegurar la recuperación de información. 
      4. Software de Facturación y Contabilidad: para estos efectos myHotel utiliza un proveedor llamado Xero, que al igual que los otros proveedores cloud, promete uptime sobre 99.9% y réplicas de la información a nivel global.
      5. Software de Manejo de Proyectos: en este caso myHotel utiliza al proveedor JIRA para manejar los proyectos tecnológicos.
      6. Reubicación del Dominio: myHotel opera bajo el dominio myhotel.cl que es donde están direccionadas todas las soluciones de clientes, y también el sitio público. Además de este dominio myHotel posee myhotel.com.es, fidelitycx.com y myhotel.io, cualquier de los 3 serviría para redireccionar todo el negocio en caso de que sea necesario.

       

      C. Procedimientos de Recuperación

       

      1. Ocurrencia del ‘desastre’: en esta primera fase se inicia con la ocurrencia del evento que genera el desastre y continúa hasta que se tome la decisión de activar los planes de recuperación. En esta fase los líderes de cada área de la empresa, al mando del CEO, deberán notificar a las personas en su mando acerca del evento, hacer un diagnóstico preliminar del daño causado, diagnosticar las repercusiones en las actividades del negocio, activar los planes de contingencia, y finalmente transitar hacia el funcionamiento de las operaciones principales de la empresa.
      2. Notificación del ‘desastre’: los líderes de cada equipo informan a los miembros del equipo que ha ocurrido un desastre. Dependiendo de la eventualidad del desastre, el personal será instruido en qué hacer.
      3. Diagnóstico preliminar del daño: los líderes de cada equipo deberán entregarle un informe al CEO de la empresa acerca de los daños causados que involucran sus respectivas áreas.
      4. Diagnóstico de repercusiones en las actividades del negocio: una vez que se ha hecho un diagnóstico preliminar del daño, el CEO de la empresa, junto con todos los líderes de las áreas, deberán hacer un análisis de la situación para tomar la decisión de qué acciones tomar para la recuperación de la continuidad del negocio.
      5. Activación de planes de contingencia: en esta fase los planes de continuidad de negocio son puestos en marcha. Para efectos de la infraestructura de la aplicación del negocio alojada en AWS, se procederá según el punto N°4 de esta sección.
      6. Transición hacia las funciones principales de la empresa: en esta fase se contemplan todas las actividades necesarias para volver a operar las funciones principales de la empresa que garanticen una continuidad del negocio para sus clientes.

       

      D. Planes de contingencia – Infraestructura Cloud del Negocio


       

      Según lo explicado en este documento, es necesario abarcar cada una de las capas afectadas de la infraestructura con el propósito de volver al funcionamiento del negocio de cara al cliente. Por ende, según cada capa se debe restaurar hasta el último punto de recuperación guardado:

      1. Base de Datos MySQL Aurora: dependiendo del desastre, se puede redireccionar hacia la réplica de la base de datos, o recuperar una de las instancias replicadas en multi zonas A-Z, o bien, levantar una nueva base de datos con la información guardada en el último snapshot que AWS guardó antes del desastre.
      2. Back-end en JAVA: dependiendo del desastre, se puede recuperar el código fuente desde el repositorio Git en su última versión guardada por ese proveedor, o recuperar un snapshot de las aplicaciones afectadas por el desastre en AWS, o bien recuperar una de las versiones previamente guardadas en AWS para cada aplicación.
      3. API Gateway: dependiendo del desastre, en este caso se debe recuperar el archivo .YAML que está guardado en AWS según cada versión que se subió. Alternativamente, estos .YAML están guardados en Gitlab para cada aplicación, por lo que también se podrían recuperar a nivel de código.
      4. Front-end en S3 – Angular : dependiendo del desastre, se puede recuperar la última versión guardada en S3 de AWS, o bien ir a recuperar una de las réplicas en multi zonas A-Z guardadas también en AWS, o bien recuperar la última versión del código del bucket en Gitlab y levantar un nuevo bucket S3 con esa versión.

       

      5.- ANTECEDENTES DE CONTINUIDAD DEL NEGOCIO

       

      En esta sección se busca documentar antecedentes de continuidad del negocio que permitan dar evidencia de que el servicio prestado en los últimos 7 años ha cumplido con los Acuerdos de Niveles de Servicios prometidos en los contratos. Esto se centra básicamente en la disponibilidad de la aplicación “Fidelity Suite” que engloba todos los productos myHotel ofrecidos. myHotel opera con una infraestructura de alta disponibilidad, siendo réplicas de los buckets S3 en todas las zonas, y réplica de la BBDD MySQL Aurora, los principales factores que afectan este funcionamiento.

       

      2018

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Uptime/Disponibilidad 99.99%

      *NOTA: hubo un evento este año que nos generó un downtime en el producto “Followup” durante alrededor de 12 horas, razón de la disponibilidad 99.99% de los buckets (fue un solo producto de cinco).

       

      2019

      BBDD MySQL Aurora: Uptime/Disponibilidad 99%

      Buckets S3: Uptime/Disponibilidad 99%

      *NOTA: hubo un evento este año que nos generó un downtime en el la base de datos, que fue programada e informada a todos sus clientes, de alrededor de 4 horas un día Domingo. Esto se debió a una migración de la base de datos hacia una mejorada versión.

       

      2020

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      NOTA: no han existido eventos durante el 2020 que nos haya generado una baja del servicio de ninguno de los productos.

       

      2021

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      NOTA: no han existido eventos durante el 2021 que nos haya generado una baja del servicio de ninguno de los productos.

       

      2022

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      NOTA: no han existido eventos durante el 2022 que nos haya generado una baja del servicio de ninguno de los productos.

       

      2023

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      NOTA: no han existido eventos durante el 2023 que nos haya generado una baja del servicio de ninguno de los productos.

       

      2024 - YTD

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      NOTA: no han existido eventos durante el 2024 que nos haya generado una baja del servicio de ninguno de los productos.

       

      6.- PROCESO DE SOPORTE E INCIDENCIAS

       

      El proceso de soporte está a cargo del área de Postventa (Customer Success), quienes son los encargados de recibir todos los tickets de soporte, y finalmente darle respuesta al cliente. En un escenario normal no existe interacción entre desarrolladores y clientes para que exista un filtro previo entre un área de interacción con clientes, y otra que no interactúa con el cliente final. De esta manera se hace una interacción que es: Cliente -> Postventa, Postventa -> Área TI, Área TI -> Postventa, y Postventa -> Cliente. 

       

      La comunicación entre Cliente y Postventa se hace a través del software Hubspot que nos entrega el formulario dentro de Fidelity Suite, como también cualquier ticket enviado a soporte@myhotel.cl. Luego, dependiendo del caso, la gran mayoría de los tickets no es necesaria la interacción con el Área TI al no haber temas técnicos, por lo que simplemente le responden directamente (generalmente son temas conceptuales y de indicadores y sus cálculos). Pero de necesitar intervención del área TI se crea un ticket de soporte interno para su resolución, y posteriormente comunicar la resolución en palabras comerciales. 

       

      Existen casos en que es necesaria la interacción entre desarrolladores de myHotel y de clientes, para los cuales se agendan reuniones programadas sobre un tema en específico, y se resuelve directamente entre las dos partes. Esto ocurre muy poco, generalmente en desarrollos a la medida de un gran cliente, o algo particular que escape del foco normal.

       

      Los acuerdos de nivel de servicios (o SLA) entregados por myHotel son de 24 horas hábiles para una primera respuesta, y de un promedio de 72 horas hábiles de resolución. En este último punto cabe destacar que es un tiempo “promedio” dado que la índole de los tickets no siempre son los mismos y muchas veces se confunden requerimientos nuevos con problemas existentes en el sistema. Cualquier problema existente en el sistema es tratado con suma urgencia dentro del Área TI y se debe resolver “lo antes posible”, es decir, existe gente dedicada a la Continuidad Operativa dentro del Área TI, quienes apenas reciben un “bug” que está en ambiente productivo, deben parar de hacer lo que están haciendo para poder resolverlo cuánto antes, generalmente en un par de horas.