[et_pb_section fb_built=\u00bb1″ admin_label=\u00bbSection\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb0px||0px||false|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_row column_structure=\u00bb1_4,3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb50px||||false|false\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb1_4″ disabled_on=\u00bbon|on|off\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb||||false|false\u00bb sticky_position=\u00bbtop\u00bb sticky_offset_top=\u00bb100px\u00bb sticky_limit_bottom=\u00bbsection\u00bb motion_trigger_start=\u00bbtop\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbindice\u00bb _builder_version=\u00bb4.27.5″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||0px||false|false\u00bb custom_padding=\u00bb||14px||false|false\u00bb link_option_url=\u00bb#1″ global_colors_info=\u00bb{}\u00bb]<\/p>\n
Secciones<\/strong><\/p>\n [\/et_pb_text][\/et_pb_column][et_pb_column type=\u00bb3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbseccion\u00bb module_id=\u00bb1″ module_class=\u00bbittopicscontent\u00bb _builder_version=\u00bb4.27.5″ _module_preset=\u00bbdefault\u00bb z_index=\u00bb0″ custom_margin=\u00bb0px||0px||true|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb custom_css_main_element=\u00bbfont-family:%22Pandora-Light%22;\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb]Existe una fantas\u00eda recurrente en el mundo de los servicios gestionados: que si algo se rompe, nos enteraremos antes que los clientes. Es decir, que podremos detectar las incidencias antes que ellos, ya que por algo somos el MSP<\/strong>. Pero la realidad, la que se manifiesta a las tres de la tarde de un viernes cualquiera cuando est\u00e1s planeando el fin de semana, opina otra cosa. El tel\u00e9fono suena y el cliente, mezclando indignaci\u00f3n, furia y s\u00faplica, nos comunica amablemente que \u00abel sistema no va\u00bb. Llegar antes que el incendio no es un capricho t\u00e9cnico, ni una medalla que colgarse en el panel del NOC<\/A>. Es una cuesti\u00f3n de pura supervivencia econ\u00f3mica y operativa para un MSP<\/strong>. Para el responsable de operaciones, la distinci\u00f3n entre incidencia, degradaci\u00f3n y s\u00edntoma no es un debate sem\u00e1ntico, sino la base de su eficiencia operativa<\/a>.<\/p>\n Detectar antes del impacto significa capturar el s\u00edntoma o la degradaci\u00f3n para evitar la incidencia<\/strong>. He aqu\u00ed una paradoja que vemos habitualmente en Pandora cuando hablamos con clientes potenciales. El MSP gasta miles de euros en herramientas de monitoreo TI<\/a>, pero su d\u00eda a d\u00eda sigue siendo una conga interminable de urgencias<\/strong> que pasan por delante haciendo burla y echando abajo los sistemas. La vida es impredecible, pero no del todo. Lo mismo ocurre con la gesti\u00f3n IT, donde muchos problemas que desangran el margen de un MSP son predecibles<\/strong>… Si sabemos donde mirar, claro, como por ejemplo en:<\/p>\n Para escapar de las garras de la reactividad necesitamos un dise\u00f1o basado en procesos s\u00f3lidos y repetibles, no en el genio del t\u00e9cnico<\/Strong> de turno o las horas de insomnio que pueda soportar. El virus que m\u00e1s convierte la monitorizaci\u00f3n en in\u00fatil m\u00e1s r\u00e1pidamente es el ruido. Por ejemplo, en el primer punto de una supresi\u00f3n inteligente, si hay una ventana de mantenimiento programada, el sistema debe callarse mientras dure, porque ya sabemos que estar\u00e1 offline o con picos durante el mantenimiento. O si una aplicaci\u00f3n depende de una base de datos ca\u00edda que estamos levantando de nuevo, la alerta de la aplicaci\u00f3n tambi\u00e9n debe suprimirse para evitar duplicidades innecesarias. Gestionar un cliente permite un trabajo de guerrilla e improvisaci\u00f3n, pero gestionar muchos, como en el caso de un MSP, exige segmentaci\u00f3n l\u00f3gica y operativa<\/strong>. Los d\u00edas de trabajo est\u00e1n hechos de reuniones hacia ninguna parte, donde planteamos los aspectos que hemos comentado, pero tras esas reuniones, la canci\u00f3n es cierta y \u00abla vida sigue igual\u00bb. Muchos proveedores de servicios gestionados sufren fragmentaci\u00f3n<\/strong> y sus herramientas parecen la flota rebelde de Star Wars, compuesta de naves muy distintas que coordinan poco: una aplicaci\u00f3n para uptime<\/a>, otra para gesti\u00f3n de logs, otra m\u00e1s para monitorizaci\u00f3n de sistemas<\/A> o mantenimiento preventivo<\/a>… Esa es la clave, pero la olvidamos porque, como dec\u00eda un colega el otro d\u00eda, el usuario tiene una capacidad infinita de acostumbrarse a lo bueno y darlo por supuesto enseguida, por muy alucinante que le parezca al principio. Habla con el equipo de ventas, pide presupuesto, o resuelve tus dudas sobre nuestras licencias<\/p>\n \u00bb content_phone=\u00bb<\/p>\n Habla con el equipo de ventas, resuelve tus dudas sobre nuestras licencias o pide presupuesto<\/p>\n \u00bb content_last_edited=\u00bbon|tablet\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb header_2_font_size=\u00bb2em\u00bb text_orientation=\u00bbcenter\u00bb module_alignment=\u00bbleft\u00bb custom_margin=\u00bb0px||20px||false|false\u00bb custom_padding=\u00bb0px||0px||true|false\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n Habla con el equipo de ventas, pide presupuesto, [\/et_pb_text][et_pb_code _builder_version=\u00bb4.27.4″ _module_preset=\u00bbdefault\u00bb width=\u00bb200px\u00bb module_alignment=\u00bbcenter\u00bb custom_margin=\u00bb40px||0px||false|false\u00bb custom_padding=\u00bb0px||0px||true|false\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n\n
\nEn ese momento, el MSP<\/a> ha fallado.
\nNo en la resoluci\u00f3n, que a lo mejor es incluso brillante luego, sino en algo m\u00e1s importante, la detecci\u00f3n. Porque en este negocio, el cliente nunca deber\u00eda ser nuestro sistema de monitorizaci\u00f3n y alerta<\/strong>.
\nSi permitimos eso, no somos un proveedor de servicios gestionados, sino bomberos novatos que esperan el humo en el horizonte para salir corriendo.
\nEsa es la receta para el burnout, la reducci\u00f3n de nuestros m\u00e1rgenes y la p\u00e9rdida de confianza de quien paga las facturas<\/strong>.<\/p>\nEl beneficio y la cordura dependen de la detecci\u00f3n temprana<\/h2>\n
\nPorque cuando se anticipa as\u00ed, la carga de soporte se vuelve predecible<\/strong>.
\nNo es lo mismo que un t\u00e9cnico senior gaste quince minutos ajustando un par\u00e1metro sin prisas, que tres t\u00e9cnicos de nivel 2 maldiciendo una tarde entera mientras un cliente les grita que su producci\u00f3n est\u00e1 parada.
\nEl coste en horas de la segunda opci\u00f3n es exponencialmente mayor<\/strong>.
\nEn Jerry Maguire Cuba Gooding Jr. le dice a Tom Cruise el cl\u00e1sico: Show me the money! Pues bien, the money en un MSP est\u00e1 en la detecci\u00f3n.
\nY adem\u00e1s, est\u00e1 la cuesti\u00f3n del SLA<\/a>.
\nCumplir un acuerdo de nivel de servicio no deber\u00eda ser un malabarismo constante para que nada se caiga. Si solo reaccionamos, siempre estamos a un paso del incumplimiento<\/strong>. Pero si detectamos antes del impacto, desde el punto de vista del cliente nada ha dejado nunca de funcionar perfectamente.
\nEso no solo implica cumplimiento contractual, sino paz mental y deleite<\/strong>, que es lo que realmente vende un MSP.
\nPor eso reducir el soporte reactivo<\/a> es proteger la viabilidad del negocio, el show me the money!
\nEn este negocio y en todos, lo que separa a los profesionales de los aficionados es que los \u00faltimos se centran en las t\u00e1cticas, mientras los primeros lo hacen en la estrategia. Eso suena a Powerpoint de escuela de negocios y lo s\u00e9, pero en un MSP, reaccionar es una habilidad t\u00e1ctica y necesaria, pero detectar antes de que ocurra es LA ESTRATEGIA operativa<\/strong>.<\/p>\nQu\u00e9 significa detectar antes del impacto en un MSP<\/h2>\n
\n
\nEn muchas operaciones, la cadena se rompe porque confundimos se\u00f1al con alerta.
\nUna se\u00f1al es un dato y una alerta deber\u00eda ser una llamada a la acci\u00f3n<\/strong>. Si inundamos el panel de se\u00f1ales sin contexto, el t\u00e9cnico acaba sufriendo la infame alert fatigue, ignorando el s\u00edntoma que precede al colapso<\/strong>.
\nDesde el punto de vista del cliente, el \u00abimpacto\u00bb es binario: o puede trabajar o no puede. Pero desde nuestra trinchera, el impacto es una pendiente peligrosa y nuestro trabajo es colocar la valla de seguridad lo m\u00e1s arriba posible de esa ladera.
\nEn el puente de mando de un MSP, no podemos esperar a que las luces rojas parpadeen y el casco de la nave empiece a crujir. Necesitamos sensores que nos digan que los escudos est\u00e1n bajando<\/strong> antes de que el primer torpedo fot\u00f3nico de realidad impacte contra la infraestructura IT.
\nEn la serie Star Trek: Voyager, una de las cosas que permite una ventaja crucial a la nave es construir la secci\u00f3n de Astrometr\u00eda, que les permite capacidades avanzadas de an\u00e1lisis y detecci\u00f3n. Esa es tambi\u00e9n nuestra misi\u00f3n<\/strong>, pero no vale cualquier monitorizaci\u00f3n, igual que a la Voyager no le serv\u00edan los sensores de siempre en territorio hostil.<\/p>\nPor qu\u00e9 muchos MSP siguen siendo reactivos aunque tengan monitorizaci\u00f3n<\/h2>\n
\n\u00bfPor qu\u00e9?
\nPrincipalmente, por la tiran\u00eda de los umbrales est\u00e1ticos<\/strong>.
\nConfigurar una alerta para que salte cuando la CPU llega al 95% es, en la mayor\u00eda de los casos, una p\u00e9rdida de tiempo, porque no suele tener contexto<\/strong>.
\n\u00bfEs un pico normal de un proceso de backup? \u00bfEs un bucle infinito en una aplicaci\u00f3n? Sin respuesta a esas preguntas, la alerta es solo ruido <\/strong>que los t\u00e9cnicos aprenden a ignorar para conservar el \u00fanico hilo de sensatez que les quede.
\nOtro factor de esa aparente paradoja en la que te gastas mucho dinero en gafas para seguir estando ciego es la priorizaci\u00f3n por urgencia percibida<\/strong>.
\nSi no tenemos datos objetivos que nos digan qu\u00e9 es realmente cr\u00edtico, acabamos atendiendo primero al cliente que m\u00e1s grita, no al que tiene el problema m\u00e1s grave.
\nYa s\u00e9 que la vida no es justa y quien m\u00e1s se queja es quien m\u00e1s recibe, pero esa es una gesti\u00f3n del p\u00e1nico, no de infraestructura<\/strong>.
\nY luego est\u00e1 la falta de responsabilidades.
\nEn muchos MSP, las alertas llegan a una bandeja com\u00fan donde \u00abtodo es de todos y nada es de nadie\u00bb como en una especie de utop\u00eda hippie. Pero si no hay un procedimiento claro de qui\u00e9n es responsable, cu\u00e1ndo act\u00faa y con qu\u00e9 evidencia, la se\u00f1al de detecci\u00f3n temprana se pierde entre las grietas, hasta reaparecer luego como un ticket reactivo abierto por un cliente cabreado.
\nVale, la teor\u00eda que hemos visto est\u00e1 muy bien, pero \u00bfc\u00f3mo implementamos de forma pr\u00e1ctica la detecci\u00f3n temprana en un MSP?
\nPara ello, podemos empezar por…<\/p>\nQu\u00e9 incidencias se pueden anticipar de forma sistem\u00e1tica<\/h2>\n
\n
El dise\u00f1o operativo de la detecci\u00f3n temprana en un MSP<\/h2>\n
\nEste dise\u00f1o empieza por definir las llamadas se\u00f1ales m\u00ednimas por capa<\/Strong>, como errores de interfaz en red, colas de ejecuci\u00f3n en sistemas, I\/O de disco y\/o tiempos de transacci\u00f3n en aplicaciones.
\nEsa es la base, pero el verdadero salto de calidad viene con los umbrales din\u00e1micos y la generaci\u00f3n de baselines<\/Strong>.
\nComo no existen dos clientes iguales, establecer esas l\u00edneas base en cada <\/strong>uno nos ense\u00f1a lo normal para cada cliente y horario<\/Strong>.
\nPor ejemplo, un 80 % de CPU un lunes a las 9:00 es normal porque todo el mundo se est\u00e1 conectando al servidor entre lega\u00f1as y resaca. Pero ese mismo 80 % un domingo a las 3:00 de la madrugada es uno de esos s\u00edntomas de los que hablaba antes.
\nAl establecer estos comportamientos base, la monitorizaci\u00f3n deja de ser un vigilante ciego para convertirse en un profeta que detecta desviaciones sutiles, diferentes y personalizadas para cada cliente<\/Strong>, antes del fallo cr\u00edtico.
\nSumemos a esto la correlaci\u00f3n b\u00e1sica operativa<\/Strong>.
\nPor ejemplo, no queremos diez alertas de servicios ca\u00eddos, sino una sola inteligente que identifique el switch que ha decidido que hoy es d\u00eda de huelga.
\nEsta consolidaci\u00f3n reduce el ruido y la fatiga de alertas<\/Strong>, permitiendo que el equipo se centre en la ra\u00edz del problema.
\nAdem\u00e1s, es fundamental separar las alertas informativas (que nos sirven para registro y an\u00e1lisis) de las accionables (las que exigen intervenci\u00f3n). De lo contrario, seguiremos sufriendo ceguera a pesar de las gafas que tenemos, porque cuando todo parece importante, nada es importante.<\/p>\nC\u00f3mo reducir ruido sin perder cobertura operativa<\/h2>\n
\nPara evitarlo, debemos:<\/p>\n\n
\nEn el segundo punto de la agrupaci\u00f3n, si no la tenemos y todo lo que funciona a la vez falla, habr\u00e1 una serie de alertas redundantes que contribuir\u00e1n a ese ruido, cuando una sola bastar\u00eda, siempre que tambi\u00e9n cumpla el siguiente aspecto de claridad<\/strong>.
\nPara dicha claridad, la nomenclatura y el etiquetado <\/strong>son vitales.
\nUna alerta \u00abServer1 Down\u00bb no sirve en un entorno multicliente como el de un MSP. Necesitamos contexto como por ejemplo: \u00abCliente A \/ ERP \/ Cr\u00edtico \/ Responsable L2\u00bb.
\nEsto permite saber enseguida qu\u00e9 ocurre sin estar descifrando jerogl\u00edficos que en su d\u00eda nos parec\u00edan inconfundibles, pero que ya no recordamos qu\u00e9 significan. Adem\u00e1s, el gestor de eventos<\/a> deber\u00eda dirigir la alerta de forma quir\u00fargica al responsable adecuado (apoy\u00e1ndose en capacidades como el seguimiento distribuido<\/a> para entender el flujo del problema). En el ejemplo anterior, el caso va al t\u00e9cnico de nivel 2 asignado al Cliente A.
\nCon un siguiente paso de automatizaci\u00f3n de operaciones, una IA integrada podr\u00eda f\u00e1cilmente gestionar la alerta y dirigirla autom\u00e1ticamente a dicho responsable, evitando ruido adicional para quienes no tienen que ocuparse de ella.
\nCada alerta accionable debe incluir adem\u00e1s un runbook<\/Strong> m\u00ednimo: instrucciones concretas que reduzcan tiempos de diagn\u00f3stico y permitan que el Nivel 1 resuelva problemas que antes requer\u00edan escalado.
\nEsto impacta directamente en Tiempo Medio de Resoluci\u00f3n<\/strong> (MTTR<\/a>) y libera a los ingenieros senior para tareas de mayor valor que estar apretando el bot\u00f3n de reset.<\/p>\nOperaci\u00f3n multicliente: C\u00f3mo priorizar y actuar sin mezclar contextos<\/h2>\n
\nY adem\u00e1s, aunque no suene bien desde la perspectiva de dichos clientes, debemos saber priorizar, tanto en lo urgente de verdad, como en lo econ\u00f3mico para nosotros <\/strong>como proveedores de servicios gestionados.
\nAs\u00ed, y hasta que desaparezca el dinero y vivamos en Star Trek, no podemos permitir que el ruido de un cliente peque\u00f1o eclipse una degradaci\u00f3n cr\u00edtica en uno de alta prioridad.
\nSi queremos escalar, el MSP necesita est\u00e1ndares replicables<\/strong>.
\nPara ello, precisamos definir pol\u00edticas globales y plantillas que aseguren una cobertura proactiva homog\u00e9nea desde el inicio<\/strong>.
\nSi todos los clientes siguen el mismo patr\u00f3n general de monitorizaci\u00f3n, podemos aplicar, por ejemplo, scripts de autocuraci\u00f3n que sirvan para todos, as\u00ed como procesos generales documentados que cualquiera (incluso con poca experiencia porque acaba de ser contratado), pueda consultar y aplicar.
\nY luego, por supuesto, ya modificaremos o a\u00f1adiremos aqu\u00ed y all\u00e1 en cada cliente partiendo de esa estructura principal com\u00fan, para acomodar las diferencias naturales que habr\u00e1 entre ellos.
\nAdem\u00e1s, los l\u00edmites entre niveles de soporte deben definirse por complejidad t\u00e9cnica y evidencia, no por el p\u00e1nico<\/strong>.
\nEl resultado de operar con esa eficiencia \u00abBorg\u00bb se ejemplifica en cosas como que un sistema de detecci\u00f3n temprana eficiente entrega al L2 un ticket ya masticado, con los logs adjuntados e incluso un diagn\u00f3stico preliminar hecho. Eso ahorrar\u00e1 minutos (y euros) valiosos al no tener que investigar desde cero.<\/p>\nC\u00f3mo medir si realmente nos estamos anticipando<\/h2>\n
\nPara evitar eso y mantenernos honestos sobre si realmente nos hemos consagrado a esa eficiencia Borg en la detecci\u00f3n temprana de incidencias, necesitamos m\u00e9tricas honestas<\/Strong>.
\nDe lo contrario, nuestro negocio vive de sensaciones mentirosas de avance y brindis al sol porque confundimos reuniones y buenas intenciones con realidad.
\nAlgunas m\u00e9tricas que reflejan si hemos implementado de verdad detecci\u00f3n temprana son:<\/p>\n\n
C\u00f3mo ayuda Pandora FMS a los MSP en este escenario operativo<\/h2>\n
\nEsta dispersi\u00f3n, adem\u00e1s de forzar el aprendizaje (y mantenimiento) de un ej\u00e9rcito en el que cada elemento hace la guerra por su cuenta, obliga tambi\u00e9n a los t\u00e9cnicos a saltar entre consolas, perdiendo contexto y concentraci\u00f3n<\/Strong>.
\nY luego est\u00e1 la integraci\u00f3n de esa Torre de Babel, otro dolor de muelas innecesario.
\nPandora FMS rompe este esquema al unificar todas las se\u00f1ales (infraestructura, red, cloud, SaaS y\/o virtualizaci\u00f3n) en un \u00fanico panel de control coherente (single pane of glass<\/a>)<\/strong> y la capacidad de distinguir bien entre clientes.
\nLas ventajas de un sistema as\u00ed para el MSP son claras:<\/p>\n\n
\nSi no queremos caer en esas relaciones disfuncionales donde el otro nos da por sentado e invisibiliza enseguida nuestro valor real (algo com\u00fan en un MSP) esto es clave.
\nAdem\u00e1s, Pandora FMS tiene capacidades de telemetr\u00eda avanzada<\/a>, consola de eventos y soporte para servidor syslog<\/A>, centralizando la informaci\u00f3n cr\u00edtica. Unido a la facilidad de despliegue y la capacidad de monitorizaci\u00f3n avanzada, permite una cobertura total.
\nPara los que buscan excelencia, la soluci\u00f3n de monitorizaci\u00f3n para MSP y SOC <\/A>que ofrece Pandora es el est\u00e1ndar de excelencia<\/Strong>.
\nDetectar antes del impacto es un cambio de mentalidad en un MSP. Es pasar de receptor de quejas a guardi\u00e1n activo de la continuidad del servicio.
\nPorque no debemos equivocarnos de negocio, la verdadera promesa de la tecnolog\u00eda es el silencio, una operaci\u00f3n suave y la paz mental. Eso vendemos realmente como MSP. Ese es el verdadero valor de un proveedor de servicios gestionados de \u00e9lite, que aspire a ser un partner<\/A> estrat\u00e9gico y no un simple solucionador de problemas.[\/et_pb_text][et_pb_button button_url=\u00bb@ET-DC@eyJkeW5hbWljIjp0cnVlLCJjb250ZW50IjoicG9zdF9saW5rX3VybF9wYWdlIiwic2V0dGluZ3MiOnsicG9zdF9pZCI6IjM2MjI3MCJ9fQ==@\u00bb button_text=\u00bb\u2190 Regresar a IT Topics\u00bb button_alignment=\u00bbleft\u00bb _builder_version=\u00bb4.22.0″ _dynamic_attributes=\u00bbbutton_url\u00bb _module_preset=\u00bbdefault\u00bb custom_button=\u00bbon\u00bb button_text_size=\u00bb1em\u00bb button_text_color=\u00bb#0C312F\u00bb button_bg_color=\u00bb#FFFFFF\u00bb button_bg_color_gradient_direction=\u00bb90deg\u00bb button_bg_color_gradient_stops=\u00bb#82B92E 0%|#3CB92E 100%\u00bb button_bg_color_gradient_start=\u00bb#82B92E\u00bb button_bg_color_gradient_end=\u00bb#3CB92E\u00bb button_border_width=\u00bb1px\u00bb button_border_color=\u00bb#eaeaea\u00bb button_border_radius=\u00bb100px\u00bb button_use_icon=\u00bboff\u00bb z_index=\u00bb0″ custom_margin=\u00bb60px||0px||false|false\u00bb custom_padding=\u00bb10px|50px|10px|50px|true|true\u00bb custom_padding_tablet=\u00bb\u00bb custom_padding_phone=\u00bb10px|20px|10px|20px|true|true\u00bb custom_padding_last_edited=\u00bbon|phone\u00bb custom_css_main_element=\u00bbright:0!important;||font-family:%22Pandora-Bold%22!important;\u00bb global_module=\u00bb367749″ locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb button_bg_color__hover_enabled=\u00bbon|desktop\u00bb button_bg_color_gradient_start__hover=\u00bb#eaeaea\u00bb button_bg_color_gradient_end__hover=\u00bb#f4f4f4″ button_bg_color__hover=\u00bb#eaeaea\u00bb button_bg_enable_color__hover=\u00bbon\u00bb button_bg_use_color_gradient__hover=\u00bbon\u00bb button_bg_color_gradient_stops__hover=\u00bb#eaeaea 0%|#f4f4f4 100%\u00bb][\/et_pb_button][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=\u00bb1″ custom_padding_last_edited=\u00bbon|desktop\u00bb admin_label=\u00bbFinal CTA\u00bb _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb background_color=\u00bb#161327″ use_background_color_gradient=\u00bbon\u00bb background_color_gradient_stops=\u00bbrgba(22,19,39,0.5) 17%|rgba(22,19,39,0.5) 100%\u00bb background_color_gradient_overlays_image=\u00bbon\u00bb background_image=\u00bbhttps:\/\/pandorafms.com\/wp-content\/uploads\/2023\/12\/banner-contacta-it-topics.webp\u00bb background_size=\u00bbcustom\u00bb background_image_width=\u00bb121%\u00bb background_image_height=\u00bb192%\u00bb background_position=\u00bbtop_left\u00bb z_index=\u00bb1″ max_width=\u00bb1080px\u00bb max_width_tablet=\u00bb98%\u00bb max_width_phone=\u00bb98%\u00bb max_width_last_edited=\u00bbon|tablet\u00bb module_alignment=\u00bbcenter\u00bb custom_margin=\u00bb80px||80px||true|false\u00bb custom_padding=\u00bb40px|20px|120px|20px|false|true\u00bb custom_padding_tablet=\u00bb40px|0px|120px|0px|false|true\u00bb custom_padding_phone=\u00bb40px|0px|120px|0px|false|true\u00bb scroll_scaling=\u00bb40|55|85|100|100%|120%|100%\u00bb motion_trigger_start=\u00bbtop\u00bb background_last_edited=\u00bbon|phone\u00bb background_size_tablet=\u00bbcover\u00bb background_size_phone=\u00bbcover\u00bb background_position_phone=\u00bbtop_center\u00bb border_radii=\u00bboff|20px|20px|20px|20px\u00bb border_color_all=\u00bb#ffffff\u00bb box_shadow_style=\u00bbpreset1″ box_shadow_vertical=\u00bb0px\u00bb box_shadow_blur=\u00bb80px\u00bb box_shadow_color=\u00bb#506da0″ global_module=\u00bb367449″ saved_tabs=\u00bball\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_row use_custom_gutter=\u00bbon\u00bb gutter_width=\u00bb2″ make_equal=\u00bbon\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb max_width=\u00bb750px\u00bb module_alignment=\u00bbcenter\u00bb custom_margin=\u00bb0px||0px||true|false\u00bb custom_padding=\u00bb0px|0px|0px|0px|true|true\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text content_tablet=\u00bb<\/p>\n
o resuelve tus dudas sobre nuestras licencias<\/p>\n