Arrendamiento de solución de telefonía y centro de contactos multicanal

1.    Requisitos de participación y admisibilidad

1.1.  Condiciones generales de admisibilidad

• Los requisitos establecidos en el presente capítulo constituyen condiciones mínimas de admisibilidad técnica, operativa y documental para la valoración de las ofertas.
• La Administración verificará cada requisito bajo el criterio cumple / no cumple, con base en la evidencia documental, técnica o verificable aportada por el oferente.
• No se aceptarán declaraciones generales de cumplimiento que no estén respaldadas por evidencia verificable.
• Se tendrá por no acreditado el requisito cuando el oferente únicamente indique “cumple”, “se acepta” o expresiones similares, sin adjuntar respaldo documental, técnico o descriptivo suficiente.
• La falta de acreditación suficiente de un requisito de admisibilidad podrá generar la inadmisibilidad de la oferta o de la línea correspondiente, cuando impida verificar la capacidad mínima del oferente para prestar el servicio requerido.

1.2.  Respaldo tecnológico de la solución ofertada

• El oferente deberá acreditar que cuenta con autorización, respaldo técnico, relación comercial vigente o capacidad contractual suficiente respecto de las soluciones, plataformas, licencias, servicios, componentes o tecnologías que conforman su oferta.
• Para acreditar este requisito, el oferente deberá aportar certificación, carta, convenio, constancia o documento equivalente emitido por el fabricante, titular, proveedor, licenciante, distribuidor autorizado o entidad competente, según corresponda a la naturaleza de la solución ofertada.
• La Administración verificará que el documento aportado:
  1. Tenga fecha de emisión no mayor a doce meses respecto de la fecha de apertura de ofertas.
  2. Identifique al oferente o a la figura mediante la cual este cuenta con respaldo para ofertar.
  3. Identifique la solución, plataforma, servicio, componente, módulo o tecnología cubierta.
  4. Indique que el oferente cuenta con capacidad para comercializar, implementar, configurar, operar, soportar, mantener, actualizar o escalar la solución ofertada, según corresponda.
  5. Permita comprobar acceso a soporte especializado, licenciamiento, actualizaciones o escalamiento técnico.
  6. No condicione la prestación del servicio a autorizaciones futuras, acuerdos no formalizados o permisos no acreditados al momento de presentar la oferta.
• Criterio de admisibilidad: Cumple si la documentación permite verificar objetivamente el respaldo tecnológico requerido para la línea ofertada. No cumple si el respaldo no se acredita, está vencido, no cubre los componentes ofertados o queda condicionado a Gestiones futuras inciertas.
• Experiencia mínima del oferente para la Línea 1
  • Para la Línea 1, el oferente deberá acreditar al menos dos experiencias verificables en la implementación, operación, administración o soporte de servicios, plataformas o soluciones similares al objeto contractual.
  • Se entenderán como servicios o soluciones similares aquellas relacionadas con comunicaciones IP, telefonía IP, centros de contacto, contact center multicanal, ACD, IVR, grabación, monitoreo, reportería, soporte de servicios críticos u operaciones 24/7.
  • Las experiencias podrán corresponder a servicios o soluciones implementadas en Costa Rica o en el extranjero, siempre que sean verificables.
  • La Administración verificará que el oferente aporte al menos dos referencias, constancias o certificaciones que permitan comprobar:

1. Existencia real del servicio, plataforma o solución referida.
2. Año de implementación, puesta en producción o inicio de operación.
3. Alcance funcional implementado.
4. Participación del oferente en la implementación, operación, administración o soporte.
5. Similitud con la Línea 1.
6. Estado actual del servicio o solución, cuando corresponda.
7. Medio de contacto verificable de la entidad o cliente referido.

• Criterio de admisibilidad: Cumple si acredita al menos dos experiencias verificables y comparables con la Línea 1. No cumple si no presenta referencias suficientes, si estas no son verificables o si no guardan relación razonable con el servicio requerido.

1.3.  Experiencia mínima de la empresa

• El oferente deberá acreditar una trayectoria mínima de siete (7) años en la implementación, operación, administración, soporte o mantenimiento de servicios, plataformas o soluciones comparables con la Línea 1.
• Para efectos de este requisito, se considerarán soluciones comparables aquellas relacionadas con comunicaciones IP, telefonía IP, centros de contacto, contact center multicanal, ACD, IVR, grabación, monitoreo, reportería, soporte de servicios críticos u operaciones 24/7.
• La experiencia deberá acreditarse mediante referencias, constancias, certificaciones, contratos, órdenes de compra, actas de recepción, cartas de clientes o documentos equivalentes que permitan verificar objetivamente el periodo durante el cual el oferente ha brindado servicios o soluciones similares. Cada documento deberá indicar, como mínimo:
  1. Nombre de la entidad o cliente que recibió el servicio o solución.
  2. Nombre, cargo, teléfono y correo electrónico de una persona de contacto verificable.
  3. Año de implementación, puesta en producción o inicio de operación.
  4. Alcance funcional del servicio o solución.
  5. Componentes incluidos, cuando corresponda: ACD, IVR, grabación, centro de contactos, monitoreo, reportes, canales digitales, soporte, continuidad operativa u otros equivalentes.
  6. Similitud con la Línea 1.
  7. Estado actual del servicio o solución, cuando corresponda.
  8. Periodo durante el cual el oferente ha brindado servicios o soluciones similares.
• El Sistema de Emergencias 9-1-1 se reserva el derecho de contactar directamente a las entidades referenciadas para verificar la información aportada.
• Cumple si las referencias permiten verificar la experiencia declarada. No cumple si las referencias son incompletas, no verificables o no permiten establecer relación con el objeto contractual.

1.4.  Personal técnico mínimo

• El oferente deberá acreditar que cuenta con personal técnico mínimo suficiente para implementar, operar, soportar y mantener el servicio ofertado.
• Para la Línea 1, el oferente deberá aportar evidencia de contar con al menos dos personas con formación, certificación emitida por el fabricante de la solución ofrecida, experiencia o respaldo técnico verificable en áreas relacionadas con:
  1. Comunicaciones IP o telefonía IP.
  2. Centro de contactos, ACD o gestión de colas.
  3. IVR o respuesta automatizada.
  4. Grabación de llamadas o interacciones.
  5. Administración, monitoreo, seguridad, soporte o continuidad del servicio ofertado.
• Cumple si acredita que cuenta con al menos dos personas con formación, certificación, experiencia o respaldo técnico verificable en áreas relacionadas con la solución ofertada, conforme a lo establecido en el numeral 3.4.2. No cumple si no acredita el personal técnico mínimo requerido, si la documentación aportada es incompleta, no verificable o no permite establecer relación razonable con las áreas técnicas necesarias para implementar, operar, soportar o mantener el servicio ofertado.

1.5.  Capacidad mínima de soporte y coordinación efectiva en Costa Rica

• El oferente deberá acreditar capacidad mínima de soporte, coordinación técnica y atención de incidentes para la prestación del servicio, incluyendo mecanismos de atención local o coordinación efectiva en Costa Rica.
• Este requisito podrá cumplirse mediante personal propio, representación local, centro de soporte, socios técnicos, aliados especializados o mecanismos equivalentes.
• La Administración verificará que el oferente aporte documentación que permita comprobar:
  1. Existencia de un mecanismo de atención y coordinación en Costa Rica.
  2. Identificación del personal, representación, socio técnico, centro de soporte o aliado especializado, según corresponda.
  3. Canales de contacto para atención de requerimientos e incidentes.
  4. Capacidad de escalar incidentes críticos hacia niveles especializados de soporte.
  5. Relación entre el mecanismo de soporte propuesto y la operación del servicio ofertado.
• Cumple si el oferente demuestra capacidad real y verificable de coordinación y soporte efectivo para atender la operación crítica institucional. No cumple si no acredita ningún mecanismo de atención, soporte o coordinación local o equivalente.
• Este requisito no sustituye ni limita los niveles de servicio, tiempos de respuesta, tiempos de resolución, monitoreo, mantenimiento y demás obligaciones que se establezcan en los capítulos técnicos y contractuales del presente pliego.

1.6.  Verificación de requisitos de admisibilidad

• Todos los requisitos establecidos en este capítulo deberán acreditarse mediante evidencia documental, técnica o verificable.
• La Administración podrá solicitar aclaraciones, ampliaciones, verificaciones, demostraciones, referencias complementarias o documentación adicional, cuando resulte necesario para determinar el cumplimiento de los requisitos de admisibilidad, siempre que ello no implique modificar la oferta ni otorgar una ventaja indebida.
• La Administración podrá declarar inadmisible la oferta cuando el oferente no acredite, de forma suficiente y verificable, alguno de los requisitos mínimos establecidos en este capítulo, y dicha omisión impida comprobar su capacidad para implementar, operar, soportar, mantener o garantizar la continuidad del servicio requerido.

1.7.  Idioma y documentación requerida

• La solución deberá permitir operación integral, soporte técnico, interfaces, mensajes operativos y reportes en idioma español.
• La documentación mínima obligatoria para operación, administración, soporte, continuidad y procedimientos de respaldo/restauración deberá entregarse en idioma español.

1.    Disposiciones generales

1.1.  Objeto de la contratación

• La presente contratación tiene como objeto la prestación de un servicio integral gestionado de comunicaciones IP y centro de contactos multicanal para la atención de emergencias, destinado a la recepción, distribución, gestión, registro, trazabilidad y supervisión de llamadas de emergencia y otros canales digitales de interacción del Sistema de Emergencias 9-1-1, incluyendo llamadas de voz, mensajería de texto, SMS, videollamadas, chat u otros canales autorizados, conforme al alcance definido en el presente pliego.
• El servicio deberá incluir la implementación, configuración, puesta en operación, licenciamiento, soporte, mantenimiento, monitoreo, continuidad operativa, capacitación e integraciones requeridas, sin que ello implique la adquisición independiente de teléfonos IP, terminales, servidores, equipos de comunicaciones u otros activos físicos por parte de la institución, salvo aquellos componentes estrictamente necesarios para la prestación del servicio y bajo responsabilidad del contratista.
• El servicio deberá proveer las capacidades necesarias para la recepción, distribución, gestión, registro y trazabilidad de llamadas de emergencia y otras comunicaciones autorizadas, incluyendo funcionalidades como distribuidor automático de llamadas (ACD), respuesta interactiva de voz (IVR), grabación de llamadas, manejo de colas, interoperabilidad SIP, capacidades multimedia, mensajería de texto, videollamadas y mecanismos de accesibilidad, conforme a las condiciones técnicas establecidas en el presente pliego.
• El servicio deberá integrarse con el Sistema de Gestión de Incidentes institucional, entendido como la plataforma actualmente utilizada por la institución para el registro, gestión y seguimiento de incidentes de emergencia, permitiendo el intercambio de información operativa en tiempo real entre ambos sistemas, con el fin de facilitar la atención de llamadas, la generación o asociación de reportes, la trazabilidad de la comunicación y la gestión operativa de las emergencias.
• El adjudicatario deberá proporcionar todos los componentes tecnológicos, configuraciones, licenciamiento, integraciones autorizadas, servicios profesionales y acompañamiento técnico necesarios para garantizar la correcta implementación, operación, soporte, mantenimiento, continuidad e interoperabilidad del servicio integral gestionado de comunicaciones IP y centro de contactos multicanal, conforme al alcance definido en el presente pliego y únicamente respecto de los sistemas institucionales expresamente autorizados por la Administración.

1.2.  Alcance y límites del proyecto

• El alcance de la presente contratación comprende la prestación, implementación, configuración, puesta en operación, soporte, mantenimiento, monitoreo y continuidad operativa de un servicio integral gestionado de comunicaciones IP y centro de contactos multicanal para la atención de emergencias, que permita la gestión eficiente, segura, trazable y continua de llamadas de emergencia y otros canales digitales de interacción asociados al servicio del Sistema de Emergencias 9-1-1.
• El servicio deberá proporcionar las capacidades necesarias para la recepción, distribución, gestión, grabación, monitoreo, supervisión, trazabilidad y explotación operativa de llamadas de voz, mensajería de texto, SMS, videollamadas, chat y otros canales autorizados, así como los mecanismos de interoperabilidad requeridos con la infraestructura institucional y los sistemas expresamente definidos en el presente pliego.
• Dentro del alcance de la contratación se incluyen, como mínimo, los siguientes componentes y servicios:
• Servicio de centro de contactos multicanal para la recepción, distribución y gestión de llamadas de emergencia y otras comunicaciones autorizadas
• Distribuidor automático de llamadas (ACD), manejo de colas, prioridades, desbordamientos y reglas de atención.
• Sistema de respuesta interactiva de voz (IVR).
• Grabación, almacenamiento, consulta, trazabilidad y exportación controlada de llamadas e interacciones, conforme a los requisitos del presente pliego.
• Herramientas de monitoreo y supervisión operativa.
• Capacidades de interoperabilidad mediante estándares abiertos de telecomunicaciones, incluyendo SIP u otros mecanismos equivalentes.
• Capacidades multicanal, incluyendo mensajería de texto, SMS, videollamadas, chat u otros canales digitales autorizados, conforme a las condiciones técnicas establecidas en el presente pliego.
• Integración con el Sistema de Gestión de Incidentes institucional y con otros sistemas expresamente autorizados por la Administración, conforme a los alcances, interfaces y condiciones definidos en el presente pliego.
• Servicios profesionales para implementación, configuración, parametrización, integración, pruebas, documentación y puesta en operación del servicio.
• Capacitación al personal técnico, operativo, supervisor y administrativo que utilizará o administrará el servicio, según corresponda.
• Soporte técnico, mantenimiento, monitoreo, atención de incidentes, continuidad operativa y acompañamiento durante la vigencia contractual.
• Para efectos de operación concurrente y dimensionamiento de terminales, la solución deberá contemplar como mínimo 65 puestos de operador/call taker, 10 puestos de supervisión y 150 puestos de despacho.

 

Los operadores/call takers y supervisores utilizarán el softphone o cliente de atención como medio principal de comunicación, sin perjuicio de que deberán contar también con teléfono IP físico como medio de respaldo, contingencia o continuidad operativa.

 

Los despachadores utilizarán teléfono IP físico como medio principal de comunicación. Adicionalmente, para efectos de continuidad operativa, contingencia, operación alterna o necesidades expresamente autorizadas por la Administración, deberá contemplarse una capacidad mínima de softphones para despacho equivalente al 25% de los puestos de despacho, es decir, 38 softphones adicionales.

 

En consecuencia, el inventario base mínimo para la operación concurrente será el siguiente:

 

1. a) 65 softphones o clientes de atención para operadores/call takers.
2. b) 10 softphones o clientes de atención para supervisores.
3. c) 38 softphones adicionales para contingencia, operación alterna o uso autorizado en despacho.
4. d) 75 teléfonos IP físicos como medio de respaldo para operadores/call takers y supervisores.
5. e) 150 teléfonos IP físicos como medio principal para puestos de despacho.

 

El inventario base mínimo total será de 113 softphones o clientes de atención y 225 teléfonos IP físicos.

• Para efectos de dimensionamiento y desempeño, el oferente deberá considerar como referencia operativa que el Sistema de Emergencias 9-1-1 recibe en promedio 12.000 llamadas diarias, de las cuales se graban en promedio 6000 llamadas con un tiempo promedio de 4 minutos cada llamada y genera aproximadamente 4.000 registros de incidentes diarios, debiendo garantizar que la solución propuesta soporte estos volúmenes con holgura y escalabilidad.
• La solución deberá integrarse con la infraestructura institucional existente, incluyendo la red WAN privada y los enlaces SIP Trunk actualmente en operación, los cuales no forman parte del suministro del contratista. No obstante, será responsabilidad del contratista proveer la conectividad necesaria para interconectar el sitio principal con el Data Center contratado por el 9-1-1, conforme a lo establecido en el presente pliego.
• La conectividad entre el sitio principal y el Data Center contratado por el 9-1-1, provista por el contratista, deberá contemplar como mínimo:
  1. Un enlace principal de 100 Mbps.
  2. Un enlace de redundancia de capacidad equivalente o superior.
  3. Punto de demarcación y entrega en los equipos WAN instalados en el 9-1-1.
• En caso de que para la operación de la solución propuesta se requieran equipos adicionales a los existentes en la infraestructura del 9-1-1 (equipos de comunicaciones, seguridad, cómputo, almacenamiento u otros), su provisión, instalación, licenciamiento y costos asociados serán responsabilidad del contratista.
• Se incluye dentro del alcance la implementación de un esquema de monitoreo y operación 24/7, a cargo del contratista, para todos los componentes de la solución (sitio principal y Data Center contratado por el 9-1-1), con capacidad de detección, notificación, diagnóstico y atención de incidencias conforme a los niveles de servicio definidos en el presente pliego.
• No forma parte del alcance de la presente contratación:
  1. La ampliación o sustitución de la red WAN institucional que interconecta los sitios remotos del 9-1-1.
  2. La contratación de enlaces SIP Trunk externos para el ingreso de llamadas a la línea 9-1-1, salvo que se establezca expresamente como un requerimiento adicional en el presente pliego.
• Cualquier componente, servicio o integración que resulte indispensable para el cumplimiento integral del objeto contractual, aunque no esté descrito explícitamente, se considerará incluido dentro del alcance y será responsabilidad del contratista proveerlo, sin costo adicional, para asegurar la operación completa y continua de la solución.

1.3.  Infraestructura institucional existente

• El Sistema de Emergencias 9-1-1 cuenta actualmente con una infraestructura tecnológica destinada a la gestión de llamadas de emergencia y la coordinación de incidentes con las instituciones de respuesta.
• Dentro de esta infraestructura se encuentra en operación un Sistema de Gestión de Incidentes utilizado para el registro de eventos, coordinación operativa y despacho de recursos de las instituciones que participan en la atención de emergencias.
• Este sistema constituye una plataforma institucional actualmente operativa y continuará siendo utilizado por la institución para la gestión de incidentes y despacho de recursos.
• En este contexto, la solución objeto de la presente contratación deberá integrarse con el sistema de Gestión de Incidentes existente, permitiendo el intercambio de información relevante entre ambos sistemas para facilitar la atención de llamadas y la gestión de emergencias.
• En caso de que durante la vigencia contractual la institución sustituya, actualice o implemente un nuevo Sistema de Gestión de Incidentes, el adjudicatario deberá participar, colaborar y ejecutar las configuraciones, ajustes técnicos, pruebas e integraciones que correspondan desde el ámbito del servicio contratado, a fin de asegurar la continuidad de la interoperabilidad entre el servicio integral gestionado de comunicaciones IP y centro de contactos multicanal y el sistema institucional que se encuentre vigente. Esta obligación comprenderá la coordinación técnica con la Administración y, cuando corresponda, con el proveedor del nuevo sistema, la entrega de información técnica, el acompañamiento en pruebas y la adecuación de interfaces, eventos, parámetros o mecanismos de intercambio de información previstos en el presente pliego. Lo anterior no implicará para el adjudicatario la responsabilidad de adquirir, desarrollar o sustituir el Sistema de Gestión de Incidentes, sino únicamente garantizar, dentro del alcance del servicio contratado, la configuración, interoperabilidad y continuidad técnica de la integración con el sistema institucional que la Administración defina.
• La integración deberá permitir, entre otros aspectos, el intercambio de información básica asociada a las llamadas entrantes, tales como:
• Número telefónico del llamante, cuando esté disponible, mediante ANI u otros identificadores equivalentes.
• Información de localización disponible, cuando esta sea recibida, generada o proporcionada por los servicios, redes, sistemas o mecanismos autorizados para tal fin.
• Eventos asociados al inicio, atención, transferencia, finalización u otros estados relevantes de la llamada o comunicación.
• Identificadores operativos necesarios para la trazabilidad de la atención, tales como identificador de llamada, extensión, agente, cola, canal de ingreso u otros equivalentes disponibles en la solución.
• Otros datos que faciliten la generación, asociación, consulta o gestión de reportes e incidentes dentro del Sistema de Gestión de Incidentes institucional, conforme a los alcances técnicos autorizados por la Administración.
• El mecanismo de integración podrá realizarse mediante interfaces de programación de aplicaciones (API), servicios web, protocolos estándar de telecomunicaciones u otros mecanismos de interoperabilidad, siempre que se garantice la compatibilidad con la arquitectura tecnológica institucional, la seguridad de la información, la trazabilidad y la continuidad operativa.
• La institución proporcionará al adjudicatario la información técnica disponible y necesaria para facilitar la implementación, configuración, pruebas y puesta en operación de dicha integración durante la fase correspondiente del proyecto.
• La infraestructura institucional existente indicada en el presente pliego deberá entenderse como infraestructura de interoperabilidad, conectividad, integración o demarcación, y no como componentes tecnológicos reutilizables puestos a disposición del contratista para alojar, desplegar o sustituir componentes propios de la solución ofertada. En consecuencia, salvo autorización expresa de la Administración, el contratista no deberá asumir disponibilidad institucional de SBC, firewalls, routers, switches, servidores físicos o virtuales, plataformas de virtualización, almacenamiento, licencias de sistemas operativos, licencias de bases de datos, antivirus u otros componentes equivalentes..

 

1.4.  Modelo conceptual y alineamiento con NG-911 (nivel PSAP)

• El servicio objeto de esta contratación se enmarca en el proceso de modernización tecnológica del Sistema de Emergencias 9-1-1, orientado a fortalecer las capacidades de recepción, distribución, gestión, trazabilidad, supervisión y análisis de las comunicaciones de emergencia, bajo un modelo alineado con los principios de Next Generation 9-1-1 (NG9-1-1) a nivel de centro de atención o PSAP.
• Para efectos del presente pliego, el alineamiento con NG9-1-1 se entenderá referido al ámbito funcional del Sistema de Emergencias 9-1-1 como punto de recepción y atención de comunicaciones de emergencia, mediante el uso de tecnologías IP, interoperabilidad entre sistemas, trazabilidad de la atención, gestión multicanal y capacidad de integración con plataformas institucionales autorizadas.
• La contratación no implica la implementación integral de una arquitectura nacional NG9-1-1 extremo a extremo, ni la sustitución de todos los componentes tecnológicos externos asociados a redes, operadores de telecomunicaciones, transporte de llamadas, ubicación u otros elementos fuera del alcance institucional directo, salvo aquellos expresamente definidos en el presente pliego.
• El servicio deberá permitir la recepción y gestión de comunicaciones de emergencia mediante canales de voz y, conforme a las condiciones técnicas establecidas en el presente pliego, otros canales digitales autorizados, tales como mensajería de texto, SMS, videollamadas, chat u otros medios compatibles con la evolución tecnológica del servicio.
• El modelo conceptual considera el servicio integral gestionado de comunicaciones IP y centro de contactos multicanal como el punto tecnológico de entrada, tratamiento, distribución, registro y supervisión de las comunicaciones de emergencia recibidas por el Sistema de Emergencias 9-1-1.
• La información relevante asociada a la comunicación deberá poder integrarse con el Sistema de Gestión de Incidentes institucional y con otros sistemas expresamente autorizados por la Administración, con el fin de facilitar la generación o asociación de reportes, la trazabilidad de la atención y la gestión operativa de las emergencias.
• La arquitectura del servicio deberá orientarse por principios de interoperabilidad, continuidad operativa, seguridad, trazabilidad, escalabilidad, accesibilidad, administración centralizada y evolución tecnológica, de forma que permita a la institución adaptar progresivamente sus capacidades de atención conforme a sus necesidades operativas y al desarrollo de modelos NG9-1-1.

1.5.  Principios rectores de la solución

• El servicio objeto de esta contratación deberá regirse por principios orientadores que aseguren la continuidad operativa, trazabilidad, seguridad, interoperabilidad, accesibilidad, escalabilidad y sostenibilidad tecnológica del Sistema de Emergencias 9-1-1, considerando la naturaleza crítica y permanente del servicio público de atención de emergencias.
• Continuidad operativa del servicio. El servicio deberá garantizar altos niveles de disponibilidad, resiliencia y capacidad de recuperación, de manera que se minimicen los riesgos de interrupción en la recepción, distribución, atención, registro y supervisión de llamadas de emergencia y demás comunicaciones autorizadas.
• Interoperabilidad controlada. El servicio deberá permitir la interoperabilidad con la infraestructura institucional, el Sistema de Gestión de Incidentes institucional y otros sistemas expresamente autorizados por la Administración, mediante mecanismos seguros, documentados, trazables y compatibles con la arquitectura tecnológica institucional.
• Gestión multicanal. El servicio deberá permitir la atención de llamadas de voz y, conforme a las condiciones técnicas establecidads en el presente pliego, otros canales digitales autorizados, tales como mensajería de texto, SMS, videollamadas, chat u otros medios de interacción, bajo un modelo integrado de centro de contactos multicanal.
• Trazabilidad y control institucional. El servicio deberá registrar y conservar evidencia verificable de las comunicaciones, eventos operativos, acciones administrativas, integraciones, grabaciones, reportes, cambios de configuración y demás elementos necesarios para el control institucional, la auditoría y la reconstrucción de la atención brindada.
• Seguridad de la información y control de accesos. El servicio deberá operar bajo controles de seguridad que protejan la confidencialidad, integridad y disponibilidad de la información, incluyendo gestión de perfiles, roles, permisos, auditoría, autenticación, protección contra accesos no autorizados y controles específicos para comunicaciones IP.
• Accesibilidad y atención inclusiva. El servicio deberá facilitar la incorporación de mecanismos que permitan mejorar el acceso de la población al Sistema de Emergencias 9-1-1, incluyendo capacidades multicanal y mecanismos de accesibilidad conforme al alcance contratado y a las posibilidades técnicas de la solución implementada.
• Escalabilidad y evolución tecnológica. El servicio deberá permitir crecimiento, actualización y adaptación progresiva a nuevas necesidades operativas, tecnológicas y funcionales, sin requerir rediseños estructurales injustificados ni generar dependencias que limiten la evolución futura del Sistema de Emergencias 9-1-1.
• Administración centralizada y sostenibilidad operativa. El servicio deberá permitir una administración ordenada, documentada y controlada durante toda la vigencia contractual, incluyendo soporte, mantenimiento, monitoreo, actualización tecnológica, gestión de cambios, capacitación y transferencia de conocimiento.
• Responsabilidad integral del contratista. El adjudicatario será responsable de proporcionar, administrar, mantener y soportar todos los componentes, licencias, configuraciones, integraciones autorizadas, servicios profesionales y elementos técnicos necesarios para la prestación continua del servicio, sin que ello implique la adquisición independiente de activos físicos por parte de la institución, salvo los componentes estrictamente requeridos para la prestación del servicio y bajo responsabilidad del contratista.

 

•  

2.    Condiciones contractuales y administrativas

Las presentes condiciones regulan los aspectos contractuales y administrativos aplicables a la contratación del servicio integral gestionado de comunicaciones IP y centro de contactos multicanal para la atención de emergencias del Sistema de Emergencias 9-1-1.

 

La contratación se estructura en una partida única con varias líneas funcionales, a fin de permitir la contratación del componente principal requerido para la continuidad del servicio, así como la eventual adquisición de componentes complementarios, según disponibilidad presupuestaria, conveniencia institucional, razonabilidad del precio y resultado del análisis técnico y económico de las ofertas.

 

2.1.  Estructura de la contratación por partida y líneas funcionales

La Línea 1 constituye el componente principal, obligatorio e indispensable de la contratación. Las líneas complementarias corresponden a módulos adicionales asociados funcionalmente a la Línea 1, los cuales podrán ser adjudicados total o parcialmente por la Administración, sin que su no adjudicación afecte la validez, ejecución, operación o aceptación del servicio base.

Tabla 1. Estructura de la contratación por partida y líneas funcionales

Partida	Línea	Condición	Descripción	Código SICOP
Única	1	Obligatoria, principal	Arrendamiento de solución de telefonía y centro de contactos multicanal	8116170792157465
	2	Complementaria	Módulo de Gestión de Calidad, Desempeño Operativo, Retroalimentación y Coaching — Quality Management / Performance Management	8116170792157465
	3	Complementaria	Módulo de Gestión de Fuerza de Trabajo / Workforce Management, planificación, programación, adherencia y gestión intradía	8116170792157465
	4	Complementaria	Módulo de Analítica Avanzada de Interacciones — Speech Analytics, transcripción, búsqueda y análisis de comunicaciones	8116170792157465

 

Nota:     Los “códigos SICOP” aquí señalados deben ser considerados únicamente como guía de referencia genérica. En este sentido, prevalecerán las especificaciones técnicas señaladas en este documento.

 

• Todo oferente que participe en el presente procedimiento de contratación estará obligado a cotizar y ofrecer la totalidad de las líneas descritas en este pliego de condiciones (tanto la Línea 1 principal, como las Líneas 2, 3 y 4 complementarias). No se aceptarán ofertas parciales que omitan alguna de las líneas complementarias; la omisión de cualquiera de ellas será motivo de descalificación de la propuesta por inelegibilidad técnica y administrativa.
• Los oferentes deberán cotizar de forma obligatoria la Línea 1 y las Líneas 2, 3 y 4, cada una de forma separada, indicando precio individual, alcance funcional, licenciamiento, implementación, soporte, mantenimiento, condiciones de operación y cualquier dependencia técnica respecto de la Línea 1. La cotización obligatoria de las líneas complementarias no implica obligación de ejecución, facturación o pago inmediato para la Administración, pero sí permite su evaluación técnica y económica y eventual adjudicación bajo modalidad de activación posterior.
• La Línea 1 constituye el componente principal, obligatorio e indispensable de la contratación. Las líneas complementarias se consideran funcional, técnica y operativamente asociadas a la Línea 1, por lo que deberán ser compatibles, interoperables e integrables con el servicio base.
• La cotización obligatoria de las Líneas 2, 3 y 4 no genera para la Administración obligación de ejecución, activación, facturación o pago inmediato. No obstante, dichas líneas deberán ser ofertadas, documentadas, evaluadas y cumplir técnicamente desde la etapa de oferta, a fin de que la Administración pueda adjudicarlas para ejecución inmediata o bajo modalidad de activación posterior, según disponibilidad presupuestaria, razonabilidad del precio, conveniencia institucional y resultado del análisis técnico y económico.
• Por razones de unidad funcional, continuidad operativa, interoperabilidad, seguridad, trazabilidad, responsabilidad integral del servicio y administración contractual, las líneas complementarias, en caso de adjudicarse, deberán adjudicarse al mismo adjudicatario de la Línea 1.
• La Administración podrá adjudicar la Línea 1 para ejecución inmediata y, adicionalmente, adjudicar una o varias líneas complementarias para ejecución inmediata o bajo modalidad de activación posterior, según disponibilidad presupuestaria, razonabilidad del precio, conveniencia institucional y resultado del análisis técnico y económico de las ofertas. La activación posterior no generará obligación de pago hasta que exista contenido presupuestario suficiente, orden formal de activación, implementación, pruebas, recepción conforme y aceptación institucional.
• En caso de adjudicarse líneas complementarias, estas deberán integrarse funcional y técnicamente con la Línea 1, sin generar duplicidad de plataformas, afectación operativa, dependencias no previstas, fragmentación de responsabilidades o costos adicionales no incluidos en la oferta adjudicada.
• Líneas complementarias de activación posterior. La Administración podrá adjudicar una o varias de las Líneas 2, 3 y 4 bajo modalidad de activación posterior, siempre que hayan sido ofertadas, evaluadas y resulten técnica y económicamente admisibles. La adjudicación bajo esta modalidad no implica inicio inmediato de ejecución, implementación, facturación o pago. La activación de cada línea quedará sujeta a disponibilidad presupuestaria, necesidad institucional, conveniencia administrativa, razonabilidad del precio y emisión de orden formal de activación. Una vez ordenada la activación, el contratista deberá implementar, configurar, integrar, probar, capacitar y poner en operación la línea correspondiente, conforme a los requisitos técnicos, niveles de servicio y criterios de aceptación establecidos en el pliego.

 

2.2.  Plazo contractual, implementación y entrada en operación

• El plazo contractual será de cuarenta y ocho (48) meses, contados a partir de la orden de inicio o del acto administrativo que corresponda, según lo defina la Administración.
• El adjudicatario deberá presentar, como parte de su oferta, un cronograma detallado de implementación para la Línea 1 y un cronograma referencial para las Líneas 2, 3 y 4, considerando que estas podrán ser adjudicadas para ejecución inmediata o bajo modalidad de activación posterior. En caso de activación posterior, el cronograma definitivo de la línea respectiva será coordinado con la Administración a partir de la orden formal de activación.
• La Línea 1, correspondiente al servicio integral gestionado de comunicaciones IP y centro de contactos multicanal para la atención de emergencias, deberá encontrarse implementada, funcional, probada, aceptada y en operación efectiva a más tardar el 1 de abril de 2027.
• La entrada en operación de la Línea 1 estará condicionada al cumplimiento de las pruebas funcionales, técnicas, de integración, seguridad, continuidad operativa, grabación, reportería, monitoreo y aceptación institucional definidas en el presente pliego.
• Las líneas complementarias, en caso de ser adjudicadas, podrán implementarse de forma paralela o posterior a la Línea 1, siempre que no afecten la puesta en operación, estabilidad, continuidad, aceptación o funcionamiento del servicio base.
• Líneas 2, 3 y 4 (Líneas Complementarias): Para las Líneas 2, 3 y 4 adjudicadas para ejecución inmediata, el plazo máximo para su implementación, pruebas de integración funcional e inicio oficial de operación no podrá ser superior a seis (6) meses calendario contados a partir de la fecha de inicio de la Línea 1. Para las líneas complementarias adjudicadas bajo modalidad de activación posterior, dicho plazo empezará a computarse a partir de la orden formal de activación emitida por la Administración, y no desde la entrada en operación de la Línea 1.
• La Administración se reserva la facultad de coordinar con el contratista puestas en marcha anticipadas de las líneas complementarias dentro de este periodo de seis meses, según la madurez técnica del proyecto y las necesidades institucionales. El incumplimiento en los plazos de entrega e inicio de cualquiera de las líneas complementarias facultará a la Administración a aplicar las penalidades por atraso correspondientes, sin perjuicio de las responsabilidades contractuales por falta de integración.
• El inicio del pago recurrente mensual de cada línea estará condicionado a la recepción conforme de la línea correspondiente, según los entregables, pruebas, actas y criterios de aceptación establecidos en el presente pliego.
• Durante el periodo de implementación, el adjudicatario deberá coordinar con la Administración las actividades necesarias para evitar afectaciones a la continuidad operativa del Sistema de Emergencias 9-1-1, incluyendo planificación de ventanas de trabajo, pruebas controladas, migración gradual, capacitación y acompañamiento técnico.
• Unificación de la Vigencia Contractual (Cláusula de Co-término): El plazo de vigencia ordinario del presente contrato se establece en cuarenta y ocho (48) meses, los cuales empezarán a computarse de forma efectiva a partir del 01 de abril de 2027 con el inicio de la operación de la Línea 1.

Las Líneas 2, 3 y 4, ya sea que se adjudiquen para ejecución inmediata o bajo modalidad de activación posterior, deberán ajustarse a la fecha de finalización del contrato principal de la Línea 1. En consecuencia, ninguna línea complementaria podrá extender su vigencia más allá del vencimiento contractual de la Línea 1. Para efectos de facturación, el contratista solo podrá cobrar los montos mensuales ofertados a partir de la entrada en operación efectiva, recepción conforme y aceptación institucional de la línea correspondiente, aplicando el prorrateo que corresponda según el periodo efectivamente ejecutado.

2.3.  Precio y forma de pago

• El oferente deberá cotizar un precio mensual fijo para cada línea ofertada, el cual deberá incluir la totalidad de costos necesarios para la prestación integral del servicio durante la vigencia contractual.
• El precio mensual ofertado para la Línea 1 deberá comprender, como mínimo, la implementación, configuración, puesta en operación, licenciamiento, soporte, mantenimiento, monitoreo, continuidad operativa, capacitación, documentación, pruebas, integraciones requeridas y demás actividades necesarias para garantizar la operación completa del servicio base.
• Para las líneas complementarias, el oferente deberá indicar el precio mensual individual de cada línea, incluyendo todos los costos asociados a su habilitación, configuración, operación, soporte, mantenimiento, licenciamiento, integración con la Línea 1 y demás condiciones necesarias para su funcionamiento.
• No se reconocerán pagos separados por concepto de implementación, instalación, configuración, integración, pruebas, capacitación, documentación, puesta en operación o cualquier otro costo requerido para iniciar o mantener el servicio, salvo que el pliego o el contrato establezcan expresamente una condición distinta.
• El pago mensual de cada línea iniciará únicamente a partir de su implementación, puesta en operación efectiva, pruebas satisfactorias, recepción conforme y aceptación institucional. En el caso de líneas complementarias adjudicadas bajo modalidad de activación posterior, no procederá facturación ni pago alguno antes de la orden formal de activación emitida por la Administración y de la recepción conforme de la línea respectiva..
• La no adjudicación de una o varias líneas complementarias no afectará el precio mensual, operación, implementación, soporte, continuidad ni aceptación de la Línea 1.
• El oferente deberá indicar en su oferta las tarifas mensuales unitarias aplicables a incrementos futuros de capacidad que sean expresamente solicitados por la Administración y que excedan la capacidad base incluida en cada línea adjudicada, tales como usuarios, agentes, supervisores, canales, almacenamiento, grabaciones, sesiones concurrentes, integraciones adicionales, licencias o capacidades complementarias. Dichas tarifas no podrán utilizarse para trasladar costos asociados a componentes, funcionalidades, licencias, configuraciones, integraciones, soporte o capacidades que formen parte del alcance mínimo requerido para la operación inicial de la línea correspondiente.

2.4.  Vigencia de la oferta

• La oferta presentada por cada oferente deberá mantenerse vigente, firme e invariable por un plazo mínimo de noventa (90) días naturales, contados a partir de la fecha límite establecida para la presentación de ofertas, salvo que el pliego o la normativa aplicable establezcan un plazo distinto.
• Durante el período de vigencia indicado, el oferente no podrá modificar los precios, condiciones, alcances, plazos, ni demás compromisos incluidos en su oferta, salvo ajustes expresamente permitidos por la normativa aplicable y debidamente autorizados por la institución.
• En caso de que el procedimiento de contratación requiera ampliación del período de vigencia de las ofertas, la institución podrá solicitar por escrito a los oferentes la extensión correspondiente. La aceptación de dicha prórroga deberá formalizarse por el oferente dentro del plazo que establezca la institución, manteniendo las condiciones originalmente ofertadas.
• La falta de aceptación de la prórroga de vigencia solicitada por la Administración podrá ser considerada como desistimiento de la oferta, conforme al marco normativo aplicable.
• La vigencia de la oferta no exime al oferente del cumplimiento de los requisitos de admisibilidad, condiciones técnicas, económicas, contractuales y demás obligaciones establecidas en el presente pliego.

 

 

2.5.  Garantía de cumplimiento

• El adjudicatario deberá extender una Garantía de Cumplimiento a nombre del contratante, dentro de los 5 días hábiles contados a partir de la fecha en que quede en firme la adjudicación.
• Si el adjudicatario no presenta la Garantía de Cumplimiento dentro del plazo aquí estipulado, el contratante podrá revocar la adjudicación sin responsabilidad de su parte, dejar sin valor ni efecto la oferta del adjudicatario, en cuyo caso se podrá re- adjudicar la contratación o declararla desierta, según convenga a sus intereses.
• La garantía de cumplimiento deberá otorgarse válidamente por un 5% del monto de la adjudicación y con una vigencia de hasta por dos meses adicionales a la fecha de terminación del plazo de la contratación (RLGCP art. 110, 111 y 114).
• La garantía de cumplimiento deberá respaldar la correcta ejecución de las obligaciones contractuales asociadas a las líneas adjudicadas, incluyendo la implementación, configuración, puesta en operación, prestación mensual del servicio, soporte, mantenimiento, monitoreo, continuidad operativa, cumplimiento de niveles de servicio, atención de incidentes, integraciones autorizadas, capacitación, documentación y demás obligaciones establecidas en el presente pliego.
• En caso de adjudicarse una o varias líneas complementarias, sea para ejecución inmediata o bajo modalidad de activación posterior, la garantía de cumplimiento deberá ajustarse conforme al monto adjudicado, monto activado o condiciones contractuales correspondientes, según lo determine la Administración. La Administración podrá requerir el ajuste de la garantía cuando se ordene la activación posterior de una línea complementaria o cuando se autoricen incrementos de capacidad.
• La garantía deberá mantenerse vigente durante todo el plazo contractual y por el periodo adicional que establezca la Administración, con el fin de cubrir eventuales responsabilidades derivadas de la ejecución, cierre, transición, entrega de información, reversibilidad o finalización del servicio.
• Cuando durante la vigencia contractual se autoricen incrementos de capacidad, ampliaciones o nuevas líneas complementarias, la Administración podrá requerir el ajuste correspondiente de la garantía de cumplimiento, de conformidad con el monto adicional autorizado y las condiciones aplicables.
• La ejecución, devolución, sustitución o ajuste de la garantía de cumplimiento se regirá por lo establecido en el contrato, el presente pliego y la normativa aplicable.

2.6.  Recepción del servicio y gestión de pago

• La recepción del servicio se realizará contra la prestación efectiva de cada línea adjudicada, conforme a los entregables, niveles de servicio, reportes, evidencias, actas y criterios de aceptación establecidos en el presente pliego y en el contrato respectivo.
• Para efectos del inicio del pago mensual de la Línea 1, el adjudicatario deberá haber completado la implementación, configuración, pruebas, capacitación, integración, documentación y puesta en operación del servicio base, y deberá contar con la recepción conforme emitida por la Administración.
• Para las líneas complementarias que sean adjudicadas, sea para ejecución inmediata o bajo modalidad de activación posterior, el pago mensual iniciará únicamente a partir de la efectiva habilitación, puesta en operación, recepción conforme y aceptación institucional de la línea correspondiente. La adjudicación bajo modalidad de activación posterior no implicará pago automático ni compromiso de consumo mientras no exista orden formal de activación.
• El adjudicatario deberá presentar mensualmente un informe de prestación del servicio, el cual deberá incluir, como mínimo, disponibilidad del servicio, incidentes registrados, tiempos de atención, cumplimiento de niveles de servicio, mantenimientos realizados, eventos relevantes, acciones correctivas, reportes de soporte y cualquier otra evidencia requerida por la Administración.
• La Administración verificará el cumplimiento mensual del servicio previo a gestionar el pago correspondiente. En caso de incumplimientos, indisponibilidades, degradaciones, incidentes no atendidos, ausencia de evidencias o incumplimiento de niveles de servicio, la Administración podrá aplicar las deducciones, multas, cláusulas penales o Gestiones contractuales que correspondan.
• La recepción mensual del servicio no libera al adjudicatario de su responsabilidad por defectos, errores, omisiones, incumplimientos, fallas recurrentes o afectaciones detectadas con posterioridad, cuando estas sean atribuibles a la prestación del servicio contratado.
• La recepción definitiva de cada línea requerirá la entrega completa de la documentación técnica, operativa, administrativa y de soporte correspondiente, así como las evidencias de pruebas, configuraciones, capacitación, manuales, procedimientos, respaldos y demás elementos definidos en el presente pliego.
• Para efectos de la recepción mensual del servicio y previo al trámite de pago, la Administración podrá utilizar la Matriz mensual de verificación para recepción del servicio y trámite de pago, incorporada como Anexo 7 del presente pliego, con el fin de documentar el cumplimiento de las obligaciones contractuales, niveles de servicio, reportes, evidencias, incidentes, acciones correctivas y demás aspectos necesarios para respaldar la recepción conforme del servicio.

2.7.  Información técnica para análisis, estudio comparativo y verificación de ofertas

• Toda oferta deberá suministrar información completa, clara, suficiente y verificable que permita a la Administración realizar el análisis técnico, económico, operativo y comparativo de las propuestas presentadas.
• El oferente deberá presentar la información técnica de forma separada para cada línea ofertada, indicando alcance funcional, componentes incluidos, capacidades habilitadas, licenciamiento, modalidad de prestación del servicio, condiciones de soporte, mantenimiento, monitoreo, continuidad operativa, escalabilidad y cualquier dependencia técnica respecto de la Línea 1.
• La oferta deberá incluir una matriz de cumplimiento técnico en la que se indique, para cada requisito del pliego, si cumple, no cumple o cumple parcialmente, incorporando la referencia documental, evidencia, descripción funcional o aclaración técnica que permita verificar objetivamente lo ofertado.
• No se aceptarán declaraciones generales de cumplimiento sin respaldo técnico verificable. La Administración podrá solicitar aclaraciones, ampliaciones o demostraciones cuando la información aportada no permita verificar el cumplimiento de los requisitos establecidos.
• El oferente deberá aportar documentación técnica del servicio ofertado, incluyendo, cuando corresponda: arquitectura propuesta, modelo de operación, esquema de alta disponibilidad, seguridad, integraciones, canales de atención, grabación, monitoreo, reportería, administración, soporte, escalamiento y continuidad operativa.
• El oferente deberá aportar referencias, constancias o certificaciones de experiencia relacionadas con servicios, plataformas o soluciones similares a las ofertadas, preferiblemente implementadas y en operación en centros de contacto, servicios críticos, instituciones públicas, servicios de emergencia, seguridad, salud, telecomunicaciones u operaciones 24/7. Dichos documentos deberán permitir verificar objetivamente la experiencia declarada y cumplir, como mínimo, con lo siguiente:
  1. Indicar el año de implementación, puesta en producción o inicio de operación del servicio o solución referida.
  2. Identificar la entidad o cliente que emite la referencia, incluyendo un medio de contacto verificable.
  3. Describir de forma concisa el alcance del servicio o solución implementada y su similitud con la línea o líneas ofertadas.
  4. Indicar, cuando corresponda, si la solución se encuentra actualmente en operación.
  5. Estar suscritos por una persona con competencia o conocimiento suficiente para emitir la referencia, constancia o certificación correspondiente.
  6. Presentarse mediante documento verificable, firmado digitalmente, copia certificada o medio equivalente que permita a la Administración validar su autenticidad.
• La Administración se reserva el derecho de verificar por cualquier medio razonable la información aportada por los oferentes y solicitar información complementaria, con el objetivo de validar antecedentes, experiencia, capacidad técnica, operación en producción, certificaciones, referencias, condiciones de soporte, continuidad operativa y correspondencia entre lo ofertado y lo verificable.
• Para efectos de verificación, inspección, demostración o aclaración de lo ofertado, la Administración podrá designar una Comisión de Verificación, con el propósito de observar, valorar y solicitar aclaraciones respecto de la propuesta del oferente y de sus evidencias técnicas, funcionales y operativas.
• La Comisión de Verificación podrá estar integrada por funcionarios de Tecnologías de Información y Operaciones, sin perjuicio de que la Administración incorpore otros funcionarios, asesores técnicos o representantes institucionales cuando lo estime necesario según la naturaleza de la verificación.
• Cuando la Administración lo determine necesario para validar experiencia, madurez, funcionalidad o correspondencia de la solución ofertada, el oferente deberá facilitar una demostración, sesión técnica, prueba de concepto o visita de verificación sobre un servicio o solución en producción indicada por el oferente. Dicha verificación podrá realizarse de forma presencial, remota o híbrida, según lo defina la Administración.
• La solución o servicio objeto de verificación deberá cumplir, como mínimo, con lo siguiente:
  1. Estar en operación productiva al momento de la demostración, visita o verificación.
  2. Contar con componentes, funcionalidades o capacidades equivalentes o comparables a la línea o líneas ofertadas.
  3. Permitir la demostración de los elementos críticos que la Administración defina, incluyendo, cuando aplique, centro de contactos, ACD, IVR, grabación, trazabilidad, monitoreo, reportes, alta disponibilidad, canales digitales, integración con sistemas institucionales autorizados y operación del servicio en condiciones reales o equivalentes.
• El oferente deberá señalar claramente en su oferta, cuando aplique, la ubicación geográfica o modalidad de verificación propuesta, la persona o personas de contacto responsables, la descripción general del servicio o solución en producción que podría ser objeto de verificación y una agenda preliminar orientada a demostrar los elementos críticos solicitados por la Administración.
• Los gastos en que incurra la Comisión de Verificación en cumplimiento de visitas o verificaciones presenciales correrán por cuenta del Sistema de Emergencias 9-1-1, conforme al Reglamento de Gastos de Viaje y de Transporte para funcionarios públicos y demás disposiciones aplicables. Lo anterior no exime al oferente de facilitar, sin costo adicional para la Administración, la coordinación, acceso razonable, sesiones técnicas, demostraciones y atención necesaria para la verificación de lo ofertado.
• Para efectos de análisis técnico comparativo y adjudicación, la Comisión de Verificación deberá rendir los informes correspondientes, en los que se deje constancia de lo observado, demostrado o verificado, así como de la correspondencia entre la oferta, la documentación aportada y la operación real del servicio o solución revisada. Dicho informe constituirá un insumo técnico para la valoración de la oferta, sin sustituir el sistema de evaluación establecido en el presente pliego.
• El estudio de las ofertas se realizará considerando el cumplimiento de los requisitos de admisibilidad, las condiciones técnicas establecidas para cada línea, la razonabilidad del precio mensual ofertado, la información técnica aportada, la matriz de cumplimiento, las evidencias documentales, las referencias de experiencia, las verificaciones que realice la Administración y el sistema de evaluación definido en el presente pliego.

 

 

2.8.  Administración y coordinación del contrato

• El adjudicatario deberá designar una persona que actuará como administrador, coordinador o enlace principal del contrato, responsable de la coordinación con la Administración, seguimiento de actividades, atención de requerimientos, gestión de incidentes, coordinación de soporte, control de entregables y seguimiento general de la prestación del servicio durante toda la vigencia contractual.
• La persona designada deberá contar con experiencia en coordinación de proyectos, servicios tecnológicos, servicios gestionados, administración de contratos o actividades equivalentes relacionadas con la prestación de servicios tecnológicos críticos.
• El adjudicatario deberá comunicar formalmente a la Administración el nombre, cargo, teléfono, correo electrónico y medios de contacto del administrador o coordinador del contrato, a más tardar dentro del plazo que establezca la Administración posterior a la formalización contractual u orden de inicio.
• El administrador o coordinador del contrato deberá participar en las reuniones de seguimiento, comités técnicos, revisiones de avance, gestión de incidentes críticos, coordinación de mantenimientos, revisión de reportes mensuales y demás actividades que la Administración convoque en relación con el servicio contratado.
• Cualquier sustitución del administrador o coordinador del contrato deberá ser comunicada previamente a la Administración, indicando la persona sustituta y acreditando que cuenta con condiciones equivalentes para asumir la coordinación del servicio.
• La designación del administrador o coordinador del contrato no exime al adjudicatario de su responsabilidad integral por la correcta prestación, soporte, mantenimiento, continuidad, seguridad, trazabilidad y cumplimiento contractual del servicio adjudicado.

2.9.  Capacitación, transferencia de conocimiento y acompañamiento técnico

• El adjudicatario deberá brindar capacitación integral al personal que defina la Administración, conforme a los perfiles de uso, administración, supervisión, soporte y control asociados a cada línea adjudicada.
• La capacitación deberá formar parte integral del servicio contratado y estar incluida dentro del precio mensual ofertado para cada línea adjudicada, sin que se reconozcan pagos adicionales por concepto de capacitación inicial, materiales, sesiones prácticas, acompañamiento, transferencia de conocimiento o capacitaciones requeridas para la correcta operación del servicio.
• El adjudicatario deberá presentar, durante la fase de implementación, un plan de capacitación que indique como mínimo:
  1. Objetivo de cada actividad de capacitación.
  2. Perfil del personal destinatario.
  3. Contenido temático.
  4. Duración estimada.
  5. Modalidad presencial, virtual o híbrida.
  6. Materiales a entregar.
  7. Cantidad de participantes por grupo.
  8. Cronograma propuesto.
  9. Mecanismo de evaluación o validación de aprovechamiento, cuando corresponda.
• La capacitación deberá contemplar, como mínimo, los siguientes perfiles, según las líneas adjudicadas:
  1. Agentes u operadores.
  2.  
  3. Administradores operativos.
  4. Administradores técnicos.
  5. Personal de monitoreo, calidad o evaluación.
  6. Personal de Tecnologías de Información.
  7. Otros perfiles que defina la Administración durante la implementación.
• La capacitación deberá incluir, según corresponda, el uso operativo del centro de contactos, ACD, gestión de colas, estados de agentes, códigos de inactividad, telefonía, softphone o cliente de atención, grabación, IVR, reportes, monitoreo, videollamadas, mensajería de texto, SMS, chat, administración básica, consulta de auditoría y demás funcionalidades adjudicadas.
• Para las líneas complementarias que sean adjudicadas, el adjudicatario deberá brindar capacitación específica sobre los módulos correspondientes, incluyendo, cuando aplique, Gestión de Calidad, Desempeño Operativo, Retroalimentación y Coaching, Workforce Management, Analítica Avanzada de Interacciones, reportería, configuración, operación, administración y explotación de información.
• Toda capacitación deberá impartirse en idioma español y deberá incluir materiales, guías, manuales, presentaciones, grabaciones de sesión cuando sea autorizado, ejercicios prácticos o documentación equivalente suficiente para facilitar la operación posterior por parte de la institución.
• El adjudicatario deberá entregar evidencia de las capacitaciones realizadas, incluyendo como mínimo listas de asistencia, contenidos impartidos, fecha, duración, modalidad, instructor responsable y materiales entregados.
• Durante toda la vigencia contractual, el adjudicatario deberá brindar acompañamiento técnico y operativo para apoyar a la Administración en configuraciones, ajustes autorizados, transferencia de conocimiento, refuerzos de capacitación y capacitaciones adicionales razonablemente requeridas para la correcta operación, administración, soporte y aprovechamiento del servicio.
• El apoyo indicado podrá comprender, entre otros aspectos, configuración de colas, perfiles, permisos, reportes, reglas operativas, plantillas, flujos de IVR, parámetros de mensajería, videollamadas, tableros, módulos complementarios, ajustes funcionales y demás configuraciones propias del servicio adjudicado, siempre dentro del alcance contractual y conforme a los mecanismos de control de cambios definidos por la Administración.
• El adjudicatario deberá brindar capacitaciones adicionales cuando se presenten actualizaciones relevantes de la solución, incorporación de nuevas funcionalidades adjudicadas, cambios operativos autorizados, sustitución de personal clave, implementación de líneas complementarias o necesidades institucionales justificadas para asegurar la continuidad y correcta operación del servicio.
• Las capacitaciones adicionales y el acompañamiento técnico durante la vigencia contractual no deberán sustituir obligaciones de soporte, mantenimiento, corrección de errores o atención de incidentes, ni podrán ser utilizados por el adjudicatario para trasladar costos adicionales a la Administración por funcionalidades incluidas en el servicio adjudicado.

2.10.          Acuerdos de nivel de servicio

• Los acuerdos de nivel de servicio establecen las condiciones mínimas de disponibilidad, continuidad, soporte, atención de incidentes, recuperación, monitoreo, documentación y reporte que deberá cumplir el adjudicatario durante toda la vigencia contractual, respecto del servicio integral gestionado de comunicaciones IP y centro de contactos multicanal, así como respecto de las líneas complementarias que sean adjudicadas.
• Los niveles de servicio serán medibles, verificables y exigibles por la Administración mediante reportes, bitácoras, herramientas de monitoreo, actas, registros técnicos, informes del contratista, evidencias institucionales y cualquier otro medio objetivo de comprobación.
• Disponibilidad mensual mínima requerida

Tabla 2. Disponibilidad mensual mínima requerida

Línea / componente	Disponibilidad mensual mínima requerida
Línea 1: Servicio integral gestionado de comunicaciones IP y centro de contactos multicanal	99,99%
Componentes  de voz, ACD, control de llamadas, IVR, grabación e integración operativa mínima	99,99%
Mensajería de texto, SMS, chat y videollamadas	99,50%
Línea 2: Gestión de Calidad, Desempeño Operativo, Retroalimentación y Coaching	99,50%
Línea 3: Workforce Management	99,50%
Línea 4: Analítica Avanzada de Interacciones / Speech Analytics	99,00%
Reportería histórica, tarificación, dashboards analíticos no críticos y consultas administrativas	99,00%

 

• La indisponibilidad de líneas complementarias no deberá afectar la continuidad operativa de la Línea 1. En caso de que una falla en una línea complementaria afecte la operación del servicio base, se valorará como incumplimiento de la Línea 1.
• Cálculo de disponibilidad. La disponibilidad mensual del servicio se calculará con la siguiente fórmula: DS = ((TSO - TIS) / TSO) × 100

Tabla 3. Cálculo de disponibilidad

Variable	Definición
DS	Disponibilidad del servicio en el mes calendario evaluado.
TSO	Tiempo total de servicio ofrecido durante el mes calendario, expresado en minutos.
TIS	Tiempo acumulado de interrupción o indisponibilidad atribuible al contratista durante el mes calendario, expresado en minutos.

 

• Inicio y cierre del tiempo de indisponibilidad. El tiempo de indisponibilidad iniciará desde el primero de los siguientes momentos:
  1. Detección automática del evento por las herramientas de monitoreo.
  2. Notificación realizada por la Administración mediante los canales definidos.
  3. Registro verificable de afectación operativa en los sistemas institucionales.
  4. Identificación del evento por personal técnico u operativo autorizado.
• El tiempo de indisponibilidad finalizará cuando el servicio afectado haya sido restablecido, se haya verificado su operación normal y exista evidencia objetiva del cierre del incidente.
• Exclusiones del cálculo de disponibilidad. No se contabilizarán como indisponibilidad atribuible al contratista los eventos derivados directa y comprobablemente de:
  1. Caso fortuito o fuerza mayor.
  2. Fallas atribuibles exclusivamente a la Administración.
  3. Fallas de servicios externos no administrados por el contratista, siempre que no formen parte del servicio contratado.
  4. Ventanas de mantenimiento previamente autorizadas por la Administración.
  5. Intervenciones solicitadas expresamente por la Administración que impliquen afectación controlada del servicio.
  6. Toda exclusión deberá estar debidamente documentada. No se aceptarán exclusiones genéricas sin evidencia técnica verificable.
• Ventanas de mantenimiento. Toda ventana de mantenimiento deberá ser solicitada por el adjudicatario y autorizada por la Administración. La solicitud deberá indicar, como mínimo:
  1. Fecha y hora propuesta.
  2. Duración estimada.
  3. Componentes afectados.
  4. Impacto esperado.
  5. Riesgos operativos.
  6. Plan de reversión.
  7. Personal responsable.
• Cualquier afectación no autorizada, extensión no aprobada o falla posterior atribuible al mantenimiento será contabilizada para efectos de disponibilidad y eventuales sanciones.
• Clasificación de Incidentes. Los incidentes se clasificarán según su impacto operativo:

Tabla 4. Clasificación de Incidentes

Prioridad	Clasificación	Descripción
P1	Crítico	Afecta la recepción, distribución, atención, grabación o trazabilidad de llamadas de emergencia, o compromete la continuidad de la Línea 1.
P2	Alto	Degrada parcialmente un componente crítico, afecta a grupos de usuarios o compromete funcionalidades relevantes sin detener totalmente la atención.
P3	Medio	Afecta funcionalidades administrativas, reportes, consultas, configuraciones no críticas o componentes complementarios sin impacto directo en la atención inmediata.
P4	Bajo	Consultas, solicitudes de apoyo, ajustes menores, capacitaciones adicionales, mejoras operativas o requerimientos sin afectación del servicio.

 

• Tiempos mínimos de atención de incidentes. El adjudicatario deberá cumplir, como mínimo, con los siguientes tiempos de atención:

Tabla 5. Tiempos mínimos de atención de incidentes

Prioridad	Acuse de recibo	Diagnóstico inicial	Actualización de avance	Restauración o solución temporal
P1 Crítico	10 minutos	20 minutos	Cada 30 minutos	Lo antes posible, con atención continua 24/7 hasta restablecer
P2 Alto	20 minutos	1 hora	Cada 2 horas	Máximo 8 horas
P3 Medio	4 horas hábiles	1 día hábil	Según plan de atención	Máximo 3 días hábiles
P4 Bajo	1 día hábil	2 días hábiles	Según coordinación	Según cronograma aprobado

 

• El cumplimiento de estos tiempos no exime al adjudicatario de cumplir el porcentaje de disponibilidad mensual comprometido.
• Soporte técnico 24/7/365. El adjudicatario deberá brindar soporte técnico 24 horas al día, 7 días a la semana, 365 días al año, para todos los componentes críticos de la Línea 1. Para las líneas complementarias, el soporte deberá brindarse conforme a la prioridad del incidente, sin que una falla de dichas líneas pueda afectar la continuidad del servicio principal. El adjudicatario deberá mantener disponibles, como mínimo:
  1. Teléfono de atención.
  2. Correo electrónico.
  3. Mesa de servicio o sistema de tiquetes.
  4. Contacto de escalamiento técnico.
  5. Contacto de escalamiento administrativo.
• Reporte mensual de cumplimiento de SLA. El adjudicatario deberá entregar mensualmente un informe de cumplimiento de niveles de servicio, como requisito para la recepción mensual y gestión de pago. El informe deberá incluir, como mínimo:
  1. Disponibilidad mensual por línea y componente.
  2. Incidentes registrados por prioridad.
  3. Fecha y hora de apertura y cierre de cada incidente.
  4. Tiempos de acuse, diagnóstico, atención y cierre.
  5. Incumplimientos detectados.
  6. Ventanas de mantenimiento ejecutadas.
  7. Acciones correctivas y preventivas.
  8. Evidencia de monitoreo y bitácoras relevantes.
  9. El informe mensual deberá permitir verificar, para cada línea adjudicada, el cumplimiento de la disponibilidad, incidentes registrados, tiempos de atención, afectaciones operativas, acciones correctivas y evidencias correspondientes.
  10. La Administración podrá contrastar este informe con sus propios registros, herramientas de monitoreo, bitácoras operativas y evidencias institucionales.
• Informe posterior a incidentes críticos o altos. Cuando se presente un incidente P1 o P2, el adjudicatario deberá presentar un informe técnico dentro de un plazo máximo de cinco días hábiles posteriores al restablecimiento del servicio. El informe deberá contener, como mínimo:
  1. Fecha y hora de inicio del incidente.
  2. Fecha y hora de detección.
  3. Fecha y hora de notificación.
  4. Fecha y hora de restablecimiento.
  5. Componentes afectados.
  6. Causa raíz identificada o causa probable.
  7. Impacto operativo.
  8. Acciones correctivas ejecutadas.
  9. Acciones preventivas propuestas.
  10. Evidencias técnicas.
• Frecuencia de interrupciones del servicio. Se utilizará el indicador de Frecuencia de Interrupción del Servicio (FIS) para controlar la recurrencia de eventos. FIS = número de interrupciones atribuibles al contratista en un período de 90 días calendario. Se considerará condición de riesgo contractual cuando se presenten tres o más interrupciones atribuibles al contratista en un período de 90 días calendario, aunque individualmente hayan sido atendidas. En ese supuesto, la Administración podrá requerir un plan de mejora obligatorio, sin perjuicio de aplicar multas o valorar otras acciones contractuales cuando corresponda.
• Planes de mejora. Cuando se detecten incumplimientos recurrentes, degradaciones repetidas o incumplimientos de SLA, la Administración podrá requerir al adjudicatario un plan de mejora. El plan deberá incluir, como mínimo:
  1. Descripción del problema.
  2. Causa raíz o causa probable.
  3. Acciones correctivas.
  4. Acciones preventivas.
  5.  
  6. Fechas de cumplimiento.
  7. Evidencias esperadas.
• La presentación o ejecución de un plan de mejora no impedirá la aplicación de multas, cláusula penal u otras medidas contractuales cuando correspondan.
• Relación con multas y cláusula penal. El incumplimiento de los acuerdos de nivel de servicio podrá dar lugar a la aplicación de multas, cláusula penal, planes de mejora, retenciones, ejecución de garantía, resolución contractual u otras acciones previstas en el pliego, el contrato y la normativa aplicable.

2.11.          Cláusula penal, multas y consecuencias por incumplimiento.

• Para efectos de la presente contratación, la Administración podrá aplicar cláusula penal o multas cuando se presenten incumplimientos imputables al contratista, conforme a lo establecido en la Ley General de Contratación Pública, su Reglamento, el presente pliego, el contrato, los acuerdos de nivel de servicio y el Anexo 1. Estudio para el cálculo de cláusula penal y multas.
• La cláusula penal procederá por ejecución tardía de las obligaciones contractuales, incluyendo atrasos imputables al adjudicatario en la implementación, configuración, integración, pruebas, capacitación, documentación, puesta en operación o entrada en funcionamiento de la Línea 1 o de las líneas complementarias adjudicadas.
• La multa procederá por ejecución defectuosa del contrato, cuando el servicio sea prestado de forma incompleta, deficiente, inestable, interrumpida, degradada o contraria a los requisitos técnicos, operativos, administrativos, de seguridad, continuidad, soporte, trazabilidad, disponibilidad o niveles de servicio definidos en el presente pliego.
• La aplicación de cláusula penal o multa requerirá que el incumplimiento se encuentre documentado mediante evidencia objetiva, tales como reportes de monitoreo, bitácoras técnicas, registros de incidentes, informes del contratista, registros institucionales, actas, pruebas técnicas, reportes de disponibilidad, reportes de grabación, registros de integración, reportes del centro de contactos o cualquier otro medio verificable.
• La base de cálculo para la aplicación de cláusula penal o multa será el precio mensual de la línea afectada, siempre que el incumplimiento se limite a una línea específica y no afecte el resto de las obligaciones contractuales.
• Cuando el incumplimiento afecte la operación de la Línea 1, comprometa la continuidad de la atención telefónica principal, afecte la recepción o distribución de llamadas de emergencia, impida la grabación o trazabilidad de comunicaciones, afecte la integración operativa con el Sistema de Gestión de Incidentes institucional o comprometa la seguridad del servicio, la base de cálculo será el precio mensual de la Línea 1.
• Cuando el incumplimiento de una línea complementaria afecte la continuidad, estabilidad, trazabilidad, seguridad, operación o desempeño de la Línea 1, la Administración podrá valorar el incumplimiento como afectación del servicio base, sin perjuicio de aplicar las sanciones que correspondan conforme al impacto real del evento.
• El cobro acumulado por concepto de cláusula penal o multas no podrá exceder el límite máximo permitido por la normativa aplicable. Para efectos de control contractual mensual, las sanciones aplicadas sobre una línea no podrán superar el veinticinco por ciento del precio mensual de la línea afectada, sin perjuicio del límite legal aplicable al precio del contrato, incluidas sus modificaciones.
• La aplicación de cláusula penal o multa no exime al contratista de la obligación de corregir el incumplimiento, restablecer el servicio, ejecutar acciones correctivas y preventivas, entregar informes, realizar configuraciones, repetir pruebas, brindar soporte, garantizar continuidad operativa y cumplir las demás obligaciones contractuales pendientes.
• El cobro de la cláusula penal o de las multas podrá hacerse con cargo a retenciones de pago, saldos pendientes de pago, deducciones aplicables a la facturación mensual o, en caso de que dichas alternativas no resulten suficientes o viables, mediante ejecución parcial o total de la garantía de cumplimiento, según corresponda.
• Cuando se presenten tres o más incumplimientos imputables al contratista en un período de noventa días calendario, sean estos continuos o alternos, la Administración podrá considerar la existencia de incumplimiento reiterado y requerir un plan de mejora obligatorio, sin perjuicio de aplicar las multas correspondientes o valorar la resolución contractual.
• Se considerarán incumplimientos críticos, entre otros, los siguientes:
  1. Atraso imputable al contratista en la puesta en operación efectiva de la Línea 1 al 1 de abril de 2027.
  2. Interrupción del servicio que afecte la recepción, distribución o atención de llamadas de emergencia.
  3. Pérdida de llamadas atribuible a la solución contratada.
  4. Indisponibilidad del ACD, IVR, control de llamadas, clientes de atención o componentes críticos de voz que afecte la operación institucional.
  5. Indisponibilidad, pérdida, alteración o imposibilidad de consulta de grabaciones o metadatos atribuible al contratista.
  6. Fallas de integración con el Sistema de Gestión de Incidentes institucional que impidan la correlación operativa de llamadas o interacciones.
  7. Incumplimiento de los porcentajes mínimos de disponibilidad establecidos en los acuerdos de nivel de servicio.
  8. Incumplimiento de los tiempos mínimos de atención de incidentes P1 o P2.
  9. Incumplimiento de obligaciones de seguridad, confidencialidad, control de accesos, auditoría o protección de información sensible.
  10. Incumplimiento de la continuidad operativa, redundancia, recuperación o mecanismos de operación ante fallas parciales.
• Para la ejecución tardía, se aplicará la cláusula penal conforme a los porcentajes, eventos, bases de cálculo y topes definidos en el Anexo 1. Estudio para el cálculo de cláusula penal y multas.
• Para la ejecución defectuosa, se aplicarán multas conforme a los incumplimientos tipificados, porcentajes, bases de cálculo y topes definidos en el Anexo 1. Estudio para el cálculo de cláusula penal y multas.
• La Administración podrá valorar la resolución contractual cuando el incumplimiento sea grave, comprometa la continuidad del servicio, afecte la atención de emergencias, supere los topes de sanción aplicables, se presente reiteración de incumplimientos o exista imposibilidad de obtener la correcta prestación del servicio contratado.
• Previo a la aplicación de una cláusula penal o multa, la Administración deberá contar con la documentación del incumplimiento y emitir el acto administrativo que corresponda, debidamente motivado y con indicación de la prueba que lo sustente, conforme al procedimiento previsto en la normativa aplicable. El Reglamento a la Ley General de Contratación Pública también dispone que la ejecución de multas y cláusulas penales requiere acto motivado con indicación de la prueba correspondiente.
• En caso de discrepancia entre los registros del contratista y la evidencia institucional, la Administración podrá solicitar aclaraciones, conciliación de registros, pruebas técnicas, informes complementarios o cualquier otra verificación razonable antes de resolver lo que corresponda.

2.12.          Reversibilidad, transferencia de información y cierre del servicio

• Toda información, dato, registro, grabación, archivo, metadato, bitácora, reporte, configuración, evidencia, respaldo o documento generado, recibido, almacenado, procesado o administrado como parte del servicio contratado será propiedad del Sistema de Emergencias 9-1-1.
• El adjudicatario deberá garantizar, durante toda la vigencia contractual y al finalizar el contrato, la transferencia completa, íntegra, segura, verificable y ordenada de la información institucional hacia los servicios, repositorios, medios, plataformas o ubicaciones que defina la Administración.
• La obligación de transferencia comprenderá, como mínimo:

1. Grabaciones de audio.
2. Grabaciones de video.
3. Metadatos asociados a llamadas, videollamadas, mensajes, SMS, chat e interacciones.
4. Registros de detalle de llamadas , CDR o equivalentes.
5. Registros de mensajería de texto, SMS, chat y videollamadas.
6. Bitácoras técnicas, operativas y de auditoría.
7. Reportes operativos, administrativos, estadísticos y de niveles de servicio.
8. Configuraciones autorizadas de colas, usuarios, perfiles, IVR, reglas, rutas, permisos e integraciones.
9. Respaldos de configuración, cuando correspondan.
10. Documentación técnica, manuales, procedimientos, diagramas y evidencias de operación.
11. Cualquier otra información necesaria para la continuidad, auditoría, consulta histórica, migración, reversibilidad o cierre del servicio.
    • Las grabaciones de audio y video deberán transferirse en formatos estándar, reproducibles y no dependientes de software propietario exclusivo, salvo que la Administración autorice expresamente un formato distinto por razones técnicas debidamente justificadas.
    • Los metadatos y datos de control deberán entregarse en formatos estructurados, documentados y utilizables por la Administración, tales como CSV, XLSX, JSON, XML, base de datos exportable u otro formato equivalente autorizado.
    • La transferencia deberá mantener la relación entre cada archivo y sus metadatos, de forma que sea posible identificar, buscar, reproducir, auditar y reconstruir cada comunicación o interacción conforme a sus datos de origen, fecha, hora, agente, cola, canal, identificador de sesión, registro operativo o cualquier otro identificador disponible.
    • El adjudicatario deberá implementar mecanismos de validación de integridad de la información transferida, incluyendo controles que permitan verificar que los archivos, grabaciones, metadatos y registros entregados corresponden a la información generada originalmente y que no presentan alteración, pérdida, duplicidad no controlada o inconsistencia.
    • La transferencia de información podrá realizarse de forma periódica, programada, bajo demanda, por evento, por lote o al cierre del contrato, conforme lo defina la Administración y sin afectar la operación normal del servicio.
    • La Administración y el adjudicatario deberán establecer un cronograma de traslado de información, el cual deberá contemplar, como mínimo, fases, fechas, responsables, volúmenes estimados, medios de transferencia, validaciones de integridad, pruebas de lectura, mecanismos de seguridad, criterios de aceptación y cierre de la transferencia.
    • El adjudicatario deberá recomendar técnicamente la forma más adecuada, segura, eficiente y verificable para realizar el traslado de la información, considerando el volumen de datos, criticidad de la información, continuidad operativa, seguridad, trazabilidad, integridad, disponibilidad de medios institucionales y requerimientos definidos por la Administración.
    • La recomendación técnica del adjudicatario deberá presentarse por escrito e incluir, como mínimo:
      1. Método propuesto de transferencia.
      2. Formatos de entrega de archivos, datos y metadatos.
      3. Requerimientos técnicos para la recepción institucional.
      4. Estimación de tiempos de traslado.
      5. Mecanismos de validación de integridad.
      6. Medidas de seguridad aplicables.
      7. Riesgos identificados y medidas de mitigación.
      8. Procedimiento de atención de errores, fallos o transferencias incompletas.
      9. Evidencias que se entregarán al finalizar cada etapa.
    • La recomendación técnica del adjudicatario no será vinculante para la Administración hasta tanto sea revisada y aprobada expresamente. La Administración podrá solicitar ajustes al método, cronograma, medios, controles o formatos propuestos, con el fin de garantizar la correcta recepción, conservación, consulta, auditoría y uso posterior de la información.
    • El adjudicatario deberá dejar evidencia verificable de cada proceso de transferencia, incluyendo como mínimo fecha y hora de inicio y finalización, cantidad de archivos o registros transferidos, volumen de información, transferencias exitosas, transferencias fallidas, detalle de errores, correcciones realizadas, responsable técnico, resultado de validación y aceptación institucional cuando corresponda.
    • Al finalizar el contrato, o cuando la Administración lo solicite, el adjudicatario deberá ejecutar un proceso de reversibilidad que garantice la entrega completa de la información institucional, configuraciones, documentación, respaldos, reportes, grabaciones, metadatos y demás elementos necesarios para asegurar la continuidad operativa, la migración a otra solución o la conservación institucional de la información.
    • El adjudicatario no podrá retener, condicionar, bloquear, limitar, cifrar de forma no autorizada, eliminar o impedir el acceso de la Administración a la información institucional generada, recibida, almacenada, procesada o administrada durante la prestación del servicio.
    • Las actividades de transferencia, reversibilidad, entrega de información, exportación de datos, entrega de grabaciones de audio, grabaciones de video, metadatos, reportes, bitácoras, configuraciones, respaldos y documentación asociada al servicio deberán estar incluidas dentro del precio mensual ofertado y no generarán costo adicional para la Administración.
    • El adjudicatario no podrá cobrar cargos adicionales por concepto de extracción, exportación, empaquetamiento, preparación, transferencia, entrega, carga, descarga, generación de respaldos, entrega de metadatos, acompañamiento técnico o cualquier otra actividad necesaria para trasladar la información institucional generada, procesada, almacenada o administrada durante la prestación del servicio.
    • La transferencia deberá realizarse sin afectar la continuidad operativa del servicio y sin limitar el acceso de la Administración a la información durante la vigencia contractual, el proceso de cierre, la transición hacia otra solución o la migración hacia servicios, repositorios o plataformas institucionales.
    • Una vez confirmada por la Administración la recepción completa y satisfactoria de la información, el adjudicatario deberá proceder, cuando corresponda, con la eliminación segura de copias bajo su custodia, dejando constancia documental del proceso realizado, salvo que exista obligación legal, contractual o autorización expresa de conservación temporal.
    • Las obligaciones de reversibilidad, transferencia, entrega de información, eliminación segura y cierre del servicio no eximen al adjudicatario del cumplimiento de sus obligaciones de confidencialidad, seguridad de la información, soporte, continuidad operativa, atención de incidentes y demás responsabilidades contractuales.

 

 

3.    Requisitos de participación y admisibilidad

3.1.  Condiciones generales de admisibilidad

• Los requisitos establecidos en el presente capítulo constituyen condiciones mínimas de admisibilidad técnica, operativa y documental para la valoración de las ofertas.
• La Administración verificará cada requisito bajo el criterio cumple / no cumple, con base en la evidencia documental, técnica o verificable aportada por el oferente.
• No se aceptarán declaraciones generales de cumplimiento que no estén respaldadas por evidencia verificable.
• Se tendrá por no acreditado el requisito cuando el oferente únicamente indique “cumple”, “se acepta” o expresiones similares, sin adjuntar respaldo documental, técnico o descriptivo suficiente.
• La falta de acreditación suficiente de un requisito de admisibilidad podrá generar la inadmisibilidad de la oferta o de la línea correspondiente, cuando impida verificar la capacidad mínima del oferente para prestar el servicio requerido.

3.2.  Respaldo tecnológico de la solución ofertada

• El oferente deberá acreditar que cuenta con autorización, respaldo técnico, relación comercial vigente o capacidad contractual suficiente respecto de las soluciones, plataformas, licencias, servicios, componentes o tecnologías que conforman su oferta.
• Para acreditar este requisito, el oferente deberá aportar certificación, carta, convenio, constancia o documento equivalente emitido por el fabricante, titular, proveedor, licenciante, distribuidor autorizado o entidad competente, según corresponda a la naturaleza de la solución ofertada.
• La Administración verificará que el documento aportado:
  1. Tenga fecha de emisión no mayor a doce meses respecto de la fecha de apertura de ofertas.
  2. Identifique al oferente o a la figura mediante la cual este cuenta con respaldo para ofertar.
  3. Identifique la solución, plataforma, servicio, componente, módulo o tecnología cubierta.
  4. Indique que el oferente cuenta con capacidad para comercializar, implementar, configurar, operar, soportar, mantener, actualizar o escalar la solución ofertada, según corresponda.
  5. Permita comprobar acceso a soporte especializado, licenciamiento, actualizaciones o escalamiento técnico.
  6. No condicione la prestación del servicio a autorizaciones futuras, acuerdos no formalizados o permisos no acreditados al momento de presentar la oferta.
• Criterio de admisibilidad: Cumple si la documentación permite verificar objetivamente el respaldo tecnológico requerido para la línea ofertada. No cumple si el respaldo no se acredita, está vencido, no cubre los componentes ofertados o queda condicionado a Gestiones futuras inciertas.
• Experiencia mínima del oferente para la Línea 1
  • Para la Línea 1, el oferente deberá acreditar al menos dos experiencias verificables en la implementación, operación, administración o soporte de servicios, plataformas o soluciones similares al objeto contractual.
  • Se entenderán como servicios o soluciones similares aquellas relacionadas con comunicaciones IP, telefonía IP, centros de contacto, contact center multicanal, ACD, IVR, grabación, monitoreo, reportería, soporte de servicios críticos u operaciones 24/7.
  • Las experiencias podrán corresponder a servicios o soluciones implementadas en Costa Rica o en el extranjero, siempre que sean verificables.
  • La Administración verificará que el oferente aporte al menos dos referencias, constancias o certificaciones que permitan comprobar:

1. Existencia real del servicio, plataforma o solución referida.
2. Año de implementación, puesta en producción o inicio de operación.
3. Alcance funcional implementado.
4. Participación del oferente en la implementación, operación, administración o soporte.
5. Similitud con la Línea 1.
6. Estado actual del servicio o solución, cuando corresponda.
7. Medio de contacto verificable de la entidad o cliente referido.

• Criterio de admisibilidad: Cumple si acredita al menos dos experiencias verificables y comparables con la Línea 1. No cumple si no presenta referencias suficientes, si estas no son verificables o si no guardan relación razonable con el servicio requerido.

3.3.  Experiencia mínima de la empresa

• El oferente deberá acreditar una trayectoria mínima de siete (7) años en la implementación, operación, administración, soporte o mantenimiento de servicios, plataformas o soluciones comparables con la Línea 1.
• Para efectos de este requisito, se considerarán soluciones comparables aquellas relacionadas con comunicaciones IP, telefonía IP, centros de contacto, contact center multicanal, ACD, IVR, grabación, monitoreo, reportería, soporte de servicios críticos u operaciones 24/7.
• La experiencia deberá acreditarse mediante referencias, constancias, certificaciones, contratos, órdenes de compra, actas de recepción, cartas de clientes o documentos equivalentes que permitan verificar objetivamente el periodo durante el cual el oferente ha brindado servicios o soluciones similares. Cada documento deberá indicar, como mínimo:
  1. Nombre de la entidad o cliente que recibió el servicio o solución.
  2. Nombre, cargo, teléfono y correo electrónico de una persona de contacto verificable.
  3. Año de implementación, puesta en producción o inicio de operación.
  4. Alcance funcional del servicio o solución.
  5. Componentes incluidos, cuando corresponda: ACD, IVR, grabación, centro de contactos, monitoreo, reportes, canales digitales, soporte, continuidad operativa u otros equivalentes.
  6. Similitud con la Línea 1.
  7. Estado actual del servicio o solución, cuando corresponda.
  8. Periodo durante el cual el oferente ha brindado servicios o soluciones similares.
• El Sistema de Emergencias 9-1-1 se reserva el derecho de contactar directamente a las entidades referenciadas para verificar la información aportada.
• Cumple si las referencias permiten verificar la experiencia declarada. No cumple si las referencias son incompletas, no verificables o no permiten establecer relación con el objeto contractual.

3.4.  Personal técnico mínimo

• El oferente deberá acreditar que cuenta con personal técnico mínimo suficiente para implementar, operar, soportar y mantener el servicio ofertado.
• Para la Línea 1, el oferente deberá aportar evidencia de contar con al menos dos personas con formación, certificación emitida por el fabricante de la solución ofrecida, experiencia o respaldo técnico verificable en áreas relacionadas con:
  1. Comunicaciones IP o telefonía IP.
  2. Centro de contactos, ACD o gestión de colas.
  3. IVR o respuesta automatizada.
  4. Grabación de llamadas o interacciones.
  5. Administración, monitoreo, seguridad, soporte o continuidad del servicio ofertado.
• Cumple si acredita que cuenta con al menos dos personas con formación, certificación, experiencia o respaldo técnico verificable en áreas relacionadas con la solución ofertada, conforme a lo establecido en el numeral 3.4.2. No cumple si no acredita el personal técnico mínimo requerido, si la documentación aportada es incompleta, no verificable o no permite establecer relación razonable con las áreas técnicas necesarias para implementar, operar, soportar o mantener el servicio ofertado.

3.5.  Capacidad mínima de soporte y coordinación efectiva en Costa Rica

• El oferente deberá acreditar capacidad mínima de soporte, coordinación técnica y atención de incidentes para la prestación del servicio, incluyendo mecanismos de atención local o coordinación efectiva en Costa Rica.
• Este requisito podrá cumplirse mediante personal propio, representación local, centro de soporte, socios técnicos, aliados especializados o mecanismos equivalentes.
• La Administración verificará que el oferente aporte documentación que permita comprobar:
  1. Existencia de un mecanismo de atención y coordinación en Costa Rica.
  2. Identificación del personal, representación, socio técnico, centro de soporte o aliado especializado, según corresponda.
  3. Canales de contacto para atención de requerimientos e incidentes.
  4. Capacidad de escalar incidentes críticos hacia niveles especializados de soporte.
  5. Relación entre el mecanismo de soporte propuesto y la operación del servicio ofertado.
• Cumple si el oferente demuestra capacidad real y verificable de coordinación y soporte efectivo para atender la operación crítica institucional. No cumple si no acredita ningún mecanismo de atención, soporte o coordinación local o equivalente.
• Este requisito no sustituye ni limita los niveles de servicio, tiempos de respuesta, tiempos de resolución, monitoreo, mantenimiento y demás obligaciones que se establezcan en los capítulos técnicos y contractuales del presente pliego.

3.6.  Verificación de requisitos de admisibilidad

• Todos los requisitos establecidos en este capítulo deberán acreditarse mediante evidencia documental, técnica o verificable.
• La Administración podrá solicitar aclaraciones, ampliaciones, verificaciones, demostraciones, referencias complementarias o documentación adicional, cuando resulte necesario para determinar el cumplimiento de los requisitos de admisibilidad, siempre que ello no implique modificar la oferta ni otorgar una ventaja indebida.
• La Administración podrá declarar inadmisible la oferta cuando el oferente no acredite, de forma suficiente y verificable, alguno de los requisitos mínimos establecidos en este capítulo, y dicha omisión impida comprobar su capacidad para implementar, operar, soportar, mantener o garantizar la continuidad del servicio requerido.

3.7.  Idioma y documentación requerida

• La solución deberá permitir operación integral, soporte técnico, interfaces, mensajes operativos y reportes en idioma español.
• La documentación mínima obligatoria para operación, administración, soporte, continuidad y procedimientos de respaldo/restauración deberá entregarse en idioma español.

 

 

4.    Componentes técnicos del servicio integral gestionado

4.1.  Componente base de comunicaciones IP y control de llamadas

• El componente base de comunicaciones IP y control de llamadas tiene por objeto gestionar, tramitar y controlar las comunicaciones de voz del Sistema de Emergencias 9-1-1 bajo un esquema de operación misión crítica, garantizando continuidad, trazabilidad, disponibilidad y capacidad de crecimiento, conforme a la arquitectura integral de la solución contratada.
• El alcance comprende, como mínimo:
  1. La provisión e implementación de la plataforma de central telefónica IP y sus componentes de control y señalización.
  2. La configuración de extensiones, rutas, plan de numeración, políticas de marcación y condiciones de enrutamiento requeridas por la institución.
  3. La habilitación de servicios base de telefonía, distribución de llamadas y facilidades de atención requeridas para la operación del 9-1-1.
  4. La integración con el Centro de Contactos/ACD y con los mecanismos de operación de agentes y supervisión, según lo definido en este módulo.
  5. La integración con la infraestructura institucional existente, incluyendo la red WAN privada y los enlaces SIP Trunk en operación, sin condicionar la operación institucional a sustituciones o cambios no autorizados.
  6. La integración con la Sistema de Gestión de Incidentes existente y los puntos de interoperabilidad requeridos (por ejemplo, identificación del registro de llamada, extensión, agente ACD, VDN u otros identificadores operativos que se definan), conforme a lo establecido en las secciones aplicables del pliego.
  7. La incorporación de mecanismos de administración, auditoría, monitoreo y reportes operativos propios de la telefonía IP.
• La institución dispone de enlaces SIP Trunk en operación para el ingreso y gestión de llamadas de emergencia, los cuales no forman parte del suministro del contratista, salvo que se indique expresamente lo contrario en el pliego; no obstante, será responsabilidad del contratista realizar las configuraciones e integraciones necesarias para la correcta interoperabilidad de la solución con dichos enlaces, bajo coordinación y autorización institucional.
• La central telefónica IP deberá administrar y controlar comunicaciones IP mediante protocolos estándar de la industria, asegurando interoperabilidad y evitando dependencias injustificadas de componentes propietarios cuando existan alternativas equivalentes soportadas por el fabricante.
• Los componentes que conforman la central telefónica IP deberán implementarse bajo un esquema de alta disponibilidad y redundancia en los elementos que resulten necesarios para garantizar la continuidad de las comunicaciones y eliminar puntos únicos de falla, manteniendo la estabilidad de las llamadas activas ante fallas parciales según la arquitectura ofertada.
• El contratista será responsable del dimensionamiento, licenciamiento y habilitación de la central telefónica IP conforme a la demanda operativa institucional, incluyendo crecimiento, picos de concurrencia y operación distribuida, sin que ello implique costos adicionales por omisiones de diseño o estimación atribuibles a la propuesta.
• La central telefónica IP deberá incluir, como mínimo, los siguientes componentes, ya sea de forma nativa o mediante componentes plenamente soportados por el fabricante, según aplique a la arquitectura ofertada:
  1. Servidores o instancias de control de llamadas y señalización (call control).
  2. Componentes de enrutamiento y gestión de numeración y marcación (dial plan).
  3. Componentes de distribución/gestión de colas y atención, cuando aplique a la solución ofertada (ACD/Contact Center).
  4. Consola(s) de administración y operación en ambiente web o equivalente, en idioma español.
  5. Herramientas o mecanismos de monitoreo, métricas, tarificación y reportes operativos.
  6. Componentes de integración e interoperabilidad con sistemas institucionales autorizados (incluyendo CAD), según lo definido en el pliego.
  7. Componentes de borde e interconexión requeridos para interoperar con SIP Trunk, redes institucionales y otros servicios de voz (por ejemplo, SBC/gateways o equivalentes), cuando aplique.
  8. Dispositivos telefónicos y clientes de atención tipo softphone requeridos para la operación institucional, incluyendo su aprovisionamiento y administración centralizada.
  9. Accesorios y periféricos asociados a los puestos de atención, cuando aplique según el diseño ofertado y las necesidades institucionales
  10. Mecanismos de auditoría y trazabilidad de acciones administrativas y eventos operativos relevantes.
• El contratista deberá entregar la documentación técnica y operativa mínima asociada a la central telefónica IP, incluyendo arquitectura implementada, inventario lógico de componentes, licenciamiento aplicado, criterios de dimensionamiento, dependencias, respaldos de configuración y procedimientos de operación.
• En los aspectos de IVR y sistema de grabación, la central telefónica IP deberá asegurar los puntos de interoperabilidad necesarios para su operación integral; dichos componentes se rigen por los requisitos específicos definidos en sus respectivos apartados.

4.2.  Capacidades funcionales de la central telefónica IP

• La central telefónica IP deberá proveer capacidades funcionales completas para gestionar, procesar, encaminar y controlar comunicaciones de voz en un entorno misión crítica, asegurando estabilidad, trazabilidad, consistencia operativa y continuidad de la atención en condiciones normales y de contingencia.
• La solución deberá permitir la gestión integral del ciclo de la llamada, incluyendo como mínimo: establecimiento, timbrado, contestación, transferencia, retención, reanudación, conferencia, finalización y registro de eventos asociados, manteniendo consistencia del registro de control de la llamada.
• La central telefónica IP deberá permitir la administración de extensiones y puntos de atención, garantizando como mínimo: creación, modificación, inactivación, reasignación, asociación a perfiles/grupos y control por roles autorizados, sin requerir cambios de programación.
• La solución deberá soportar la tramitación y gestión de llamadas entrantes, salientes e internas, y la aplicación de políticas de marcación, restricciones y permisos según perfil del usuario, grupo operativo, horarios u otros criterios institucionales definidos.
• La solución deberá permitir la gestión de llamadas entrantes, salientes e internas, asegurando consistencia del estado de la llamada a través de los componentes involucrados (teléfono IP, cliente de atención, consola y herramientas de supervisión cuando aplique).
• La solución deberá permitir la definición y administración de un plan de numeración institucional, incluyendo extensiones, rangos, prefijos, rutas y condiciones de enrutamiento, con mecanismos que eviten colisiones, duplicidades o asignaciones inconsistentes.
• La central telefónica IP deberá permitir configurar un plan de marcado centralizado a nivel institucional, aplicable de forma consistente a todos los puntos de atención definidos en la solución.
• La solución deberá soportar, cuando aplique por diseño, un esquema tipo multicompañía y la gestión de números directos (DID), permitiendo disponer de múltiples números de entrada y aplicar tratamiento diferenciado conforme a reglas institucionales.
• La solución deberá soportar la identificación del número marcado (DNIS) u otro mecanismo equivalente, de manera que el tratamiento de la llamada pueda basarse en el número de destino marcado, conforme a la configuración institucional.
• La solución deberá permitir la ejecución de reglas de tratamiento y encaminamiento basadas en condiciones configurables, incluyendo como mínimo: origen/destino, tipo de llamada, DNIS cuando aplique, horarios, días, estado de disponibilidad del destino, prioridades operativas y condiciones de contingencia.
• La solución deberá permitir la identificación y visualización de información de la llamada en el puesto de atención, incluyendo como mínimo: número de origen cuando esté disponible, número destino, extensión, cola/VDN u otro identificador operativo equivalente, y estado de la llamada, visualizable tanto en el teléfono IP como en el cliente de atención cuando aplique.
• La central telefónica IP deberá permitir funcionalidades de transferencia asistida y transferencia ciega, así como transferencia hacia extensiones, colas/ACD, grupos definidos o destinos autorizados, registrando los eventos asociados para trazabilidad.
• La solución deberá soportar conferencias telefónicas bajo control de perfiles autorizados, con capacidad para adicionar y retirar participantes y registrar los eventos asociados.
• La central telefónica IP deberá permitir la configuración de música en espera y mensajes o tonos institucionales, con capacidad de aplicación por cola, destino o condición, cuando aplique a la arquitectura ofertada.
• La solución deberá permitir la administración de grupos de timbrado o grupos operativos equivalentes, incluyendo políticas de distribución (simultáneo, secuencial, circular u otras disponibles) y condiciones de escalamiento, cuando aplique.
• La central telefónica IP deberá permitir la parametrización de tiempos y umbrales operativos asociados a la llamada, incluyendo como mínimo: tiempo máximo de timbrado, tiempo máximo en espera, tiempos de presentación de llamada y condiciones de desbordamiento (overflow) y redirección de la llamada a destinos alternos definidos por la institución.
• La solución deberá permitir definir un intervalo parametrizable, expresado en segundos, entre llamadas asignadas a un agente, cuando aplique según el diseño del centro de contactos, con el fin de controlar el ritmo de asignación y la estabilidad operativa.
• La solución deberá permitir, cuando aplique, la asignación forzosa de llamadas hacia un agente o hacia un grupo definido, conforme a reglas operativas autorizadas, manteniendo registro del evento para control y auditoría.
• La solución deberá permitir establecer políticas de desvío y redirección de la llamada controlada (por ejemplo: por no respuesta, ocupado, fuera de servicio u otros estados), conforme a perfiles autorizados y reglas institucionales, evitando desvíos no autorizados hacia destinos externos no permitidos.
• La solución deberá permitir configurar y habilitar la función de llamada en espera (call waiting) para las extensiones o perfiles que determine la institución.
• La solución deberá permitir la funcionalidad de toma de llamada por terceros (call pick-up) o equivalente, de manera que una llamada entrante en una extensión pueda ser atendida desde otra extensión autorizada, conforme a permisos definidos.
• La central telefónica IP deberá permitir la gestión de estados de usuarios y puntos de atención, incluyendo como mínimo estados de disponibilidad y no disponibilidad, conforme al esquema operativo definido por la institución y de manera consistente con el centro de contactos cuando aplique.
• La central telefónica IP deberá soportar la configuración de códigos de estado y códigos de inactividad para agentes, conforme a la operación institucional, incluyendo su registro para fines de supervisión y explotación estadística.
• La solución deberá permitir indicadores operativos básicos relacionados con el tráfico de llamadas, como mínimo: llamadas entrantes, contestadas, abandonadas, transferidas, en espera, tiempos de atención y tiempos de espera, conforme al alcance del centro de contactos cuando aplique.
• La solución deberá permitir la reproducción de un mensaje de bienvenida personalizado por agente, previamente grabado, y deberá permitir al agente ejecutarlo de forma manual durante una llamada en curso, cuando aplique al diseño del centro de contactos.
• La central telefónica IP deberá permitir la asociación lógica de la llamada con identificadores operativos relevantes para fines de trazabilidad e interoperabilidad, incluyendo como mínimo: extensión, agente, cola/ACD, VDN u otros identificadores equivalentes definidos por la institución.
• La solución deberá registrar eventos operativos relevantes asociados al tratamiento de llamadas, incluyendo como mínimo: inicio y fin de llamada, cambios de estado, transferencia, retención, reanudación, conferencia, asignación a cola/agente, desbordamientos, redirecciones de la llamada y eventos de contingencia, con marcas de tiempo y datos mínimos de identificación del usuario y estación de trabajo cuando aplique, para fines de auditoría y control institucional.
• La central telefónica IP deberá disponer de mecanismos para operar en condiciones de contingencia, permitiendo la redirección de la llamada hacia destinos alternos definidos por la institución, sin bloquear el servicio y sin degradar la continuidad de la atención más allá de lo técnicamente inevitable por la falla presentada.
• La solución deberá permitir que parámetros funcionales críticos puedan ser administrados por la institución desde la consola autorizada, incluyendo como mínimo: asignación de extensiones, grupos, rutas, restricciones de marcación, parámetros de timbrado, intervalos operativos y destinos alternos, sin requerir intervención del fabricante para cambios rutinarios posteriores a la puesta en operación.
• La solución deberá permitir la interoperabilidad funcional con el Sistema de Gestión de Incidentes y demás componentes institucionales autorizados, de manera que, al momento de recibirse una llamada en el cliente de atención, se disponga de los identificadores mínimos necesarios para la correlación operativa, incluyendo como mínimo: número de origen, identificador de llamada generado por la central, extensión, identificador y nombre del agente, y VDN u otro identificador equivalente, conforme a lo establecido en la sección correspondiente del presente módulo.
• La solución deberá permitir capacidades de atención automatizada tipo auto attendant cuando aplique por diseño; cuando dichas capacidades correspondan al componente de respuesta interactiva de voz, regirán los requisitos específicos definidos en la sección correspondiente del presente pliego, evitando duplicidad de alcance dentro de este apartado.
• La central telefónica IP deberá operar de forma armónica con el componente de respuesta interactiva de voz y con el sistema de grabación de llamadas definidos en sus secciones correspondientes, asegurando los puntos de interoperabilidad necesarios para su funcionamiento integral, sin afectar la continuidad y estabilidad de la atención telefónica.

 

4.3.  Arquitectura y modelo de despliegue (lógico y físico) de la plataforma de telefonía

• El contratista deberá diseñar, suministrar, implementar y dejar en operación una arquitectura acorde con la naturaleza misión crítica del Sistema de Emergencias 9-1-1, asegurando continuidad operativa, escalabilidad, administración centralizada e interoperabilidad con los demás componentes de la solución integral.
• La arquitectura deberá contemplar, como mínimo, una separación clara entre:
  1. Componentes de control y señalización de llamadas.
  2. Componentes de distribución y atención (centro de contactos/ACD), cuando aplique.
  3. Componentes de administración, monitoreo, auditoría y reportes.
  4. Componentes de integración e interoperabilidad con sistemas institucionales autorizados.
  5. Componentes de borde e interconexión con troncales SIP, redes institucionales y servicios externos autorizados.
  6. Componentes requeridos para operación de usuarios finales (clientes de atención), cuando aplique.
• El contratista deberá definir y documentar el modelo de despliegue lógico, indicando al menos: servicios, roles, dependencias entre componentes, interfaces de comunicación, protocolos utilizados, puertos requeridos y flujos principales de interacción (señalización, medios, administración, monitoreo, auditoría e integraciones).
• El contratista deberá definir y documentar el modelo de despliegue físico, indicando al menos: ubicación de cada componente (sitio principal y, cuando aplique, sitio alterno o de contingencia), distribución por servidores/instancias, clústeres o nodos, y su relación con la infraestructura de red institucional.
• La arquitectura de la plataforma de telefonía deberá implementarse en modalidad de alta disponibilidad activo-activo, manteniendo infraestructura tecnológica duplicada como mínimo en el sitio principal del Sistema de Emergencias 9-1-1 y en el Data Center contratado por el 9-1-1 que defina la Administración. Los componentes tecnológicos, licencias, configuraciones, conectividad, seguridad, cómputo, almacenamiento, virtualización, respaldo, monitoreo y demás elementos requeridos para operar en dichos entornos deberán ser provistos por el contratista, de manera que ambos entornos puedan operar simultáneamente para sostener la continuidad del servicio.
• El contratista deberá definir y documentar la distribución de componentes y servicios por entorno, indicando cuáles operan en el sitio principal del 9-1-1 y cuáles operan en el Data Center contratado por el 9-1-1, ubicado en el ICE Centro de Datos, Guatuso, El Guarco, Cartago; así como las dependencias, sincronizaciones, mecanismos de continuidad y responsabilidades de soporte necesarias para asegurar operación estable sin pérdida de trazabilidad.
• La arquitectura deberá eliminar puntos únicos de falla en los componentes críticos mediante redundancia o mecanismos equivalentes, incluyendo como mínimo los elementos de control de llamadas y aquellos indispensables para sostener la atención telefónica, conforme a la solución ofertada.
• La arquitectura deberá definir con precisión el comportamiento ante fallas parciales, incluyendo como mínimo: pérdida de un nodo, pérdida de un enlace interno relevante, pérdida de un componente de borde, pérdida de conectividad con el Data Center contratado por el 9-1-1 y pérdida de un componente de administración, indicando el impacto esperado, el mecanismo de recuperación y el comportamiento de los servicios esenciales durante el evento.
• La solución deberá ser escalable, permitiendo crecimiento por aumento de demanda sin rediseños estructurales, mediante ampliación controlada de recursos (por ejemplo: adición de nodos, licencias, instancias o recursos de cómputo), según la arquitectura ofertada.
• El contratista deberá describir el modelo de continuidad operativa aplicable a la plataforma de telefonía, incluyendo la forma en que se mantiene la estabilidad operativa ante fallas parciales, la forma en que se recupera el servicio y los criterios operativos para retorno a condición normal.
• La conectividad entre el sitio principal del 9-1-1 y el Data Center contratado por el 9-1-1,; deberá ser suministrada por el contratista, mediante un enlace principal con capacidad mínima de 100 Mbps y un enlace redundante de capacidad equivalente o superior, entregados en los puntos de demarcación definidos por la Administración.
• La conectividad entre el sitio principal del Sistema de Emergencias 9-1-1 y la infraestructura en el Data Center contratado por el 9-1-1 suministrada por el contratista deberá ser provista integralmente por el adjudicatario, mediante un enlace principal con capacidad mínima de 100 Mbps y un enlace redundante con capacidad equivalente o superior, ambos debidamente configurados y entregados sobre los equipos WAN institucionales definidos por la Administración.
• La solución deberá garantizar alta disponibilidad, estabilidad, continuidad operativa, redundancia y desempeño adecuado para la operación de los servicios de telefonía y centro de contactos, minimizando riesgos de interrupción o degradación del servicio.
• La plataforma tecnológica ofertada deberá corresponder a una infraestructura de uso exclusivo y dedicado para el Sistema de Emergencias 9-1-1, por lo que no se permitirá el uso de ambientes compartidos, multicliente (multi-tenant) o infraestructura utilizada simultáneamente para otros clientes del contratista.Lo anterior con el propósito de garantizar mayores niveles de seguridad, aislamiento lógico y operativo, desempeño, control de la plataforma, continuidad del servicio y protección de la operación crítica institucional.
• La arquitectura deberá operar sobre la red privada institucional existente para interconexión con sitios remotos y puestos de atención. Si el oferente determina que su arquitectura requiere mayor capacidad o ajustes técnicos (por ejemplo, para estabilidad, desempeño o continuidad), deberá declararlo expresamente en su propuesta técnica, detallando requerimientos y justificación; no será admisible alegar posteriormente limitaciones de ancho de banda o conectividad no advertidas en la oferta.
• El contratista deberá documentar los supuestos de diseño relacionados con consumo de ancho de banda, concurrencia, cantidad de usuarios y condiciones de operación, de manera que la institución pueda verificar el criterio aplicado y su correspondencia con la capacidad ofrecida.
• La infraestructura en el Data Center contratado por el 9-1-1 incorporada a la plataforma de telefonía deberá estar físicamente ubicada en territorio nacional. El contratista deberá declarar y acreditar la ubicación del centro de datos y garantizar que los datos operativos, registros técnicos y bitácoras asociadas a la plataforma no sean almacenados, procesados o replicados fuera del territorio nacional, salvo autorización institucional expresa.
• La arquitectura deberá contemplar ambientes y componentes requeridos para operación, pruebas y soporte según lo defina la institución durante la implementación, indicando criterios mínimos de segregación, control de cambios y trazabilidad entre ambientes.
• El contratista deberá definir y documentar la segmentación de red requerida para la solución, incluyendo como mínimo: zonas o segmentos para componentes críticos, administración, integraciones y borde, así como los requisitos de conectividad entre segmentos, con el fin de facilitar la operación segura y el control institucional.
• La arquitectura deberá incluir mecanismos de sincronización de tiempo para todos los componentes, garantizando coherencia de marcas de tiempo en bitácoras, auditorías, eventos y reportes.
• La arquitectura deberá contemplar los requerimientos de resolución de nombres, certificados y servicios de infraestructura necesarios para operación segura (por ejemplo: DNS, directorio institucional, certificados digitales u otros equivalentes), indicando responsabilidades del contratista y de la institución para su puesta en marcha.
• El contratista deberá asegurar que el diseño propuesto sea consistente con la operación existente y con las restricciones institucionales de infraestructura, sin asumir dependencias no disponibles ni requerir componentes externos no contemplados como parte integral de la solución.
• El contratista deberá identificar explícitamente todos los componentes de software, firmware y licenciamiento necesarios para el funcionamiento de la arquitectura, indicando su rol dentro de la solución, su modalidad de licenciamiento y su relación con la capacidad ofrecida.
• El contratista deberá definir el modelo de virtualización o despliegue físico de cada componente, según aplique, indicando requisitos mínimos de recursos (CPU, memoria, almacenamiento, red) por rol, así como supuestos de rendimiento utilizados para el diseño.
• El contratista deberá definir, documentar y entregar el esquema de respaldo y recuperación de configuraciones críticas de la plataforma de telefonía (por ejemplo: parámetros de control de llamadas, plan de numeración, rutas, colas, perfiles, reglas operativas y configuraciones de borde), incluyendo como mínimo: periodicidad, almacenamiento, retención, responsables, evidencias y procedimiento de restauración.
• La arquitectura deberá proveerse bajo una estructura modular verificable que permita identificar, configurar, integrar, probar y aceptar la plataforma de telefonía de forma controlada, con límites bien definidos entre capacidades, de modo que sea posible demostrar cumplimiento mediante pruebas y evidencias de configuración.
• La arquitectura deberá incorporar interfaces documentadas para intercambio de información con sistemas institucionales autorizados, y deberá registrar transacciones o eventos relevantes de interoperabilidad (fecha/hora, origen/destino, tipo de operación, resultado y componente ejecutor), garantizando trazabilidad y auditoría.
• El contratista deberá entregar un diagrama completo de la solución de telefonía IP, el cual deberá incluir como mínimo:
  1. Todos los componentes de la plataforma (lógicos y físicos), incluyendo redundancias y su relación entre entornos.
  2. Relación y conectividad entre componentes, indicando identificadores lógicos, zonas o segmentos, enlaces relevantes y dependencias técnicas.
  3. Puntos de integración con sistemas institucionales autorizados y con los componentes definidos en las secciones correspondientes del pliego.
  4. Componentes de borde e interconexión con troncales SIP y redes institucionales.
  5. Componentes de administración, monitoreo, auditoría y reportes, incluyendo su relación con la operación 24/7.
  6. Componentes o mecanismos de continuidad operativa, incluyendo el comportamiento ante fallas parciales y el uso de enlaces principal y redundante hacia el Data Center contratado por el 9-1-1.
• El diagrama deberá ser acompañado obligatoriamente por un documento descriptivo, elaborado por el contratista, que explique la función de cada elemento representado y describa, como mínimo:
  1. Rol del componente y su responsabilidad dentro del flujo de operación.
  2. Dependencias técnicas y servicios requeridos para su funcionamiento.
  3. Interfaces de comunicación relevantes (protocolos y propósito funcional).
  4. Consideraciones de continuidad operativa asociadas al componente.
  5. Consideraciones de seguridad y administración asociadas al componente.
  6. Supuestos de diseño aplicados y restricciones relevantes, cuando corresponda.
• El diagrama y el documento descriptivo deberán formar parte de los entregables oficiales de implementación y deberán mantenerse actualizados conforme a la configuración finalmente instalada y aceptada por la institución, incluyendo cualquier ajuste realizado durante pruebas y puesta en operación.
• La institución podrá solicitar ajustes a la representación del diagrama o al nivel de detalle del documento descriptivo, con el fin de asegurar trazabilidad, claridad y verificabilidad del diseño implementado, sin que ello implique costos adicionales cuando se trate de correcciones por omisiones atribuibles a la propuesta o a la implementación.

4.4.  Conectividad de voz y enrutamiento (troncales, rutas, plan de numeración y reglas de marcación)

• La solución deberá proveer los mecanismos de conectividad de voz necesarios para la recepción y gestión de llamadas de emergencia, así como para las comunicaciones internas y salientes autorizadas, asegurando operación continua 24/7/365 y consistencia con el modelo de atención institucional.
• La plataforma de telefonía deberá integrarse con las troncales SIP (SIP Trunk) utilizadas por la institución para la atención de llamadas, así como con los esquemas de interconexión que la institución defina durante la implementación, garantizando interoperabilidad sin dependencia de desarrollos no contemplados como parte integral de la solución.
• El contratista deberá ejecutar las configuraciones y ajustes requeridos para integrar la solución con el proveedor o proveedores de conectividad de voz que la institución indique, utilizando la documentación técnica y parámetros que se suministren para tal fin, sin trasladar a la institución responsabilidades técnicas propias de la configuración de la plataforma ofertada.
• La solución deberá operar bajo el esquema institucional de atención centralizada definido, incluyendo la distribución de llamadas mediante balanceo de carga sobre las troncales SIP existentes, garantizando tratamiento consistente, estabilidad operativa y continuidad de la atención ante variaciones de demanda.
• Los enlaces SIP Trunk utilizados por la institución se consideran existentes y operativos. La solución no deberá depender de modificaciones sobre dichos enlaces como condición para su funcionamiento; cualquier ajuste requerido deberá ser mínimo, técnicamente justificado, coordinado y autorizado por la institución, sin que ello implique interrupción de la atención.
• La solución no deberá requerir la implementación de enrutamiento geográfico entre múltiples centros como condición mínima de operación; no obstante, el diseño deberá evitar limitaciones que impidan una evolución futura si la institución lo definiera.
• La solución deberá soportar la capacidad de sesiones SIP concurrentes que la institución disponga para el establecimiento de llamadas entrantes y salientes asociadas a la operación 9-1-1, asegurando estabilidad bajo picos de demanda conforme al dimensionamiento requerido.
• La arquitectura de borde e interconexión de voz deberá permitir la terminación, control y protección del tráfico de señalización y de medios, incluyendo mecanismos de compatibilidad e interoperabilidad con redes IP institucionales y con las troncales SIP, conforme al diseño ofertado.
• La solución deberá operar sobre la red privada institucional existente para la interconexión entre el sitio principal y los sitios remotos. El contratista deberá considerar las capacidades referenciales de enlaces disponibles en sitios remotos (enlaces primarios y de redundancia definidos por la institución) y asegurar que el diseño propuesto sea viable bajo dichas condiciones.
• La ampliación, sustitución o contratación de enlaces de datos WAN institucionales no forma parte del alcance de este módulo, salvo que el pliego disponga expresamente lo contrario. Si el oferente estima que se requiere capacidad adicional para cumplir el desempeño ofrecido, deberá declararlo de forma explícita en su propuesta técnica, indicando el requerimiento y su justificación, sin condicionar la operación institucional a cambios no autorizados.
• La provisión o contratación de troncales SIP externas adicionales no forma parte del alcance, salvo que se indique expresamente lo contrario en el pliego; no obstante, será responsabilidad del contratista asegurar que la plataforma opere correctamente con las troncales SIP existentes y con las condiciones de interconexión autorizadas.
• La solución deberá permitir la definición y administración de un plan de numeración institucional, incluyendo como mínimo: extensiones, rangos, prefijos, alias cuando aplique, y su relación con perfiles, grupos y ubicaciones operativas.
• La solución deberá permitir la configuración de un plan de marcado centralizado para toda la organización, aplicable de forma consistente a todos los puestos y extensiones, incluyendo reglas de validación que eviten conflictos, duplicidades o asignaciones inconsistentes.
• La plataforma deberá permitir la definición y administración de rutas de entrada y salida, incluyendo como mínimo:
  1. Rutas de entrada asociadas a números directos, troncales o dominios SIP definidos.
  2. Rutas de salida asociadas a prefijos, rangos o reglas institucionales.
  3. Rutas internas para numeración corta y extensiones.
  4. Rutas de contingencia para continuidad operativa ante fallas parciales.
• La solución deberá soportar, cuando aplique por diseño, un esquema tipo multicompañía y la gestión de números directos (DID), permitiendo disponer de múltiples números de entrada y aplicar tratamiento diferenciado conforme a reglas operativas definidas.
• La solución deberá soportar la identificación del número marcado (DNIS) o mecanismo equivalente, permitiendo que las reglas de tratamiento y encaminamiento se basen en el número destino marcado y sus variantes definidas por la institución.
• La solución deberá permitir identificar y visualizar el número telefónico entrante, cuando esté disponible, y deberá mantener consistencia de esta información a través de los componentes involucrados en la atención (por ejemplo: cliente de atención del agente, consola y componentes de supervisión), conforme a los permisos definidos.
• La solución deberá permitir la definición de reglas de tratamiento y distribución basadas en criterios configurables, incluyendo como mínimo:
  1. Número de origen (cuando esté disponible).
  2. Número marcado (DNIS) o equivalentes.
  3. Trunk, ruta o dominio SIP de ingreso.
  4. Horarios, días y calendarios operativos.
  5. Estado de disponibilidad del destino o del grupo de destino.
  6. Prioridad operativa definida por la institución.
  7. Condiciones de contingencia y destinos alternos.
• La solución deberá permitir parametrizar tiempos de timbrado, tiempos máximos de espera, tiempos de presentación al agente cuando aplique, y reglas de desbordamiento hacia destinos alternos, garantizando que dichas reglas puedan ser administradas por perfiles autorizados sin cambios de programación.
• La solución deberá permitir políticas de desvío y redirección de la llamada controladas (por ejemplo: por no respuesta, ocupado, fuera de servicio u otros estados), conforme a reglas institucionales y perfiles autorizados, evitando redirecciones no autorizadas a destinos externos.
• La solución deberá permitir la definición de destinos alternos de continuidad (por ejemplo: colas, grupos, extensiones, destinos institucionales autorizados u otros equivalentes), con activación por reglas automáticas y/o activación controlada por perfiles autorizados, dejando registro auditable del evento.
• La solución deberá permitir aplicar restricciones de marcación por perfil, rol, grupo operativo, ubicación lógica o condición horaria, incluyendo como mínimo:
  1. Restricción de llamadas salientes hacia destinos no autorizados.
  2. Restricción por prefijos o rangos.
  3. Permisos especiales por rol (por ejemplo: supervisión/administración).
  4. Reglas diferenciadas para comunicaciones internas y externas.
• La solución deberá permitir la administración de reglas de marcación que incluyan normalización o transformación de números cuando aplique (por ejemplo, agregar o quitar prefijos o ajustar formato), manteniendo trazabilidad entre el número original y el número finalmente procesado para efectos de auditoría y control.
• La solución deberá permitir la administración de grupos de timbrado y/o destinos grupales equivalentes, con estrategias de distribución configurables, y con reglas de escalamiento o redirección cuando no exista atención disponible, conforme a la operación institucional.
• La solución deberá soportar la coexistencia de múltiples números de ingreso y múltiples destinos internos, garantizando consistencia del tratamiento para cada número directo y evitando configuraciones ambiguas que generen enrutamientos indeterminados.
• La plataforma deberá registrar eventos relevantes del enrutamiento y tratamiento de llamadas, incluyendo como mínimo: ruta de ingreso, número marcado cuando aplique, destino aplicado, redirecciones ejecutadas, desbordamientos y activaciones de contingencia, con marcas de tiempo y datos mínimos para trazabilidad institucional.
• El contratista deberá documentar y entregar a la institución la configuración de conectividad y enrutamiento implementada, incluyendo como mínimo:
  1. Inventario de troncales y rutas configuradas.
  2. Plan de numeración y plan de marcado vigente.
  3. Reglas de tratamiento y distribución asociadas a DID/DNIS cuando aplique.
  4. Restricciones de marcación por perfiles.
  5. Destinos alternos y reglas de continuidad.
  6. Procedimiento controlado para cambios operativos y su validación.
• Cualquier ajuste requerido por la institución sobre rutas, numeración o reglas de marcación durante la implementación y puesta en operación deberá ser atendido por el contratista como parte de la puesta en marcha, garantizando pruebas, evidencias y control de cambios, sin introducir dependencias no previstas ni ambigüedades operativas.

4.5.  Servicios base de telefonía y gestión de llamadas

• La central telefónica IP deberá proveer los servicios base requeridos para la operación institucional, permitiendo gestionar la atención de llamadas de forma estable, controlada y trazable, bajo condiciones de servicio misión crítica.
• El sistema de telefonía IP deberá permitir la gestión de llamadas entrantes, salientes e internas, asegurando consistencia del estado de la llamada a través de los componentes involucrados (teléfono IP, cliente de atención, consola y herramientas de supervisión cuando aplique).
• El componente de telefonía deberá permitir a los perfiles autorizados realizar, como mínimo, las siguientes acciones sobre una llamada activa: atender, finalizar, retener, reanudar, transferir, iniciar conferencia y registrar eventos asociados.
• La plataforma de telefonía deberá permitir retención de llamada (hold) con indicación visible en el puesto de atención y con capacidad de aplicar música en espera o tono institucional conforme a configuración autorizada.
• El sistema deberá permitir la transferencia asistida y la transferencia ciega hacia extensiones internas, grupos y destinos autorizados, manteniendo trazabilidad de la llamada y registrando el evento de transferencia.
• La central telefónica IP deberá permitir la creación y administración de conferencias telefónicas con participación de múltiples usuarios, bajo control de perfiles autorizados, manteniendo registro de eventos relevantes.
• El sistema de telefonía IP deberá permitir la funcionalidad de llamada en espera (call waiting) para los perfiles definidos por la institución, incluyendo parámetros de comportamiento cuando exista más de una llamada simultánea.
• La plataforma de telefonía deberá permitir la toma de llamada por terceros (call pick-up) o equivalente, conforme a permisos definidos, de manera que una llamada entrante en una extensión autorizada pueda ser atendida desde otra extensión autorizada.
• El componente de telefonía deberá permitir la funcionalidad de parqueo de llamadas (call park) o equivalente cuando aplique, para retener temporalmente una llamada y recuperarla desde otra extensión autorizada, manteniendo registro del evento.
• El sistema deberá permitir la funcionalidad de captura automática de llamada (auto answer) cuando aplique, únicamente para perfiles autorizados y bajo condiciones operativas definidas por la institución.
• La central telefónica IP deberá permitir la habilitación de “No molestar” (DND) o equivalente, controlada por permisos y conforme a políticas institucionales, evitando que esta función impida el tratamiento de llamadas críticas cuando así se defina.
• El sistema de telefonía IP deberá permitir desvíos controlados de llamadas (por no respuesta, ocupado, fuera de servicio u otros estados), conforme a perfiles autorizados y reglas institucionales, sin permitir desvíos no autorizados hacia destinos externos.
• La plataforma de telefonía deberá permitir definir y aplicar destinos alternos para continuidad operativa, de forma automática o mediante activación manual controlada por perfiles autorizados, manteniendo registro auditable de la activación y reversión de la condición operativa.
• El componente de telefonía deberá permitir la definición de grupos de timbrado o grupos operativos equivalentes para atención de llamadas, con políticas de distribución configurables (simultáneo, secuencial, circular u otras) y con reglas de escalamiento definidas por la institución.
• El sistema deberá permitir la creación y administración de listas de destinos autorizados para transferencia o marcación rápida, conforme a perfiles, grupos y reglas institucionales.
• La central telefónica IP deberá permitir la administración de un directorio institucional de extensiones, con capacidad de búsqueda por criterios básicos (por ejemplo: nombre, extensión, unidad o equivalente), conforme a permisos.
• El sistema de telefonía IP deberá permitir la marcación abreviada o marcación rápida (speed dial) bajo control institucional, incluyendo su asignación por usuario, por grupo o por perfil.
• La plataforma de telefonía deberá permitir la visualización de la identificación del llamante (cuando esté disponible) y la identificación del número marcado (cuando aplique), en el puesto de atención, en el teléfono IP y/o en el cliente de atención, manteniendo consistencia de la información entre componentes.
• El componente de telefonía deberá permitir la visualización del estado de la llamada en tiempo real, como mínimo: timbrando, contestada, en espera, en transferencia, en conferencia y finalizada.
• El sistema deberá permitir la gestión de múltiples llamadas por un mismo usuario conforme a permisos y a la capacidad del perfil operativo, manteniendo un comportamiento consistente y predecible para selección de llamada activa, retención, conmutación y finalización.
• La central telefónica IP deberá permitir registrar y consultar el historial básico de llamadas por extensión y/o usuario, incluyendo como mínimo: fecha/hora, número origen (cuando esté disponible), número destino, duración y tipo de llamada (entrante/saliente/interna), conforme a permisos.
• La plataforma de telefonía deberá permitir la generación de registros de detalle de llamadas (CDR) o equivalente, de forma que la institución disponga de evidencia para análisis, control y tarificación, según lo definido para reportes operativos.
• El sistema de telefonía IP deberá permitir aplicar restricciones de marcación y permisos funcionales a nivel de usuario/perfil, garantizando que los servicios base (por ejemplo: conferencia, transferencia, marcación externa) sean habilitados o restringidos según política institucional.
• El componente de telefonía deberá permitir que parámetros operativos asociados a los servicios base puedan ser configurados por perfiles autorizados, incluyendo como mínimo: tiempos de timbrado, comportamientos de no respuesta, música en espera, políticas de transferencia y límites de conferencia cuando aplique.
• La central telefónica IP deberá permitir la configuración y administración de atención automatizada tipo auto attendant cuando aplique por diseño; cuando esta capacidad sea provista por el componente de respuesta interactiva de voz, regirá lo establecido en la sección correspondiente del pliego, evitando duplicidad de alcance en este apartado.
• El sistema deberá permitir la administración de buzón de voz (voice mail) o mecanismo equivalente cuando aplique, bajo control institucional, con reglas de habilitación por perfil y sin afectar el tratamiento de llamadas críticas cuando así se defina.
• En caso de habilitar buzón de voz, la plataforma de telefonía deberá permitir su administración centralizada, incluyendo como mínimo: habilitar/deshabilitar, límites de almacenamiento por buzón, notificaciones y políticas de retención, conforme a permisos.
• El componente de telefonía deberá permitir, cuando aplique, la grabación controlada de mensajes institucionales (por ejemplo: mensajes de bienvenida por agente) y su reproducción manual durante una llamada activa, conforme a permisos y bajo trazabilidad operativa.
• El sistema de telefonía IP deberá permitir la definición de tonos y anuncios institucionales asociados a estados de llamada, cuando aplique, incluyendo música en espera y mensajes informativos en espera, conforme a configuración autorizada.
• La central telefónica IP deberá permitir configurar políticas de devolución de llamada o retomar llamada (cuando aplique) sin afectar la integridad del registro de control del evento, manteniendo trazabilidad del flujo de atención.
• La plataforma de telefonía deberá permitir el manejo controlado de llamadas abandonadas o no atendidas, incluyendo registro del evento y capacidad de reportarlo, conforme a la explotación estadística definida para la operación.
• El sistema deberá permitir la parametrización de condiciones de “ocupado” y estados de “no disponible” por usuario o extensión, conforme al comportamiento esperado por la institución para los servicios base.
• El componente de telefonía deberá permitir habilitar servicios diferenciados por tipo de punto de atención (por ejemplo: posición operativa, supervisión, administración u otros), manteniendo un control consistente de capacidades y restricciones por perfil.
• El sistema de telefonía IP deberá integrarse con los mecanismos de monitoreo, auditoría y reportes, asegurando que los eventos relevantes de llamada queden disponibles para trazabilidad institucional.
• La central telefónica IP deberá registrar los eventos relevantes asociados a los servicios base, incluyendo como mínimo: inicio y fin de llamada, retención y reanudación, transferencias, conferencias, parqueo y recuperación cuando aplique, desvíos y redirecciones, con marca de tiempo y datos mínimos de identificación del usuario y estación de trabajo cuando aplique.
• La plataforma de telefonía deberá permitir la operación simultánea de los servicios base para múltiples usuarios, sin degradación perceptible atribuible al sistema en escenarios de alta demanda, conforme al dimensionamiento requerido.
• El sistema de telefonía IP deberá mantener coherencia operativa con el sistema de grabación de llamadas definido en la sección correspondiente del pliego, asegurando que el flujo real de la llamada (transferencias, conferencias, retenciones y reanudaciones) sea reflejado en los metadatos y eventos necesarios para trazabilidad.
• La central telefónica IP deberá mantener coherencia operativa con el componente de respuesta interactiva de voz definido en la sección correspondiente del pliego, asegurando que el tratamiento previo y la entrega hacia destinos de atención no afecte la estabilidad de los servicios base ni la continuidad de la atención.

4.6.  Centro de contactos y distribuidor automático de llamadas (ACD)

• El centro de contactos deberá constituir el componente institucional para la distribución y gestión de interacciones de atención, integrándose de forma nativa o plenamente soportada con la central telefónica IP, bajo un esquema de operación misión crítica.
• El ACD deberá formar parte integral del centro de contactos y heredar las mismas condiciones de redundancia, alta disponibilidad, estabilidad y continuidad operativa definidas para dicho componente.
• El sistema de centro de contactos deberá operar de forma continua 24/7/365 y mantener capacidad de crecimiento conforme a la demanda institucional, sin requerir rediseños estructurales.
• El contratista deberá suministrar el hardware, software, licenciamiento y servicios necesarios para el funcionamiento del centro de contactos y del ACD, incluyendo los componentes requeridos para su operación redundante.
• La administración y control del centro de contactos deberá realizarse mediante una interfaz web o equivalente, en idioma español, compatible con navegadores de uso general.
• La consola administrativa del centro de contactos deberá integrarse con el Directorio Activo institucional, siendo responsabilidad del contratista ejecutar la integración, configuración y pruebas de funcionamiento.
• El ACD deberá permitir la gestión de colas de atención, controlando el tráfico entrante a dichas colas conforme a reglas configurables, garantizando tratamiento consistente y trazable.
• La distribución de llamadas entrantes hacia una cola ACD deberá considerar como mínimo: pertenencia del agente a una o más colas, estado de disponibilidad del agente, y el criterio de asignación basado en mayor tiempo de desocupación (mayor tiempo en estado disponible sin recibir llamadas).
• El ACD deberá permitir que un mismo agente esté registrado en una o más colas, sin generar asignaciones ambiguas ni dobles entregas de una misma interacción.
• El ACD deberá permitir definir prioridades por cola, de forma que, cuando un agente esté habilitado para múltiples colas, la asignación de una nueva interacción respete la prioridad más alta configurada entre las colas aplicables.
• El centro de contactos deberá permitir configurar prioridades numéricas por cola, con el fin de identificar la recepción de una interacción de forma más prioritaria.
• El ACD deberá permitir establecer un intervalo parametrizable entre las llamadas asignadas a un agente; el valor deberá registrarse en segundos y aplicarse conforme a la política institucional definida.
• El sistema de centro de contactos deberá permitir la contestación o toma de llamadas de forma forzosa a un agente o a un grupo de agentes, conforme a permisos autorizados.
• Para la asignación forzosa, el componente ACD deberá permitir definir un tiempo de espera para presentar una llamada antes de aplicar la acción correspondiente definida por la institución.
• El centro de contactos deberá permitir la reproducción de un mensaje de bienvenida al ingreso de una llamada, personalizado por agente, grabado previamente, y el cliente de atención del agente deberá permitir reproducir dicho mensaje de forma manual con una llamada en curso, conforme a permisos definidos.
• El ACD deberá permitir la creación, modificación e inactivación de colas de atención, garantizando que las colas operen de forma independiente conforme a su configuración.
• La solución de centro de contactos deberá permitir crear como mínimo diez (10) colas ACD, sin perjuicio de que se habiliten colas adicionales según la operación institucional.
• Para la creación y administración de una cola ACD se deberá registrar, como mínimo:
  1. Nombre de la cola.
  2. Valor numérico de prioridad.
  3. Reglas de marcación y/o tratamiento asociadas a la cola, cuando aplique.
  4. Parámetros de desbordamiento (overflow) ante saturación o condiciones de no atención.
  5. Asignación de agentes a una o más colas y su priorización cuando aplique.
• El sistema deberá permitir la eliminación o inactivación de colas ACD bajo controles de seguridad y auditoría, evitando afectación no controlada de la operación.
• El ACD deberá permitir definir reglas de desbordamiento para una cola, incluyendo destinos alternos autorizados, conforme a políticas institucionales y manteniendo trazabilidad del evento.
• El centro de contactos deberá permitir administrar la afiliación de un agente a colas ACD, incluyendo cambios operativos controlados y registro auditable de dichas modificaciones.
• Cuando un agente esté habilitado para atender diferentes colas o tipos de interacción, el centro de contactos deberá permitir configurar si el agente recibe una notificación única de tráfico entrante o notificaciones diferenciadas por cola, según política institucional.
• El sistema deberá controlar que, una vez asignada una interacción a un agente, este se refleje como ocupado respecto de las demás colas o tipos de interacción configurados, evitando asignaciones simultáneas no permitidas.
• El ACD deberá permitir administrar el tráfico entrante tomando en consideración la prioridad asignada a una cola, conforme al esquema operativo definido.
• El centro de contactos deberá incorporar la gestión y control de códigos de inactividad para agentes.
• El sistema deberá permitir crear, modificar e inactivar códigos de inactividad, utilizados por el agente al seleccionar el estado “ausente” o “no disponible” en una cola ACD.
• El centro de contactos deberá permitir registrar como mínimo quince (15) códigos de inactividad.
• Para cada código de inactividad se deberá definir como mínimo: nombre o descripción, orden de visualización y asociación con el estado “ausente” de la cola ACD.
• El sistema deberá permitir establecer y administrar el orden de visualización de los códigos de inactividad en la interfaz utilizada por el agente.
• La plataforma de centro de contactos deberá permitir generar informes sobre el uso de códigos de inactividad por agente, por periodos de tiempo configurables.
• El ACD deberá permitir la gestión de umbrales operativos mediante perfiles de umbrales configurables.
• El sistema deberá permitir crear, modificar e inactivar perfiles de umbrales para variables operativas del centro de contactos.
• Cada umbral deberá registrar como mínimo: nombre, descripción y valor según la unidad de medida aplicable.
• El centro de contactos deberá permitir definir umbrales, como mínimo, para las siguientes variables:
  1. Tiempo de duración de una llamada activa para un agente.
  2. Tiempo en estado ausente de un agente.
  3. Tiempo sin recibir llamadas para un agente.
  4. Tiempo sin recibir llamadas en una cola ACD.
  5. Cantidad de llamadas en espera.
  6. Cantidad de agentes registrados.
  7. Nivel de servicio.
• El sistema deberá soportar la configuración de uno o más umbrales por cada variable, según se defina institucionalmente.
• El centro de contactos deberá notificar las variables que transgredan los umbrales establecidos, conforme a los mecanismos de alerta definidos por la institución.
• El componente ACD deberá permitir seleccionar la forma de visualización de alertas, incluyendo como mínimo: cambio de color de la variable afectada, ventana emergente con mensaje de alerta y/o alerta sonora.
• El centro de contactos deberá permitir la gestión de agentes como entidades operativas del ACD, manteniendo trazabilidad y control institucional.
• El sistema deberá permitir crear como mínimo trescientos (300) agentes, sin perjuicio de la ampliación requerida por crecimiento.
• Para la creación y administración de un agente se deberá registrar como mínimo:
  1. Identificador único (ID).
  2. Nombre y apellidos.
  3. Estado inicial inactivo, cuando aplique.
  4. Asignación de perfil de usuario, como mínimo: agente y supervisor, sin perjuicio de perfiles adicionales autorizados.
  5. Campo de observaciones.
  6. Relación con la cuenta del Directorio Activo institucional.
  7. Asignación de perfil de umbrales aplicable al control de tiempos en estados operativos.
  8. Selección de colas ACD en las que puede participar el agente.
• El centro de contactos deberá permitir la definición de perfiles de usuario preconfigurados y administrables para el acceso a funciones del ACD.
• El sistema deberá permitir como mínimo los siguientes perfiles: agente, supervisor y administrador.
• El componente ACD deberá permitir asignar al menos un perfil a cada usuario, con control por roles y registro auditable de cambios.
• El centro de contactos deberá proveer una interfaz para funciones de agente mediante aplicación de escritorio o en ambiente web, en idioma español, conforme a lo definido por la institución durante la implementación.
• Cuando se utilice aplicación de escritorio para agente, esta deberá ser compatible con sistema operativo Microsoft Windows 11 de 64 bits o superior.
• Cuando se utilice interfaz web para agente, esta deberá ser compatible con navegadores de uso general disponibles.
• El inicio de sesión y credenciales del usuario que utiliza la interfaz de agente deberán integrarse con el Directorio Activo institucional, bajo responsabilidad del contratista para su configuración y pruebas.
• La interfaz de agente deberá permitir interacción entrante y saliente para los medios habilitados institucionalmente, incluyendo como mínimo voz, y cuando aplique según el alcance contratado, mensajería de texto y videollamadas, sin duplicar los requisitos específicos definidos en las secciones correspondientes del pliego para dichos medios.
• La interfaz de agente deberá incluir opciones para gestión de participación en colas ACD, incluyendo como mínimo:
  1. Ingreso y salida de cola ACD.
  2. Estado “listo”.
  3. Estado “ausente”, con selección de código de inactividad desde lista.
  4. Cierre de sesión.
• La interfaz de agente deberá proveer accesos directos configurables o fijos, como mínimo para: contacto al supervisor, registro de llamadas, directorio de contactos, búsqueda de contactos y estadísticas del agente.
• La interfaz de agente deberá permitir visualizar el número entrante y, cuando aplique, el nombre del llamante asociado a la extensión, conforme a la información disponible y autorizada.
• La interfaz de agente deberá incluir controles telefónicos mínimos para: transferencia, conferencia, finalizar llamada, realizar llamada mediante tablero numérico o digitación, llamada en espera y silenciar micrófono.
• La interfaz de agente deberá mostrar un listado de al menos las últimas veinte (20) llamadas gestionadas, mostrando como mínimo número telefónico, fecha/hora, y para llamadas internas el nombre del llamante, clasificando como mínimo en entrantes, salientes y perdidas.
• El sistema deberá permitir devolver llamada al último número recibido o mediante el listado de llamadas, a través de un acceso directo habilitado para tal fin, conforme a permisos.
• La interfaz de agente deberá incorporar un directorio de contactos telefónicos con campos mínimos: nombre, número telefónico y organización, sin perjuicio de campos adicionales definidos por la institución.
• Para el caso de interacciones no voz administradas por el centro de contactos (cuando aplique), el contratista deberá proveer la aplicación encargada de recibir y procesar dichas interacciones en ambas vías, conforme al alcance contratado y a las secciones correspondientes del pliego.
• El centro de contactos deberá incluir facilidades para un usuario con perfil de supervisor.
• La interfaz o consola de supervisión deberá mostrar el listado general de agentes bajo supervisión asignada, visualizando como mínimo: ID del agente, nombre, número de extensión del puesto y estado del agente.
• El estado del agente mostrado a supervisión deberá contemplar como mínimo: registrado para atender, disponible, con llamada activa y no disponible.
• Cuando el agente se encuentre en estado no disponible, la supervisión deberá visualizar la descripción del código de inactividad seleccionado.
• La solución deberá permitir al supervisor cambiar el estado del agente mediante opción en pantalla, conforme a permisos y políticas institucionales, registrando auditoría del cambio.
• El supervisor deberá poder asignar uno o más agentes a una o más colas ACD, permitiendo establecer prioridad por cola para cada agente cuando aplique, registrando auditoría del ajuste.
• El centro de contactos deberá permitir la función de monitoreo en tiempo real de una llamada (escucha), donde el supervisor escucha la conversación sin ser escuchado por agente ni usuario, conforme a permisos.
• El sistema deberá permitir la función de asesoría en tiempo real (coach), donde únicamente el agente escucha las indicaciones del supervisor, sin ser escuchado por el usuario, conforme a permisos.
• El componente ACD deberá permitir la función de intervención (barge-in), donde supervisor, agente y usuario pueden interactuar, conforme a permisos y bajo registro auditable.
• La plataforma de centro de contactos deberá registrar y conservar evidencia de operaciones relevantes del ACD, incluyendo como mínimo: altas/bajas de colas, cambios de prioridades, asignaciones de agentes, cambios de estado de agentes, aplicación de códigos de inactividad, eventos de desbordamiento, alertas por umbrales y acciones de supervisión.
• El sistema deberá permitir que las bitácoras y evidencias de operación del ACD sean consultables por perfiles autorizados y exportables cuando aplique, conforme a las políticas institucionales.
• El centro de contactos deberá soportar el registro de métricas operativas base para explotación estadística, incluyendo como mínimo: interacciones recibidas, atendidas, en espera, abandonadas, tiempos de espera y atención, y nivel de servicio cuando aplique.
• El ACD deberá permitir asociar cada interacción con identificadores operativos mínimos para correlación institucional, tales como: cola, agente, extensión, prioridad y estado, de manera consistente con el esquema de integración definido en la sección correspondiente del pliego.
• El contratista deberá entregar documentación técnica y operativa del centro de contactos, describiendo su configuración implementada, colas definidas, parámetros de prioridades y umbrales, reglas de distribución, perfiles y permisos, y procedimiento controlado para ajustes operativos.
• El contratista deberá ejecutar pruebas funcionales con participación institucional que demuestren, como mínimo: creación y operación de colas, asignación de agentes a múltiples colas con prioridad, distribución por mayor tiempo disponible, aplicación de intervalos entre llamadas, desbordamientos, códigos de inactividad, alertas por umbrales y funciones de supervisión (monitoreo, asesoría e intervención), dejando evidencias verificables para aceptación.
• El contratista deberá incluir en su oferta e implementar el licenciamiento requerido para el funcionamiento completo del centro de contactos y del ACD, conforme a la capacidad mínima exigida por la institución y sin restricciones que limiten la operación 24/7/365.
• El licenciamiento del centro de contactos deberá contemplar, como mínimo, las licencias necesarias para:
  1. Agentes, conforme a la cantidad mínima requerida y su crecimiento.
  2. Supervisores, incluyendo funciones de monitoreo, asesoría e intervención, cuando aplique.
  3. Colas ACD y sus capacidades de prioridad, desbordamiento y reglas operativas.
  4. Gestión de códigos de inactividad y registro de tiempos asociados.
  5. Gestión de umbrales, alertas y visualización de eventos operativos.
  6. Reportería operativa del ACD y exportaciones permitidas por el sistema.
  7. Interacción por los medios habilitados institucionalmente a través del centro de contactos, cuando aplique al alcance contratado (voz y, cuando corresponda, SMS, WhatsApp y videollamadas), sin duplicar lo definido en las secciones correspondientes.
• El oferente deberá detallar en su propuesta el esquema de licenciamiento ofertado (tipo, unidad de licenciamiento, cantidades, vigencia, restricciones y crecimiento), garantizando que no existan costos ocultos por habilitación de funcionalidades requeridas en este pliego.
• La institución no aceptará esquemas de licenciamiento que condicionen el uso de funciones requeridas (por ejemplo: priorización de colas, intervalos, desbordamientos, umbrales, alertas o funciones de supervisión) a adquisiciones posteriores no contempladas en la propuesta.

4.7.  Gestión y control de agentes, supervisores y perfiles de usuario

• La plataforma de telefonía deberá disponer de un esquema integral de gestión de identidades y control de accesos para agentes, supervisores y perfiles administrativos, garantizando que cada usuario disponga únicamente de las funciones necesarias para su rol operativo.
• El sistema de telefonía IP deberá permitir la administración del ciclo de vida de usuarios operativos, incluyendo como mínimo: creación, modificación, suspensión, inactivación, reasignación y reactivación, bajo control de perfiles autorizados y con trazabilidad auditable.
• El componente de centro de contactos deberá gestionar el concepto de “agente” como entidad operativa, manteniendo consistencia entre la identidad del usuario institucional, su extensión o puesto de atención y su configuración funcional dentro del ACD.
• La central telefónica IP y el centro de contactos deberán integrarse con el Directorio Activo institucional para autenticación y asociación de cuentas, siendo responsabilidad del contratista configurar, probar y dejar operativa dicha integración.
• El acceso de agentes y supervisores a las interfaces de operación deberá realizarse mediante credenciales institucionales y, cuando aplique, inicio de sesión único (SSO), evitando el uso de cuentas locales no administradas por la institución.
• La administración de usuarios deberá permitir asociar cada agente con su cuenta institucional y con el puesto de atención correspondiente, incluyendo como mínimo: extensión asignada, colas autorizadas y perfil operativo.
• El sistema de telefonía IP deberá permitir la segregación de funciones entre administración técnica, administración operativa, supervisión y atención, evitando que un mismo rol concentre capacidades incompatibles según política institucional.
• El esquema de permisos deberá contemplar, como mínimo, los siguientes perfiles base, sin perjuicio de perfiles adicionales definidos por la institución:
  1.  
  2.  
  3. Administrador operativo de telefonía.
  4. Administrador técnico de la plataforma.
  5. Auditor o perfil de consulta.
• Cada perfil deberá definirse mediante un conjunto de permisos granular, de manera que la institución pueda habilitar o restringir funcionalidades específicas, sin requerir cambios de programación.
• El sistema deberá permitir la creación, modificación e inactivación de perfiles de usuario del centro de contactos, bajo control de perfiles autorizados y con registro auditable de cada cambio.
• El sistema deberá permitir que un usuario tenga uno o más roles, cuando la institución lo autorice, aplicando siempre el principio de mínimo privilegio y registrando el cambio en auditoría.
• El centro de contactos deberá permitir crear como mínimo trescientos (300) agentes, sin perjuicio de habilitar una cantidad superior conforme al crecimiento institucional.
• Para la creación y administración de un agente se deberá registrar como mínimo:
  1. Identificador único del agente.
  2. Nombre y apellidos.
  3. Estado inicial (activo/inactivo) conforme a política institucional.
  4. Perfil operativo asignado (agente/supervisor u otros).
  5. Campo de observaciones.
  6. Asociación con cuenta institucional del Directorio Activo.
  7. Asignación de perfil de umbrales o controles operativos aplicable, cuando corresponda.
  8. Colas ACD autorizadas y prioridad por cola, cuando aplique.
• Todo agente deberá registrarse con un perfil de usuario asignado, como mínimo “agente” o “supervisor”, y no se permitirá operar agentes sin perfil asociado.
• La plataforma de telefonía deberá permitir administrar la pertenencia de un agente a una o más colas ACD, evitando asignaciones ambiguas y garantizando que los cambios se reflejen de forma controlada en operación.
• El sistema deberá permitir que un agente se incorpore o se retire de colas, conforme a permisos, registrando el evento y manteniendo trazabilidad operativa.
• La gestión de perfiles deberá permitir definir qué funciones están disponibles para un agente, incluyendo como mínimo: atender, transferir, conferencia, retener, reanudar, finalizar, uso de directorio, marcación autorizada y estados operativos.
• La plataforma de telefonía deberá permitir controlar las restricciones de marcación y las capacidades funcionales por perfil, de manera que las llamadas salientes, transferencias a destinos externos y otras acciones sensibles se habiliten únicamente a roles autorizados.
• El centro de contactos deberá permitir Gestionar estados operativos del agente, incluyendo como mínimo: disponible, no disponible y con interacción activa, manteniendo consistencia con el mecanismo de distribución del ACD.
• La gestión de estados deberá contemplar el uso de códigos de inactividad cuando el agente seleccione estado no disponible, manteniendo trazabilidad del código utilizado y su duración, conforme a la configuración institucional.
• El sistema deberá permitir controlar el orden de visualización de los códigos de inactividad en la interfaz del agente, así como su habilitación o inactivación por perfiles autorizados.
• El centro de contactos deberá permitir asignar a cada agente un perfil de umbrales o reglas de control de tiempos, cuando aplique, para monitorear variables como duración de llamada, tiempo en no disponible y tiempos sin recibir interacciones.
• La plataforma de telefonía deberá permitir que un supervisor visualice en tiempo real el estado de los agentes bajo su ámbito de supervisión, incluyendo como mínimo: identificador del agente, nombre, extensión o puesto, cola(s) asociadas y estado actual.
• Cuando un agente esté no disponible, la supervisión deberá visualizar el código de inactividad aplicado o su descripción equivalente.
• El sistema deberá permitir a perfiles de supervisión ejecutar acciones autorizadas sobre agentes, incluyendo como mínimo: cambio de estado, incorporación o retiro de colas y ajustes operativos permitidos por política institucional, registrando auditoría.
• La plataforma de telefonía deberá permitir asignar y administrar qué supervisores tienen ámbito sobre qué agentes, colas o grupos operativos, evitando supervisión fuera del ámbito autorizado.
• El componente de centro de contactos deberá permitir capacidades de monitoreo y acompañamiento por supervisión, cuando aplique, asegurando control por permisos y registro auditable, incluyendo como mínimo:
  1. Monitoreo en tiempo real (escucha).
  2. Asesoría al agente (coach).
  3. Intervención en la llamada (barge-in).
• El sistema deberá permitir definir permisos específicos para habilitar o restringir monitoreo, asesoría e intervención por supervisor, evitando habilitaciones globales sin control institucional.
• La administración de perfiles deberá permitir definir permisos diferenciados para consultar métricas, reportes y paneles operativos, incluyendo restricciones por colas, por agentes o por ámbitos definidos por la institución.
• El control de acceso deberá contemplar mecanismos de bloqueo o restricción ante intentos fallidos de autenticación, así como políticas de sesión conforme a lo definido por la institución durante la implementación.
• La plataforma de telefonía deberá permitir el cierre de sesión forzado para perfiles autorizados, cuando aplique por razones operativas o de seguridad, dejando registro auditable del evento.
• El sistema deberá permitir limitar sesiones concurrentes por usuario cuando la institución así lo requiera, evitando accesos simultáneos no controlados.
• La administración de usuarios deberá permitir la trazabilidad completa de cambios, registrando como mínimo: usuario administrador que ejecuta el cambio, fecha/hora, tipo de modificación y valores relevantes antes/después, cuando aplique.
• Toda modificación de perfiles o reasignación de roles deberá quedar registrada en auditoría, indicando como mínimo: usuario ejecutor, fecha/hora y detalle del cambio.
• La plataforma de telefonía deberá registrar y conservar bitácoras de auditoría para eventos relevantes asociados a usuarios y perfiles, incluyendo como mínimo:
  1. Creación, modificación e inactivación de agentes.
  2. Cambios de roles y permisos.
  3. Cambios de asignación de colas y prioridades.
  4. Cambios de estados operativos ejecutados por supervisión.
  5. Inicios y cierres de sesión.
  6. Acciones de monitoreo, asesoría o intervención, cuando aplique.
• El sistema deberá permitir consultar y exportar las bitácoras de auditoría por rangos de fecha, usuario, tipo de acción y ámbito operativo, conforme a permisos autorizados.
• El contratista deberá entregar documentación del modelo de roles y permisos implementado, incluyendo matriz de permisos por perfil, alcance de supervisión y procedimientos para altas, cambios y bajas de usuarios.
• El sistema deberá permitir aplicar cambios operativos de usuarios y perfiles bajo un mecanismo controlado, evitando impactos no planificados en horas críticas, conforme a la política institucional que se defina en la implementación.
• Cuando existan usuarios con funciones administrativas, el sistema deberá permitir perfiles diferenciados para administración operativa (por ejemplo: colas, agentes, estados, umbrales) y administración técnica (por ejemplo: parámetros de plataforma), conforme al principio de segregación de funciones.
• El centro de contactos deberá permitir que las configuraciones asociadas a agentes (colas, prioridades, umbrales, estados) se mantengan consistentes y disponibles aun ante fallas parciales cubiertas por el esquema de continuidad operativa de la plataforma.
• La institución podrá definir roles adicionales o variantes de perfiles base para atender necesidades operativas específicas (por ejemplo: supervisor por cola, supervisor por grupo operativo, auditor de calidad u otros), debiendo el sistema permitir dicha parametrización sin desarrollos adicionales.
• El contratista deberá ejecutar pruebas funcionales con participación institucional que evidencien, como mínimo: creación de agentes, asignación a múltiples colas con prioridades, aplicación de roles, restricción efectiva de permisos, trazabilidad de cambios, control de supervisión por ámbito y auditoría de eventos relevantes.

4.8.  Consola de administración de telefonía

• La central telefónica IP deberá proporcionar una consola de administración para la gestión integral del componente de telefonía, permitiendo configuración, operación, control y mantenimiento de los parámetros requeridos por la institución, bajo un esquema de servicio misión crítica.
• La consola de administración deberá operar mediante una interfaz web o equivalente, en idioma español, y ser compatible con las últimas versiones disponibles de navegadores de internet de uso general.
• La consola deberá integrarse con el Directorio Activo de Microsoft Windows para fines de autenticación y administración de accesos, siendo responsabilidad del contratista ejecutar la integración, configuración, pruebas y puesta en operación.
• El acceso a la consola deberá soportar el mecanismo de inicio de sesión único (SSO) conforme al esquema institucional definido, sin depender de cuentas locales no administradas por la institución.
• La plataforma de telefonía deberá permitir la creación y administración de usuarios con acceso a la consola, registrando como mínimo para cada usuario:
  1. Nombre y apellidos.
  2. Rol o perfil de seguridad asignado.
  3. Posibilidad de establecer el usuario en estado inactivo.
• La consola deberá permitir definir y aplicar controles de seguridad para administrar el acceso y las opciones habilitadas por perfil de usuario, de manera que cada perfil visualice y ejecute únicamente las funciones autorizadas.
• El sistema de telefonía IP deberá permitir la segregación de funciones dentro de la consola, diferenciando al menos administración operativa y administración técnica, conforme a las políticas institucionales.
• La consola de administración deberá facilitar las labores de mantenimiento para la gestión de extensiones telefónicas, permitiendo como mínimo: creación, modificación, inactivación y eliminación, así como la configuración de facilidades asociadas a cada extensión.
• La consola deberá permitir administrar el inventario lógico de extensiones y su asociación a usuarios, puestos o perfiles definidos por la institución, manteniendo consistencia operativa y evitando duplicidades.
• El componente de telefonía deberá permitir administrar grupos operativos relacionados con la atención (por ejemplo: grupos de timbrado u otros equivalentes), incluyendo su creación, modificación e inactivación, conforme a permisos.
• La consola deberá permitir administrar parámetros operativos de tratamiento de llamadas, incluyendo tiempos y reglas generales aplicables a servicios base, conforme a lo establecido en las secciones correspondientes del presente módulo.
• La plataforma de telefonía deberá permitir administrar el plan de numeración y el plan de marcado centralizado desde la consola, incluyendo creación, modificación, activación e inactivación de reglas, bajo control de perfiles autorizados.
• La consola deberá permitir administrar rutas y reglas de marcación, incluyendo rutas de entrada, rutas de salida, rutas internas y rutas de continuidad, conforme a la configuración definida por la institución.
• El sistema de telefonía IP deberá permitir administrar los parámetros de conectividad y enrutamiento asociados a troncales SIP y reglas de tratamiento, conforme a permisos y bajo control de cambios, evitando configuraciones ambiguas.
• La consola deberá permitir Gestionar restricciones de marcación por perfiles o grupos, incluyendo reglas por prefijos o rangos, y permisos especiales por rol, conforme a políticas institucionales.
• La administración del componente de telefonía deberá permitir parametrizar destinos alternos autorizados para continuidad operativa, así como condiciones de activación controlada y su reversión, manteniendo trazabilidad del cambio.
• La consola deberá permitir administrar facilidades de llamada (por ejemplo: transferencia, conferencia, retención, llamada en espera, toma de llamada por terceros u otras equivalentes), habilitándolas o restringiéndolas por perfil cuando aplique.
• La consola deberá permitir administrar anuncios institucionales y música en espera cuando aplique, incluyendo carga o actualización de elementos permitidos y asignación por condición o destino autorizado.
• El sistema de telefonía IP deberá permitir respaldar y restaurar configuraciones críticas administradas desde la consola (por ejemplo: extensiones, rutas, reglas de marcación, grupos y parámetros operativos), mediante mecanismos controlados y documentados.
• La plataforma de telefonía deberá permitir exportar configuraciones o respaldos en formatos utilizables para resguardo institucional, conforme a perfiles autorizados y bajo auditoría.
• La consola deberá incluir un mecanismo de búsqueda que facilite localizar configuraciones por criterios operativos (por ejemplo: extensión, nombre de usuario, cola o grupo, ruta o regla), sin requerir recorridos manuales extensos.
• La consola deberá permitir visualizar el estado general de componentes de la plataforma de telefonía (según la arquitectura ofertada), a fin de apoyar las labores de operación y soporte, sin sustituir los mecanismos de monitoreo integral definidos en la sección correspondiente de este módulo.
• El sistema de telefonía IP deberá registrar en auditoría las acciones administrativas realizadas desde la consola, incluyendo como mínimo: creación/modificación/inactivación de extensiones, cambios de rutas, cambios de reglas de marcación, cambios de restricciones, activación de destinos alternos y cambios de perfiles.
• Los registros de auditoría deberán conservar fecha y hora, usuario ejecutor, tipo de acción y detalle mínimo del cambio, y deberán ser consultables por perfiles autorizados, conforme a las políticas definidas en la sección correspondiente del pliego.
• La consola deberá permitir generar y consultar información de registro y control de llamadas, mediante el almacenamiento del detalle de cada registro de llamada (CDR – Call Detail Record) o equivalente, sin afectar la operación normal de atención.
• Los registros CDR deberán contener como mínimo:
  1. Fecha y hora de inicio de la llamada.
  2. Fecha y hora de fin de la llamada.
  3. Número telefónico de origen.
  4. Número telefónico de destino.
  5. Tiempo de timbrado.
• El sistema de telefonía IP deberá incorporar un mecanismo de redundancia para el almacenamiento de registros tipo CDR, evitando puntos únicos de falla para la trazabilidad operativa.
• El repositorio de CDR deberá ser dimensionado para permitir el almacenamiento durante toda la vigencia del contrato o el periodo institucional definido, según corresponda.
• La plataforma de telefonía deberá proveer un aplicativo o interfaz para consulta de los CDR generados y almacenados, con filtros por criterios mínimos definidos por la institución.
• La consola deberá permitir la exportación de los registros CDR conforme a permisos autorizados.
• El sistema de telefonía IP deberá permitir la generación de reportes basados en CDR y la exportación de datos como mínimo a formatos PDF y Excel.
• La plataforma de telefonía deberá permitir configurar alarmas ante inconvenientes detectados en la operación normal de generación o almacenamiento de CDR, con capacidad de notificación por correo electrónico a destinatarios institucionales definidos.
• La consola deberá incluir o integrarse con el servicio de tarificación, proporcionando una interfaz web para visualizar reportes y ejecutar consultas sobre registros CDR, conforme a permisos.
• El servicio de tarificación deberá generar informes sobre la utilización de los servicios de telefonía, indicando como mínimo: extensión que origina la llamada, número telefónico de destino, hora y duración de la llamada, y totales por período.
• La plataforma de tarificación deberá permitir agrupar usuarios por centro de costo, área y ubicación, conforme al modelo institucional definido.
• La consola de tarificación deberá permitir generar reportes, tableros y gráficos desde la interfaz web y exportarlos como mínimo a formatos PDF y Excel.
• El sistema de tarificación deberá permitir configurar alarmas ante inconvenientes detectados en la operación normal de dicha función, con notificación por correo electrónico.
• La consola deberá permitir la parametrización de destinatarios, umbrales y condiciones de disparo para alarmas operativas asociadas a telefonía, conforme al esquema institucional de soporte.
• El componente de telefonía deberá permitir que los cambios críticos realizados desde la consola se ejecuten bajo control de cambios, incluyendo registro del cambio, validación y mecanismo de reversión cuando aplique, conforme a lo definido por la institución durante la implementación.
• La consola deberá permitir la administración centralizada sin requerir intervención del fabricante para cambios rutinarios posteriores a la puesta en operación, siempre que se trate de funciones contempladas en este pliego y ejecutadas por perfiles autorizados.
• La interfaz administrativa deberá mantener disponibilidad operacional acorde con la naturaleza misión crítica de la plataforma; en caso de degradación o indisponibilidad, no deberá comprometer la continuidad del servicio de atención de llamadas más allá de lo técnicamente inevitable según la arquitectura ofertada.
• El contratista deberá entregar documentación técnica y operativa de la consola de administración, incluyendo como mínimo: descripción de funciones, matriz de roles y permisos, procedimientos de administración de extensiones y rutas, procedimientos de respaldo y restauración, y guía de operación para consulta y exportación de CDR y tarificación.

4.9.  Dispositivos de borde e interconexión de voz (SBC, gateways y equivalentes)

• El sistema de telefonía IP deberá incorporar los dispositivos de borde e interconexión necesarios para integrar la plataforma de telefonía con las troncales SIP existentes, redes institucionales y servicios de voz autorizados, asegurando estabilidad, continuidad operativa y control del tráfico de señalización y medios.
• Los dispositivos de borde deberán formar parte integral del suministro del contratista cuando sean requeridos por la arquitectura ofertada, incluyendo hardware, software, licenciamiento, instalación, configuración, puesta en operación y soporte durante toda la vigencia contractual.
• Cuando para asegurar la operación, alta disponibilidad, seguridad o desempeño se requiera incorporar equipos adicionales a los ya existentes en la infraestructura institucional (por ejemplo, dispositivos de borde, componentes de seguridad o interconexión u otros equivalentes), su provisión, instalación, licenciamiento y costos asociados serán responsabilidad del contratista.
• El contratista será responsable de diseñar y definir el esquema de borde, indicando el rol específico de cada elemento (SBC, gateway u otro equivalente), su ubicación en la red y su relación con los componentes de control de llamadas y con las troncales SIP existentes.
• Los dispositivos de borde deberán permitir la interoperabilidad con SIP Trunk, garantizando compatibilidad con parámetros operativos, negociación de sesiones y comportamiento consistente bajo condiciones normales y picos de demanda.
• El diseño de borde deberá integrarse y operar con el esquema institucional vigente de atención centralizada y balanceo de carga sobre las troncales SIP existentes, como condición mínima obligatoria, manteniendo operación estable y sin introducir dependencias que obliguen a modificar las troncales SIP como requisito de funcionamiento.
• Cualquier ajuste requerido sobre las troncales SIP existentes deberá ser mínimo, técnicamente justificado, coordinado y autorizado por la institución, sin interrupción de la atención.
• Cuando la arquitectura requiera gateways, estos deberán permitir la interconexión con tecnologías o interfaces de voz que la institución defina como necesarias durante la implementación, bajo control institucional y sin incorporar componentes externos no contemplados en la solución.
• Los dispositivos de borde deberán soportar políticas de control de admisión de llamadas y sesiones, de forma que se evite saturación y se mantenga estabilidad del servicio ante picos de tráfico.
• El SBC o dispositivo equivalente deberá permitir la normalización de señalización SIP y la gestión de interoperabilidad, incluyendo manipulación controlada de encabezados cuando sea necesario para compatibilidad, manteniendo trazabilidad del tratamiento aplicado.
• El dispositivo de borde deberá permitir aplicar reglas para aceptación, rechazo y encaminamiento de sesiones según criterios definidos por la institución, incluyendo como mínimo: troncal de ingreso, dominios autorizados, rangos de números, horarios y condiciones de contingencia.
• El sistema de borde deberá soportar la identificación del número marcado (DNIS) y el manejo de números directos (DID) cuando aplique, preservando los datos requeridos para el tratamiento y correlación operativa en el resto de componentes.
• El dispositivo de borde deberá permitir la preservación y entrega consistente de identificación de origen (cuando esté disponible) hacia los componentes internos autorizados, evitando alteraciones no justificadas que afecten trazabilidad o tratamiento.
• Los equipos de borde deberán soportar mecanismos de traducción de direcciones y traversal de NAT cuando aplique, de forma que no se comprometa la estabilidad del tráfico de señalización ni de medios.
• El SBC o equivalente deberá permitir ocultamiento de topología (topology hiding) hacia redes externas, de manera que no se expongan direcciones internas, nombres de componentes o detalles innecesarios de la infraestructura institucional.
• El sistema de borde deberá incorporar controles para mitigación de amenazas sobre SIP, incluyendo como mínimo: limitación de tasa (rate limiting), protección ante intentos masivos, control de sesiones concurrentes por origen y listas de permitidos/bloqueados según política institucional.
• El dispositivo de borde deberá permitir aplicar políticas de seguridad para evitar fraude telefónico, incluyendo controles sobre destinos externos autorizados, restricciones por prefijos o rangos y reglas de bloqueo ante patrones anómalos definidos por la institución.
• Cuando la arquitectura lo permita, el dispositivo de borde deberá soportar cifrado de señalización y/o medios según el diseño ofertado y la política institucional definida, manteniendo interoperabilidad con las troncales SIP existentes.
• El contratista deberá documentar los protocolos, puertos y dependencias requeridas por los dispositivos de borde, así como el flujo de señalización y de medios, para su validación en la infraestructura institucional.
• Los dispositivos de borde deberán permitir administración centralizada y segura, evitando configuraciones directas no controladas y garantizando que el acceso administrativo quede restringido a perfiles autorizados.
• La administración de los dispositivos de borde deberá integrarse con el esquema institucional de autenticación cuando aplique, o en su defecto, deberá permitir control por roles, políticas de contraseñas y restricciones por origen de conexión administrativa.
• Toda modificación de configuración en el SBC/gateway deberá quedar registrada en auditoría, indicando como mínimo: usuario, fecha/hora y detalle del cambio.
• Los dispositivos de borde deberán soportar respaldo y restauración de configuración, permitiendo recuperación controlada ante fallas, errores operativos o cambios no deseados.
• El contratista deberá entregar respaldos iniciales de configuración y un procedimiento documentado de recuperación, incluyendo criterios de reversión ante cambios críticos.
• El equipo de borde deberá permitir monitoreo de estado y métricas técnicas relevantes (por ejemplo: disponibilidad, sesiones concurrentes, intentos rechazados, uso de recursos y eventos de seguridad), sin sustituir el monitoreo integral definido en la sección correspondiente del módulo.
• El dispositivo de borde deberá generar bitácoras técnicas exportables para análisis institucional, incluyendo eventos de registro de sesiones, fallos de interoperabilidad, rechazos por política y eventos de seguridad.
• Las bitácoras del borde deberán contar con marcas de tiempo consistentes y sincronización horaria institucional para correlación con el resto de los componentes.
• Los dispositivos de borde deberán soportar actualización controlada de firmware/software, aplicando un mecanismo que permita mantenimiento planificado sin interrumpir la atención más allá de lo técnicamente inevitable.
• El esquema de borde deberá implementarse sin puntos únicos de falla, mediante redundancia o mecanismos equivalentes, incluyendo como mínimo redundancia de equipos, fuentes de poder, enlaces relevantes y componentes críticos para la interconexión de voz.
• El contratista deberá definir el comportamiento de conmutación ante fallas (por ejemplo: falla de un SBC, falla de enlace, degradación de un nodo), indicando impacto esperado, tiempos objetivos y mecanismo de retorno a condición normal.
• El diseño deberá permitir mantenimiento de componentes de borde sin detener por completo la interconexión de voz, cuando la arquitectura ofertada lo permita, y deberá documentarse el procedimiento operativo.
• Los dispositivos de borde deberán dimensionarse para soportar la concurrencia de llamadas y sesiones requerida por la institución, incluyendo crecimiento y picos de demanda, sin degradación atribuible a subdimensionamiento.
• El oferente deberá declarar en su propuesta el dimensionamiento aplicado al borde (capacidad de sesiones, límites relevantes, supuestos de carga), así como las licencias asociadas que habilitan dicha capacidad.
• El sistema de borde deberá permitir segmentación y control de tráfico de administración, separándolo del tráfico de señalización y medios, conforme a la segmentación de red institucional definida durante la implementación.
• El contratista deberá asegurar que los dispositivos de borde operen con la conectividad institucional definida entre sitio principal y el Data Center contratado por el 9-1-1 provista por el contratista, manteniendo estabilidad ante conmutación de enlace principal a enlace redundante, conforme al modelo de continuidad operativa establecido.
• Cuando se requieran certificados digitales o elementos de infraestructura (DNS u otros) para operación segura del borde, el contratista deberá documentar el requerimiento y ejecutar la configuración correspondiente bajo coordinación institucional.
• El sistema de borde deberá permitir pruebas controladas de interoperabilidad con las troncales SIP existentes, incluyendo escenarios de alta demanda, rechazo por políticas y conmutación ante fallas parciales, dejando evidencia verificable para aceptación.
• El contratista deberá entregar, como parte de la documentación técnica, un diagrama específico del borde de voz, que muestre equipos, redundancias, enlaces, flujos de señalización y medios, y puntos de control aplicados.
• El diagrama del borde deberá acompañarse de un documento descriptivo que explique la función de cada elemento, reglas de operación, políticas configuradas, dependencias y consideraciones de continuidad y seguridad aplicables.
• Los dispositivos de borde e interconexión deberán cumplir el principio de neutralidad tecnológica, evitando dependencias exclusivas con un proveedor, fabricante o integrador, salvo casos debidamente justificados y aceptados por la Administración; no se admitirán restricciones técnicas que limiten la interoperabilidad, la evolución futura o la integración con sistemas de terceros.
• La institución podrá solicitar ajustes a la configuración del borde para atender cambios operativos autorizados (por ejemplo: ajustes de reglas, rutas, políticas o restricciones), debiendo el contratista ejecutarlos bajo control de cambios y con validación funcional.
• El contratista deberá garantizar que el diseño y configuración del borde no introduzcan ambigüedades en el tratamiento de llamadas, ni alteraciones no controladas de identificadores operativos requeridos para trazabilidad e integración institucional.

4.10.          Dispositivos telefónicos y clientes de atención (teléfonos IP, softphones y compatibilidad)

• El sistema de telefonía IP deberá incluir los dispositivos telefónicos y clientes de atención requeridos para la operación institucional, asegurando compatibilidad total con la central telefónica IP, el centro de contactos y las integraciones definidas para la atención de llamadas.Los teléfonos IP suministrados como parte de la solución deberán corresponder a la misma marca del fabricante de la plataforma de telefonía IP ofertada.
• Los teléfonos IP físicos, softphones, clientes de atención, licenciamiento, configuración, aprovisionamiento, administración centralizada y demás componentes necesarios para la operación de los terminales deberán ser suministrados, instalados, configurados y puestos en operación por el contratista, conforme al inventario base definido por la Administración.

 

Para los operadores/call takers y supervisores, el softphone o cliente de atención constituirá el medio principal de comunicación, debiendo suministrarse además teléfono IP físico como medio de respaldo, contingencia o continuidad operativa.

 

Para los despachadores, el teléfono IP físico constituirá el medio principal de comunicación. La capacidad de softphones prevista para despacho tendrá carácter de contingencia, operación alterna o uso autorizado por la Administración, y no sustituye el requerimiento de teléfonos IP físicos para dichos puestos.

 

Se aclara que los headsets, diademas o auriculares serán suministrados por la Administración, por lo que no deberán ser cotizados como parte del suministro base del contratista.

 

• Los dispositivos telefónicos y clientes de atención deberán operar de forma estable bajo condiciones de servicio misión crítica, incluyendo operación continua 24/7/365 y escenarios de alta demanda conforme al dimensionamiento definido.
• El contratista deberá asegurar que los teléfonos IP y los clientes softphone sean plenamente compatibles con las funciones requeridas del sistema de telefonía IP y del ACD, sin limitar funcionalidades por tipo de terminal cuando el rol operativo lo requiera.
• El oferente deberá describir en su propuesta el modelo de terminales ofrecidos, respetando el inventario base definido por la Administración. La propuesta deberá detallar, como mínimo, los 225 teléfonos IP físicos y 113 softphones o clientes de atención requeridos, su asignación por perfil operativo, licenciamiento, aprovisionamiento, administración, compatibilidad, operación principal, respaldo y contingencia.

 

Para los operadores/call takers y supervisores, el oferente deberá considerar el softphone o cliente de atención como medio principal de comunicación y el teléfono IP físico como medio de respaldo, contingencia o continuidad operativa.

 

Para los despachadores, el oferente deberá considerar el teléfono IP físico como medio principal de comunicación. Los softphones adicionales previstos para despacho deberán entenderse como capacidad de contingencia, operación alterna o uso autorizado por la Administración, y no como sustitutos del teléfono IP físico requerido para dichos puestos.

 

El oferente deberá justificar los supuestos utilizados para la selección y asignación de los terminales, considerando al menos ergonomía, continuidad, administración, compatibilidad, criticidad del servicio y facilidad de soporte.

 

• Los teléfonos IP ofertados deberán contar con compatibilidad certificada, homologada o formalmente soportada con la central telefónica IP y la solución de centro de contactos propuesta, garantizando interoperabilidad, administración centralizada, soporte técnico unificado, continuidad operativa, estabilidad, seguridad y acceso pleno a las funcionalidades requeridas en el presente pliego.
• La compatibilidad deberá acreditarse mediante documentación técnica del fabricante, matriz de compatibilidad, certificación, carta de soporte, ficha técnica, homologación o documento equivalente que permita verificar objetivamente que los teléfonos IP propuestos operan de forma estable, segura y plenamente soportada con la solución ofertada.
• El contratista será responsable de garantizar el funcionamiento integral de los teléfonos IP con la plataforma ofertada durante toda la vigencia contractual, sin que pueda trasladar a la Administración limitaciones, incompatibilidades, degradaciones funcionales o costos adicionales derivados de la selección de los terminales propuestos.
• Teléfonos IP
  1. Los teléfonos IP deberán soportar el protocolo y mecanismo de señalización definido por la arquitectura ofertada y ser compatibles con la central telefónica IP sin dependencias de adaptaciones no contempladas en la solución.
  2. Los terminales IP deberán soportar aprovisionamiento y administración centralizada, permitiendo alta, modificación, reasignación e inactivación por perfiles autorizados, sin requerir programación en cada dispositivo.
  3. Los teléfonos IP deberán permitir visualizar, como mínimo, identificación de la llamada entrante cuando esté disponible, número marcado cuando aplique, extensión asociada y estado de la llamada.
  4. Los dispositivos IP deberán permitir la operación de funciones base cuando el perfil lo requiera, incluyendo como mínimo: atender/finalizar, retener/reanudar, transferencia asistida y ciega, conferencia, silenciar, llamada en espera y toma de llamada por terceros cuando aplique.
  5. Los teléfonos IP deberán soportar actualización de firmware controlada y centralizada, con mecanismos que reduzcan impacto operativo y permitan retorno a versión anterior cuando aplique.
  6. Los terminales IP deberán soportar sincronización horaria y mantener coherencia de fecha/hora para trazabilidad de eventos operativos y auditorías.
  7. Los dispositivos IP deberán ser compatibles con la segmentación de red institucional definida para telefonía (por ejemplo, separación lógica de voz/administración) cuando aplique según la arquitectura implementada.
  8. Cuando aplique por diseño, los teléfonos IP deberán soportar alimentación por Ethernet (PoE) o el mecanismo que defina la institución, debiendo el contratista suministrar los accesorios necesarios si se requieren para su operación.
  9. Todos los teléfonos IP físicos suministrados deberán permitir la conexión y operación directa de los headsets USB institucionales (JABRA ENGAGE 50II) mediante puerto USB nativo compatible. Esta obligación aplica tanto para los teléfonos IP utilizados como respaldo por operadores y supervisores, como para los teléfonos IP utilizados como medio principal por despachadores y cualquier otro teléfono IP asignado a perfiles autorizados por la Administración. No se aceptará como cumplimiento la disponibilidad exclusiva de conectores RJ9, QD, jack 3.5 mm, Bluetooth, adaptadores no incluidos u otros mecanismos que obliguen a sustituir los headsets USB institucionales.
  10. El contratista deberá validar durante la fase de implementación la compatibilidad funcional de los teléfonos IP o clientes de atención con los headsets USB institucionales, incluyendo como mínimo recepción de audio, transmisión de voz, control de volumen y función de silenciamiento del micrófono, cuando estas funciones sean soportadas por el headset utilizado. La validación deberá documentarse como parte de las pruebas de aceptación.
• Clientes softphone y cliente de atención del agente
  1. El cliente softphone o cliente de atención deberá operar como parte integral del sistema de telefonía IP y, cuando aplique, del centro de contactos, permitiendo atención de llamadas de forma controlada, trazable y consistente.
  2. El cliente de atención podrá ser una aplicación de escritorio o una interfaz web, según la arquitectura ofertada; en ambos casos deberá estar en idioma español y ser plenamente funcional para el rol operativo asignado.
  3. Cuando el cliente de atención sea una aplicación de escritorio, deberá ser compatible como mínimo con Microsoft Windows 11 de 64 bits o versión superior disponible en la institución.
  4. Cuando el cliente de atención sea una interfaz web, deberá ser compatible con navegadores de uso general disponibles en la institución, sin requerir complementos no autorizados o componentes obsoletos.
  5. El acceso al cliente de atención deberá integrarse con el Directorio Activo institucional para autenticación y asociación de la cuenta con el agente y su perfil, siendo responsabilidad del contratista la configuración y pruebas de esta integración.
  6. El cliente de atención deberá permitir la gestión operativa mínima del agente, incluyendo como mínimo: ingreso y salida de colas, estado “listo”, estado “no disponible” y cierre de sesión, conforme a permisos.
  7. Cuando exista estado “no disponible”, el cliente deberá permitir seleccionar el código de inactividad desde la lista configurada por la institución y reflejarlo para fines operativos y de supervisión.
  8. El cliente de atención deberá incluir controles telefónicos mínimos para: transferencia, conferencia, finalizar llamada, realizar llamada (tablero numérico o digitación), retener/reanudar, llamada en espera y silenciar micrófono, conforme a permisos.
  9. El cliente de atención deberá mostrar un listado de, al menos, las últimas veinte (20) llamadas Gestiónadas, mostrando como mínimo: número telefónico, fecha/hora y, para llamadas internas, el nombre del llamante, clasificando como mínimo en entrantes, salientes y perdidas.
  10. El cliente de atención deberá permitir devolver llamada al último número recibido o mediante el listado de llamadas, mediante una opción disponible para perfiles autorizados.
  11. El cliente de atención deberá incorporar un directorio de contactos telefónicos con campos mínimos: nombre, número telefónico y organización, sin perjuicio de campos adicionales definidos por la institución.
  12. El cliente de atención deberá permitir búsqueda de contactos y acceso rápido a contactos definidos, conforme a permisos.
  13. El cliente de atención deberá permitir accesos directos configurables o fijos, como mínimo para: contacto al supervisor, directorio de contactos, búsqueda de contactos y estadísticas del agente cuando aplique.
  14. El cliente de atención deberá presentar al agente la información de la llamada entrante (cuando esté disponible) y mantener consistencia de dicha información durante transferencias, retenciones y conferencias, conforme al flujo real de atención.
  15. El cliente de atención deberá soportar la reproducción de un mensaje de bienvenida personalizado por agente cuando aplique al diseño institucional, permitiendo ejecutarlo manualmente durante una llamada en curso conforme a permisos.
  16. El cliente de atención deberá mantener consistencia entre la identidad del agente (ID, nombre), la extensión o puesto de atención y la cola/VDN u otros identificadores operativos que correspondan, para efectos de trazabilidad e interoperabilidad.
• Compatibilidad, periféricos y ergonomía operativa
  1. Los terminales telefónicos y softphones deberán ser compatibles con periféricos de audio de uso operativo (por ejemplo: diademas/headsets), asegurando calidad de audio y estabilidad en atención continua.
  2. Cuando el diseño institucional requiera diademas o accesorios específicos (por ejemplo: controles físicos de silencio/volumen), el contratista deberá suministrarlos como parte integral de la solución.
  3. Los dispositivos y clientes de atención deberán permitir ajuste de volumen y control de audio de manera sencilla, sin afectar la operación del resto de componentes.
  4. Los terminales y clientes deberán soportar, cuando aplique, múltiples dispositivos de audio disponibles en el equipo del usuario (por ejemplo: selección de micrófono y salida), manteniendo operación estable.
• Administración centralizada y control
  1. El sistema de telefonía IP deberá permitir administración centralizada de teléfonos IP y softphones, incluyendo como mínimo: aprovisionamiento, asignación a usuarios, reasignación, respaldo de parámetros, restauración y control de inventario.
  2. El contratista deberá entregar a la lista de terminales y clientes implementados, su versión de firmware/software y su método de administración, como parte de la documentación técnica de la solución.
  3. Toda modificación relevante de asignación de terminal/softphone a usuario, extensión o perfil deberá quedar registrada para trazabilidad institucional, conforme al esquema de auditoría aplicable.
  4. El diseño no deberá permitir que un usuario no autorizado configure manualmente parámetros críticos del terminal o del softphone que afecten el tratamiento de llamadas, la seguridad o la trazabilidad, salvo funciones expresamente habilitadas por política institucional.
• Interoperabilidad y continuidad operativa
  1. Los terminales y clientes de atención deberán operar de forma consistente con el esquema de continuidad operativa definido para telefonía, permitiendo recuperación controlada ante pérdida temporal de conectividad o reinicio de componentes, según la arquitectura ofertada.
  2. El cliente de atención deberá mantener comportamiento predecible ante fallas parciales (por ejemplo: reconexión controlada, actualización de estado del agente, y registro de eventos relevantes cuando aplique), sin comprometer la atención más allá de lo técnicamente inevitable.
  3. Los teléfonos IP y softphones deberán preservar la entrega de identificadores operativos requeridos para correlación institucional (por ejemplo: número de origen, identificador de llamada central, extensión, identificación del agente y cola/VDN u equivalente), conforme a la integración definida en la sección correspondiente del módulo.
• Pruebas, aceptación y evidencias
  1. El contratista deberá ejecutar pruebas funcionales con participación institucional que evidencien, como mínimo, en teléfonos IP y en clientes softphone según aplique: atención de llamadas, transferencia, retención, conferencia, visualización de identificación de llamada, listado de llamadas, directorio, estados del agente y operación en cola ACD.
  2. Las pruebas deberán dejar evidencia verificable, incluyendo capturas, bitácoras y validaciones de operación, conforme a los criterios de aceptación definidos para este módulo.
  3. El contratista deberá entregar guías operativas de uso para agentes y supervisores aplicables a los terminales y clientes de atención, incluyendo procedimientos de inicio de sesión, cambio de estados, atención de llamadas, transferencias, conferencias y uso del directorio.

 

 

 

5.    Monitoreo, métricas operativas, tarificación y reportes de la plataforma de telefonía

5.1.  Definición objetivo y alcance del módulo

• La plataforma de telefonía deberá incorporar capacidades de monitoreo, métricas operativas, tarificación y reportes que permitan a la institución supervisar en forma continua el estado del servicio, detectar condiciones anómalas, generar evidencia verificable y apoyar la toma de decisiones operativas.
• El esquema de monitoreo y reportería deberá operar bajo un enfoque misión crítica, con disponibilidad acorde a operación 24/7/365 y con generación de registros verificables por la institución.
• El monitoreo y las métricas deberán cubrir, como mínimo, los componentes de control de llamadas, centro de contactos/ACD, dispositivos de borde e interconexión, consolas administrativas, repositorios de registros operativos y funciones de tarificación.
• El contratista deberá implementar y dejar en operación un monitoreo técnico 24/7 para los componentes asociados a la plataforma de telefonía (servicios, nodos, enlaces relevantes y componentes críticos), incorporando alertas, registros y consulta histórica.
• El monitoreo técnico deberá permitir visualizar el estado de salud del servicio, incluyendo como mínimo: disponibilidad de servicios, estado de nodos, utilización de recursos críticos, fallos, degradaciones y eventos de conmutación cuando aplique.
• El sistema de monitoreo deberá permitir parametrizar umbrales, severidades, condiciones de alerta, ventanas horarias y destinatarios de notificación, conforme a la organización institucional definida durante la implementación.
• Las alertas deberán soportar notificación por medios institucionales, incluyendo como mínimo correo electrónico, sin perjuicio de mecanismos adicionales soportados por la tecnología ofertada.
• El registro de alertas deberá conservar, como mínimo: fecha/hora, componente afectado, condición detectada, severidad, estado de la alerta (abierta/cerrada) y evidencia asociada.
• La plataforma de telefonía deberá permitir la consulta histórica de eventos por rangos de fechas y filtros por componente, severidad y tipo de evento.
• Los registros de monitoreo deberán mantener coherencia temporal mediante sincronización horaria institucional para correlación con auditorías, registros de llamadas y evidencias operativas.
• El monitoreo deberá permitir identificar condiciones técnicas que impacten la operación (por ejemplo, saturación de sesiones, fallos de interconexión, degradación de servicios de control), sin sustituir los controles operativos propios del ACD.
• La plataforma de telefonía deberá disponer de tableros o vistas de operación para identificación rápida de condiciones críticas, con información suficiente para una primera atención técnica y operativa.
• El contratista deberá entregar documentación de la configuración de monitoreo implementada (umbrales, severidades, destinatarios, eventos monitoreados, reportes disponibles y procedimientos de verificación).

5.2.  Monitoreo operativo y control de calidad del servicio

• La solución de telefonía deberá incorporar un módulo de monitoreo y control orientado al seguimiento integral de la operación y a la evaluación de la calidad del servicio, permitiendo supervisión en tiempo real y consulta histórica de la gestión asociada a la atención de comunicaciones.
• El módulo de monitoreo y control deberá contar con una interfaz gráfica de usuario en ambiente web, en idioma español, compatible con navegadores de uso general.
• El módulo de monitoreo y control deberá permitir la supervisión y monitoreo operativo por perfiles autorizados, incluyendo como mínimo el monitoreo en tiempo real de la operación de comunicaciones.
• El módulo deberá permitir la visualización en tiempo real de indicadores como mínimo: volumen de llamadas, tiempos de espera, comunicaciones atendidas y comunicaciones abandonadas.
• La supervisión operativa deberá ejecutarse conforme a perfiles y niveles de acceso definidos por la Administración, evitando accesos fuera del ámbito autorizado.
• El módulo deberá permitir consulta histórica de indicadores y resultados, con filtros por periodos, colas/ACD, agentes, extensiones y otros ámbitos disponibles.
• La plataforma deberá permitir la configuración de perfiles de seguridad para el módulo de monitoreo y control, de manera que las funciones de consulta, supervisión y evaluación estén restringidas por rol.
• Cuando el módulo contemple formularios o mecanismos de evaluación operativa/de calidad (cuando aplique), deberá permitir que un evaluador almacene una evaluación finalizada asignando un nombre descriptivo o utilizando un identificador provisto automáticamente por el sistema.
• El contratista deberá considerar el almacenamiento de las evaluaciones y controles generados durante toda la vigencia contractual y garantizar un respaldo confiable de dicha información.
• El módulo de monitoreo y control deberá ser compatible con la solución de telefonía IP propuesta y mantener coherencia con los datos operativos disponibles (colas, agentes, estados, tiempos y métricas).

5.3.  Métricas operativas del servicio de telefonía

• El sistema de telefonía IP deberá generar y disponibilizar métricas operativas del tráfico de llamadas, incluyendo como mínimo: llamadas entrantes, contestadas, no atendidas, transferidas, en espera, duraciones, tiempos de timbrado y tiempos de espera cuando aplique.
• La plataforma de telefonía deberá permitir desagregar métricas por criterios tales como: intervalo de tiempo, extensión, agente, cola/VDN u otros identificadores operativos equivalentes definidos por la institución.
• El centro de contactos deberá disponibilizar métricas operativas, incluyendo como mínimo: llamadas ofrecidas, atendidas, abandonadas, tiempo promedio de espera, tiempo promedio de atención y nivel de servicio cuando aplique.
• Las métricas deberán ser consultables en pantalla por perfiles autorizados y exportables para control institucional.
• La plataforma de telefonía deberá permitir comparación de periodos (por ejemplo: día vs día, semana vs semana, mes vs mes) para facilitar la detección de tendencias.
• El sistema deberá permitir reportes con periodicidad configurable (por ejemplo: diario, semanal, mensual u otros), conforme a necesidades institucionales.
• Cuando existan umbrales operativos (por ejemplo, umbrales del ACD), el sistema deberá permitir consolidar su visualización y conservar evidencia de activaciones, evitando pérdida de trazabilidad.
• El componente de telefonía deberá permitir reportes de disponibilidad y continuidad de componentes críticos (por ejemplo: indisponibilidades, degradaciones y eventos de conmutación), en la medida en que la arquitectura implementada lo soporte.

5.4.  Registro y control de llamadas y base de reportes

• El sistema de telefonía IP deberá generar y almacenar registros de detalle de llamadas (CDR) o equivalente, como evidencia operativa para consulta, control institucional y tarificación.
• La consulta de registros de detalle de llamadas deberá estar controlada por perfiles y permisos, y deberá permitir filtros operativos por rangos de fecha/hora, origen, destino, extensión y otros criterios disponibles.
• El repositorio de registros de detalle de llamadas deberá contar con redundancia que evite puntos únicos de falla para la trazabilidad operativa.
• El repositorio de registros deberá dimensionarse para almacenar la información durante la vigencia contractual o el periodo institucional que se defina, sin afectar la operación normal.
• La plataforma deberá permitir exportar registros y reportes derivados conforme a permisos autorizados.
• El sistema deberá permitir configurar alarmas ante inconvenientes detectados en la generación, almacenamiento o consulta de registros operativos, con notificación a destinatarios institucionales definidos.

5.5.  Tarificación

• La plataforma de telefonía deberá incorporar un servicio de tarificación o mecanismo equivalente basado en registros de detalle de llamadas, con interfaz web en idioma español, para consulta y generación de reportes conforme a permisos.
• El servicio de tarificación deberá generar informes sobre utilización de servicios de telefonía, indicando como mínimo: extensión que origina la llamada, número destino, hora y duración, y totales por período.
• El sistema de tarificación deberá permitir agrupar y consolidar resultados por criterios institucionales, incluyendo como mínimo: centro de costo, área y ubicación.
• La tarificación deberá permitir generar reportes, tableros y gráficos desde la interfaz web.
• Los resultados de tarificación deberán poder exportarse como mínimo a formatos PDF y Excel.
• El servicio de tarificación deberá permitir configurar alarmas ante fallos o inconsistencias en su operación normal, con notificación por correo electrónico a destinatarios institucionales definidos.
• La ejecución de reportes, consultas y exportaciones de tarificación no deberá afectar el desempeño del servicio telefónico ni la disponibilidad de la atención, aplicando mecanismos de control de recursos cuando corresponda.

5.6.  Reportes operativos y exportación

• La plataforma de telefonía deberá permitir reportes operativos orientados a la gestión institucional, incluyendo reportes por periodos y por ámbitos (extensión, agente, cola/VDN u otros).
• Los reportes deberán ser consultables por perfiles autorizados y permitir impresión o exportación conforme a permisos.
• El sistema deberá permitir exportar reportes como mínimo a formatos PDF y Excel, sin perjuicio de otros formatos disponibles autorizados por la institución.
• Los reportes deberán conservar consistencia de datos con los repositorios de evidencia (registros operativos), evitando discrepancias por procesamiento no trazable.
• La plataforma de telefonía deberá permitir definir plantillas, filtros y criterios de reporte reutilizables por perfiles autorizados, cuando la tecnología lo permita.
• El sistema deberá permitir programar la generación de reportes recurrentes cuando aplique, con entrega a destinatarios institucionales definidos y bajo control de permisos.

5.7.  Auditoría, acceso y verificación

• El acceso a métricas, tableros, reportes, registros operativos y tarificación deberá regirse por roles y permisos, aplicando segregación de funciones según política institucional.
• La plataforma deberá registrar auditoría de acciones relevantes asociadas a monitoreo, métricas y reportes, incluyendo como mínimo: consultas sensibles, exportaciones, cambios de configuración de umbrales/alertas y cambios de destinatarios.
• Los registros de auditoría deberán ser consultables por perfiles autorizados y exportables para control institucional, conforme a la política aplicable.
• El contratista deberá entregar documentación técnica y operativa de las capacidades de monitoreo, métricas, tarificación y reportes, incluyendo: catálogo de métricas, reportes disponibles, filtros, periodicidades, umbrales configurados, destinatarios de alertas y procedimientos de verificación.
• El contratista deberá ejecutar pruebas con participación institucional que evidencien, como mínimo: consulta y exportación de registros operativos, generación de reportes, funcionamiento de tarificación, activación de alarmas configuradas y consulta histórica de eventos, dejando evidencias verificables para aceptación.

5.8.  Alta disponibilidad y continuidad operativa de la plataforma de telefonía

• La plataforma de telefonía deberá operar bajo un esquema de alta disponibilidad y continuidad operativa acorde con un servicio misión crítica, garantizando atención continua 24/7/365 y mitigando puntos únicos de falla en los componentes esenciales.
• El diseño de alta disponibilidad de telefonía deberá alinearse con el esquema general de alta disponibilidad y continuidad operativa definido en la sección general correspondiente del pliego, sin perjuicio de los requerimientos específicos establecidos en el presente módulo.
• El contratista deberá implementar un modelo de operación activo-activo entre el sitio principal institucional y la infraestructura en el Data Center contratado por el 9-1-1 provista por el contratista, manteniendo capacidad operativa simultánea en ambos entornos conforme a la arquitectura ofertada.
• El modelo activo-activo deberá contemplar los componentes de control de llamadas, centro de contactos/ACD cuando aplique, servicios de administración indispensables, dispositivos de borde e interconexión y los repositorios de registros operativos requeridos para trazabilidad.
• La conectividad entre el sitio principal institucional y la infraestructura en el Data Center contratado por el 9-1-1 provista por el contratista deberá operar con enlace principal y enlace redundante, asegurando continuidad ante conmutación entre enlaces, sin afectar la atención más allá de lo técnicamente inevitable.
• El contratista deberá definir, documentar y dejar probado el comportamiento de la plataforma ante pérdida del enlace principal, incluyendo el mecanismo de conmutación al enlace redundante y el mecanismo de retorno a condición normal.
• La continuidad operativa deberá contemplar eventos de falla parcial, incluyendo como mínimo: caída de un nodo de control, falla de un servicio crítico, falla de un componente de borde, pérdida de conectividad entre entornos, falla de consola administrativa y degradación de recursos (CPU, memoria, almacenamiento o red).
• El sistema de telefonía IP no deberá depender de intervención manual inmediata para sostener la atención ante fallas parciales; cuando exista intervención requerida, deberá definirse como procedimiento controlado y documentado, incluyendo responsables y tiempos objetivo.
• Durante eventos de conmutación automática, failover, pérdida del enlace principal, caída parcial de nodo o falla de componentes de control, borde o servicios críticos bajo responsabilidad del contratista, a solución deberá preservar las llamadas activas en curso durante eventos de conmutación, siempre que técnicamente sea posible según la arquitectura ofertada y el tipo de falla presentada, debiendo el oferente documentar los escenarios cubiertos, las limitaciones técnicas aplicables y el comportamiento esperado ante cada evento.

 

La solución deberá mantener, además, la capacidad de recepción, distribución y atención de nuevas llamadas mediante los componentes redundantes habilitados. Este comportamiento deberá estar documentado en la arquitectura propuesta y deberá ser demostrado durante las pruebas de implementación, aceptación, continuidad operativa y alta disponibilidad.

Nota:    Debido a la inclusión del nuevo numeral 5.8.9., la numeración del articulado subsiguiente de esta sección sufre un desplazamiento secuencial de forma automática.

En consecuencia, el resto de los numerales posteriores se desplazan de manera correlativa a partir de dicha inclusión. Toda referencia realizada en el pliego original, anexos, aclaraciones o consultas que haga mención a los numerales modificados, deberá entenderse ajustada automáticamente a la nueva numeración de la presente versión corregida del Pliego de Condiciones, sin que esto altere el fondo, la validez, ni la obligatoriedad de los requisitos ahí contemplados.)

• El contratista deberá eliminar puntos únicos de falla en los siguientes elementos, como mínimo:
  1. Control de llamadas y señalización.
  2. Componentes esenciales del centro de contactos/ACD cuando aplique.
  3. Dispositivos de borde e interconexión de voz cuando sean parte de la arquitectura.
  4. Elementos de conectividad crítica entre componentes internos y entre entornos.
  5. Repositorios necesarios para trazabilidad operativa.
• El esquema de redundancia deberá contemplar componentes físicos y lógicos, incluyendo fuentes de poder, enlaces de red, interfaces críticas, servicios de virtualización cuando aplique y mecanismos de conmutación según la arquitectura implementada.
• La plataforma de telefonía deberá permitir mantenimiento planificado (parches, actualizaciones, cambios de configuración, sustitución de componentes) sin interrupción total de la atención, cuando la arquitectura ofertada lo permita.
• En caso de que un mantenimiento implique degradación temporal de capacidad, el contratista deberá definir el modo de operación durante mantenimiento, los límites operativos y las medidas para minimizar impacto en horas críticas.
• El contratista deberá definir los objetivos de continuidad aplicables a telefonía (por ejemplo, tiempos objetivo de recuperación y puntos objetivo de recuperación para configuraciones y registros), de forma consistente con el esquema general de continuidad operativa del pliego.
• El sistema de telefonía IP deberá mantener consistencia de configuraciones críticas durante conmutaciones, incluyendo como mínimo: plan de numeración, plan de marcado, rutas, restricciones de marcación, colas/ACD, perfiles y parámetros operativos.
• El contratista deberá implementar mecanismos de respaldo y restauración de configuraciones críticas de telefonía, con periodicidad definida, retención, evidencias de respaldo y procedimiento de restauración documentado.
• La restauración de configuraciones críticas deberá poder ejecutarse sin reinstalación completa de la solución y sin dependencias no contempladas en la arquitectura entregada.
• La continuidad operativa deberá asegurar que los registros operativos y evidencias de telefonía (por ejemplo, registros de llamadas, métricas y bitácoras técnicas) permanezcan disponibles para consulta autorizada según las políticas institucionales aplicables.
• El contratista deberá asegurar que la conmutación de componentes no genere duplicidades no controladas, inconsistencias de estado o pérdida de correlación de identificadores operativos de llamada necesarios para trazabilidad e interoperabilidad.
• En escenarios de falla parcial, la plataforma deberá mantener, como prioridad, la continuidad de recepción y atención de llamadas, aun cuando se degrade temporalmente el acceso a componentes no esenciales (por ejemplo, vistas administrativas), según la arquitectura ofertada.
• El contratista deberá especificar y documentar qué funciones pueden degradarse temporalmente sin comprometer la atención, y cuáles se consideran esenciales y no degradables.
• El diseño deberá contemplar la continuidad operativa del centro de contactos/ACD cuando aplique, incluyendo mantenimiento de colas, asignación de agentes, estados y reglas de desbordamiento, conforme a los límites del modo degradado definido.
• El esquema de alta disponibilidad deberá contemplar la continuidad de los dispositivos de borde e interconexión cuando formen parte de la arquitectura, evitando la pérdida total de interconexión por falla de un único equipo o enlace.
• La conmutación ante falla de un componente de borde deberá mantener la integridad de señalización y medios, preservando identificadores operativos requeridos para el tratamiento y trazabilidad de la llamada.
• El contratista deberá definir el comportamiento ante pérdida de un entorno completo (sitio principal o Data Center del 9-1-1), incluyendo el modo de operación resultante, el alcance funcional disponible y el procedimiento para retorno controlado a operación normal.
• El contratista deberá implementar monitoreo continuo y alertamiento para los componentes de la plataforma de telefonía desplegados en la infraestructura en el Data Center del 9-1-1, integrándolo con el esquema institucional de soporte definido para la solución, permitiendo identificar fallas, degradaciones y eventos relevantes de continuidad.
• El contratista deberá diseñar, implementar y mantener un plan de respaldo y restauración aplicable a las configuraciones y componentes críticos de la plataforma de telefonía durante toda la vigencia contractual, alineado con el plan general definido en el pliego, incluyendo como mínimo: componentes a respaldar, periodicidad, retención, procedimiento de restauración y verificación periódica mediante pruebas documentadas.
• La solución deberá permitir pruebas controladas de conmutación y continuidad operativa, sin afectar la operación real más allá de ventanas autorizadas por la institución.
• El contratista deberá ejecutar, con participación institucional, pruebas de continuidad que incluyan como mínimo:
  1. Conmutación por pérdida de un nodo de control de llamadas.
  2. Conmutación por falla de un componente crítico del ACD cuando aplique.
  3. Conmutación por falla de un dispositivo de borde cuando aplique.
  4. Conmutación por pérdida del enlace principal entre entornos.
  5. Operación en modo degradado y retorno a condición normal.
• Las pruebas deberán dejar evidencias verificables, incluyendo bitácoras técnicas, registros de eventos, resultados observados, tiempos de recuperación y actas de validación institucional.
• El contratista deberá documentar procedimientos operativos de continuidad, incluyendo: activación de contingencias, verificación de estado, comunicación de incidentes, escalamiento y retorno a condición normal.
• La plataforma deberá soportar sincronización horaria consistente en ambos entornos y en todos los componentes, de forma que eventos de conmutación y fallas sean correlacionables en bitácoras y reportes.
• El sistema de telefonía IP deberá mantener coherencia operativa con el componente de respuesta interactiva de voz y con el sistema de grabación de llamadas definidos en sus secciones correspondientes, asegurando que sus mecanismos de continuidad no se contradigan ni generen puntos únicos de falla adicionales.
• Cuando los componentes de respuesta interactiva de voz y grabación tengan sus propios mecanismos de redundancia, el contratista deberá asegurar compatibilidad y coordinación de conmutaciones para evitar pérdida de estabilidad o inconsistencias operativas.
• El contratista deberá entregar diagramas actualizados de alta disponibilidad de telefonía, mostrando redundancias, enlaces críticos, dependencias y flujos de conmutación, acompañados de un documento descriptivo del comportamiento ante fallas.
• El contratista deberá detallar el licenciamiento y capacidades asociadas a alta disponibilidad, garantizando que no existan restricciones de licencia que impidan operar en redundancia, conmutación o crecimiento durante la vigencia contractual.
• La institución no aceptará esquemas donde la continuidad operativa dependa de adquisiciones posteriores no contempladas en la oferta o de componentes externos no incluidos como parte integral de la solución.
• La continuidad operativa deberá considerar fallas simultáneas razonables (por ejemplo, falla de un nodo y degradación de un enlace), según el nivel de redundancia ofertado y validado en pruebas.
• El contratista deberá mantener actualizado un inventario de componentes críticos de telefonía sujetos a alta disponibilidad, indicando su rol, redundancia asociada, dependencias y puntos de monitoreo.
• La aceptación de este apartado requerirá evidencia de la implementación, documentación completa, pruebas ejecutadas y estabilidad operativa del esquema de alta disponibilidad en operación controlada conforme a criterios institucionales.

5.9.  Seguridad específica de telefonía y controles antifraude

• La plataforma de telefonía deberá incorporar controles de seguridad específicos para proteger la señalización, los medios, la administración y los servicios operativos asociados, de manera que se minimicen riesgos de intrusión, fraude telefónico, abuso de recursos y alteración de la trazabilidad.
• Los controles de seguridad de telefonía deberán alinearse con el marco general de seguridad definido en la sección correspondiente del pliego, sin duplicar disposiciones generales, incorporando únicamente requisitos específicos del componente de telefonía.
• El sistema de telefonía IP deberá aplicar el principio de mínimo privilegio, asegurando que los accesos administrativos, operativos y de supervisión estén limitados por roles y permisos, con segregación de funciones entre administración técnica, administración operativa y operación de atención.
• La autenticación de usuarios para consolas administrativas y clientes de atención deberá integrarse con el Directorio Activo institucional y, cuando aplique, con inicio de sesión único (SSO), evitando cuentas locales no administradas por la institución.
• La solución deberá permitir controlar el acceso administrativo por origen de conexión, permitiendo definir listas de equipos o segmentos autorizados para administración, conforme a políticas institucionales.
• El componente de telefonía deberá permitir control por roles para funciones sensibles, incluyendo como mínimo: cambios de rutas, cambios de reglas de marcación, cambios de restricciones, habilitación de destinos externos, cambios de perfiles, exportación de registros y cambios de parámetros de continuidad operativa.
• Toda acción administrativa relevante deberá registrarse en auditoría, indicando como mínimo: usuario, fecha/hora, componente afectado, tipo de acción y detalle del cambio.
• La plataforma de telefonía deberá incluir mecanismos de protección contra fraudes de telefonía (toll fraud) y uso indebido de llamadas salientes, mediante restricciones, validaciones y monitoreo de patrones anómalos conforme a la política institucional.
• El sistema deberá permitir definir listas de destinos externos autorizados y listas de destinos prohibidos, aplicables por perfil, grupo o condición operativa, evitando llamadas hacia destinos no autorizados.
• El componente de telefonía deberá permitir aplicar restricciones por prefijos o rangos, incluyendo reglas diferenciadas por perfiles y por horarios, conforme a políticas institucionales.
• El sistema deberá permitir reglas de prevención antifraude basadas en umbrales o patrones, incluyendo como mínimo:
  1. Tasa de intentos de llamadas por extensión o por origen.
  2. Cantidad de llamadas salientes por intervalo de tiempo.
  3. Intentos fallidos repetitivos hacia destinos externos.
  4. Incrementos anómalos de duración o frecuencia según criterio institucional.
• Cuando se detecten patrones anómalos o condiciones de riesgo, la plataforma deberá permitir ejecutar acciones automáticas o controladas, incluyendo como mínimo: bloqueo temporal, restricción de marcación, notificación a destinatarios institucionales y registro auditable del evento.
• El sistema de telefonía IP deberá proteger la señalización SIP ante intentos de abuso o ataques, incluyendo controles de limitación de tasa, validación de orígenes, listas de permitidos/bloqueados y mecanismos equivalentes disponibles en la tecnología ofertada.
• El componente de borde (SBC u equivalente) deberá soportar medidas de protección específicas para SIP, incluyendo ocultamiento de topología y filtrado de tráfico no autorizado, conforme al diseño implementado.
• El sistema deberá permitir definir reglas para aceptación o rechazo de sesiones SIP basadas en criterios tales como troncal, dominio, dirección origen, certificados cuando aplique, rangos autorizados y condiciones de operación.
• La plataforma de telefonía deberá preservar la integridad de identificadores de llamada, número origen y número marcado cuando estén disponibles, evitando alteraciones no justificadas que afecten trazabilidad y correlación institucional.
• Cuando la arquitectura lo permita y la política institucional lo defina, la solución deberá soportar cifrado de señalización y/o medios, manteniendo interoperabilidad con los enlaces SIP existentes y con los componentes internos autorizados.
• La administración de certificados digitales requeridos para cifrado o autenticación deberá documentarse y ejecutarse bajo coordinación institucional, manteniendo control de vigencia, renovación y almacenamiento seguro.
• El sistema de telefonía IP deberá permitir segmentación lógica de red para separar administración, señalización y medios, conforme a la segmentación institucional definida durante la implementación.
• La plataforma de telefonía deberá permitir registrar eventos de seguridad relevantes, incluyendo como mínimo: intentos de acceso fallidos, cambios críticos de configuración, intentos de llamadas bloqueadas por política, rechazos de sesiones SIP por reglas y activaciones de mecanismos antifraude.
• Los registros de seguridad deberán ser consultables por perfiles autorizados y exportables para control institucional, manteniendo sincronización horaria consistente para correlación con otros eventos.
• La solución deberá permitir configurar alertas ante eventos de seguridad relevantes, con notificación a destinatarios institucionales definidos, incluyendo como mínimo correo electrónico.
• El sistema de telefonía IP deberá permitir políticas de sesión y control de acceso, incluyendo bloqueo o restricción ante múltiples intentos fallidos, cierre de sesión forzado por perfiles autorizados y limitación de sesiones concurrentes cuando aplique.
• El componente de telefonía deberá permitir registrar y controlar exportaciones de registros operativos sensibles (por ejemplo, CDR, reportes o datos de tarificación), manteniendo auditoría del usuario, fecha/hora y criterio aplicado.
• La plataforma deberá permitir definir políticas para cambios de configuración en horarios controlados, con registro y capacidad de reversión, conforme al control de cambios institucional.
• El contratista deberá entregar un documento de endurecimiento y configuración segura específico de telefonía, que incluya como mínimo: controles implementados, parámetros relevantes, reglas antifraude, perfiles y permisos, y recomendaciones operativas para mantenimiento seguro.
• El contratista deberá ejecutar pruebas con participación institucional que evidencien, como mínimo: aplicación efectiva de restricciones de marcación, bloqueo por listas, generación de alertas antifraude, registro auditable de cambios críticos, y protección ante intentos no autorizados de acceso a consolas y servicios.
• La plataforma de telefonía deberá mantener coherencia con el componente de respuesta interactiva de voz y con el sistema de grabación de llamadas definidos en sus secciones correspondientes, asegurando que los controles de seguridad no afecten la continuidad del servicio ni permitan bypass de controles antifraude o de trazabilidad.

5.10.          Integraciones e interoperabilidad

• La plataforma de telefonía deberá incorporar capacidades de integración e interoperabilidad que permitan su operación coordinada con el Sistema de Gestión de Incidentes y con los demás componentes institucionales autorizados, garantizando trazabilidad, control de acceso, continuidad operativa y verificabilidad mediante pruebas.
• Las integraciones deberán implementarse mediante interfaces documentadas y mecanismos estándar de la industria (por ejemplo, servicios, APIs o mecanismos equivalentes), evitando dependencias cerradas que limiten la interoperabilidad o condicionen a la institución a un único fabricante o integrador.
• El contratista será responsable de diseñar, suministrar, implementar, configurar, probar y dejar operativas las integraciones requeridas, incluyendo componentes técnicos, licenciamiento y servicios necesarios para su funcionamiento continuo.
• La propuesta técnica deberá describir las capacidades de interoperabilidad ofrecidas, indicando como mínimo: interfaces disponibles, eventos soportados, formatos de intercambio, mecanismos de seguridad, alcance funcional y evidencias previstas para demostrar funcionamiento en pruebas de aceptación.
• Las integraciones deberán permitir el intercambio de información en tiempo real o cuasi tiempo real cuando la operación lo requiera, sin afectar la continuidad del servicio telefónico.
• La plataforma deberá registrar transacciones y eventos relevantes de interoperabilidad, incluyendo como mínimo: fecha y hora, origen y destino, tipo de operación, resultado, y componente o usuario ejecutor cuando aplique, permitiendo trazabilidad y auditoría.
• El acceso a funciones de integración y a los datos intercambiados deberá estar protegido por roles y permisos, evitando accesos no autorizados.
• Las integraciones deberán permitir incorporar fuentes adicionales o nuevas integraciones autorizadas por la institución, sin rediseños estructurales y manteniendo control de acceso, trazabilidad y auditoría.

5.11.          Integración operativa Sistema de Gestión de Incidentes y Telefonía (evento de ingreso y correlación)

• La integración operativa entre la solución y el Sistema de Gestión de Incidentes deberá permitir, como mínimo, asociar el identificador de la llamada con el registro operativo correspondiente, manteniendo trazabilidad completa entre ingreso de una llamada, sms, videollamada registro y acciones ejecutadas durante la atención.
• Al momento en que el cliente de atención tipo softphone reciba un evento proveniente del ACD para atención de emergencias, deberá generarse el evento de ingreso del reporte en la plataforma CAD, conforme al mecanismo de integración definido.
• Como resultado de la integración, el cliente de atención o el componente correspondiente deberá remitir a la plataforma CAD un paquete de datos que indique el ingreso del evento, conteniendo como mínimo:
  1. Número telefónico que origina la llamada.
  2. Identificador del registro de la llamada a nivel de la central telefónica.
  3. Número de extensión telefónica desde la cual se atiende la llamada.
  4. Identificador del agente ACD con sesión activa.
  5. Nombre del agente ACD con sesión activa.
  6. VDN o identificador operativo equivalente por el cual ingresa la llamada en la central telefónica.
• El evento deberá presentarse al agente en el cliente de atención, de forma paralela a la gestión del reporte en el CAD, garantizando operación coordinada y consistente entre ambos componentes.
• La integración deberá permitir consultar posteriormente la relación evento–registro operativo mediante criterios de búsqueda por fecha y hora, usuario, estación de trabajo cuando aplique, número telefónico y/o identificadores operativos disponibles, conforme a permisos autorizados.
• La plataforma deberá preservar y proveer los identificadores necesarios para correlación operativa (por ejemplo: identificador de evento, extensión, agente, cola/VDN u otros equivalentes), evitando alteraciones no controladas que afecten trazabilidad.
• Cuando existan transferencias, conferencias, retenciones, desbordamientos u otros eventos relevantes, la integración deberá permitir conservar la trazabilidad mínima necesaria para reconstruir el flujo real de atención.

5.12.          Interoperabilidad con componentes institucionales autorizados

• La plataforma deberá permitir interoperar con servicios institucionales autorizados que aporten datos asociados a la comunicación (por ejemplo, datos complementarios relacionados con el evento), manteniendo control de accesos y auditoría de consultas o consumos cuando aplique.
• Cuando se consuman servicios institucionales, la solución deberá utilizar mecanismos autenticados y controlados, evitando accesos directos no autorizados a bases de datos institucionales.
• La plataforma deberá permitir parametrizar endpoints, tiempos máximos de espera, políticas de reintento y mecanismos de autenticación para integraciones, bajo perfiles autorizados y control de cambios.

5.13.          Integración operativa con respuesta automatizada y grabación

• La plataforma deberá operar de forma integrada con el componente de respuesta automatizada definido por la institución, garantizando que el encaminamiento y entrega de eventos hacia ACD, extensiones o destinos autorizados se ejecute de forma consistente y trazable.
• La plataforma deberá operar de forma integrada con el sistema de grabación definido por la institución, asegurando que el flujo real de atención (transferencias, retenciones, conferencias y demás eventos) sea consistente con los metadatos y referencias operativas necesarias para trazabilidad.

5.14.          Requisitos técnicos de integración, documentación y control

• El contratista deberá entregar un catálogo de interfaces de integración aplicables, incluyendo como mínimo: descripción funcional, tipo de interfaz, eventos y operaciones disponibles, formatos de datos, diccionario de campos, validaciones y ejemplos de intercambio.
• Toda interfaz expuesta o consumida por la plataforma deberá incluir mecanismos de autenticación y autorización, evitando credenciales embebidas, claves compartidas sin control o accesos sin registro.
• Las integraciones deberán contemplar manejo de errores y condiciones de indisponibilidad, evitando que la falla temporal de un servicio externo autorizado bloquee la recepción o atención de llamadas; en dichos casos deberá registrarse el evento para auditoría y control institucional.
• El contratista deberá documentar los flujos de integración, indicando eventos de inicio, puntos de intercambio de datos, dependencias, reglas de negocio relevantes para el intercambio y resultado esperado en cada etapa.
• Las integraciones deberán soportar control de versiones y cambios controlados, de manera que ajustes posteriores no afecten la operación ni rompan compatibilidad con componentes institucionales existentes.
• La interoperabilidad no deberá quedar condicionada a herramientas propietarias no contempladas como parte integral de la solución; los mecanismos de integración deberán ser verificables por la institución mediante documentación y pruebas.

5.15.          Pruebas, aceptación y evidencias

• El contratista deberá ejecutar pruebas de integración con participación institucional, que evidencien como mínimo: generación del evento de ingreso de evento al Sistema de Gestión de Incidentes, envío del paquete mínimo de datos, correlación evento–registro operativo y consulta posterior de la relación mediante criterios autorizados.
• Las pruebas deberán incluir escenarios controlados de falla parcial (por ejemplo, indisponibilidad temporal de un servicio de integración autorizado), verificando que la atención de llamadas continúe y que el evento quede registrado.
• El contratista deberá entregar evidencias verificables de las pruebas (bitácoras, auditorías, capturas, listados de transacciones y actas de validación institucional), como condición para la aceptación de las integraciones.
• La institución podrá requerir ajustes a integraciones autorizadas durante la implementación para asegurar consistencia operativa, trazabilidad y seguridad; dichos ajustes deberán ejecutarse bajo control de cambios y con validación funcional.

5.16.          Mensajería de texto y videollamadas

• La plataforma deberá permitir la gestión de comunicaciones multimedia que incluyan mensajería de texto, SMS, chat y videollamadas, asegurando control institucional, trazabilidad, seguridad, continuidad operativa e integración con los componentes de atención definidos.
• El contratista deberá suministrar, implementar, configurar, probar y dejar en operación las capacidades de mensajería de texto, SMS, chat y videollamadas, incorporando licenciamiento, componentes y servicios necesarios para su operación continua 24/7/365.
• Las capacidades de mensajería de texto, SMS, chat y videollamadas deberán ser atendidas desde el mismo entorno operativo utilizado por los agentes autorizados, preferiblemente desde el centro de contactos y/o cliente de atención definido por la institución, sin requerir plataformas aisladas, consolas separadas o flujos operativos independientes que fragmenten la atención.
• La solución deberá permitir que las comunicaciones de voz, mensajería de texto, SMS, chat y videollamadas sean gestionadas mediante una cola lógica unificada o cola operativa común, integrada al centro de contactos, en la cual participen únicamente los agentes que cuenten con el perfil, permiso, competencia o habilitación correspondiente para atender cada tipo de interacción.
• La asignación de interacciones deberá realizarse conforme a reglas configurables de disponibilidad, perfil, prioridad, canal y capacidad del agente, evitando la generación de eventos operativos separados, colas paralelas no autorizadas o registros desvinculados del flujo institucional de atención.
• Las interacciones de mensajería de texto, SMS, chat y videollamadas deberán poder asociarse al registro operativo correspondiente, de manera que queden vinculadas a la atención institucional, sin generar reportes, incidentes o eventos independientes, salvo autorización expresa de la institución.
• La solución deberá permitir definir políticas de uso para mensajería de texto, SMS, chat y videollamadas, incluyendo como mínimo: perfiles habilitados, canales autorizados, reglas de asignación, restricciones por horarios, criterios de prioridad y reglas operativas para continuidad.
• El acceso a mensajería de texto, SMS, chat y videollamadas deberá regirse por roles y permisos, aplicando segregación de funciones según política institucional.
• Toda acción relevante sobre comunicaciones multimedia deberá quedar registrada en auditoría, incluyendo como mínimo: inicio de sesión, recepción, respuesta, transferencia, cierre, consulta, exportación y cambios de configuración.
• La indisponibilidad temporal de mensajería de texto, SMS, chat o videollamadas no deberá afectar la continuidad de la atención telefónica principal; en dichos casos deberá registrarse el evento para control institucional.

5.17.          Mensajería de texto

• La solución deberá permitir la recepción y gestión de interacciones de texto bajo el alcance contratado, incluyendo como mínimo mensajería tipo SMS, tipo WhatsApp y, cuando aplique por la arquitectura ofrecida, capacidades de texto en tiempo real (RTT) u otro mecanismo equivalente autorizado por la institución.
• Cuando se requiera interoperar con esquemas de mensajería basados en WhatsApp, el proveedor debe conectarse con META mediante un broker. La solución deberá soportar el mecanismo de interconexión aplicable para su entrega al entorno de atención, manteniendo trazabilidad de sesión e identificadores de la interacción.
• Cuando se requiera interoperar con esquemas de mensajería basados en SMS o mecanismos equivalentes, la solución deberá soportar el mecanismo de interconexión aplicable para su entrega al entorno de atención, manteniendo trazabilidad de sesión e identificadores de la interacción.
• El consumo efectivo de SMS será asumido por el Sistema de Emergencias 9-1-1 mediante el servicio de telecomunicaciones contratado o autorizado por la Administración, de forma similar al tratamiento del tráfico telefónico. En consecuencia, el oferente no deberá cotizar el consumo de SMS como rubro variable a cargo del contratista. No obstante, deberá incluir en su oferta todos los componentes, configuraciones, integraciones, licenciamiento, soporte, pruebas y servicios técnicos necesarios para que la solución opere adecuadamente.

Nota:    Debido a la inclusión del nuevo numeral 5.17.4., la numeración del articulado subsiguiente de esta sección sufre un desplazamiento secuencial de forma automática.

En consecuencia, el resto de los numerales posteriores se desplazan de manera correlativa a partir de dicha inclusión. Toda referencia realizada en el pliego original, anexos, aclaraciones o consultas que haga mención a los numerales modificados, deberá entenderse ajustada automáticamente a la nueva numeración de la presente versión corregida del Pliego de Condiciones, sin que esto altere el fondo, la validez, ni la obligatoriedad de los requisitos ahí contemplados.)

• La mensajería de texto deberá permitir, como mínimo: recepción, respuesta, continuidad de hilo o sesión cuando aplique, cierre controlado de sesión y registro de eventos de la interacción.
• El sistema deberá permitir asociar la interacción de texto a un agente, cola o ámbito operativo equivalente, registrando fecha y hora, identificadores disponibles, resultado de entrega/recepción y estado final de la interacción.
• La solución deberá permitir el uso de plantillas o respuestas predefinidas cuando aplique, bajo control institucional, con registro de su uso por agente.
• El historial de mensajes deberá conservarse y ser consultable por perfiles autorizados, con filtros mínimos por rango de fechas, agente/usuario, número origen/destino o identificador equivalente, estado y criterio de búsqueda definido.
• El sistema deberá permitir exportar el historial de mensajería conforme a permisos autorizados, manteniendo registro auditable de cada exportación.
• La solución deberá permitir métricas y reportes básicos de mensajería, incluyendo como mínimo: cantidad de mensajes enviados/recibidos por período, por agente y por cola cuando aplique, y estados de entrega.
• La plataforma deberá permitir alertas ante fallos relevantes del servicio de mensajería (por ejemplo: fallos de entrega, indisponibilidad del servicio o saturación), conforme al esquema institucional de soporte.
• La solución deberá contemplar manejo de contingencias, de manera que la indisponibilidad temporal de mensajería no afecte la continuidad de la atención telefónica principal, manteniendo registro del evento y su impacto operativo.

5.18.          Mensajería institucional por WhatsApp

• La solución deberá permitir la gestión de mensajería institucional por medio de WhatsApp, contemplando el envío de mensajes salientes por parte de la Administración y la recepción controlada de respuestas asociadas a dichos mensajes, campañas, contactos o interacciones previamente autorizadas.
• La mensajería por WhatsApp deberá operar integrada al entorno de gestión definido por la Administración, permitiendo el envío de mensajes institucionales y la recepción controlada de respuestas asociadas a dichos mensajes, campañas, contactos o interacciones previamente autorizadas.
• La solución deberá permitir registrar, consultar, auditar y dar seguimiento a las respuestas recibidas, manteniendo trazabilidad de fecha, hora, usuario responsable, contacto, estado de entrega, estado de respuesta e identificador de conversación cuando corresponda.
• La habilitación de WhatsApp no implicará, por sí misma, la creación de un canal oficial alternativo para la recepción general de emergencias, ni sustituirá la atención telefónica principal del 9-1-1. Cualquier uso del canal para atención directa, derivación operativa o gestión de reportes deberá quedar sujeto a las reglas, perfiles, horarios, protocolos y autorizaciones expresas que defina la Administración.
• En caso de que una persona usuaria inicie una comunicación directa por WhatsApp hacia el número, enlace, código QR u otro medio institucional habilitado, la solución deberá permitir aplicar reglas de recepción controlada, respuesta automática, clasificación, registro y derivación conforme a los lineamientos que defina la Administración.
• La Administración podrá definir que estos mensajes sean tratados como comunicaciones informativas, consultas, respuestas a campañas, reportes no urgentes o cualquier otra categoría autorizada, sin que ello implique la obligación automática de tramitar emergencias por este canal, salvo que así sea establecido formalmente mediante protocolo institucional.
• La solución deberá permitir configurar mensajes automáticos de orientación para las personas usuarias, indicando que, ante una emergencia en curso o una situación que requiera atención inmediata, deberán comunicarse por los canales oficiales definidos por el Sistema de Emergencias 9-1-1. Dichos mensajes deberán ser configurables por la Administración.
• Para efectos de dimensionamiento, el oferente deberá considerar un volumen estimado de 25.000 mensajes salientes mensuales por WhatsApp, destinados a comunicaciones institucionales, campañas autorizadas, avisos, notificaciones u otros usos definidos por la Administración.
• El contratista deberá proveer, configurar, habilitar y mantener el mecanismo de interconexión necesario con la plataforma oficial de WhatsApp Business o mecanismo equivalente autorizado, mediante proveedor, intermediario, broker o canal técnicamente habilitado para tales efectos, incluyendo los componentes, integraciones, permisos, configuraciones, servicios y costos necesarios para su operación.
• El oferente deberá indicar en su oferta la capacidad incluida para mensajes salientes, mensajes entrantes, respuestas de usuarios, conversaciones, sesiones o unidad de consumo aplicable según el modelo técnico y comercial utilizado, así como el costo unitario por excedentes, cuando corresponda.
• El contratista deberá suministrar una aplicación web, módulo o interfaz equivalente que permita a perfiles autorizados por la Administración elaborar, revisar, aprobar, programar y enviar mensajes salientes por WhatsApp a contactos, grupos, listas o bases definidas por la Administración.
• La aplicación web, módulo o interfaz deberá permitir, como mínimo:
  • Crear y editar mensajes salientes.
  • Adjuntar imágenes u otros archivos permitidos por el canal, cuando corresponda.
  • Asociar mensajes a contactos, grupos, listas o bases institucionales autorizadas.
  • Gestionar campañas o envíos institucionales autorizados.
  • Programar envíos, cuando la funcionalidad sea ofertada.
  • Registrar fecha, hora, usuario responsable, destinatarios, estado de envío, estado de entrega, respuestas recibidas, conversaciones generadas y errores.
  • Consultar el historial de mensajes enviados y recibidos.
  • Generar reportes de mensajes enviados, entregados, fallidos, pendientes, rechazados, respondidos y atendidos.
  • Mantener trazabilidad y auditoría de las acciones realizadas.
• La solución deberá permitir cargar, administrar o integrar listas de contactos autorizadas por la Administración, aplicando controles de seguridad, acceso, uso, actualización y resguardo de la información.
• Cuando una persona usuaria responda a un mensaje enviado por la Administración, la solución deberá permitir asociar dicha respuesta con el mensaje original, campaña, contacto, número de origen, identificador de conversación o registro operativo correspondiente, cuando técnicamente sea posible.
• La solución deberá registrar los metadatos mínimos de las interacciones por WhatsApp, incluyendo como mínimo: fecha y hora de envío, fecha y hora de recepción, número o identificador disponible, usuario institucional responsable, estado del mensaje, estado de entrega, estado de respuesta, conversación asociada, adjuntos cuando existan, resultado final y errores relevantes.
• Toda interacción por WhatsApp deberá quedar registrada para efectos de supervisión, auditoría, reportería, control institucional y trazabilidad, conforme a los permisos, perfiles y políticas definidas por la Administración.
• La solución deberá permitir reportes mensuales de operación del canal WhatsApp, incluyendo como mínimo: cantidad de mensajes salientes, cantidad de mensajes entrantes, respuestas recibidas, conversaciones generadas, conversaciones atendidas cuando corresponda, conversaciones no atendidas, estados de entrega, errores, fallos del canal, usuarios institucionales participantes y distribución por período.
• La indisponibilidad, degradación o falla del canal de WhatsApp no deberá afectar la operación principal de la atención telefónica de emergencias ni los componentes críticos de la Línea 1, debiendo registrarse el evento para control institucional, seguimiento y aplicación de los niveles de servicio que correspondan.
• El uso de WhatsApp deberá realizarse conforme a las condiciones técnicas, legales, operativas, de seguridad, confidencialidad y protección de datos aplicables, así como a las políticas vigentes del canal utilizado, sin que ello exima al contratista de garantizar la trazabilidad, seguridad y control institucional del servicio ofertado.
• La Administración podrá definir, modificar, suspender o restringir el uso del canal WhatsApp, total o parcialmente, conforme a criterios de seguridad, continuidad operativa, protección de datos, conveniencia institucional, política pública, capacidad operativa o lineamientos internos.

5.19.          Videollamadas y contenido multimedia

• La solución deberá permitir establecer, mantener y finalizar videollamadas bajo control institucional, con registro de eventos, trazabilidad de la sesión y asociación con el flujo de atención correspondiente.
• Las videollamadas deberán poder ser iniciadas por la persona usuaria mediante un enlace disponible en una página web, aplicativo institucional u otro canal autorizado por la Administración, sin que se requiera la instalación obligatoria de aplicaciones, programas, complementos o componentes adicionales en el dispositivo de la persona usuaria.
• La solución deberá permitir que el operador, agente o perfil autorizado envíe a la persona usuaria un enlace seguro para iniciar una videollamada, mediante SMS, mensaje de texto, chat u otro canal autorizado por la institución.
• Los enlaces generados para iniciar videollamadas deberán contar con mecanismos de seguridad y control, incluyendo como mínimo identificación de sesión, vigencia temporal, control de acceso, trazabilidad de uso y prevención de accesos no autorizados.
• La videollamada deberá poder asociarse al agente, cola o ámbito operativo equivalente, así como al registro operativo correspondiente, de manera que se mantenga trazabilidad entre la comunicación, la persona atendida, el operador interviniente y la gestión institucional realizada.
• La solución deberá registrar metadatos mínimos de la videollamada, incluyendo como mínimo: fecha y hora de inicio y fin, duración, identificador de sesión, agente u operador asociado, canal de inicio, estado final de la sesión y resultado operativo.
• Las videollamadas deberán ser grabadas y conservadas conforme a las políticas institucionales de grabación, almacenamiento, consulta, retención, seguridad, auditoría y exportación aplicables a las comunicaciones atendidas por el Sistema de Emergencias 9-1-1.
• La grabación de la videollamada deberá incluir, como mínimo, el audio y video de la sesión, así como los metadatos necesarios para su búsqueda, consulta, trazabilidad, reproducción y exportación por perfiles autorizados.
• La solución deberá permitir la realización de videollamadas en modalidad de conferencia, de forma que puedan incorporarse participantes adicionales autorizados, tales como supervisores, personal especializado, instituciones de respuesta u otros perfiles definidos por la Administración, manteniendo control de acceso, trazabilidad y registro de participación.
• La plataforma deberá permitir controles operativos para videollamadas, incluyendo como mínimo: aceptación, rechazo, finalización, incorporación de participantes autorizados, retiro de participantes, recuperación ante reconexión y cierre controlado de la sesión, sin perder trazabilidad.
• Las videollamadas y el contenido multimedia deberán operar desde los clientes de atención definidos por la institución, tales como cliente de atención, softphone, interfaz web o consola operativa autorizada, sin requerir plataformas aisladas, consolas separadas o aplicaciones externas no contempladas como parte integral de la solución.
• La solución deberá permitir la recepción y visualización controlada de contenido multimedia asociado a la interacción, incluyendo imágenes, videos o archivos adjuntos, cuando sean remitidos por la persona usuaria o generados durante la atención, manteniendo control de accesos, auditoría y trazabilidad.
• La solución deberá permitir métricas y reportes básicos de videollamadas, incluyendo como mínimo: cantidad de sesiones, duración, estados, fallos relevantes, sesiones iniciadas por enlace, sesiones iniciadas por envío del operador, conferencias realizadas y distribución por período, agente o cola.
• La plataforma deberá permitir alertas ante fallos relevantes del servicio de videollamadas o de contenido multimedia, conforme al esquema institucional de soporte.
• La solución deberá implementar controles para evitar suplantación, uso no autorizado, acceso indebido, exposición de datos sensibles o participación no autorizada en videollamadas, conforme a las políticas institucionales y controles de seguridad aplicables.

5.20.                     Documentación y pruebas

• El contratista deberá entregar documentación técnica y operativa de mensajería de texto y videollamadas, incluyendo: arquitectura de componentes, flujos de atención, perfiles habilitados, bitácoras disponibles, métricas, reportes y procedimientos de operación.
• El contratista deberá ejecutar pruebas con participación institucional que evidencien como mínimo: envío y recepción de texto, registro y consulta de historial, aplicación de permisos, auditoría de eventos, y establecimiento y cierre de videollamada cuando aplique, dejando evidencias verificables para aceptación.
• Las pruebas deberán incluir escenarios controlados de falla parcial (por ejemplo, indisponibilidad temporal del servicio de mensajería o video), verificando continuidad de atención por los canales disponibles y registro del evento.
• Las pruebas deberán dejar evidencias verificables (bitácoras, auditorías, capturas y actas de validación institucional) para aceptación.
• La institución podrá requerir ajustes operativos a flujos, plantillas, permisos o reglas de operación durante la implementación, debiendo el contratista ejecutarlos bajo control de cambios y con validación funcional.
• Las videollamadas deberán contar con un motor o funcionalidad de videollamada de uso común en el mercado, sin que ello implique la obligación de utilizar una marca, producto, fabricante, plataforma comercial o servicio específico. Esta funcionalidad tendrá como finalidad apoyar la atención de emergencias, especialmente cuando se requiera habilitar un canal visual de comunicación con personas sordas o con discapacidad auditiva, u otros casos en que la Administración lo estime necesario conforme a sus protocolos operativos. La persona usuaria deberá poder acceder a la videollamada mediante enlace seguro o mecanismo equivalente autorizado, sin que se le exija instalar aplicaciones, programas, complementos, extensiones o componentes adicionales en su dispositivo. Esta condición resulta necesaria para evitar barreras de acceso durante una emergencia y para asegurar que el mecanismo pueda ser utilizado de forma inmediata, sencilla y segura. La funcionalidad deberá operar integrada al flujo de atención de la solución, con seguridad, trazabilidad, control institucional, metadatos, registro, grabación cuando corresponda, auditoría y asociación a la interacción o caso respectivo, conforme a las condiciones establecidas en el pliego.

5.21.          Requisitos de desempeño y aceptación

• La plataforma deberá garantizar un desempeño consistente con operación misión crítica, asegurando continuidad del servicio, estabilidad bajo alta demanda y capacidad de crecimiento, sin afectar la atención de llamadas de emergencia.
• El contratista deberá definir y documentar, como parte de la implementación, los criterios de desempeño verificables aplicables a la plataforma de telefonía, incluyendo métricas, umbrales, métodos de medición, escenarios de prueba y evidencias esperadas.
• Los criterios de desempeño y aceptación de este módulo deberán alinearse con los criterios generales de pruebas y aceptación definidos en la sección general correspondiente del pliego, sin duplicar requisitos generales, incorporando únicamente criterios específicos de telefonía.
• La aceptación del módulo de telefonía requerirá demostrar cumplimiento funcional y de desempeño para los componentes de: control de llamadas, centro de contactos/ACD, consola administrativa, conectividad y enrutamiento, dispositivos de borde, clientes de atención, métricas y reportes, continuidad operativa, seguridad específica e integraciones.
• El contratista deberá ejecutar pruebas con participación institucional, en ambientes controlados, y documentar resultados con evidencias verificables, incluyendo bitácoras, capturas, listados de eventos y actas institucionales.
• La institución podrá exigir la repetición de pruebas cuando existan fallas atribuibles a la solución o cuando los resultados no sean reproducibles o verificables.

5.22.          Requisitos mínimos de desempeño

• El sistema de telefonía IP deberá soportar la concurrencia de llamadas y sesiones definida por el dimensionamiento institucional, manteniendo estabilidad y sin degradación perceptible atribuible a subdimensionamiento o a fallas de diseño.
• La plataforma deberá mantener tiempos de respuesta consistentes en las funciones críticas, incluyendo como mínimo: presentación de llamada al agente, ejecución de transferencias, retención y reanudación, conferencias y actualización de estados del agente, conforme a métricas de aceptación definidas por la institución.
• La plataforma de telefonía deberá mantener continuidad de recepción y atención de llamadas ante picos de demanda, sin pérdida de llamadas atribuible al sistema.
• El centro de contactos/ACD deberá mantener estabilidad al administrar colas, prioridades, intervalos, desbordamientos, estados y códigos de inactividad, sin asignaciones ambiguas ni fallas de distribución atribuibles al sistema.
• El sistema deberá permitir la consulta de CDR, métricas, reportes y tarificación sin degradar la atención en tiempo real, aplicando mecanismos de control de recursos cuando corresponda.
• La plataforma deberá registrar eventos operativos y de auditoría de forma consistente, manteniendo marcas de tiempo coherentes y preservando trazabilidad entre llamada, agente, extensión y cola/VDN u otros identificadores equivalentes.
• Los dispositivos de borde deberán soportar la carga de sesiones prevista, manteniendo interoperabilidad estable con las troncales SIP existentes, sin rechazos erráticos o degradación atribuible al borde.
• Los clientes de atención (teléfonos IP y softphones) deberán operar de forma estable durante sesiones prolongadas, manteniendo consistencia de estados, visualización de identificadores y ejecución de funciones base sin interrupciones atribuibles a la solución.
• Las integraciones con CAD deberán operar de forma consistente, permitiendo el envío y registro del paquete mínimo de datos de la llamada y la correlación posterior, sin generación de eventos duplicados o inconsistentes atribuibles a la solución.
• Las capacidades de mensajería de texto y videollamadas, conforme a las condiciones técnicas establecidas en el presente pliego, deberán operar de forma estable y registrarse con trazabilidad y auditoría, sin afectar la continuidad de la atención telefónica principal.

5.23.          Pruebas obligatorias de aceptación

• El contratista deberá ejecutar pruebas documentadas de aceptación, con participación de la institución, que evidencien como mínimo:
  1. Recepción y atención de llamadas entrantes por troncales SIP existentes, incluyendo balanceo de carga y tratamiento configurado.
  2. Operación de plan de numeración, plan de marcado, rutas y restricciones, con evidencias verificables.
  3. Funciones base de telefonía: atención, transferencia asistida y ciega, retención y reanudación, conferencia, llamada en espera, toma de llamada por terceros y parqueo cuando aplique.
  4. Operación del ACD: creación de colas, prioridades, distribución por mayor tiempo disponible, asignación a múltiples colas, intervalos entre llamadas, desbordamientos, estados del agente y códigos de inactividad.
  5. Operación de supervisión: visualización de estados, cambio de estado autorizado, monitoreo, asesoría e intervención cuando aplique, con auditoría.
  6. Integración CAD–telefonía: generación del evento de ingreso, envío del paquete mínimo de datos, y consulta posterior de trazabilidad.
  7. Generación, consulta y exportación de registros de detalle de llamadas, métricas, reportes y tarificación, incluyendo alarmas configuradas.
  8. Controles de seguridad específica y antifraude: restricciones de marcación, listas, bloqueo por políticas y evidencia de auditoría.
  9. Continuidad operativa: pruebas de conmutación definidas (nodo, enlace entre entornos, borde), modo degradado y retorno a condición normal.
  10. Operación de teléfonos IP y softphones conforme perfiles, incluyendo registro de llamadas, directorio y estados.
  11. Mensajería de texto y videollamadas cuando aplique: envío/recepción, registro, consulta, auditoría y manejo de falla parcial.
• Para cada prueba se deberán registrar como mínimo: objetivo, precondiciones, pasos ejecutados, resultados esperados, resultados obtenidos, evidencias adjuntas y criterio de aprobación o rechazo.
• Las pruebas deberán ejecutarse en condiciones controladas y reproducibles, con escenarios que incluyan carga y concurrencia equivalentes o superiores a las esperadas en operación real, según lo defina la institución durante la implementación.
• El contratista deberá entregar evidencias verificables de las pruebas, incluyendo bitácoras, registros de auditoría, listados de llamadas/interacciones procesadas, y actas de validación institucional.
• La institución podrá requerir pruebas adicionales si se identifican riesgos operativos o si se detectan condiciones no previstas durante la implementación.

5.24.          Criterios de rechazo y aceptación formal

• La institución no aceptará el módulo si se presentan fallas atribuibles a la solución que impliquen, como mínimo:
  1. Pérdida de llamadas o interrupciones recurrentes de atención.
  2. Inestabilidad del ACD que afecte distribución, estados o colas.
  3. Inconsistencias de trazabilidad entre llamada, agente, extensión, cola/VDN y registros operativos.
  4. Fallas recurrentes en integraciones que generen eventos duplicados, pérdida de correlación o ausencia del paquete mínimo de datos requerido.
  5. Ausencia de auditoría verificable o capacidad de exportación conforme a permisos.
  6. Controles antifraude insuficientes o posibilidad de llamadas no autorizadas atribuibles a configuración o diseño.
  7. Fallas de continuidad operativa verificadas en pruebas (conmutación o retorno) atribuibles a la arquitectura ofertada.
• La aceptación final del módulo requerirá el cumplimiento integral de los requisitos establecidos en el presente capítulo, la entrega completa de documentación y evidencias, y la formalización mediante acta institucional.
• La plataforma deberá permanecer estable durante un periodo de operación controlada definido por la institución, posterior a la implementación, como condición para aceptación definitiva.
• El contratista deberá corregir, sin costo adicional, las fallas atribuibles a la solución identificadas durante pruebas u operación controlada, y deberá repetir las pruebas necesarias hasta demostrar cumplimiento verificable.

5.25.          Monitoreo, analítica operativa y gestión del centro de contactos

• La solución deberá incorporar un módulo de monitoreo, analítica operativa y gestión del centro de contactos, orientado a la supervisión, control y análisis de la operación en tiempo real y de forma histórica.
• El módulo deberá permitir a la institución contar con visibilidad integral del estado de la operación, facilitando la toma de decisiones operativas en tiempo real y el análisis posterior para la mejora continua del servicio.
• El módulo deberá consumir la información generada por los componentes de telefonía IP, centro de contactos (ACD), registros de llamadas (CDR) y eventos operativos, sin duplicar su almacenamiento.
• El módulo deberá garantizar la consistencia de la información entre los distintos componentes de la solución.
• El módulo deberá operar como una capa de explotación de información, sin interferir con la operación base de atención de llamadas.

5.26.          Monitoreo operativo en tiempo real

• La solución deberá permitir el monitoreo en tiempo real del estado de los agentes, incluyendo como mínimo estados tales como disponible, en llamada, en espera, en pausa, no disponible u otros definidos por la institución.
• La solución deberá permitir visualizar en tiempo real el estado de las colas de atención, incluyendo volumen de llamadas en espera, en atención y otros indicadores operativos relevantes.
• La solución deberá permitir la visualización de eventos, en espera, en transferencia o en cualquier otra etapa del ciclo de la llamada.
• La solución deberá permitir la identificación en tiempo real de eventos operativos relevantes, incluyendo como mínimo desbordamientos, redirecciones, abandonos y eventos de contingencia.
• La información deberá actualizarse de forma continua o casi en tiempo real, sin requerir intervención manual del usuario.
• La solución deberá permitir la navegación jerárquica de la información (drill-down), desde indicadores generales hacia niveles de detalle, incluyendo como mínimo cola, agente y evento de llamada asociado.

5.27.          Indicadores clave de desempeño (KPIs operativos)

• La solución deberá calcular y presentar indicadores clave de desempeño del centro de contactos en tiempo real y de forma histórica.
• La solución deberá incluir como mínimo los siguientes indicadores:
  1. Nivel de servicio (SLA).
  2. Tiempo promedio de espera (ASA).
  3. Tiempo promedio de atención (AHT).
  4. Tasa de abandono de llamadas.
  5. Volumen de llamadas atendidas, en espera y no atendidas.
  6. Ocupación de agentes.
• La solución deberá permitir la parametrización de los indicadores en cuanto a umbrales, periodos de medición y condiciones de cálculo.
• La solución deberá permitir la definición de intervalos de medición configurables, incluyendo como mínimo intervalos de 5, 15, 30 y 60 minutos.
• La solución deberá permitir la creación y configuración de indicadores adicionales por parte de la institución, a partir de la combinación de métricas disponibles en la solución.

5.28.          Tableros de control y visualización operativa (dashboards y wallboards)

• La solución deberá proporcionar tableros de control para visualización de la operación en tiempo real.
• La solución deberá permitir la visualización mediante paneles tipo “wallboard” para despliegue en pantallas de monitoreo.
• La solución deberá permitir la configuración de vistas personalizadas según el perfil del usuario.
• La solución deberá permitir la representación gráfica de la información mediante tablas, gráficos, indicadores visuales u otros mecanismos.
• Los tableros deberán actualizarse automáticamente sin intervención manual.
• La solución deberá permitir la interacción con los elementos visuales para acceder a niveles de detalle asociados.

5.29.          Gestión de alertas operativas y umbrales

• La solución deberá permitir la definición de umbrales para indicadores operativos críticos.
• La solución deberá generar alertas automáticas ante el incumplimiento de los umbrales definidos.
• La solución deberá permitir la notificación de alertas mediante mecanismos configurables, incluyendo como mínimo interfaz visual y correo electrónico.
• La solución deberá permitir la clasificación de alertas según niveles de criticidad.
• La solución deberá mantener un registro de las alertas generadas para fines de auditoría y análisis posterior.

5.30.          Supervisión de agentes y control operativo

• La solución deberá permitir la visualización del desempeño de los agentes en tiempo real y de forma histórica.
• La solución deberá permitir la consulta de estados, tiempos y carga operativa asociados a cada agente.
• La solución deberá permitir la identificación de cargas de trabajo por agente y por grupo operativo.
• La solución deberá permitir el análisis del comportamiento de atención por agente, cola o servicio.

5.31.          Analítica histórica y explotación de información

• La solución deberá permitir el análisis histórico del comportamiento de la operación del centro de contactos.
• La solución deberá permitir el análisis de tendencias de llamadas y atención.
• La solución deberá permitir la comparación de indicadores entre distintos periodos de tiempo.
• La solución deberá permitir la segmentación de la información por intervalos de tiempo definidos por la institución.
• La solución deberá permitir el análisis por dimensiones tales como agente, cola, servicio u otras definidas por la institución.
• La solución deberá permitir trabajar con distintos niveles de detalle de la información, incluyendo eventos asociados al ciclo de vida de la llamada.
• La solución deberá garantizar la disponibilidad de la información histórica para análisis durante el periodo definido por la institución, conforme a los lineamientos generales de retención establecidos en el pliego.

5.32.          Capacidades de consulta, filtrado y exportación de información

• La solución deberá permitir la consulta avanzada de la información operativa mediante la aplicación de filtros múltiples.
• La solución deberá permitir la generación de conjuntos de datos para análisis específico.
• La solución deberá permitir la exportación de la información a formatos estructurados para análisis externo.
• La solución deberá garantizar que las consultas y exportaciones no afecten la operación normal del sistema.
• El acceso a la información deberá estar controlado mediante perfiles y permisos definidos por la institución.
• La solución deberá permitir la restricción de acceso a la información a nivel de datos, incluyendo como mínimo por cola, grupo operativo o unidad organizativa.

5.33.          Integración con otros componentes de la solución

• El módulo deberá integrarse con los componentes de telefonía IP, centro de contactos (ACD) y registros de llamadas (CDR).
• El módulo deberá integrarse con el sistema CAD u otros sistemas institucionales autorizados.
• La solución deberá garantizar la consistencia de la información entre los distintos componentes.
• La solución deberá disponer de mecanismos de interoperabilidad que permitan la explotación de la información por otros sistemas autorizados.

 

 

6.    Sistema de grabación IP

6.1.  Objetivo y alcance

• El Sistema de Grabación IP tiene por objeto registrar, conservar y permitir la consulta controlada de las comunicaciones telefónicas gestionadas por la solución de telefonía IP del Sistema de Emergencias 9-1-1, garantizando trazabilidad, integridad, disponibilidad y cumplimiento normativo, conforme a la naturaleza de servicio misión crítica.
• El sistema de grabación deberá formar parte integral de la solución de telefonía IP, operar de forma continua 24/7/365 y mantener compatibilidad total con el esquema de atención, distribución y operación definido para la plataforma.
• El alcance funcional mínimo del sistema de grabación comprende, como mínimo:
  1. Grabación de llamadas entrantes atendidas por la línea 9-1-1.
  2. Grabación de llamadas salientes realizadas desde puestos autorizados.
  3. Grabación de llamadas internas entre extensiones cuando aplique.
  4. Grabación de eventos asociados a la llamada, incluyendo transferencias, conferencias, retenciones y reanudaciones, de forma que la evidencia refleje el flujo real de atención.
• La grabación deberá iniciarse de forma automática y no depender de acciones del usuario operativo, sin permitir mecanismos que detengan, pausen, alteren o eliminen la grabación ni sus datos de control.
• Cada grabación y su registro de control deberá contar con identificadores únicos, irrepetibles y no editables, generados al momento de su creación, manteniendo trazabilidad y consistencia de la información.
• El sistema deberá almacenar, como parte del registro de control, metadatos mínimos suficientes para búsqueda, auditoría y reconstrucción del evento, incluyendo al menos: identificadores de llamada y grabación, fecha/hora de inicio y fin, número de origen y destino cuando aplique, extensión/puesto, y referencia de agente/ACD cuando aplique.
• El alcance incluye la disponibilidad de un aplicativo o interfaz gráfica para búsqueda, visualización, reproducción y exportación de grabaciones, conforme a perfiles y permisos, incluyendo mecanismos de auditoría de accesos y acciones.
• El alcance incluye el almacenamiento centralizado y los mecanismos de transferencia automática y exportación de archivos de audio y metadatos, según lo establecido en las secciones siguientes del presente módulo.
• El sistema deberá asegurar conservación de largo plazo conforme al periodo de retención institucional definido para las grabaciones, incluyendo su disponibilidad para consulta autorizada durante dicho periodo.
• La información de grabaciones, metadatos, bitácoras y respaldos será propiedad exclusiva de la institución y deberá mantenerse bajo soberanía del Estado costarricense, sin almacenamiento, procesamiento o replicación fuera del territorio nacional salvo autorización expresa.
• El sistema de grabación deberá integrarse al esquema de alta disponibilidad definido para la solución integral, evitando puntos únicos de falla y garantizando continuidad operativa aun ante fallas parciales.
• Toda acción relevante sobre la consulta, reproducción, exportación y administración del sistema deberá quedar registrada en bitácoras auditables, preservando historial y sin permitir sobrescritura irreversible de la información registrada.

6.2.  Sistema de grabación integrado

• El sistema de grabación deberá encontrarse integrado a la solución de telefonía IP, de forma nativa o mediante componentes plenamente soportados por el fabricante, garantizando operación continua y consistente con la atención de llamadas del 9-1-1.
• El sistema deberá grabar de forma automática todas las comunicaciones incluidas en el alcance del numeral 1.3, sin requerir acciones manuales del usuario y sin depender de aplicaciones externas no contempladas como parte integral de la solución.
• El sistema deberá garantizar que cada llamada grabada cuente con un registro de control asociado y que dicho registro mantenga relación inequívoca entre:
  1. Identificador de llamada.
  2. Identificador de grabación.
  3. Archivo de audio correspondiente.
• El sistema deberá capturar, como parte del proceso de grabación, los metadatos operativos definidos en el numeral 1.6, asegurando que dichos datos se generen de forma automática y consistente para permitir búsqueda, auditoría y exportación posterior.
• El sistema deberá permitir la grabación simultánea de llamadas de forma concurrente, conforme a las capacidades mínimas requeridas por la institución, sin degradación perceptible de la calidad del audio ni pérdida de información de control.
• El sistema deberá permitir, cuando aplique según la arquitectura ofertada, la existencia de componentes de grabación redundantes o distribuidos, de forma que una falla parcial no interrumpa el proceso de grabación.
• El sistema deberá permitir la configuración de las extensiones, colas, agentes o puntos de atención sujetos a grabación, mediante la consola de administración autorizada, sin requerir cambios de programación.
• El sistema deberá registrar eventos técnicos relevantes asociados al proceso de grabación, como mínimo: inicio de grabación, fin de grabación, fallos de captura, reintentos y eventos de conmutación, de forma que la institución pueda verificar la continuidad y consistencia del servicio.
• El sistema deberá garantizar que, ante condiciones de contingencia operacional definidas por la institución, las llamadas continúen siendo grabadas y queden disponibles para su transferencia hacia el repositorio centralizado cuando se restablezca la operación normal.
• El oferente deberá describir en su propuesta el mecanismo técnico utilizado para la captura de audio y su relación con los componentes de telefonía IP, detallando al menos:
  1. Punto o capa donde se realiza la captura.
  2. Cómo se garantiza que la grabación corresponde a la llamada registrada.
  3. Cómo se evita duplicidad de archivos por una misma llamada.
  4. Cómo se preserva la continuidad ante fallas parciales.
• El sistema deberá permitir que los archivos de audio generados sean compatibles con los mecanismos de consulta y exportación definidos en este mismo módulo, evitando formatos cerrados que impidan su reproducción fuera del sistema, cuando aplique según los procedimientos autorizados de exportación.

6.3.  Almacenamiento centralizado

• La solución deberá disponer de un almacenamiento centralizado destinado a resguardar la totalidad de las grabaciones de los eventos y sus datos de control, constituyéndose como repositorio oficial para consulta, auditoría, exportación y conservación conforme a los plazos institucionales definidos.
• El almacenamiento centralizado deberá ser provisto, dimensionado, instalado, configurado y dejado en operación por el contratista como parte integral de la solución, incluyendo todos los componentes de infraestructura, software, licenciamiento y servicios requeridos para su correcto funcionamiento.
• El repositorio centralizado deberá almacenar, como mínimo:
  1. Los archivos resultantes de las grabaciones.
  2. Los metadatos y registros de control asociados a cada grabación.
  3. Las bitácoras técnicas y de auditoría relacionadas con el almacenamiento, transferencias y accesos, cuando aplique.
• El almacenamiento centralizado deberá permitir que las grabaciones y registros de control se mantengan disponibles para consulta autorizada durante todo el periodo de retención establecido, sin degradación que afecte la operación y sin dependencia de medios externos no contemplados en la solución.
• El diseño del repositorio deberá garantizar integridad y consistencia entre archivo y metadatos, evitando que existan grabaciones sin registro de control, registros de control sin archivo, o rutas de archivo no válidas.
• El repositorio deberá mantener una organización lógica que permita administración y control, incluyendo como mínimo:
  1. Estructura de almacenamiento consistente y documentada.
  2. Identificación inequívoca del archivo asociado a cada registro.
  3. Mecanismos de indexación o referencias que permitan ubicar rápidamente el archivo correspondiente durante búsquedas o exportaciones.
• La solución deberá permitir definir políticas de conservación, archivado y administración del repositorio, manteniendo siempre la disponibilidad bajo consulta autorizada y sin permitir pérdida de información por rotación no controlada.

6.4.  Redundancia del almacenamiento centralizado

• El almacenamiento centralizado deberá operar bajo un esquema de redundancia que elimine puntos únicos de falla y garantice continuidad del servicio ante fallas de componentes.
• La redundancia deberá aplicarse como mínimo a:

1. Controladores o nodos de almacenamiento, cuando aplique.
2. Discos o grupos de discos.
3. Componentes de conectividad interna del almacenamiento.
4. Fuentes de poder y ventilación, cuando aplique.
   • La solución deberá garantizar tolerancia a fallos sin pérdida de grabaciones ni de registros de control, incluyendo mecanismos automáticos de conmutación o continuidad según la arquitectura ofertada.
   • El oferente deberá detallar en su propuesta el esquema de redundancia ofrecido, incluyendo:
     1. Tipo de arquitectura (por ejemplo, arreglo redundante, clúster, replicación u otro equivalente).
     2. Nivel de tolerancia a fallos (cantidad de fallas simultáneas soportadas sin pérdida de servicio).
     3. Comportamiento ante falla y procedimiento de recuperación.
     4. Evidencia de que la operación puede continuar durante mantenimiento o sustitución de componentes críticos.

6.5.  Respaldo y recuperación del repositorio.

• El contratista deberá implementar un esquema de respaldo y recuperación aplicable al repositorio centralizado y a sus metadatos, que garantice la restauración de grabaciones y registros de control ante corrupción, pérdida lógica o eventos de desastre. El esquema deberá contemplar como mínimo:

1. Periodicidad de respaldos.
2. Retención de respaldos.
3. Procedimientos de restauración.
4. Verificación periódica de restauración mediante pruebas documentadas.
   • El mecanismo de respaldo no deberá afectar la operación normal, ni degradar el acceso y consulta de grabaciones durante horas operativas críticas.

6.6.  Monitoreo y alertas del almacenamiento

• El repositorio centralizado deberá contar con monitoreo de capacidad, salud de componentes y eventos relevantes.
• La solución deberá generar alertas ante condiciones críticas, como mínimo:

1. Umbral de capacidad.
2. Fallo de discos o degradación del arreglo.
3. Fallo de controladores o nodos.
4. Interrupción de servicios de almacenamiento.
   • Las alertas deberán estar integradas a los mecanismos de soporte establecidos para la solución, permitiendo atención oportuna.

6.7.  Documentación y entrega

• El contratista deberá entregar documentación técnica del almacenamiento centralizado, incluyendo:
  1. Arquitectura implementada.
  2. Esquema de redundancia.
  3. Capacidad instalada y capacidad utilizable.
  4. Proyección de crecimiento y criterios de ampliación.
  5. Procedimientos de operación y recuperación.
• La documentación deberá permitir a la institución verificar el cumplimiento del diseño y mantener trazabilidad de la configuración entregada.

6.8.  Transferencia automática y exportación de archivos

• La solución deberá disponer de mecanismos automáticos y controlados para transferir las grabaciones desde los componentes de captura hacia el almacenamiento centralizado, así como mecanismos de exportación conforme a perfiles autorizados, garantizando trazabilidad, integridad y continuidad operativa.
• La transferencia y la exportación deberán operar sin afectar la disponibilidad de la grabación, ni interferir con la atención de llamadas, ni degradar la operación de los componentes críticos de la solución.

6.9.  Transferencia automática hacia almacenamiento centralizado

• El sistema deberá ejecutar un proceso de transferencia automática de los archivos de audio generados, desde el origen donde se produce la grabación hacia el repositorio centralizado definido en el numeral 8.2.3.
• El proceso deberá garantizar que, por cada llamada grabada, se transfieran:
  1. El archivo de audio correspondiente.
  2. Los metadatos y registros de control asociados.
• La solución deberá garantizar consistencia post-transferencia, evitando que existan:
  1. Grabaciones visibles sin archivo asociado.
  2. Archivos sin metadatos consultables.
  3. Referencias a rutas inexistentes o no accesibles.
• El proceso de transferencia deberá contemplar reintentos automáticos ante fallos temporales, sin requerir intervención manual inmediata.
• En caso de operación contingente o captura temporal fuera del repositorio central, el sistema deberá permitir la transferencia diferida y controlada al restablecerse la conectividad o la operación normal, sin pérdida de información.

6.10.          Control de ejecución, bitácora y notificaciones

• La solución deberá mantener una bitácora de ejecución de la transferencia automática, registrando como mínimo:
  1. Fecha y hora de inicio del proceso.
  2. Fecha y hora de finalización.
  3. Cantidad de archivos procesados.
  4. Cantidad de transferencias exitosas.
  5. Cantidad de transferencias fallidas.
  6. Detalle de fallos por archivo o por lote (cuando aplique).
• La bitácora deberá ser consultable por perfiles autorizados y exportable para control institucional.
• La solución deberá permitir la configuración de notificaciones ante fallos relevantes del proceso de transferencia, incluyendo al menos la notificación a destinatarios institucionales definidos.

6.11.          Ventanas operativas y control de impacto

• La solución deberá permitir configurar ventanas horarias, prioridades o políticas operativas para el proceso de transferencia, con el fin de minimizar cualquier impacto sobre la operación en horas de alta demanda.
• La solución deberá permitir limitar consumo de recursos del proceso de transferencia (por ejemplo, concurrencia de transferencias o uso de ancho de banda), cuando la arquitectura lo permita, manteniendo cumplimiento del objetivo de disponibilidad oportuna de los registros.
• Validación de integridad post-transferencia
  1. La solución deberá implementar un mecanismo de validación de integridad posterior a la transferencia, que permita verificar que el archivo almacenado en el repositorio central corresponde al archivo originalmente generado.
  2. La validación deberá operar de forma automática y registrar el resultado para fines de auditoría y control institucional.

6.12.          Exportación de grabaciones (individual)

• La solución deberá permitir exportar grabaciones de forma individual conforme a permisos autorizados, sin alterar el registro original del repositorio.
• La exportación individual deberá mantener asociada la información mínima de control necesaria para identificar la grabación exportada.
• Toda exportación individual deberá quedar registrada en auditoría indicando al menos: usuario, fecha/hora, estación de trabajo (cuando aplique), criterio de búsqueda utilizado y referencia del registro exportado.

6.13.          Exportación masiva de archivos de audio

• La solución deberá permitir la exportación masiva de grabaciones almacenadas en el repositorio centralizado, para fines autorizados institucionalmente, tales como custodia, migración, verificación o procesos administrativos/judiciales.
• La exportación masiva deberá:
  1. Permitir definir rangos de fechas y otros criterios de selección.
  2. Generar archivos de audio en formatos estándar reproducibles.
  3. No requerir software propietario para su reproducción.
  4. Mantener trazabilidad entre cada archivo exportado y su registro de control.
• La exportación masiva deberá permitir su ejecución controlada para evitar afectación de desempeño, incluyendo programación por ventanas, segmentación por lotes u otros mecanismos equivalentes.

6.14.          Exportación de metadatos y datos de control

• La solución deberá permitir exportar los metadatos asociados a grabaciones, de forma estructurada, para su carga o consulta en repositorios institucionales.
• La exportación de metadatos deberá contemplar, como mínimo:
  1. Identificadores de llamada y grabación.
  2. Fechas y horas de inicio y fin.
  3. Duración.
  4. Número de origen y destino cuando aplique.
  5. Agente/ACD o extensión cuando aplique.
  6. Ruta o referencia del archivo de audio en el repositorio centralizado.
  7. Indicadores relevantes del flujo de llamada (por ejemplo: entrante/saliente/interna; transferida; conferencia), cuando aplique.
• La estructura exacta de campos, tipos de datos y diccionario de datos de metadatos exportables deberá quedar definida y documentada durante la fase de implementación, como parte de la documentación técnica entregable.

6.15.          Auditoría integral de transferencia y exportación

• La solución deberá auditar, como mínimo, los siguientes eventos:
  1. Ejecución de procesos de transferencia (inicio/fin/resultado).
  2. Reintentos automáticos por fallos.
  3. Exportaciones individuales.
  4. Exportaciones masivas.
  5. Consultas asociadas a procesos de exportación cuando aplique.
• Los registros de auditoría deberán ser consultables por perfiles autorizados y conservarse conforme a la política institucional aplicable.

6.16.          Modo de operación del sistema de grabación

• El sistema de grabación deberá contar con un modo de operación que permita a los perfiles autorizados consultar, buscar, reproducir, monitorear y exportar grabaciones, bajo controles estrictos de seguridad, trazabilidad y auditoría, sin afectar la operación de grabación ni la atención de llamadas.
• La solución deberá proveer una interfaz gráfica en ambiente web o equivalente, en idioma español, para la gestión operativa del sistema de grabación, sin requerir herramientas externas no contempladas como parte integral de la solución. La interfaz deberá permitir, como mínimo:
  1. Búsqueda de grabaciones.
  2. Visualización de resultados y metadatos.
  3. Reproducción de archivos de audio.
  4. Monitoreo en línea cuando aplique.
  5. Exportación de grabaciones según permisos.
• La interfaz no deberá permitir la modificación, alteración o eliminación de grabaciones ni de sus datos de control.
• Operación simultánea. El sistema deberá permitir operar simultáneamente, como mínimo, las siguientes funciones:
  1. Grabación de llamadas en curso.
  2. Reproducción de grabaciones históricas.
  3. Monitoreo en línea de llamadas cuando aplique.
• La operación simultánea no deberá degradar perceptiblemente la calidad de grabación ni afectar la disponibilidad de la atención telefónica.
• Registro de control y metadatos mínimos por grabación. El sistema deberá registrar y mantener disponibles, por cada grabación, metadatos mínimos que permitan su identificación, búsqueda, auditoría y exportación. El registro deberá incluir como mínimo:
  1. Identificador único del registro de grabación.
  2. Identificador único del registro de llamada.
  3. Fecha y hora de inicio de grabación.
  4. Fecha y hora de finalización de grabación.
  5. Duración de la grabación.
  6. Número telefónico de origen, cuando aplique.
  7. Número telefónico de destino, cuando aplique.
  8. Número de extensión o punto de atención asociado, cuando aplique.
  9. Nombre del agente, cuando aplique.
  10. Identificador del agente, cuando aplique.
• Los metadatos deberán generarse de forma automática y mantenerse consistentes con la grabación almacenada.
• Etiquetas personalizadas (tags). El sistema deberá permitir asociar etiquetas personalizadas a los registros de grabación, con fines de clasificación, búsqueda y trazabilidad operativa.
  1. El sistema deberá permitir configurar y utilizar como mínimo tres (3) etiquetas personalizadas por registro de grabación.
  2. Las etiquetas deberán poder recibir valores definidos por la institución y, cuando aplique, valores alimentados por mecanismos de integración definidos para tal fin.
  3. La edición de etiquetas deberá estar controlada por permisos y quedar registrada en auditoría.

6.17.          Búsqueda y consulta de grabaciones

• La solución deberá permitir la búsqueda de grabaciones mediante filtros y criterios múltiples, como mínimo:
  1. Identificador único de grabación.
  2. Identificador único de llamada.
  3. Número de origen.
  4. Número de destino.
  5. Rango de fecha y hora (inicio y fin).
  6. Agente o extensión, cuando aplique.
  7. Identificador del agente, cuando aplique.
  8. Etiquetas personalizadas.
• Los resultados deberán mostrar metadatos suficientes para identificar inequívocamente la grabación antes de reproducirla o exportarla.
• La búsqueda deberá quedar registrada en auditoría cuando así se defina por política institucional, especialmente para perfiles con acceso a información sensible.

6.18.          Reproducción de grabaciones

• La solución deberá permitir la reproducción de grabaciones desde la interfaz gráfica, sin requerir aplicaciones de terceros no contempladas por la solución.
• El reproductor deberá incluir como mínimo los siguientes controles:
  1.  
  2. Detener y volver al inicio.
  3.  
  4.  
  5.  
• La reproducción deberá registrar en auditoría, como mínimo: usuario, fecha/hora y grabación consultada, y cuando aplique, duración reproducida.
• Monitoreo en línea (cuando aplique)
  1. El sistema deberá permitir monitoreo en línea de llamadas, únicamente para perfiles autorizados, y bajo los controles de auditoría correspondientes.
  2. El monitoreo en línea no deberá interferir con la grabación ni con la atención telefónica.
• Control de acceso y autenticación
  1. El acceso a la interfaz de grabación deberá integrarse con el esquema institucional de autenticación, permitiendo el uso de inicio de sesión único (SSO) cuando aplique.
  2. El sistema deberá soportar roles y permisos diferenciados, de manera que cada usuario acceda únicamente a las funciones autorizadas.
• Los permisos deberán permitir, como mínimo, controlar:
  1. Búsqueda y reproducción por extensión o rangos autorizados.
  2. Búsqueda y reproducción por agente.
  3. Monitoreo en línea.
  4. Exportación de grabaciones.
  5. Administración y configuración del sistema.
• El sistema deberá permitir la definición de perfiles administradores con capacidad de crear usuarios, asignar permisos y configurar parámetros operativos del sistema de grabación.

6.19.          Configuración operativa del sistema

• El sistema deberá disponer de una sección de configuración que permita a perfiles autorizados administrar, como mínimo:
  1. Extensiones, colas o puntos de atención sujetos a grabación.
  2. Parámetros de notificación para eventos relevantes del sistema.
  3. Parámetros generales de operación del sistema de grabación.
  4. Gestión de usuarios y permisos.
• Toda modificación de configuración deberá quedar registrada en auditoría, indicando usuario, fecha/hora y detalle del cambio.

6.20.          Auditoría del sistema de grabación

• El sistema deberá contar con un módulo de auditoría que registre y permita consultar las acciones realizadas sobre el sistema de grabación.
• La auditoría deberá registrar como mínimo:
  1. Inicios de sesión.
  2. Búsquedas realizadas.
  3. Reproducciones ejecutadas.
  4. Exportaciones realizadas.
  5. Acciones de administración y configuración.
• Cada evento auditado deberá registrar como mínimo:
  1. Fecha y hora.
  2.  
  3. Descripción de la acción.
• El módulo de auditoría deberá permitir consulta en pantalla con filtros por:
  1. Rango de tiempo.
  2.  
  3. Tipo de acción.
• Restricciones de modificación y conservación operativa
  1. No deberá existir en la interfaz ni en la administración del sistema ninguna opción que permita modificar o eliminar grabaciones o sus datos de control.
  2. Cualquier ajuste permitido (por ejemplo, etiquetas o parámetros de consulta) deberá realizarse sin alterar el contenido del audio ni el registro histórico de control.

6.21.          Requisitos de desempeño y aceptación

• El sistema de grabación IP deberá garantizar un desempeño consistente con la operación de misión crítica, asegurando continuidad del servicio, disponibilidad de evidencia y capacidad de consulta controlada, sin afectar la atención de llamadas ni la operación del CAD.
• El desempeño deberá evaluarse mediante pruebas funcionales y operativas definidas por la institución durante la fase de implementación, con resultados verificables y reproducibles, formando parte de los criterios de aceptación.
• Requisitos mínimos de desempeño del proceso de grabación
  1. La solución deberá grabar la totalidad de las llamadas alcanzadas por el alcance definido, sin omisiones atribuibles al sistema.
  2. La grabación deberá iniciar y finalizar de forma consistente con el evento real de la llamada, sin recortes atribuibles al sistema que impidan reconstruir la atención.
  3. La calidad de audio deberá ser suficiente para fines operativos, de supervisión, auditoría y eventuales requerimientos institucionales, sin distorsión o degradación atribuible a la solución.
  4. El sistema deberá soportar la concurrencia de grabaciones conforme al dimensionamiento requerido, manteniendo estabilidad operativa y sin degradación perceptible del servicio.
• Requisitos mínimos de desempeño del almacenamiento centralizado

1. El repositorio centralizado deberá mantener disponibilidad para consulta autorizada, garantizando acceso a grabaciones y metadatos sin inconsistencias.
2. El repositorio deberá sostener la operación continua aun ante fallas parciales cubiertas por el esquema de redundancia, sin pérdida de información.
3. El sistema deberá permitir el crecimiento del almacenamiento, mediante ampliación controlada, sin interrumpir la operación y sin requerir reinstalación completa.
   • Requisitos mínimos de desempeño de transferencia automática
     1. El sistema deberá transferir automáticamente las grabaciones al repositorio centralizado dentro de un tiempo máximo operativo definido por la institución durante la implementación, sin afectar la grabación en curso.
     2. El proceso deberá registrar evidencia de ejecución y resultado, permitiendo identificar transferencias exitosas y fallidas.
     3. Ante fallos temporales, el sistema deberá reintentar automáticamente y completar la transferencia cuando se restablezcan las condiciones, sin pérdida de archivos ni metadatos.
     4. Requisitos mínimos de desempeño de búsqueda y reproducción
     5. La búsqueda por criterios mínimos definidos deberá devolver resultados de forma consistente y sin afectar la operación de grabación.
     6. La reproducción desde la interfaz deberá ejecutarse de forma estable, sin interrupciones atribuibles al sistema, para grabaciones dentro del repositorio centralizado.
     7. El acceso simultáneo de múltiples usuarios autorizados para consulta y reproducción no deberá afectar la grabación de llamadas en curso.

6.22.          Criterios mínimos de aceptación (pruebas obligatorias)

• El contratista deberá ejecutar pruebas documentadas de aceptación, con participación de la institución, que evidencien como mínimo:
  1. Grabación automática de llamadas entrantes, salientes e internas (cuando aplique).
  2. Registro completo de metadatos mínimos por grabación.
  3. Transferencia automática al almacenamiento centralizado y verificación de consistencia archivo–metadatos.
  4. Búsqueda por todos los criterios mínimos definidos y reproducción exitosa desde la interfaz.
  5. Aplicación efectiva de roles, permisos y restricciones (incluyendo bloqueo de modificación/eliminación).
  6. Registro de auditoría para inicios de sesión, búsquedas, reproducciones, exportaciones y acciones administrativas.
  7. Pruebas de operación concurrente (grabación + consulta/reproducción) sin degradación operativa atribuible al sistema.
  8. Pruebas de tolerancia a fallos según el esquema de redundancia del almacenamiento, verificando continuidad y ausencia de pérdida de información.
• Los resultados de pruebas deberán quedar respaldados mediante evidencias verificables, como mínimo: bitácoras de sistema, registros de auditoría, listados de llamadas/grabaciones procesadas y actas de validación institucional.
• Condiciones para aceptación formal del módulo La aceptación del módulo requerirá el cumplimiento integral de los requisitos establecidos en los apartados 1 al 6.6, así como la entrega de documentación técnica y operativa aplicable.
• La institución no aceptará el módulo si se presentan fallas que impliquen:
  1. Omisión de grabaciones atribuible al sistema.
  2. Inconsistencias entre archivos de audio y metadatos que impidan su trazabilidad.
  3. Indisponibilidad recurrente del repositorio centralizado.
  4. Controles de acceso insuficientes o ausencia de auditoría verificable.
  5. Mecanismos que permitan modificación o eliminación de evidencia.
• La aceptación final deberá formalizarse mediante acta institucional, una vez verificado el cumplimiento y la estabilidad del módulo en operación controlada.

6.23.          Texto a voz.  Respuesta a voz interactiva.

• Se debe incluir la reproducción de mensajes de voz mediante el uso de la facilidad de text-to-speech, para ser utilizados en la ejecución de un determinado flujo de condiciones en el tratamiento de llamadas. Se debe proporcionar el componente que permita reproducir un texto a voz.
• El audio de voz debe ser proporcionado en español, al menos en dos voces (una de hombre y una de mujer).
• Para el envío de una campaña mediante llamada telefónica, el sistema debe permitir la transformación de un texto en un mensaje saliente de voz, utilizando para ello la función de texto a llamada (text-to-speech).
• La solución debe tener habilitados al menos 75 puertos.
• La funcionalidad de reconocimiento de voz debe tener implementada la facilidad para el reconocimiento de varios idiomas en la misma aplicación IVR (multi-idioma).

 

6.24.          Sistema de campañas salientes de voz.

• Se requiere que la solución incorpore el desarrollo de un sistema que permita la gestión de campañas salientes a través de la conversión de texto a voz (text-to-speech).
• Se debe proporcionar una interfaz gráfica de usuario en ambiente Web y en idioma español, compatible al menos con los navegadores Internet actuales.
• La aplicación debe tener una compatibilidad e integración con la central telefónica IP para la comunicación de las campañas salientes.
• Debe permitir la utilización de la gestión de listas señalado en los incisos anteriores, para poder crear y enviar campañas.
• Interfaz gráfica. La interfaz gráfica debe incluir la incorporación del logo institucional, para lo cual se debe permitir la asignación de la imagen institucional del 9-1-1.
• Debe contar con una ventana de inicio de sesión en la cual se soliciten las credenciales de ingreso al usuario.
• Debe contener un título que identifique la aplicación.
• Debe incorporar una nota al pie de la página principal, sobre el acuerdo de uso de la aplicación, el cual le permita al usuario conocer las condiciones de uso de la herramienta, así como las responsabilidades que deriven de tener acceso a la misma.
• La solución debe tener 30 puertos salientes de canales.

 

 

7.    Sistema de respuesta interactiva de voz (IVR)

7.1.  Definición objeto y alcance del módulo

• La solución deberá incorporar un Sistema de Respuesta Interactiva de Voz (IVR) como componente integral de la plataforma de comunicaciones del 9-1-1, destinado a Gestionar de manera automatizada el tratamiento inicial de las llamadas entrantes previo a su atención por parte del personal operador.
• El IVR formará parte de la solución contratada y deberá ser implementado, integrado, probado y puesto en operación bajo el mismo esquema de alta disponibilidad, seguridad, soporte y mantenimiento exigido para el resto de los componentes de la solución.
• El alcance del IVR comprenderá la reproducción de mensajes informativos, la ejecución de flujos de decisión configurables, la consulta a servicios institucionales autorizados y el enrutamiento de llamadas hacia destinos definidos por la Administración, la emisión de campañas.
• El IVR no deberá ejecutar funciones propias de creación del Reporte de Emergencia ni de gestión del incidente en la plataforma CAD; su alcance se limitará al tratamiento y enrutamiento previo a la atención humana y a las integraciones expresamente definidas en este pliego.

7.2.  Requisitos funcionales generales

• El IVR deberá permitir la reproducción de mensajes de bienvenida, mensajes informativos, mensajes de orientación y mensajes de concientización definidos por la institución (emisión de campañas).
• El IVR deberá permitir el enrutamiento automático de llamadas conforme a reglas configurables basadas en criterios operativos definidos por el 9-1-1.
• El IVR deberá soportar captura de tonos DTMF y permitir la ejecución de acciones ante la marcación de dígitos por parte del llamante.
• El IVR deberá permitir, cuando la solución lo contemple, la ejecución de acciones ante la pronunciación de palabras clave por parte del llamante, conforme a reglas definidas por la Administración.
• El IVR deberá permitir transferencias a números internos o externos, así como transferencias hacia colas de ACD o destinos equivalentes definidos en la plataforma de comunicaciones.
• El IVR deberá integrarse con la infraestructura de telefonía IP mediante protocolo SIP u otro protocolo estándar soportado por la arquitectura de la solución, garantizando compatibilidad y coherencia con el modelo general de comunicaciones.
• El IVR deberá contar con una consola administrativa en ambiente web, en idioma español, que permita la configuración de flujos, mensajes, parámetros y destinos de enrutamiento.
• La consola administrativa deberá permitir control de acceso basado en roles y deberá integrarse con el Directorio Activo institucional, siendo responsabilidad del contratista realizar la integración correspondiente.

7.3.  Flujos de tratamiento y configuración

• El IVR deberá permitir la creación, modificación y eliminación de flujos de tratamiento de llamadas de forma configurable por personal autorizado del 9-1-1.
• La solución deberá permitir la habilitación de al menos diez (10) flujos de tratamiento distintos, configurables y asignables conforme a criterios operativos definidos por la Administración.
• Los flujos deberán permitir la definición de horarios de activación, días específicos de aplicación y condiciones diferenciadas según parámetros establecidos por la institución.
• Los flujos deberán soportar, como mínimo, los siguientes elementos:
  1. Elementos de consulta a servicios o bases de datos internas o externas autorizadas.
  2. Elementos de decisión basados en respuestas del llamante o resultados de consulta.
  3. Elementos de acción tales como reproducción de mensajes, transferencias y finalización de llamada.
• Cuando un flujo incluya consultas a fuentes de datos, el IVR deberá ejecutar dichas consultas mediante mecanismos autenticados y controlados, sin acceso directo no autorizado a bases de datos institucionales.
• El IVR deberá permitir la actualización de mensajes y parámetros operativos por parte del personal autorizado, sin requerir intervención del fabricante para cambios rutinarios posteriores a la puesta en operación.

7.4.  Integración con servicios institucionales y listas de prioridad

• El IVR deberá consumir obligatoriamente la API institucional desarrollada e implementada por el 9-1-1 para la consulta de Listas de Prioridad asociadas al número telefónico de origen de la llamada.
• La invocación a dicha API deberá ejecutarse inmediatamente después del ingreso de la llamada al IVR y antes de definir el flujo de enrutamiento correspondiente.
• El IVR actuará exclusivamente como consumidor del servicio institucional; no deberá replicar, almacenar de forma persistente ni administrar el contenido de las listas de prioridad.
• Con base en la clasificación obtenida a través de la API institucional, el IVR deberá aplicar la siguiente lógica mínima de tratamiento:
  1. Cuando el número pertenezca a Lista Blanca, la llamada deberá ser enrutada a un destino de alta prioridad definido por la Administración.
  2. Cuando el número pertenezca a Lista Gris y cumpla las condiciones definidas por la lógica institucional, la llamada deberá ser dirigida a un mensaje de concientización y posteriormente a un destino de baja prioridad.
  3. Cuando el número no se encuentre clasificado, la llamada deberá ser enrutada al flujo normal de atención definido por la Administración.
• El IVR deberá permitir la parametrización del endpoint del servicio, los tiempos máximos de espera, políticas de reintento y mecanismos de autenticación definidos por la institución.
• En caso de indisponibilidad temporal del servicio de consulta, el IVR no deberá bloquear ni rechazar la llamada; deberá aplicar el flujo normal de atención y registrar el evento correspondiente para efectos de auditoría.

7.5.  Requisitos de desempeño, disponibilidad y escalabilidad

• El IVR deberá operar bajo arquitectura redundante y de alta disponibilidad, sin punto único de falla.
• La solución deberá garantizar continuidad operativa aun ante fallos parciales de infraestructura, incluyendo fallas de uno o más nodos del componente IVR.
• El IVR deberá mantener estabilidad en escenarios de alta demanda y picos simultáneos de llamadas, sin degradación perceptible en tiempos de respuesta atribuible a limitaciones de diseño o dimensionamiento.
• Para efectos de dimensionamiento, el oferente deberá considerar la operación institucional promedio y sus variaciones estacionales, garantizando capacidad suficiente para soportar crecimiento futuro sin necesidad de rediseños estructurales.

7.6.  Auditoría y trazabilidad

• El IVR deberá registrar y conservar información relevante para efectos de auditoría y supervisión operativa.
• Se deberá registrar, como mínimo, la siguiente información por cada llamada tratada:
  1. Fecha y hora de ingreso al IVR.
  2. Número telefónico de origen, cuando esté disponible.
  3. Flujo aplicado y decisiones ejecutadas.
  4. Resultado de la consulta a la API de listas de prioridad, cuando corresponda.
  5. Destino final de enrutamiento.
  6. Eventos de error o fallos en consultas externas.
• La consola administrativa deberá registrar toda modificación realizada en la configuración del IVR, indicando usuario, fecha y hora.
• Los registros deberán poder consultarse por rango de fechas y criterios de búsqueda definidos por la Administración, y deberán conservarse conforme a las políticas institucionales aplicables.

 

 

8.    Componentes complementarios asociados a la optimización operativa

8.1.  Disposiciones generales de las líneas complementarias

• Las líneas complementarias corresponden a módulos adicionales asociados funcionalmente a la Línea 1, orientados a fortalecer la gestión de calidad, la planificación de la fuerza de trabajo, la supervisión del desempeño operativo y la analítica avanzada de interacciones del Sistema de Emergencias 9-1-1.
• Las líneas complementarias podrán conformar progresivamente un modelo de Workforce Optimization (WFO), siempre que sean adjudicadas por la Administración y operen integradas funcionalmente con el servicio integral gestionado de comunicaciones IP y centro de contactos multicanal.
• Para efectos del presente pliego, el modelo de optimización operativa podrá estar compuesto por las siguientes líneas complementarias:
  1. Línea 2: Módulo de Gestión de Calidad — Quality Management, retroalimentación y coaching.
  2. Línea 3: Módulo de Gestión de Fuerza de Trabajo — Workforce Management, planificación, programación, adherencia y gestión intradía.
  3. Línea 4: Módulo de Analítica Avanzada de Interacciones — Speech Analytics, transcripción, búsqueda, categorización y análisis de comunicaciones.
• Las líneas complementarias podrán ser adjudicadas total o parcialmente por la Administración, sea para ejecución inmediata o bajo modalidad de activación posterior, según disponibilidad presupuestaria, conveniencia institucional, razonabilidad del precio y resultado del análisis técnico y económico de las ofertas.
• La no adjudicación de una o varias líneas complementarias no afectará la validez, ejecución, operación, continuidad ni aceptación de la Línea 1.
• En caso de adjudicarse, las líneas complementarias deberán operar de forma integrada con la Línea 1 y, cuando corresponda, entre sí, garantizando correlación de datos, trazabilidad de interacciones, seguridad, consistencia operativa, control institucional y responsabilidad integral del adjudicatario.
• Las líneas complementarias no deberán operar como plataformas aisladas, repositorios desconectados o herramientas que fragmenten la gestión institucional. En caso de que se implementen mediante componentes interoperables, el adjudicatario deberá garantizar integración funcional verificable, intercambio de información, administración coordinada y trazabilidad de las interacciones.
• La ausencia de una línea complementaria no activada no constituirá incumplimiento técnico de la Línea 1. No obstante, cuando una línea complementaria sea ofertada, adjudicada y activada para ejecución inmediata o posterior, su incumplimiento será valorado conforme a los requisitos técnicos, contractuales, niveles de servicio, criterios de aceptación y régimen de multas aplicables a dicha línea.

8.2.  Módulo de Gestión de la Fuerza de Trabajo (WFM)

• El oferente deberá suministrar un Módulo de Gestión de la Fuerza de Trabajo (WFM) como parte integral de la solución ofertada, orientado a la planificación, optimización, monitoreo, control y análisis del recurso humano operativo del centro de contacto del Sistema de Emergencias 9-1-1.
• El módulo deberá encontrarse plenamente integrado a la operación del centro de contacto y deberá soportar, como mínimo, procesos de pronóstico, planificación, programación de turnos, gestión intradía, adherencia, excepciones operativas, cobertura, solicitudes del personal, autoservicio, movilidad, desempeño, reportería y trazabilidad.
• La solución deberá operar como una plataforma unificada y no como un conjunto fragmentado de herramientas aisladas, evitando dependencias funcionales de múltiples motores externos para el cumplimiento ordinario de las capacidades requeridas.
• El módulo deberá ser apto para operar en un entorno de misión crítica, bajo un esquema de operación continua 24x7x365, permitiendo la administración de la fuerza laboral sin afectar la continuidad del servicio público de atención de emergencias.
• El alcance del módulo deberá contemplar la administración del personal operativo asociado al centro de contacto, incluyendo al menos agentes, supervisores y perfiles de administración autorizados conforme al modelo organizacional que defina la institución.
• Para efectos de dimensionamiento de las funcionalidades móviles asociadas al módulo de Gestión de Fuerza de Trabajo / WFM, la Administración estima una base inicial de 186 usuarios móviles operativos, integrada por 159 operadores/call takers, 23 supervisores, 2 jefes de sala y 2 coordinadores. El oferente deberá considerar una capacidad de crecimiento de hasta un 10% anual durante la vigencia contractual, permitiendo escalar, como referencia, hasta aproximadamente 255 usuarios móviles operativos, sin afectar la operación, seguridad, trazabilidad, licenciamiento, soporte ni disponibilidad del servicio.
• El módulo deberá permitir la gestión diferenciada de múltiples colas, servicios, grupos operativos, habilidades, calendarios y reglas laborales, conforme a las necesidades de la institución.
• El oferente deberá garantizar que todas las capacidades requeridas se suministren con el licenciamiento, parametrización, integración, documentación, soporte y acompañamiento técnico necesarios para su funcionamiento completo.
• El módulo deberá contemplar interfaces para uso administrativo, de supervisión y de autoservicio, conforme a perfiles autorizados, garantizando segregación funcional y control de acceso.
• La solución deberá quedar configurada y documentada para permitir su administración posterior por parte del personal técnico autorizado de la institución, sin dependencia obligatoria del fabricante para cambios rutinarios de operación.
• Requisitos funcionales generales
• El módulo deberá permitir la administración de la estructura organizativa requerida para la operación del WFM, incluyendo como mínimo unidades operativas, equipos, grupos, colas, habilidades, calendarios, perfiles y usuarios autorizados.
• La solución deberá permitir la parametrización de jornadas laborales, horarios, descansos, tiempos de alimentación, reuniones, capacitaciones, feriados, eventos especiales y demás condiciones operativas que impacten la disponibilidad del personal.
• El módulo deberá permitir la administración de perfiles de habilidades (multiskill), de forma que un agente pueda pertenecer a una o más colas o servicios, con prioridades y condiciones de atención diferenciadas.
• La solución deberá permitir definir reglas institucionales para programación, priorización, asignación, restricciones y excepciones, sin requerir cambios de desarrollo para ajustes ordinarios.
• El módulo deberá operar preferiblemente en ambiente web, independiente del sistema operativo del cliente, y deberá permitir acceso seguro desde ubicaciones autorizadas por la institución.
• La solución deberá soportar autenticación unificada y control de acceso basado en roles, asegurando que cada usuario visualice y Gestióne únicamente la información y funciones que le correspondan.
• El módulo deberá permitir la configuración de parámetros por intervalo de tiempo, con granularidad mínima de quince (15) minutos, para fines de pronóstico, planificación, adherencia y gestión intradía.
• La solución deberá permitir la operación sobre un modelo unificado de múltiples canales cuando la arquitectura del centro de contacto así lo contemple, incluyendo como mínimo voz y back-office, y dejando abierta la posibilidad de incorporar canales digitales.
• El módulo deberá permitir la visualización consolidada y detallada de la situación operativa planificada y real, mediante paneles, calendarios, vistas tabulares, gráficas y reportes configurables.
• La solución deberá mantener consistencia de datos entre pronóstico, horarios, adherencia, excepciones, desempeño y reportería, evitando duplicidades o discrepancias funcionales entre componentes.
• Pronóstico de demanda
  1. El módulo deberá permitir la generación de pronósticos de demanda de interacciones para el centro de contacto, utilizando información histórica, tendencias, estacionalidad y demás variables relevantes para la operación.
  2. La solución deberá permitir generar pronóstico por intervalos de tiempo configurables, con granularidad mínima de quince (15) minutos y con capacidad para consolidación por hora, día, semana y mes.
  3. El módulo deberá permitir generar pronósticos por cola, servicio, grupo de atención, habilidad y combinación de estos criterios, conforme a la estructura operativa definida por la institución.
  4. La solución deberá soportar pronóstico para entornos multiskill, considerando que un mismo agente pueda atender múltiples tipos de interacción o colas operativas.
  5. El módulo deberá permitir incorporar variables históricas tales como volumen de llamadas, AHT, tiempos de espera, abandonos, cargas de trabajo, backlog y demás métricas necesarias para construir pronósticos consistentes.
  6. La solución deberá permitir considerar variaciones por día de semana, franjas horarias, feriados, cierres contables, campañas, eventos extraordinarios y otras condiciones que impacten la demanda operativa.
  7. El módulo deberá permitir importar y exportar datos utilizados para pronóstico, así como administrar outliers, depurar anomalías y recalcular proyecciones con base en datos corregidos.
  8. La solución deberá permitir la construcción de perfiles de pronóstico personalizados, de manera que la institución pueda definir escenarios diferenciados por servicio, temporada, evento especial o necesidad operativa.
  9. El módulo deberá permitir conservar el histórico de pronóstico generados, indicando fecha de generación, parámetros aplicados, usuario responsable y período cubierto.
  10. La solución deberá permitir comparar pronóstico generados contra la demanda real observada, con el fin de medir precisión, desviaciones y oportunidades de ajuste.
  11. El módulo deberá permitir recalcular pronóstico cuando se detecten cambios significativos en la demanda esperada, sin afectar el histórico de pronóstico previamente aprobados.
  12. La solución deberá permitir utilizar pronóstico intradía o repronóstico cuando la operación real se aparte de lo planificado, conforme a lo definido en las secciones correspondientes.
• Modelos de pronóstico y aprendizaje automático
  1. La solución deberá incorporar capacidades avanzadas de pronóstico basadas en modelos analíticos y/o inteligencia artificial que permitan anticipar comportamientos operativos en entornos de alta exigencia.
  2. El módulo deberá permitir seleccionar, configurar y administrar diferentes modelos de pronóstico, según el comportamiento de cada cola, servicio o grupo de atención.
  3. La solución deberá permitir aprendizaje continuo a partir de históricos de operación, de forma que los modelos puedan mejorar su precisión conforme se acumule información real.
  4. El módulo deberá permitir incorporar variables externas en el pronóstico, incluyendo cuando aplique campañas, clima, comportamiento digital, eventos extraordinarios u otros factores definidos por la institución.
  5. La solución deberá permitir evaluar la precisión de los modelos mediante indicadores cuantificables, tales como error promedio absoluto, desviación porcentual u otros equivalentes disponibles en la tecnología ofertada.
  6. El módulo deberá permitir comparar resultados entre distintos modelos o configuraciones de pronóstico para seleccionar la alternativa más conveniente.
  7. La solución deberá permitir aplicar ajustes manuales controlados sobre el pronóstico generado automáticamente, conservando trazabilidad del valor original, justificación y usuario responsable.
  8. El módulo deberá permitir excluir o tratar valores atípicos sin destruir el histórico original, manteniendo integridad y trazabilidad de los datos utilizados para aprendizaje.
  9. La solución deberá permitir parametrizar reglas para definir cuándo un modelo se considera aceptable, cuándo requiere ajuste y cuándo debe ser reemplazado o reentrenado.
  10. El oferente deberá demostrar que la arquitectura propuesta soporta el uso de estos modelos sin degradar el desempeño general del módulo ni la disponibilidad del servicio.
• Planificación operativa
  1. El módulo deberá permitir la planificación operativa de corto, mediano y largo plazo del recurso humano requerido para atender la demanda pronosticada.
  2. La solución deberá calcular la cantidad de personal requerido por intervalo de tiempo, cola, servicio o habilidad, conforme al pronóstico, niveles de servicio y parámetros operativos definidos por la institución.
  3. El módulo deberá permitir modelar diferentes objetivos de servicio, tales como metas de atención, tiempos de espera aceptables, ocupación esperada y utilización del personal.
  4. La solución deberá permitir la planificación semanal y mensual, así como la consolidación y revisión de la cobertura diaria resultante.
  5. El módulo deberá permitir visualizar la cobertura planificada frente a la cobertura requerida, identificando excedentes, déficits, riesgos de subcobertura y sobreasignación de personal.
  6. La solución deberá permitir considerar en la planificación todos los eventos que restan capacidad productiva, incluyendo descansos, almuerzos, reuniones, capacitaciones, ausencias programadas, tiempos administrativos y demás actividades no productivas.
  7. El módulo deberá permitir planificar bajo esquemas presencial, remoto e híbrido, cuando la política institucional así lo permita.
  8. La solución deberá permitir la consolidación de requerimientos operativos por equipo, por servicio y por conjunto de habilidades, facilitando la toma de decisiones de supervisión.
  9. El módulo deberá permitir generar vistas de planificación con distintos niveles de agregación, incluyendo como mínimo por día, semana, mes, cola, equipo y agente.
  10. La solución deberá permitir aprobar, ajustar o rechazar planes de cobertura antes de su publicación, manteniendo trazabilidad del ciclo de revisión y aprobación.
• Gestión de capacidades y dimensionamiento de recursos
  1. El módulo deberá permitir definir y administrar la capacidad disponible del personal operativo en función de cantidad de agentes, habilidades, horarios, restricciones y eventos programados.
  2. La solución deberá permitir medir la brecha entre capacidad requerida y capacidad disponible por intervalo de tiempo, identificando tempranamente riesgos de incumplimiento operativo.
  3. El módulo deberá permitir administrar perfiles multiskill y ponderar la contribución de cada agente según las habilidades efectivamente asignadas.
  4. La solución deberá permitir evaluar la cobertura por habilidad crítica, de forma que la institución pueda identificar si una cola o servicio está cubierto en cantidad y en perfil requerido.
  5. El módulo deberá permitir estimar el impacto de capacitaciones, ausencias, restricciones o cambios de turno sobre la capacidad neta disponible.
  6. La solución deberá permitir proyectar escenarios de incremento o reducción de personal y su efecto sobre niveles de servicio, ocupación y cumplimiento operativo.
  7. El módulo deberá soportar dimensionamiento para la operación nominal y para escenarios extraordinarios, con criterios de resiliencia y continuidad.
  8. La solución deberá permitir utilizar datos de productividad histórica para mejorar el dimensionamiento y evitar asignaciones teóricas que no reflejen la realidad operativa.
• Generación y optimización automática de horarios
  1. La solución deberá permitir la generación automática de horarios optimizados, considerando múltiples restricciones operativas, habilidades del personal y condiciones laborales, dentro de un esquema dinámico y adaptable.
  2. El módulo deberá permitir construir horarios por agente, equipo, servicio o cola, conforme a la cobertura requerida para cada intervalo de tiempo.
  3. La solución deberá permitir la asignación automática de descansos, almuerzos, reuniones, entrenamientos y demás eventos programables, de manera coherente con la demanda esperada.
  4. El módulo deberá permitir la optimización de descansos y reuniones, evitando su concentración en intervalos críticos para la operación.
  5. La solución deberá permitir programación semanal, mensual y periódica, así como ajustes dinámicos posteriores sobre la programación publicada.
  6. El módulo deberá permitir generar múltiples alternativas de horarios, mostrando al usuario autorizado la comparación entre opciones según cobertura, eficiencia y cumplimiento de reglas.
  7. La solución deberá permitir publicación controlada de horarios a los agentes, con registro de fecha, hora y responsable de la publicación.
  8. El módulo deberá permitir modificación manual de horarios por perfiles autorizados, conservando el histórico del horario original, el cambio aplicado, la justificación y el usuario responsable.
  9. La solución deberá permitir definir preferencias de turnos, días libres y horas extra de los agentes, incluyendo su priorización, sin que ello obligue a la institución a aceptar automáticamente dichas preferencias.
  10. La solución deberá permitir reglas de equidad o distribución balanceada de horarios no preferidos, turnos especiales y descansos, cuando así lo defina la institución.
  11. El módulo deberá impedir la generación de horarios incompatibles con restricciones laborales o institucionales definidas en el sistema.
  12. La solución deberá permitir trazabilidad completa del proceso de generación, ajuste, aprobación, publicación y reemplazo de horarios.
• Motor de optimización y gestión de restricciones
  1. El módulo deberá incorporar un motor de optimización capaz de procesar simultáneamente múltiples restricciones y objetivos de negocio al generar o ajustar horarios.
  2. La solución deberá considerar como mínimo restricciones de habilidades, cobertura requerida, jornadas máximas, descansos mínimos, calendarios, disponibilidad declarada, ausencias aprobadas y reglas institucionales.
  3. El motor deberá permitir balancear objetivos tales como cobertura, cumplimiento de nivel de servicio, utilización del personal, equidad de asignaciones y minimización de sobrecarga operativa.
  4. La solución deberá permitir definir restricciones duras y restricciones blandas, de manera que la institución pueda distinguir condiciones obligatorias de criterios deseables.
  5. El módulo deberá mostrar al usuario autorizado los conflictos detectados cuando no sea posible cumplir simultáneamente todas las restricciones configuradas.
  6. La solución deberá permitir priorizar unas restricciones sobre otras conforme a la política operativa definida por la institución.
  7. El motor deberá permitir reutilizar plantillas o reglas de optimización por servicio, cola o grupo operativo.
  8. La solución deberá permitir revisar el impacto de una restricción específica sobre el resultado final de la programación.
  9. El módulo deberá permitir la regeneración parcial o total de horarios cuando cambien restricciones relevantes, sin perder el histórico de las corridas previas.
  10. El oferente deberá garantizar que el motor de optimización forma parte de la solución ofertada y no depende de procesos manuales externos para su funcionamiento ordinario.
• Simulación y análisis de escenarios operativos
  1. El módulo deberá permitir la simulación de escenarios “what-if” basados en demanda, costos, dotación, reglas operativas y disponibilidad del personal.
  2. La solución deberá permitir comparar simultáneamente múltiples escenarios operativos y visualizar sus diferencias en términos de cobertura, utilización, niveles de servicio y requerimiento de personal.
  3. El módulo deberá permitir modelar variaciones en pronóstico, cambios de horarios, aumento o disminución de personal, reasignación de habilidades y eventos especiales.
  4. La solución deberá permitir la simulación por período futuro, por servicio, por cola y por combinación multiskill.
  5. El módulo deberá permitir conservar escenarios guardados, identificando fecha, responsable, supuestos aplicados y resultados proyectados.
  6. La solución deberá permitir comparar un escenario base contra uno o más escenarios alternativos, facilitando la toma de decisiones.
  7. El módulo deberá permitir visualizar los riesgos operativos resultantes de cada escenario, incluyendo déficit de cobertura, picos sin atención suficiente o sobreasignación de recursos.
  8. La solución deberá permitir usar escenarios para justificar decisiones de programación, contingencia, contratación temporal o reasignación de personal.
• Gestión de escenarios críticos y contingencias
  1. Dada la naturaleza crítica del servicio brindado por el Sistema de Emergencias 9-1-1, la solución deberá estar diseñada para operar en entornos de alta exigencia, caracterizados por variaciones abruptas en la demanda y necesidad de respuesta inmediata.
  2. El módulo deberá demostrar capacidad para Gestionar picos de interacción derivados de emergencias nacionales, desastres naturales, incidentes de alta magnitud u otros eventos extraordinarios.
  3. La solución deberá permitir la replanificación dinámica de recursos en tiempo real, priorizando la asignación eficiente del personal ante escenarios de contingencia.
  4. El módulo deberá permitir definir y activar escenarios de contingencia previamente configurados, incluyendo dotaciones reforzadas, ampliación de cobertura horaria y reasignación extraordinaria de personal.
  5. La solución deberá permitir identificar rápidamente brechas de cobertura originadas por ausencias masivas, eventos extraordinarios o fallas de componentes relacionados.
  6. El módulo deberá permitir recomendaciones operativas de ajuste ante escenarios críticos, sin sustituir la decisión final de los perfiles autorizados.
  7. La solución deberá mantener continuidad de operación y acceso a información crítica de WFM durante eventos de alta demanda, evitando indisponibilidad precisamente en los momentos de mayor necesidad operativa.
  8. El módulo deberá facilitar la toma de decisiones basada en información actualizada, confiable y visible en tiempo real para la institución.
• Gestión intradía y control de adherencia
  1. La solución deberá contar con capacidades de gestión intradía que permitan el monitoreo continuo de la operación y la comparación entre planificación y ejecución real.
  2. El módulo deberá medir adherencia en tiempo real comparando la actividad real del agente contra el horario programado.
  3. La solución deberá permitir monitoreo detallado por agente, equipo, servicio y cola, con visibilidad de desviaciones positivas y negativas respecto del plan.
  4. El módulo deberá permitir la definición y administración de excepciones aprobadas que justifiquen desvíos de adherencia, sin contaminar indebidamente los indicadores.
  5. La solución deberá generar alertas automáticas ante incumplimientos relevantes de horario, niveles de adherencia inferiores a umbrales definidos o desviaciones críticas frente al pronóstico.
  6. El módulo deberá permitir reportes históricos de adherencia y control operativo, con filtros por agente, fecha, intervalo, cola, supervisor y tipo de excepción.
  7. La solución deberá permitir el análisis de adherencia planificada versus realizada, diferenciando causas atribuibles al agente, a la supervisión o a condiciones extraordinarias.
  8. El módulo deberá permitir paneles de supervisión en tiempo real con información suficiente para intervenir la operación cuando se detecten desbalances relevantes.
• Replanificación dinámica y ajuste en tiempo real
  1. El módulo deberá permitir ajustes dinámicos de la planificación durante el día, con base en el comportamiento real de la demanda y de la adherencia operativa.
  2. La solución deberá permitir repronóstico intradía cuando se observen desviaciones significativas entre la demanda esperada y la real.
  3. El módulo deberá permitir reubicar descansos, reuniones, capacitaciones y otras actividades planificadas para proteger la cobertura operativa.
  4. La solución deberá permitir sugerir acciones correctivas en tiempo real, tales como reasignación de habilidades, ampliación temporal de cobertura, activación de personal disponible o reprogramación de actividades no críticas.
  5. El módulo deberá permitir que los cambios intradía queden reflejados inmediatamente en las vistas de supervisión y, cuando corresponda, en los portales de autoservicio del agente.
  6. La solución deberá conservar trazabilidad de toda replanificación intradía, incluyendo condición original, ajuste realizado, motivo y usuario responsable.
  7. El módulo deberá permitir distinguir entre ajustes automáticos, ajustes sugeridos y ajustes manualmente aprobados por supervisión.
  8. La solución deberá permitir la operación intradía sin comprometer la estabilidad de los horarios base ni generar pérdida del histórico de planificación aprobado.
• Gestión de excepciones operativas
  1. El módulo deberá permitir la gestión de excepciones operativas tales como ausencias, incapacidades, permisos, capacitaciones, licencias, tiempos de alimentación, reuniones, actividades administrativas y otras condiciones que afecten la disponibilidad del personal.
  2. La solución deberá permitir registrar, aprobar, rechazar, modificar y auditar excepciones, conforme a permisos y flujos definidos por la institución.
  3. El módulo deberá permitir clasificar excepciones por tipo, causa, impacto operativo y condición de aprobación.
  4. La solución deberá permitir que las excepciones aprobadas actualicen automáticamente la planificación, la adherencia esperada y la cobertura disponible.
  5. El módulo deberá permitir mantener listas de espera, prioridades o reglas de sustitución cuando una excepción aprobada comprometa la cobertura operativa.
  6. La solución deberá conservar el histórico completo de excepciones, con fecha, hora, usuario, tipo de excepción, duración y estado de aprobación.
  7. El módulo deberá permitir identificar excepciones recurrentes por agente, equipo o período, para fines de supervisión y mejora operativa.
  8. La solución deberá permitir reportes de impacto de excepciones sobre pronóstico, cobertura, adherencia y desempeño.
• Gestión de cobertura y capacidades operativas
  1. El módulo deberá permitir evaluar continuamente la cobertura operativa en función del pronóstico, del horario publicado y de la disponibilidad real observada.
  2. La solución deberá permitir visualizar capacidad requerida, capacidad planificada y capacidad efectivamente disponible por intervalo de tiempo.
  3. El módulo deberá permitir identificar períodos con déficit, equilibrio o exceso de cobertura, facilitando decisiones de ajuste oportunas.
  4. La solución deberá permitir evaluación de cobertura por cola, servicio, habilidad, equipo y conjunto multiskill.
  5. El módulo deberá permitir configurar umbrales de cobertura aceptable y generar alertas cuando estos se incumplan.
  6. La solución deberá permitir recomendar acciones para recuperar cobertura, tales como reasignación, activación de personal adicional, ajuste de descansos o replanteamiento de actividades no críticas.
  7. El módulo deberá permitir considerar capacidades diferenciadas del personal, evitando tratar como equivalentes agentes con perfiles de habilidad distintos.
  8. La solución deberá permitir evaluación de cobertura tanto a corto plazo como en horizontes semanales y mensuales.
• Gestión de solicitudes del personal
  1. La solución deberá permitir la gestión integral de solicitudes del personal, incluyendo como mínimo cambios de turno, vacaciones, permisos, días libres, horas extra y solicitudes equivalentes definidas por la institución.
  2. El módulo deberá permitir el registro de solicitudes desde interfaz web y desde dispositivos móviles autorizados.
  3. La solución deberá permitir automatizar la aprobación mediante reglas configurables, sin perjuicio de la capacidad de revisión manual por supervisión.
  4. El módulo deberá permitir establecer listas de espera para solicitudes cuando no sea posible su aprobación inmediata por razones de cobertura operativa.
  5. La solución deberá permitir modificar solicitudes existentes, conservando trazabilidad del cambio y del aprobador correspondiente.
  6. El módulo deberá permitir reglas diferenciadas de aprobación por tipo de solicitud, período, supervisor, servicio o condición operativa.
  7. La solución deberá permitir el registro y control de acumulación de tiempo libre cuando aplique, así como su interoperabilidad con sistemas HR/HCM si la institución lo requiere.
  8. La solución deberá impedir la aprobación automática de solicitudes cuando su aceptación produzca una cobertura inferior al umbral mínimo definido para la operación.
  9. El módulo deberá conservar bitácora completa de toda solicitud, incluyendo creación, modificación, aprobación, rechazo, cancelación y ejecución.
• Autoservicio del agente

1. La solución deberá incluir funcionalidades de autoservicio para los agentes, facilitando la gestión de solicitudes operativas y el acceso a información de su programación.
2. El módulo deberá permitir al agente consultar su horario vigente, historial de horarios, turnos publicados, cambios aprobados, excepciones registradas y estado de sus solicitudes.
3. La solución deberá permitir al agente registrar solicitudes, dar seguimiento a su estado y recibir notificaciones sobre aprobación, rechazo o modificación.
4. El módulo deberá permitir al agente visualizar indicadores de desempeño y scorecards cuando la institución así lo habilite.
5. La solución deberá permitir acceso web independiente del sistema operativo para gestión de horarios, solicitudes y métricas de desempeño.
6. El módulo deberá permitir comunicación de objetivos organizacionales, metas o avisos relacionados con la operación, conforme a la configuración institucional.
7. La solución deberá aplicar autenticación segura, segregación por perfil y registro de auditoría de las acciones relevantes ejecutadas por el agente.
8. El módulo deberá impedir que un agente modifique unilateralmente información crítica de planificación fuera de los mecanismos de solicitud y autorización definidos.
   • Capacidades móviles
     1. La solución deberá ofrecer aplicaciones móviles o interfaces móviles plenamente funcionales para iOS y Android, orientadas a la gestión de horarios, solicitudes y notificaciones.
     2. El módulo deberá garantizar seguridad y sincronización en tiempo real con la plataforma principal, evitando discrepancias entre la versión móvil y la versión web.
     3. La solución deberá permitir consulta de horarios, registro de solicitudes, seguimiento de aprobaciones y recepción de avisos operativos desde dispositivos móviles autorizados.
     4. El módulo deberá permitir notificaciones push, correo u otros mecanismos equivalentes para informar eventos relevantes al agente o supervisor.
     5. La solución deberá contemplar manejo de sesión segura, políticas de expiración, control de acceso y mecanismos razonables de protección de datos en dispositivos móviles.
     6. El módulo deberá mantener experiencia funcional consistente entre canales de acceso, sin pérdida de trazabilidad por el uso de interfaz móvil.
   • Reportería y analítica operativa
     1. La solución deberá contar con herramientas de reporting integradas, APIs abiertas y capacidades de visualización de datos para la explotación operativa del módulo WFM.
     2. El módulo deberá permitir reportería en tiempo real e histórica, incluyendo como mínimo pronóstico, cobertura, horarios, adherencia, excepciones, desempeño, utilización y solicitudes del personal.
     3. La solución deberá permitir paneles gráficos, vistas tabulares, tendencias, comparativos y análisis drill-down hasta nivel de agente o intervalo.
     4. El módulo deberá permitir generación de reportes bajo demanda y reportes programados, así como distribución automática a destinatarios autorizados.
     5. La solución deberá permitir exportación de reportes y datos en formatos estándar utilizados por la institución.
     6. El módulo deberá permitir análisis avanzado y detección de anomalías sobre comportamiento operativo, desviaciones de pronóstico, cobertura y adherencia.
     7. La solución deberá permitir analítica ad-hoc por perfiles autorizados, sin requerir intervención del fabricante para consultas ordinarias.
     8. El módulo deberá permitir correlación entre variables operativas, tales como pronóstico, disponibilidad, ausentismo, adherencia, desempeño y calidad de atención.
     9. La solución deberá permitir segmentar reportes por rango de fechas, cola, servicio, equipo, agente, supervisor, habilidad y demás dimensiones relevantes.
   • Integración en tiempo real con la plataforma de telefonía y ACD
     1. La solución deberá integrarse en tiempo real con la plataforma de telefonía y con el ACD, a fin de consumir información operativa necesaria para pronóstico, adherencia, intradía y reportería.
     2. El módulo deberá utilizar como mínimo datos de llamadas entrantes, contestadas, abandonadas, tiempos de atención, tiempos de espera, estados de agentes y eventos de cola para fines de gestión WFM, conforme a la disponibilidad de la arquitectura del centro de contacto.
     3. La solución deberá poder relacionar la planificación del personal con la actividad real observada en el ACD, de forma consistente y trazable.
     4. El módulo deberá permitir consumir información casi en tiempo real para fines de adherencia y gestión intradía, evitando dependencias de cierres diarios para la supervisión operativa.
     5. La integración deberá realizarse mediante mecanismos estándar, APIs o conectores certificados por el fabricante, garantizando soporte y compatibilidad a largo plazo.
     6. La falla temporal de una integración no deberá corromper la información ya registrada en el módulo WFM y deberá permitir recuperación controlada de datos cuando técnicamente sea viable.
   • Integración con otros módulos
     1. La solución deberá permitir su integración con sistemas existentes del Sistema de Emergencias 9-1-1, incluyendo plataformas de telefonía, ACD, IVR, CAD, grabación y otros componentes relevantes.
     2. El módulo deberá permitir integración con sistemas HR, HCM o equivalentes para la sincronización de datos de personal, ausencias, acumulaciones y condiciones laborales, cuando la institución así lo requiera.
     3. La solución deberá permitir integración con CRM u otras fuentes institucionales cuando estas aporten variables relevantes para pronóstico o gestión operativa.
     4. El módulo deberá soportar interoperabilidad mediante APIs abiertas y mecanismos documentados, evitando acoplamientos rígidos o dependencias cerradas.
     5. La solución deberá permitir que resultados de desempeño y analítica alimenten procesos de coaching, calidad y aprendizaje cuando la arquitectura ofertada lo contemple.
     6. La integración deberá respetar control de acceso, trazabilidad y seguridad de la información conforme a las políticas institucionales.
   • Requisitos de desempeño, escalabilidad y disponibilidad
     1. La solución deberá operar bajo una arquitectura SaaS o equivalente de nivel empresarial, garantizando altos niveles de disponibilidad, escalabilidad y resiliencia acordes con un entorno de misión crítica.
     2. El módulo deberá mantener desempeño adecuado aun con ciento ochenta (180) agentes nominales, múltiples supervisores, múltiples colas y operación simultánea de pronóstico, scheduling, intradía, reportería y autoservicio.
     3. La solución deberá soportar crecimiento futuro de usuarios, datos históricos, reportes y carga operativa sin requerir rediseños estructurales.
     4. El módulo deberá ofrecer tiempos de respuesta coherentes para operaciones de consulta, edición, aprobación, publicación y reportería, sin degradación perceptible atribuible a la plataforma en condiciones normales de uso.
     5. La solución deberá permitir operación continua sin interrupciones, con actualizaciones evolutivas y correctivas realizadas de forma segura y controlada.
     6. El módulo deberá contar con mecanismos de observabilidad y monitoreo operativo que permitan identificar degradaciones, errores y afectaciones antes de que comprometan la operación.
     7. La solución deberá disponer de capacidades de recuperación ante incidentes y continuidad del servicio acordes a la criticidad del entorno del 9-1-1.
     8. El oferente deberá dimensionar la solución con holgura suficiente para períodos de alta demanda, cierres de período, procesos simultáneos y escenarios de contingencia.
   • Auditoría y trazabilidad
     1. La solución deberá incorporar capacidades de auditoría completa que permitan la trazabilidad de todas las acciones relevantes realizadas dentro del módulo WFM.
     2. El módulo deberá registrar, como mínimo, creación, modificación, aprobación, rechazo, publicación, cancelación y reprogramación de pronóstico, horarios, excepciones, solicitudes, parámetros y configuraciones relevantes.
     3. Cada registro de auditoría deberá incluir como mínimo fecha y hora, usuario, perfil, tipo de acción, entidad afectada y detalle del cambio realizado.
     4. La solución deberá permitir consulta y exportación de auditoría por perfiles autorizados, con filtros por fecha, usuario, tipo de acción, agente, supervisor o entidad afectada.
     5. El módulo deberá preservar la integridad del historial, evitando alteraciones no autorizadas, borrado de evidencias o pérdida de trazabilidad.
     6. La solución deberá permitir trazabilidad diferenciada entre acciones automáticas del sistema y acciones ejecutadas manualmente por usuarios autorizados.
     7. El módulo deberá mantener consistencia entre auditoría funcional, datos operativos y reportería, de forma que los registros puedan utilizarse para control institucional, revisión operativa y eventual verificación contractual.
     8. La auditoría del módulo deberá operar de forma coherente con la política general de auditoría y seguridad del resto de la solución ofertada.

8.3.  Módulo de Gestión de Calidad (Quality Management – QM / Gestión de retroalimentación y coaching / Acceso a evidencia y reproducción de interacciones)

• El oferente deberá suministrar un Módulo de Gestión de Calidad (Quality Management - QM) orientado a la evaluación, monitoreo, mejora continua y optimización del desempeño del personal operativo del centro de contacto del Sistema de Emergencias 9-1-1.
• El módulo deberá constituirse como la herramienta institucional para la evaluación estructurada de las interacciones atendidas por los agentes, permitiendo medir de forma objetiva el cumplimiento de protocolos, lineamientos operativos, estándares de calidad y criterios definidos por la institución.
• La solución deberá cubrir de forma integral, como mínimo, la captura de interacciones, reproducción sincronizada de evidencia, definición de metodologías de evaluación, selección de muestras, formularios configurables, gestión de evaluaciones, automatización de calidad, retroalimentación, coaching, revisiones, reportería, seguridad, almacenamiento, auditoría e integración con otros módulos.
• El módulo deberá operar como parte de una plataforma unificada de gestión de experiencia, desempeño y calidad, evitando dependencias funcionales de herramientas desconectadas para grabación, evaluación, analítica y coaching.
• El alcance del módulo deberá contemplar la gestión de calidad para interacciones de voz y, cuando la arquitectura ofertada lo permita, para interacciones no voz, tales como chat, correo electrónico y otros canales digitales que puedan incorporarse institucionalmente.
• La solución deberá permitir la evaluación diferenciada por servicio, cola, tipo de interacción, grupo de agentes, equipo operativo, supervisor, unidad o cualquier otro criterio organizacional que defina la institución.
• El módulo deberá ser apto para operar en un entorno de misión crítica, permitiendo priorizar interacciones relevantes para la operación 9-1-1, incluyendo aquellas asociadas a eventos de alto impacto, desviaciones operativas o incumplimientos relevantes.
• El oferente deberá dimensionar la solución para soportar como mínimo ciento ochenta (180) agentes nominales, así como los perfiles de supervisión, evaluación, análisis y administración que se requieran para la gestión completa del módulo.
• El módulo deberá quedar implementado con todos los componentes, licencias, configuraciones, integraciones, documentación, capacitación y servicios necesarios para su operación completa, sin que la institución deba adquirir componentes adicionales no declarados para hacerlo funcional.
• La solución deberá quedar preparada para evolucionar hacia esquemas de automatización, analítica avanzada y coaching asistido, sin que ello implique rediseños estructurales del módulo base.
• Requisitos funcionales generales

1. El módulo deberá permitir la administración centralizada de usuarios, perfiles, equipos de evaluación, grupos de agentes, colas, campañas, servicios, criterios de evaluación, formularios, plantillas, reglas y parámetros generales del proceso de calidad.
2. La solución deberá permitir diferenciar perfiles funcionales, incluyendo como mínimo administradores del módulo, analistas de calidad, supervisores, evaluadores y agentes evaluados, con permisos segregados conforme a las funciones institucionales.
3. El módulo deberá operar preferiblemente en ambiente web, obligatoriamente en idioma español, y ser compatible con todas las versiones de navegadores para Windows liberados al momento del inicio de la contratación, sin requerir estaciones especializadas para sus funciones ordinarias.
4. La solución deberá permitir la parametrización institucional de los principales elementos del módulo, sin requerir intervención del fabricante para ajustes rutinarios de operación, tales como formularios, ponderaciones, criterios, metas, reglas de muestreo, umbrales, bandejas y flujos de revisión.
5. El módulo deberá permitir la visualización consolidada y detallada de las evaluaciones, muestras, grabaciones, evidencia asociada, métricas de calidad y tareas pendientes de revisión.
6. La solución deberá mantener consistencia entre las interacciones capturadas, los metadatos operativos, la evaluación aplicada, el resultado obtenido y la reportería resultante, evitando duplicidades o discrepancias funcionales.
7. El módulo deberá permitir la operación con múltiples tipos de formularios, distintos flujos de aprobación y metodologías diferenciadas según el contexto operativo.
8. La solución deberá permitir la gestión concurrente de múltiples evaluadores y supervisores sin generar bloqueos indebidos, pérdida de información o inconsistencias en las evaluaciones.
9. El módulo deberá permitir que los evaluadores trabajen sobre una interfaz unificada, desde la cual puedan acceder a la interacción, a la evidencia, al formulario de evaluación, a los metadatos y a los controles de revisión sin necesidad de cambiar entre múltiples pantallas o aplicaciones.
10. La solución deberá permitir la creación de bandejas de trabajo, colas internas o mecanismos equivalentes para distribuir carga entre evaluadores, supervisores y analistas de calidad.
11. El módulo deberá permitir que las acciones de calidad se asocien, cuando corresponda, a métricas operativas, KPIs, eventos CTI, transcripciones, etiquetas, anotaciones y demás metadatos disponibles en la solución.
12. La solución deberá permitir el uso del módulo tanto para evaluación manual como para evaluación automática o híbrida, según lo que la institución defina.
    • Captura y registro de interacciones
      1. La solución deberá permitir la captura automática y continua de interacciones completas bajo un enfoque extremo a extremo, desde el punto de contacto inicial hasta el cierre de la interacción.
      2. La captura deberá contemplar, como mínimo, audio de la interacción, grabación de pantalla del agente, eventos CTI asociados, metadatos operativos, marcas de tiempo y demás elementos necesarios para reconstruir de forma íntegra el contexto de la atención.
      3. Cuando la arquitectura ofertada lo permita, la solución deberá contemplar transcripción asociada a la interacción y eventos de analítica de escritorio o analítica de voz, de forma sincronizada con la evidencia principal.
      4. La solución deberá garantizar que la captura de la interacción se produzca automáticamente sin depender de la activación manual del usuario final para su funcionamiento ordinario.
      5. El módulo deberá permitir la captura de interacciones de voz y no voz cuando estos canales se encuentren habilitados dentro de la solución institucional.
      6. La plataforma deberá permitir la asociación estructurada de cada interacción con datos mínimos de identificación, incluyendo como mínimo fecha y hora, identificador de interacción, agente, cola o servicio, duración, canal, y demás metadatos disponibles en la arquitectura implementada.
      7. La solución deberá impedir inconsistencias entre la evidencia capturada y los metadatos asociados, garantizando integridad y trazabilidad entre ambos componentes.
      8. El módulo deberá permitir conservar evidencia suficiente para sustentar evaluaciones, revisiones, coaching, auditorías y eventuales verificaciones institucionales.
      9. La captura de interacciones no deberá degradar de forma perceptible la operación normal del puesto de atención ni afectar la continuidad del servicio.
      10. La solución deberá permitir registrar etiquetas, anotaciones o marcadores sobre la interacción capturada, ya sea durante la reproducción o mediante mecanismos equivalentes autorizados.
      11. El oferente deberá garantizar que la captura y registro de interacciones opere en concordancia con el sistema de grabación de la plataforma de telefonía y con los eventos relevantes del ACD, asegurando coherencia entre ambos componentes.
      12. La institución deberá poder verificar, durante las pruebas de aceptación, que las interacciones capturadas conservan la trazabilidad necesaria desde su origen hasta su utilización en procesos de evaluación.
    • Modelo de evaluación y metodología configurable
      1. El módulo deberá permitir definir metodologías de evaluación configurables, que incluyan criterios, ponderaciones, umbrales de aprobación, reglas de cálculo y demás parámetros necesarios para estructurar el proceso institucional de calidad.
      2. La solución deberá permitir la coexistencia de múltiples metodologías activas o históricas, de forma que la institución pueda aplicar distintos enfoques de evaluación según el tipo de interacción, cola, campaña, servicio o grupo de agentes.
      3. El módulo deberá permitir establecer porcentajes mínimos obligatorios de muestra por agente, por período, por equipo, por cola o por cualquier otra segmentación que defina la institución.
      4. La solución deberá permitir definir metas mínimas de evaluaciones por evaluador, supervisor, turno, área o período, con capacidad de seguimiento y control de cumplimiento.
      5. El módulo deberá permitir configurar evaluaciones con carácter obligatorio, aleatorio, dirigido, correctivo, preventivo o cualquier otra modalidad metodológica definida por la institución.
      6. La solución deberá permitir versionamiento de metodologías, de forma que toda modificación posterior conserve el histórico de la metodología previa sin alterar evaluaciones ya realizadas.
      7. El módulo deberá permitir aplicar criterios de evaluación diferenciados por canal, por tipo de interacción, por nivel de criticidad o por categoría operativa.
      8. La solución deberá permitir definir reglas que asocien automáticamente una metodología específica a una interacción según condiciones configurables, tales como cola, servicio, tipo de llamada, duración, agente, evento CTI o cualquier otro dato disponible.
      9. El módulo deberá permitir identificar claramente qué metodología, versión y conjunto de reglas fue aplicado a cada evaluación finalizada.
      10. Toda modificación a las metodologías deberá quedar registrada en auditoría, incluyendo usuario responsable, fecha, hora y detalle del cambio realizado.
    • Administración de muestras y selección de interacciones
      1. El módulo deberá permitir la selección manual de interacciones mediante filtros avanzados aplicables sobre los campos estructurados disponibles en la solución.
      2. La solución deberá permitir la combinación múltiple de filtros sin restricciones artificiales relevantes, incluyendo como mínimo fecha, hora, agente, duración, identificador de interacción, cola, servicio, etiquetas definidas por usuario y otros criterios operativos disponibles.
      3. El módulo deberá permitir la selección aleatoria automática configurable por grupo evaluado, período, servicio, cola o cualquier otra dimensión relevante.
      4. La solución deberá permitir la programación automática de generación de muestras para períodos definidos por la institución, tales como diario, semanal, quincenal o mensual.
      5. El módulo deberá identificar interacciones previamente evaluadas, evitando duplicidades no deseadas en el proceso de calidad.
      6. La solución deberá permitir reglas de muestreo dirigidas por riesgo, criticidad, incumplimiento de KPIs, eventos CTI, palabras clave, duración inusual o cualquier otro criterio disponible.
      7. El módulo deberá permitir asignar automáticamente las interacciones seleccionadas a evaluadores, supervisores o bandejas de trabajo, conforme a reglas de distribución configurables.
      8. La solución deberá permitir que toda selección de muestra quede registrada en bitácora, indicando método de selección, criterios utilizados, fecha, hora, usuario o proceso responsable y resultado obtenido.
      9. El módulo deberá permitir excluir interacciones de procesos de muestreo cuando la institución lo requiera por reglas previamente definidas, sin que ello implique pérdida del registro original.
      10. La solución deberá permitir mostrar la población total de interacciones elegibles, la muestra efectivamente tomada y las interacciones ya evaluadas, a efectos de control metodológico.
      11. El módulo deberá permitir muestreo por períodos comparativos y facilitar análisis de cobertura del plan de calidad por agente, equipo o servicio.
    • Formularios de evaluación configurables
      1. La solución deberá proporcionar un constructor de formularios de evaluación que permita la creación, reutilización, adaptación y versionamiento de formularios según distintos escenarios operativos.
      2. El módulo deberá soportar múltiples tipos de preguntas, incluyendo preguntas ponderadas, preguntas condicionales, respuestas cerradas, respuestas abiertas, escalas, listas de selección y demás formatos equivalentes disponibles en la solución.
      3. La solución deberá permitir evaluaciones dinámicas según tipo de interacción, canal, cola, servicio, perfil de agente o condición operativa definida por la institución.
      4. El módulo deberá permitir la definición de preguntas obligatorias, opcionales, excluyentes o dependientes de respuestas previas, conforme al diseño metodológico institucional.
      5. La solución deberá permitir configurar secciones, agrupaciones temáticas, encabezados, textos de ayuda, reglas de cálculo y criterios de aprobación dentro de cada formulario.
      6. El módulo deberá permitir reutilizar formularios o plantillas base para reducir duplicidad de configuración, sin afectar la trazabilidad entre versiones.
      7. La solución deberá permitir activar, desactivar o reemplazar formularios, conservando histórico de versiones y evitando la alteración retroactiva de evaluaciones ya completadas.
      8. El módulo deberá permitir asociar automáticamente un formulario a una interacción según reglas configurables o permitir su selección manual por perfiles autorizados.
      9. La solución deberá permitir que los formularios sean aplicables únicamente a los grupos, servicios o escenarios para los que fueron diseñados, evitando uso indebido sobre perfiles no correspondientes, siguiendo la lógica institucional ya definida para evaluación diferenciada.
      10. La solución deberá permitir validar consistencia interna del formulario antes de su activación, detectando condiciones lógicas incompatibles o configuraciones incompletas.
    • Gestión de evaluaciones
      1. El módulo deberá permitir evaluación manual, evaluación automática y modelos híbridos de evaluación, conforme a la política institucional de calidad.
      2. La solución deberá permitir registrar evaluaciones efectuadas por analistas de calidad, supervisores y otros perfiles autorizados, así como autoevaluaciones del agente cuando la institución habilite dicha capacidad.
      3. El módulo deberá permitir almacenar evaluaciones en estado borrador, en revisión y finalizadas, con trazabilidad completa del ciclo de vida de cada evaluación.
      4. La solución deberá permitir guardar respuestas parciales y reanudar evaluaciones no finalizadas sin pérdida de información.
      5. El módulo deberá permitir el cierre formal de una evaluación, registrando fecha, hora, evaluador, metodología aplicada, formulario utilizado y resultado final obtenido.
      6. La solución deberá permitir asignar un nombre descriptivo o un identificador automático a cada evaluación finalizada, conforme a la política institucional.
      7. El módulo deberá permitir vincular una evaluación con la interacción exacta que la originó, sin ambigüedad sobre la evidencia utilizada.
      8. La solución deberá permitir comparar evaluaciones realizadas sobre una misma interacción cuando la institución defina procesos de doble revisión, calibración o control de consistencia.
      9. El módulo deberá permitir registrar comentarios, hallazgos, observaciones y justificaciones por parte del evaluador dentro del contexto de la evaluación.
      10. La solución deberá permitir reabrir evaluaciones únicamente por perfiles autorizados, dejando registro de la causa, fecha, hora y responsable de la reapertura.
      11. El módulo deberá impedir modificaciones no autorizadas sobre evaluaciones finalizadas, salvo mediante los mecanismos de revisión o apelación formalmente definidos.
    • Automatización de evaluaciones y reglas de calidad
      1. La solución deberá permitir la automatización parcial o total de procesos de evaluación mediante el uso de reglas, analítica avanzada e inteligencia artificial, con capacidad de analizar hasta el cien por ciento (100%) de las interacciones, cuando la arquitectura ofertada así lo contemple.
      2. El módulo deberá permitir generar automáticamente evaluaciones a partir de reglas configurables, sin requerir intervención del fabricante para su definición, prueba y ajuste.
      3. La solución deberá permitir que las reglas automáticas utilicen como insumo transcripciones de voz, datos CTI, eventos de escritorio, metadatos de la interacción y demás datos disponibles en la solución.
      4. El módulo deberá permitir aplicar múltiples formularios automáticos seleccionados dinámicamente según tipo de interacción, canal, evento o condición operativa.
      5. La solución deberá permitir sobrescribir resultados automáticos mediante intervención manual controlada, conservando trazabilidad del resultado automático original y del ajuste posterior.
      6. El módulo deberá permitir priorizar automáticamente interacciones críticas para evaluación inmediata, incluyendo aquellas relacionadas con emergencias de alto impacto, desviaciones operativas o incumplimientos relevantes.
      7. La solución deberá permitir asignar automáticamente interacciones a evaluadores, analistas o supervisores mediante reglas de negocio, KPIs o condiciones operativas específicas.
      8. El módulo deberá permitir validar el desempeño de las reglas automáticas mediante reportes comparativos entre resultados automáticos y validaciones humanas.
      9. La solución deberá permitir desactivar, ajustar o reemplazar reglas automáticas sin afectar evaluaciones históricas ya generadas.
      10. Toda regla automática aplicada deberá quedar trazada, permitiendo identificar qué condición disparó la evaluación, cuándo ocurrió y qué resultado produjo.
    • Acceso a evidencia y reproducción de interacciones
      1. La solución deberá ofrecer reproducción sincronizada de audio, pantalla, eventos CTI, transcripciones y metadatos asociados, dentro de una interfaz unificada.
      2. El módulo deberá permitir visualización completa de la interacción, incluyendo audio, pantalla del agente, eventos CTI tales como hold o transferencias, anotaciones, marcadores y transcripciones cuando apliquen.
      3. La solución deberá permitir búsqueda avanzada de interacciones mediante múltiples criterios, incluyendo fecha y hora, agente, duración, identificador de interacción, etiquetas definidas por usuario, metadatos operativos y búsqueda de texto cuando exista transcripción.
      4. El módulo deberá permitir reproducir fragmentos específicos de una interacción cuando existan etiquetas, eventos, marcas temporales o hallazgos de analítica que justifiquen revisión focalizada.
      5. La solución deberá permitir agregar etiquetas, anotaciones y marcadores durante la reproducción de las interacciones, conservando su asociación con el punto exacto de la línea de tiempo.
      6. El módulo deberá permitir compartir interacciones o extractos de revisión con otros perfiles autorizados, cuando la política institucional así lo permita y siempre bajo control de acceso y auditoría.
      7. La solución deberá impedir que el acceso a evidencia quede desvinculado del control de permisos, evitando reproducción, exportación o difusión no autorizada.
      8. El módulo deberá operar de forma coherente con los controles de integridad y protección de evidencia definidos para el sistema de grabación institucional.
      9. La solución deberá permitir que el evaluador realice su análisis sin necesidad de consultar herramientas externas para reconstruir el contexto de la interacción.
      10. El acceso a evidencia deberá quedar completamente registrado en auditoría, incluyendo al menos búsquedas, reproducciones, exportaciones y demás acciones relevantes.
    • Gestión de apelaciones y revisiones
      1. El módulo deberá permitir un proceso formal de revisión o apelación de evaluaciones, aplicable a resultados finalizados que el agente, supervisor o perfil autorizado solicite revisar.
      2. La solución deberá permitir registrar el motivo de la apelación o revisión, el usuario solicitante, la fecha, la hora y la evaluación afectada.
      3. El módulo deberá permitir asignar la revisión a un perfil autorizado distinto del evaluador original, cuando la institución así lo defina para asegurar independencia del proceso.
      4. La solución deberá permitir mantener visible tanto el resultado original como el resultado revisado, en caso de que la metodología institucional contemple modificaciones posteriores.
      5. El módulo deberá permitir registrar comentarios, justificaciones, hallazgos y resolución final dentro del expediente de revisión.
      6. La solución deberá permitir definir estados del flujo de revisión o apelación, tales como recibido, en análisis, resuelto, aceptado, rechazado u otros equivalentes configurables.
      7. El módulo deberá impedir la pérdida del histórico original de la evaluación aun cuando exista una resolución que modifique el resultado final.
      8. Toda acción de apelación o revisión deberá quedar registrada en auditoría y ser consultable por perfiles autorizados.
      9. La solución deberá permitir reportería específica sobre revisiones y apelaciones, a efectos de control institucional y análisis de consistencia del proceso de calidad.
    • Reportería y analítica de calidad
      1. La solución deberá incluir un módulo de reportería integrado, con acceso en tiempo real a métricas clave de desempeño y calidad.
      2. El módulo deberá permitir visualización gráfica y tabular, análisis de tendencias, drill-down a nivel de interacción y comparación entre agentes, equipos, servicios o unidades organizativas.
      3. La solución deberá soportar generación de reportes bajo demanda y reportes programados, así como su distribución automática a destinatarios autorizados.
      4. El módulo deberá permitir creación de reportes personalizados por parte del usuario autorizado, sin requerir desarrollos adicionales para consultas ordinarias.
      5. La solución deberá permitir métricas de calidad por agente, evaluador, supervisor, equipo, cola, servicio, período y metodología aplicada.
      6. El módulo deberá permitir identificar patrones recurrentes de incumplimiento, fortalezas operativas, oportunidades de mejora, desviaciones y segmentos de riesgo.
      7. La solución deberá permitir vincular métricas de calidad con KPIs operativos cuando las integraciones respectivas estén habilitadas.
      8. El módulo deberá permitir analítica histórica y comparativa de la calidad, incluyendo evaluaciones por período, por muestra, por cola y por grupo de agentes.
      9. La solución deberá facilitar la toma de decisiones operativas mediante información consolidada, confiable y disponible en tiempo real.
      10. La reportería deberá poder integrarse con plataformas externas mediante mecanismos abiertos o capas de datos autorizadas, cuando la institución así lo requiera.
    • Seguridad de la información y control de acceso
      1. La solución deberá incorporar mecanismos robustos de autenticación y autorización aplicables al módulo QM, en coherencia con el modelo general de seguridad de la solución institucional.
      2. El módulo deberá permitir control de acceso basado en roles, de forma que cada perfil visualice y Gestióne únicamente las interacciones, evaluaciones, métricas, formularios y funciones que le correspondan.
      3. La solución deberá permitir restringir el acceso a grabaciones, pantallas, transcripciones, evaluaciones, reportes, planes de coaching y procesos de revisión conforme a permisos diferenciados por rol.
      4. El módulo deberá impedir la consulta, reproducción, descarga, exportación o modificación de información de calidad por usuarios no autorizados.
      5. La solución deberá permitir perfiles diferenciados para administración del módulo, evaluación, supervisión, coaching, agente evaluado, consulta y auditoría.
      6. El módulo deberá mantener coherencia con los controles de acceso del sistema de grabación y con la protección de evidencia definida para la plataforma de telefonía.
      7. La solución deberá registrar en auditoría los inicios de sesión, búsquedas, reproducciones, exportaciones, cambios de configuración y demás acciones relevantes relacionadas con el control de acceso.
      8. El módulo deberá proteger la información en tránsito y en reposo conforme a buenas prácticas y capacidades de seguridad de la plataforma ofertada.
      9. La solución deberá permitir segregación lógica de la información, de manera que pueda controlarse el acceso por área, cola, grupo o cualquier otra dimensión organizacional definida por la institución.
      10. Los controles de seguridad del módulo no deberán depender de procesos manuales externos para su funcionamiento ordinario.
    • Histórico, almacenamiento y auditoría
      1. El contratista deberá considerar el almacenamiento de las evaluaciones, controles, evidencia asociada, planes de coaching, revisiones y demás registros generados por el módulo durante toda la vigencia contractual, garantizando un respaldo confiable de dicha información.
      2. La solución deberá permitir histórico completo de interacciones evaluadas, formularios utilizados, metodologías aplicadas, resultados obtenidos, revisiones efectuadas y acciones de coaching derivadas.
      3. El módulo deberá conservar el histórico de formularios y metodologías, de manera que toda evaluación pueda reconstruirse conforme a la versión exacta vigente al momento de su aplicación.
      4. La solución deberá permitir consulta histórica por período, agente, evaluador, supervisor, cola, servicio, formulario, metodología o cualquier otra dimensión relevante.
      5. El módulo deberá soportar almacenamiento suficiente para la cantidad de interacciones, evaluaciones y controles requeridos por la operación institucional, sin afectar el desempeño normal de la plataforma.
      6. La solución deberá registrar auditoría completa de acciones funcionales y administrativas, incluyendo creación, modificación, aprobación, cierre, reapertura, revisión, exportación y configuración del módulo.
      7. El histórico y la auditoría deberán preservarse aun cuando existan cambios de metodología, formularios, reglas o estructuras organizativas.
      8. La solución deberá impedir mecanismos que permitan modificación o eliminación indebida de evidencia, evaluaciones o registros históricos asociados al módulo.
      9. El módulo deberá permitir exportación controlada de históricos y auditorías por perfiles autorizados, sin comprometer la integridad del repositorio principal.
      10. La institución deberá poder verificar, durante las pruebas de aceptación, la preservación de datos históricos, el correcto versionamiento de formularios y la existencia de auditoría verificable sobre las acciones del módulo, siguiendo la misma lógica ya definida en los módulos institucionales de calidad y formularios estructurados.
    • Integración con otros módulos
      1. El módulo deberá integrarse de forma nativa o plenamente soportada con el sistema de grabación, la plataforma de telefonía IP y el ACD, garantizando coherencia entre interacciones, evidencia, eventos CTI y métricas operativas.
      2. La solución deberá integrarse con mecanismos de monitoreo, auditoría y reportes de la plataforma de telefonía, de modo que los datos operativos disponibles puedan ser utilizados para fines de calidad.
      3. El módulo deberá mantener coherencia con colas, agentes, estados, tiempos, métricas y demás datos operativos disponibles en la solución de telefonía propuesta.
      4. La solución deberá permitir integración con módulos de analytics, performance management, coaching y aprendizaje, de forma que los resultados analíticos puedan alimentar procesos de evaluación, mejora y desarrollo del personal.
      5. Cuando la institución lo requiera, el módulo deberá poder interoperar con el CAD u otros sistemas institucionales mediante interfaces documentadas, seguras y trazables, siempre dentro del alcance autorizado por la Administración.
      6. La solución deberá permitir mecanismos de integración con plataformas externas mediante APIs o capas de datos abiertas, sin comprometer seguridad, integridad, trazabilidad ni control de acceso.
      7. Toda integración del módulo deberá registrar en bitácora las operaciones relevantes de intercambio de datos, cuando ello aplique conforme a la arquitectura implementada.
      8. El oferente deberá garantizar que las integraciones necesarias para la funcionalidad completa del módulo forman parte de la solución ofertada y no se considerarán opcionales cuando resulten indispensables para el cumplimiento del alcance definido.

8.4.  Módulo de Analítica Avanzada de Interacciones (Speech Analytics)

• El oferente deberá suministrar un Módulo de Analítica Avanzada de Interacciones (Speech Analytics) orientado al análisis automatizado de las comunicaciones Gestiónadas por el centro de contacto del Sistema de Emergencias 9-1-1, con el fin de identificar patrones, tendencias, causas raíz, eventos críticos y oportunidades de mejora operativa.
• El módulo deberá permitir el análisis estructurado de grandes volúmenes de interacciones de voz, apoyándose en tecnologías de reconocimiento de voz, procesamiento de lenguaje natural, aprendizaje automático e inteligencia artificial, según las capacidades ofertadas.
• La solución deberá operar bajo un modelo unificado de analítica, donde las capacidades de speech analytics, interaction analytics y, cuando aplique a la arquitectura del fabricante, text analytics, se encuentren integradas de forma nativa dentro de una misma plataforma; no obstante, para la presente contratación se deberá considerar obligatoriamente el componente de speech analytics.
• El módulo deberá permitir la exploración y análisis de interacciones con fines operativos, de supervisión, control de calidad, mejora continua, toma de decisiones, apoyo a la gestión del personal y detección temprana de desviaciones relevantes para la operación del 9-1-1.
• El alcance del módulo deberá comprender, como mínimo, transcripción automática, indexación, búsqueda avanzada, categorización automática, descubrimiento de temas, análisis de causa raíz, identificación de patrones, detección de eventos críticos, consultas analíticas en lenguaje natural, reportería, dashboards, integración con otros módulos, seguridad, auditoría y trazabilidad.
• La solución deberá estar dimensionada para soportar al menos ciento ochenta (180) agentes nominales dentro del alcance institucional del centro de contacto, sin perjuicio de que el oferente deba considerar holgura razonable para crecimiento, picos de carga y evolución futura.
• El módulo deberá ser apto para un entorno de misión crítica, permitiendo la disponibilidad de análisis útiles para la operación en tiempos acordes a las necesidades del servicio público de emergencias.
• La solución deberá evitar dependencias funcionales de herramientas externas no contempladas en la propuesta para cumplir con las capacidades analíticas aquí requeridas.
• El oferente deberá garantizar que el módulo se entregue con todos los componentes, licencias, configuraciones, integraciones, documentación, parametrización y servicios profesionales necesarios para su funcionamiento integral.
• El módulo deberá permitir evolución futura sin rediseños estructurales relevantes, incluyendo crecimiento en volumen de interacciones, reglas analíticas, consultas, categorías, reportes y usuarios autorizados.
• Requisitos funcionales generales
  1. El módulo deberá operar sobre las interacciones registradas por la solución institucional, permitiendo el análisis posterior de la conversación y de sus metadatos asociados.
  2. La solución deberá permitir el procesamiento masivo de interacciones, generando transcripciones completas y estructuradas, junto con metadatos enriquecidos que permitan su análisis posterior.
  3. El módulo deberá permitir la exploración de grandes volúmenes de interacciones mediante mecanismos de búsqueda avanzada, análisis automatizado y generación de hallazgos sin depender exclusivamente de listas predefinidas de palabras clave.
  4. La solución deberá permitir la navegación entre métricas agregadas y el detalle de la interacción individual que respalda cada hallazgo analítico.
  5. El módulo deberá permitir el análisis sobre la totalidad de las interacciones procesadas o sobre subconjuntos definidos por filtros, períodos, colas, agentes, categorías, etiquetas o condiciones operativas.
  6. La solución deberá permitir análisis ad-hoc por parte de perfiles autorizados, sin requerir intervención del fabricante para la exploración ordinaria de la información.
  7. El módulo deberá mantener consistencia entre transcripción, audio, metadatos, resultados analíticos, categorías, hallazgos y reportería, evitando discrepancias funcionales entre componentes.
  8. La solución deberá permitir interfaces diferenciadas para administración, análisis, supervisión y consulta, conforme a los perfiles y permisos que defina la institución.
  9. El módulo deberá operar preferiblemente en ambiente web, en idioma español, y ser accesible desde el entorno institucional sin requerir instalaciones especiales en estaciones de trabajo para sus funciones ordinarias.
  10. La solución deberá permitir la administración centralizada de parámetros del módulo, incluyendo modelos, diccionarios, categorías, umbrales, alertas, perfiles, tableros, consultas y reglas analíticas.
  11. El módulo deberá permitir correlacionar información analítica con variables operativas relevantes, tales como servicio, cola, agente, duración, tiempo de espera, transferencias, llamadas retenidas, eventos CTI u otras dimensiones disponibles en la solución.
  12. La plataforma deberá permitir, cuando la arquitectura del fabricante lo soporte, la correlación analítica entre canales, aun cuando en esta etapa contractual el alcance obligatorio se concentre en speech analytics.
• Transcripción automática de interacciones
  1. La solución deberá generar transcripciones completas de las interacciones de voz procesadas, de forma automática y estructurada, sin requerir intervención manual para su generación ordinaria.
  2. El módulo deberá permitir el uso de modelos adaptados al dominio del negocio, incluyendo ajuste de vocabulario, reconocimiento contextual y mejora continua de precisión tanto supervisada como automática.
  3. La solución deberá permitir la incorporación y administración de vocabulario especializado institucional, incluyendo términos técnicos, acrónimos, nombres de lugares, jergas operativas, denominaciones de instituciones de respuesta, nombres propios relevantes y demás expresiones frecuentes del ámbito 9-1-1.
  4. El módulo deberá permitir el reconocimiento de diferentes pronunciaciones, variaciones fonéticas, muletillas y expresiones propias del contexto nacional, en la medida en que lo soporte la tecnología ofertada.
  5. La solución deberá permitir separación de hablantes o funcionalidad equivalente, de forma que el texto transcrito pueda distinguir, cuando la tecnología lo permita, entre las diferentes voces participantes de la interacción.
  6. El módulo deberá mantener sincronización entre audio y transcripción, permitiendo ubicar y reproducir segmentos específicos de la interacción a partir del texto transcrito.
  7. La solución deberá permitir identificar el idioma o la variante lingüística utilizada en la interacción cuando dicha capacidad forme parte de la oferta.
  8. El módulo deberá permitir conservar múltiples versiones de transcripción cuando se apliquen mejoras o reprocesamientos autorizados, sin pérdida del histórico de resultados previos cuando ello resulte necesario para trazabilidad.
  9. La solución deberá permitir medir, revisar y mejorar la precisión de transcripción mediante mecanismos controlados, trazables y administrables por perfiles autorizados.
  10. El módulo deberá impedir que ajustes posteriores del modelo alteren de forma inconsulta el valor probatorio o la trazabilidad de los resultados ya utilizados en procesos analíticos, de calidad o de supervisión.
  11. La transcripción automática no deberá degradar el desempeño general de la plataforma ni comprometer la disponibilidad de otros componentes críticos.
  12. La institución deberá poder verificar en pruebas que la transcripción generada mantiene una calidad suficiente para soportar búsqueda, categorización, descubrimiento de temas y reportería analítica.
• Indexación y búsqueda avanzada
  1. La solución deberá permitir la búsqueda avanzada de contenido dentro de interacciones sin requerir que los términos de búsqueda hayan sido previamente definidos antes del procesamiento de las llamadas.
  2. El módulo deberá soportar sugerencias automáticas de términos y frases durante la construcción de búsquedas, basadas en el comportamiento real de los datos procesados.
  3. La solución deberá permitir búsquedas por palabras, frases, conceptos, categorías, metadatos, etiquetas, duración, agente, servicio, cola, fecha, hora y demás dimensiones disponibles en la arquitectura implementada.
  4. El módulo deberá soportar operadores lógicos avanzados, incluyendo como mínimo AND, OR, NEAR y otras capacidades equivalentes soportadas por la plataforma.
  5. La solución deberá permitir búsquedas contextuales, tales como ocurrencia de términos antes o después de una frase, cercanía entre términos y ubicación dentro de la interacción.
  6. El módulo deberá permitir la búsqueda por ubicación dentro de la llamada, identificando si un término o evento ocurrió al inicio, en la parte media o al final de la interacción.
  7. La solución deberá permitir identificar rápidamente el segmento exacto de la interacción donde ocurre un resultado y reproducir directamente dicho fragmento sin necesidad de revisar la llamada completa.
  8. El módulo deberá soportar indexación suficiente para que la búsqueda opere sobre texto transcrito, metadatos enriquecidos, categorías y demás atributos analíticos disponibles.
  9. La solución deberá permitir guardar consultas frecuentes, compartirlas con perfiles autorizados y reutilizarlas en procesos recurrentes de análisis o supervisión.
  10. El módulo deberá permitir exportar resultados de búsqueda conforme a permisos y bajo trazabilidad completa.
  11. La búsqueda deberá operar con tiempos razonables y consistentes aun sobre grandes volúmenes de interacciones procesadas, sin degradación perceptible atribuible al motor de indexación.
• Análisis de contenido y categorización automática
  1. La solución deberá permitir la categorización automática de interacciones mediante el uso de modelos avanzados de análisis de lenguaje y demás tecnologías analíticas disponibles en la plataforma.
  2. El módulo deberá permitir la creación dinámica de categorías sin requerir reprocesamiento completo de las grabaciones históricas, cuando la tecnología ofertada contemple esa capacidad.
  3. La solución deberá soportar categorización basada en contenido de la conversación, categorización basada en metadata y categorización combinada, cuando la arquitectura ofertada lo permita.
  4. El módulo deberá permitir estructuras jerárquicas de categorías, incluyendo al menos categorías padre e hijo, así como la administración de taxonomías analíticas por parte de perfiles autorizados.
  5. La solución deberá permitir la creación, modificación, activación, desactivación y versionamiento de categorías sin afectar la integridad del histórico analítico previamente generado.
  6. El módulo deberá permitir clasificar una misma interacción en una o varias categorías cuando ello corresponda a la metodología definida por la institución.
  7. La solución deberá permitir detectar atributos relevantes dentro de la conversación, incluyendo cuando la tecnología lo permita sentimiento, emoción, intención, eventos de conflicto, señales de estrés u otras dimensiones equivalentes.
  8. El módulo deberá permitir validar, revisar y ajustar categorías asignadas automáticamente, conservando trazabilidad del resultado automático original y de los cambios manuales autorizados.
  9. La solución deberá permitir utilizar resultados de categorización para búsquedas, reportería, priorización, quality management, coaching y análisis de tendencias.
  10. El módulo deberá permitir configurar umbrales, reglas o criterios adicionales para fortalecer o restringir la asignación automática de determinadas categorías.
  11. La plataforma deberá evitar dependencias rígidas de listas estáticas de palabras clave como único método de categorización, permitiendo un análisis más rico y contextual de las interacciones.
  12. Descubrimiento automático de temas y causas raíz
  13. La solución deberá incorporar capacidades de descubrimiento automático de temas (unsupervised discovery) que permitan identificar comportamientos, tendencias y causas raíz no previamente definidas por el usuario.
  14. El módulo deberá ser capaz de descubrir temas, patrones y comportamientos sin depender exclusivamente de taxonomías o categorías previamente definidas por la institución.
  15. La solución deberá permitir identificar causas raíz de problemas operativos a partir de técnicas de correlación, agrupamiento, análisis estadístico y demás mecanismos equivalentes soportados por la plataforma.
  16. El módulo deberá permitir detectar tendencias emergentes, cambios significativos en la frecuencia de temas, anomalías y patrones no evidentes en el comportamiento de las interacciones.
  17. La solución deberá permitir generar explicaciones automáticas basadas en datos reales, acompañadas de evidencia asociada a interacciones específicas que respalden los hallazgos identificados.
  18. El módulo deberá permitir validar los hallazgos mediante acceso directo a las interacciones que soportan las conclusiones analíticas, evitando resultados opacos o no verificables.
  19. La solución deberá permitir distinguir entre hallazgos descubiertos automáticamente y hallazgos definidos a partir de reglas o categorías preexistentes.
  20. El módulo deberá permitir la exploración progresiva de temas descubiertos, pasando desde agrupaciones amplias a subconjuntos más específicos sin perder contexto.
  21. La solución deberá permitir utilizar los descubrimientos automáticos como insumo para reportería, mejora operativa, gestión de calidad, coaching y toma de decisiones.
  22. Los hallazgos automáticos deberán conservar trazabilidad suficiente para identificar el período analizado, los datos considerados, el usuario que ejecutó la consulta y la evidencia asociada.
• Identificación de patrones y tendencias
  1. La solución deberá permitir identificar patrones recurrentes en las interacciones procesadas, utilizando la totalidad del universo analizado o subconjuntos definidos por filtros autorizados.
  2. El módulo deberá permitir identificar tendencias operativas por período, cola, agente, tema, categoría, servicio, grupo o cualquier otra dimensión relevante.
  3. La solución deberá permitir detectar cambios en la frecuencia de temas, comportamiento anómalo, variaciones abruptas y señales emergentes de riesgo u oportunidad.
  4. El módulo deberá permitir análisis comparativo entre períodos, segmentos, equipos, grupos de atención o configuraciones de operación.
  5. La solución deberá permitir análisis de tendencias sobre la totalidad de las interacciones, sin depender exclusivamente de subconjuntos previamente filtrados o muestras reducidas.
  6. El módulo deberá permitir correlación entre variables, facilitando identificar relaciones entre categorías, tiempos de atención, transferencias, colas, eventos CTI y demás datos disponibles.
  7. La solución deberá permitir al usuario autorizado navegar desde la métrica agregada hasta la interacción específica que compone el patrón o tendencia observada.
  8. El módulo deberá permitir el uso de filtros temporales, operativos y organizacionales para acotar el análisis de patrones y tendencias según la necesidad institucional.
  9. La solución deberá permitir resaltar visualmente cambios significativos y variaciones estadísticamente relevantes cuando la plataforma ofertada contemple dicha capacidad.
• Detección de eventos críticos
  1. La solución deberá permitir la detección temprana de eventos críticos, escalaciones, fallas operativas o comportamientos anómalos mediante análisis automatizado de interacciones.
  2. El módulo deberá permitir identificar situaciones relevantes para la operación del 9-1-1, incluyendo como mínimo patrones de alto impacto, llamadas asociadas a incidentes críticos, expresiones o conductas que sugieran urgencia extraordinaria, y demás eventos que la institución defina.
  3. La solución deberá permitir priorizar analíticamente interacciones críticas para revisión inmediata por parte de perfiles autorizados.
  4. El módulo deberá permitir la configuración de reglas, umbrales, categorías o criterios combinados para activar alertas sobre eventos relevantes.
  5. La solución deberá permitir que la detección de eventos críticos se base en combinación de contenido conversacional, metadatos, categorías, transcripciones y demás atributos analíticos disponibles.
  6. El módulo deberá permitir asociar evidencia directa a cada evento crítico detectado, facilitando su validación y revisión posterior.
  7. La solución deberá permitir que los eventos críticos detectados alimenten procesos de QM, coaching, reportería y supervisión operativa cuando esas integraciones estén habilitadas.
  8. El módulo deberá permitir diferenciar entre alertas automáticas confirmadas, alertas en revisión y alertas descartadas, manteniendo trazabilidad del tratamiento dado a cada caso.
  9. La detección automatizada no deberá sustituir el juicio operativo institucional, pero sí deberá aportar insumos útiles, verificables y oportunos para la toma de decisiones.
• Consultas analíticas en lenguaje natural
  1. La solución deberá permitir la interacción mediante consultas en lenguaje natural, facilitando que los usuarios autorizados obtengan respuestas inmediatas sobre el comportamiento de las interacciones, causas de contacto, tendencias y desempeño operativo.
  2. El módulo deberá ser capaz de responder preguntas formuladas en lenguaje natural y producir resultados basados en datos reales del repositorio analítico, acompañados de evidencia trazable a nivel de interacción individual.
  3. La solución deberá incluir capacidades de inteligencia artificial generativa que permitan analizar automáticamente las interacciones y responder consultas en lenguaje natural realizadas por los usuarios.
  4. El módulo deberá permitir consultas orientadas, como mínimo, a identificar causas raíz, tendencias emergentes, hallazgos relevantes, patrones de comportamiento y segmentos de interacción relacionados con el resultado presentado.
  5. La solución deberá permitir que las respuestas generadas remitan a evidencia verificable, evitando respuestas no sustentadas en datos reales.
  6. El módulo deberá permitir refinar preguntas, guardar consultas frecuentes y reutilizarlas por perfiles autorizados.
  7. La solución deberá permitir administrar permisos para el uso de esta capacidad, diferenciando entre usuarios con capacidad de consulta simple y usuarios con capacidad de exploración más amplia.
  8. El uso de lenguaje natural no deberá reemplazar las herramientas analíticas tradicionales, sino complementarlas como mecanismo adicional de acceso a la información.
  9. Toda consulta analítica en lenguaje natural deberá quedar registrada en bitácora, identificando usuario, fecha, hora, consulta ejecutada y resultado generado, cuando la arquitectura del fabricante lo permita.
• Generación de reportes y dashboards
  1. La solución deberá incluir un módulo de reportería integrado que permita la visualización de datos en formatos gráficos y tabulares, sin requerir herramientas externas para la explotación ordinaria del módulo.
  2. El módulo deberá soportar dashboards configurables, reportes programados, reportes bajo demanda, análisis comparativo entre segmentos e identificación de diferencias estadísticas, cuando dichas capacidades estén incluidas en la plataforma ofertada.
  3. La solución deberá permitir análisis ad-hoc, correlación entre variables, navegación entre métricas y detalle de interacciones y exploración visual de los resultados analíticos.
  4. El módulo deberá permitir construir tableros por perfil, área, objetivo analítico o necesidad operativa, con permisos diferenciados para creación, modificación, publicación y consulta.
  5. La solución deberá permitir exportación de reportes en formatos estándar y, cuando la arquitectura lo contemple, integración con plataformas externas mediante capas de datos abiertas o mecanismos equivalentes autorizados.
  6. El módulo deberá permitir reportería comparativa entre períodos, equipos, colas, servicios, categorías, causas de contacto y cualquier otra dimensión relevante disponible en la solución.
  7. La solución deberá permitir enlazar visualizaciones con el detalle de las interacciones que sustentan cada indicador, facilitando verificación inmediata del hallazgo.
  8. El módulo deberá permitir guardar, compartir y versionar dashboards y reportes por perfiles autorizados, manteniendo trazabilidad de sus cambios relevantes.
  9. La reportería deberá ser apta para uso operativo y de supervisión, así como para explotación analítica más profunda por perfiles especializados.
  10. La solución deberá permitir que los resultados analíticos alimenten directamente procesos de calidad, mejora operativa y desarrollo del personal, cuando las integraciones respectivas se encuentren habilitadas.
• Integración con otros módulos
  1. El módulo deberá integrarse de forma nativa o plenamente soportada con el sistema de grabación, el ACD, la plataforma de telefonía y los demás componentes necesarios para obtener las interacciones y sus metadatos asociados.
  2. La solución deberá integrarse de manera nativa con módulos de Quality Management, Performance Management, Coaching y eLearning, cuando dichas capacidades formen parte de la plataforma ofertada.
  3. El módulo deberá permitir que los resultados analíticos alimenten directamente procesos de evaluación, mejora y desarrollo del personal, sin necesidad de reprocesos manuales extensivos.
  4. La solución deberá operar de forma armónica con el módulo QM ya definido para la institución, evitando duplicidad funcional y permitiendo complementariedad entre analítica avanzada y gestión de calidad.
  5. Cuando la institución lo requiera, el módulo deberá poder interoperar con el CAD u otros sistemas institucionales mediante interfaces documentadas, seguras y trazables, siempre dentro del alcance autorizado por la Administración.
  6. La integración deberá permitir reutilizar transcripciones, categorías, hallazgos, alertas y demás resultados analíticos como insumos para reportería institucional, calidad, supervisión y toma de decisiones.
  7. Toda integración relevante deberá respetar control de acceso, trazabilidad, seguridad de la información y consistencia de datos entre componentes.
  8. El oferente deberá garantizar que las integraciones indispensables para el funcionamiento completo del módulo forman parte del alcance ofertado y no se considerarán opcionales cuando resulten necesarias para cumplir los requerimientos aquí definidos.
• Requisitos de desempeño, procesamiento y escalabilidad
  1. La solución deberá ser escalable a nivel empresarial, soportando múltiples sitios, unidades organizativas, reglas operativas y crecimiento progresivo del volumen de interacciones procesadas.
  2. El módulo deberá permitir el procesamiento eficiente de grandes volúmenes de datos sin degradación del desempeño general atribuible al motor analítico.
  3. La solución deberá garantizar tiempos de disponibilidad de resultados analíticos acordes a las necesidades operativas del 9-1-1, incluyendo disponibilidad en tiempo casi real cuando la arquitectura ofertada contemple dicha capacidad.
  4. El módulo deberá soportar crecimiento en cantidad de interacciones, transcripciones, categorías, consultas, dashboards, usuarios analíticos y reglas automáticas sin requerir rediseños estructurales relevantes.
  5. La solución deberá mantener consistencia de procesamiento entre audio, transcripción, indexación, búsqueda y reportería, evitando retrasos no justificados entre etapas del flujo analítico.
  6. El módulo deberá permitir procesamiento masivo y concurrente, así como consultas simultáneas por múltiples usuarios autorizados, sin degradación significativa del servicio.
  7. La solución deberá incluir mecanismos de monitoreo técnico y operativo que permitan identificar cuellos de botella, errores de procesamiento y degradaciones del motor analítico antes de que afecten la operación.
  8. El módulo deberá estar preparado para incorporar nuevas reglas, categorías, modelos o consultas sin comprometer estabilidad ni integridad de los resultados previos.
  9. El oferente deberá dimensionar la solución con holgura suficiente para la operación nominal y para escenarios de incremento de carga, sin alegar posteriormente insuficiencias de arquitectura no advertidas en la oferta.
• Consideraciones operativas del módulo de analítica de interacciones
  1. El módulo de Analítica Avanzada de Interacciones deberá operar como un componente analítico complementario a la solución de telefonía y grabación, orientado al procesamiento de interacciones ya registradas, sin intervenir en el flujo de atención en tiempo real.
  2. La solución deberá garantizar que el módulo no participa en el enrutamiento de llamadas, no forma parte del proceso de atención directa al usuario final y no introduce latencia ni degradación en la calidad de la comunicación durante la llamada.
  3. El módulo deberá procesar las interacciones una vez finalizadas, utilizando como insumo las grabaciones de audio, metadatos del ACD, eventos CTI y demás información generada por la operación del centro de contacto.
  4. La solución deberá permitir el procesamiento de interacciones en modalidad post-proceso, ya sea en tiempo diferido o en esquemas de procesamiento continuo, garantizando que los resultados analíticos se encuentren disponibles en tiempos acordes a las necesidades operativas de la institución.
  5. Cuando la tecnología ofertada lo contemple, el módulo podrá ofrecer capacidades de análisis en tiempo cercano al real (near real-time); sin embargo, dichas capacidades no deberán ser obligatorias para la operación básica ni generar dependencia para la atención de emergencias.
  6. La solución deberá garantizar que cualquier capacidad de análisis en tiempo cercano al real opere de forma no intrusiva, sin afectar la estabilidad, disponibilidad o desempeño del entorno productivo de telefonía.
  7. El módulo deberá integrarse con el sistema de grabación institucional, reutilizando las interacciones ya capturadas, evitando la duplicidad de mecanismos de grabación o procesamiento paralelo innecesario.
  8. La solución deberá consumir información del ACD, PBX o componentes equivalentes mediante interfaces estándar, APIs o mecanismos soportados por la plataforma, asegurando consistencia entre los datos operativos y los resultados analíticos.
  9. El módulo deberá mantener coherencia entre las interacciones procesadas, las transcripciones generadas, los metadatos asociados y los resultados analíticos, garantizando trazabilidad completa desde la interacción original hasta el hallazgo generado.
  10. La solución deberá permitir la ejecución de procesos analíticos de forma independiente al horario de operación del centro de contacto, sin afectar la continuidad del servicio ni la disponibilidad de los sistemas críticos.
  11. El módulo deberá garantizar que el procesamiento masivo de interacciones no genere afectaciones en el desempeño de la plataforma de telefonía, del sistema de grabación ni de los demás módulos integrados.
  12. La solución deberá permitir escalabilidad en el procesamiento analítico, de forma que el incremento en el volumen de interacciones no comprometa los tiempos de disponibilidad de los resultados ni la estabilidad del sistema.
  13. El módulo deberá operar bajo un esquema de desacoplamiento funcional respecto a los componentes de atención en vivo, de manera que cualquier falla en el componente analítico no impacte la operación del servicio de atención de emergencias.
  14. El oferente deberá garantizar que la arquitectura propuesta respeta los principios de continuidad operativa, alta disponibilidad, redundancia y resiliencia definidos para la solución institucional, evitando puntos únicos de falla asociados al módulo de analítica.
  15. La institución deberá poder verificar, durante las pruebas de aceptación, que el módulo opera conforme a un esquema no intrusivo, que no afecta la atención de llamadas en producción y que los procesos analíticos se ejecutan sobre información correctamente integrada desde los sistemas fuente.
• Seguridad de la información
  1. La solución deberá incorporar mecanismos robustos de autenticación y autorización aplicables al módulo de speech analytics, coherentes con el modelo general de seguridad de la solución institucional.
  2. El módulo deberá permitir control de acceso basado en roles, de manera que cada perfil visualice únicamente las interacciones, transcripciones, hallazgos, reportes, dashboards y funciones que le correspondan.
  3. La solución deberá impedir accesos no autorizados a transcripciones, resultados analíticos, consultas en lenguaje natural, reportes, exportaciones y configuraciones del módulo.
  4. El módulo deberá proteger la información en tránsito y en reposo conforme a las capacidades de seguridad de la plataforma ofertada y a las políticas institucionales.
  5. La solución deberá respetar la sensibilidad de la información tratada, incluyendo contenido de llamadas de emergencia, datos operativos, hallazgos analíticos y metadatos relacionados con agentes y usuarios.
  6. El módulo deberá permitir segregación lógica de acceso por área, servicio, cola, grupo, unidad o cualquier otra dimensión organizacional que defina la institución.
  7. La solución deberá registrar en bitácora las acciones relevantes relacionadas con acceso, búsquedas, reproducciones, exportaciones, consultas analíticas, cambios de configuración y demás operaciones sensibles.
  8. Los controles de seguridad del módulo deberán operar de forma armónica con los controles del sistema de grabación, de QM y del resto de la plataforma, evitando vacíos de control entre componentes.
  9. El módulo deberá impedir mecanismos de modificación no autorizada sobre resultados históricos, evidencias asociadas o trazabilidad de hallazgos analíticos.
  10. La institución deberá poder verificar, durante pruebas, que los perfiles y permisos definidos restringen efectivamente el acceso a la información analítica conforme al rol asignado.
• Auditoría y trazabilidad
  1. La solución deberá incorporar capacidades de auditoría completa que permitan trazabilidad de todas las acciones relevantes realizadas dentro del módulo de speech analytics.
  2. El módulo deberá registrar, como mínimo, procesamiento de interacciones, generación de transcripciones, ejecución de búsquedas, creación y ajuste de categorías, descubrimiento de temas, generación de hallazgos, consultas en lenguaje natural, creación de reportes, exportaciones y cambios de configuración.
  3. Cada registro de auditoría deberá incluir, como mínimo, fecha y hora, usuario, perfil, tipo de acción, objeto afectado y detalle suficiente para reconstruir la operación realizada.
  4. La solución deberá permitir consulta y exportación de auditoría por perfiles autorizados, con filtros por fecha, usuario, tipo de acción, interacción, categoría, hallazgo o reporte.
  5. El módulo deberá diferenciar, cuando aplique, entre acciones ejecutadas automáticamente por el sistema y acciones ejecutadas manualmente por usuarios autorizados.
  6. La solución deberá preservar la integridad del historial de auditoría, evitando borrado, alteración no autorizada o pérdida de trazabilidad.
  7. El módulo deberá mantener consistencia entre la auditoría funcional, la evidencia analítica y la reportería generada, de forma que cada hallazgo o resultado pueda rastrearse hasta su origen.
  8. La auditoría del módulo deberá operar en coherencia con la política general de auditoría institucional y con los controles transversales definidos para la solución contratada.
  9. La institución deberá poder verificar, durante pruebas de aceptación, la existencia de trazabilidad suficiente sobre búsquedas, hallazgos, consultas, exportaciones, ajustes de categorías, cambios de configuración y uso de consultas en lenguaje natural.
  10. La auditoría del módulo deberá estar disponible durante toda la vigencia contractual y preservarse conforme a las políticas de retención que resulten aplicables al entorno institucional.

 

 

 

 

 

 

9.    Sistema de evaluación de ofertas

9.1.         Regla general de evaluación

• El presente sistema de evaluación contempla los factores ponderables, su grado de importancia y el método para comparar las ofertas recibidas.
• Solamente podrán ser sometidas al sistema de evaluación aquellas ofertas que cumplan con los requisitos de admisibilidad, las condiciones técnicas mínimas, las condiciones administrativas y demás requisitos esenciales establecidos en el presente pliego.
• La calificación se realizará sobre una base de cien puntos, conforme a la siguiente distribución:

Criterio de evaluación	Puntaje máximo
Precio mensual ofertado	75 puntos
Trayectoria verificable en servicios similares	5 puntos
Experiencia específica en proyectos similares	5 puntos
Porcentaje de disponibilidad ofrecido	10 puntos
Certificación ISO/IEC 27001	5 puntos
Total	100 puntos

 

9.2.  Precio mensual ofertado — 75 puntos

• Una vez aplicada la metodología anterior, se asignará el puntaje máximo a la oferta que presente el mejor resultado evaluable, siempre que cumpla con los requisitos de admisibilidad y las condiciones técnicas establecidas en el pliego.
• Las demás ofertas serán calificadas mediante la siguiente fórmula matemática de proporcionalidad compuesta (regla de tres).:

P = (P1 / P2) × PM

Donde:

P = Puntaje por asignar.

P1 = Menor precio mensual ofertado.

P2 = Precio mensual de la oferta por evaluar.

PM = Puntaje máximo del criterio, equivalente a 75 puntos.

• Para efectos de evaluación, el precio mensual deberá incluir todos los costos necesarios para la prestación integral del servicio de la línea correspondiente, incluyendo implementación, configuración, licenciamiento, soporte, mantenimiento, monitoreo, continuidad operativa, capacitación, documentación, pruebas, integraciones y demás costos asociados al servicio.
• Para efectos de la evaluación, comparación de ofertas e igualdad de condiciones, la Administración realizará el análisis económico proyectando de forma homogénea el costo mensual ofertado para las cuatro (4) líneas por el plazo total de cuarenta y ocho (48) meses, independientemente de que la entrada en operación efectiva o la fecha de arranque de los Módulos Especializados (Líneas 2, 3 y 4) ocurra en un momento posterior a la Línea 1 principal debido al cronograma de implementación técnica. El contratista adjudicado cobrará y facturará a la institución el costo mensual de cada línea a partir del momento en que dicha línea o módulo especializado cuente con el respectiva acta de recibido conforme y puesta en operación efectiva, resguardando que la Administración no pague por componentes que no se encuentren en ejecución

 

9.3.  Trayectoria verificable en servicios similares — 5 puntos

• Se otorgará puntaje adicional al oferente que acredite mayor trayectoria verificable en la implementación, operación, administración o soporte de servicios o soluciones similares al objeto contractual.
• Para estos efectos, se considerarán servicios similares aquellos relacionados con comunicaciones IP, telefonía IP, centros de contacto, contact center multicanal, ACD, IVR, grabación, monitoreo, reportería, soporte de servicios críticos u operaciones 24/7.
• La trayectoria deberá acreditarse mediante referencias, constancias, certificaciones, contratos, órdenes de compra, actas de recepción, cartas de clientes o documentos equivalentes que permitan verificar objetivamente la participación del oferente, el alcance del servicio y el periodo durante el cual ha brindado servicios similares.

Trayectoria verificable del oferente	Puntaje
Más de 7 y hasta 9 años	2 puntos
Más de 9 y menos de 12 años	4 puntos
12 años o más	5 puntos

 

• Para efectos de esta evaluación, no se valorará únicamente la antigüedad comercial de la empresa, sino la experiencia verificable en servicios o soluciones similares al objeto contractual.

9.4.  Experiencia específica en proyectos similares — 5 puntos

Se otorgará puntaje adicional a los oferentes que acrediten experiencia verificable en la implementación de soluciones de telefonía IP y centros de contacto multicanal similares al objeto contractual.

Para efectos de evaluación únicamente se considerarán proyectos finalizados o en operación productiva, debidamente acreditados mediante certificaciones, constancias o cartas emitidas por los clientes respectivos.

La asignación de puntaje se realizará de la siguiente forma:

• 3 a 4 proyectos verificables: 2 puntos.
• 5 a 6 proyectos verificables: 3 puntos.
• 7 a 9 proyectos verificables: 4 puntos.
• 10 o más proyectos verificables: 5 puntos.

No se otorgará puntaje por los proyectos utilizados para acreditar el requisito mínimo de admisibilidad.

9.5.  Porcentaje de disponibilidad ofrecido — 10 puntos

• Se otorgará puntaje adicional al oferente que ofrezca un porcentaje de disponibilidad superior al mínimo requerido en el presente pliego para la línea 1.

Porcentaje de disponibilidad ofrecido	Puntaje
Igual al mínimo requerido en el pliego	0 puntos
Superior al mínimo requerido y hasta 99,995%	5 puntos
Superior a 99,995% y hasta 99,999%	8 puntos
Superior a 99,999%	10 puntos

 

• El porcentaje de disponibilidad ofrecido por el adjudicatario formará parte de sus obligaciones contractuales y deberá ser medible, verificable y exigible durante la ejecución del contrato.

9.6.  Certificación ISO/IEC 27001 — 5 puntos

Con el propósito de incentivar la adopción de buenas prácticas en materia de seguridad de la información, la Administración otorgará puntaje de hasta cinco (5) puntos a aquellos oferentes que acrediten contar con una certificación ISO/IEC 27001 vigente, emitida por un organismo certificador acreditado.

Para acreditar este criterio el oferente deberá aportar copia de la certificación vigente emitida a su nombre, en la cual se identifique claramente la entidad certificadora, el alcance de la certificación y su vigencia.

El alcance de la certificación deberá guardar relación con la prestación de servicios de tecnologías de información, telecomunicaciones, centros de contacto, servicios administrados, plataformas en la nube o actividades equivalentes relacionadas con el objeto contractual.

La asignación de puntaje se realizará de la siguiente manera:

• Certificación ISO/IEC 27001 vigente y con alcance relacionado con el objeto contractual: 5 puntos.
• No acredita certificación ISO/IEC 27001 vigente o el alcance no guarda relación con el objeto contractual: 0 puntos.

La certificación deberá encontrarse vigente a la fecha de apertura de las ofertas.

9.7.  Evaluación de líneas complementarias

• La Línea 1 será evaluada como componente principal, obligatorio e indispensable de la contratación.
• Las líneas complementarias solo podrán ser adjudicadas para ejecución inmediata si cumplen con los requisitos técnicos correspondientes, resultan razonables en precio, se encuentran integradas funcionalmente con la Línea 1 y existe disponibilidad presupuestaria. Cuando no exista disponibilidad presupuestaria inmediata, la Administración podrá adjudicarlas bajo modalidad de activación posterior, siempre que hayan sido ofertadas, evaluadas y resulten técnica y económicamente admisibles. En tal supuesto, su ejecución, implementación, facturación y pago quedarán sujetos a disponibilidad presupuestaria futura, necesidad institucional, conveniencia administrativa y orden formal de activación.
• La no adjudicación de una o varias líneas complementarias no afectará la adjudicación, ejecución, operación ni aceptación de la Línea 1.
• La evaluación económica integral de las cuatro líneas no implica obligación de la Administración de ejecutar, activar o pagar de forma inmediata la totalidad de los componentes evaluados. Su finalidad es comparar objetivamente el costo integral de las soluciones ofertadas, resguardar la razonabilidad del precio y evitar estrategias de traslado artificial de costos entre líneas.

 

9.8.  Criterios de desempate

• En caso de empate en la calificación final, se aplicarán los siguientes criterios, en orden sucesivo:
  1. Mayor puntaje obtenido en el criterio de precio.
  2. Mayor puntaje obtenido en el criterio de disponibilidad.
  3. Mayor puntaje obtenido en el criterio de trayectoria verificable.
  4. Mayor cantidad de experiencias verificables en servicios similares.
  5. De persistir el empate, se aplicará el mecanismo que corresponda conforme a la normativa aplicable.

10.         ANEXOS

10.1.          Lista de anexos

• Forman parte integral del presente pliego de condiciones los siguientes anexos:

Tabla 6. Lista de anexos

Anexo	Nombre
Anexo 1	Estudio para la determinación de cláusula penal y multas
Anexo 2	Matriz de evaluación de ofertas
Anexo 3	Matriz de cumplimiento técnico
Anexo 4	Matriz de oferta económica por línea
Anexo 5	Matriz de experiencia y referencias verificables
Anexo 6	Convenio de confidencialidad
Anexo 7	Matriz mensual de verificación para recepción del servicio y trámite de pago

 

• Los anexos deberán ser considerados por los oferentes para la preparación de sus ofertas y por la Administración para el análisis, evaluación, adjudicación, ejecución, recepción y control contractual del servicio.

En caso de contradicción entre el cuerpo principal del pliego y un anexo, prevalecerá el cuerpo principal del pliego, salvo que el anexo desarrolle una condición expresamente remitida por el pliego.

CAPÍTULO I CONDICIONES GENERALES

 

1. La presente contratación será financiada con fondos propios del Sistema de Emergencias 9-1-1.

 

1. Precio
   • El Sistema de Emergencias 9-1-1 no está exento del Impuesto sobre el Valor Agregado (IVA)
   • El oferente está obligado a cotizar todo el objeto. No se admitirá la cotización parcial de una línea. La oferta económica debe contemplar la totalidad de la oferta técnica. El contratista estará obligado a cumplir con el objeto íntegro, sin cobrar ninguna suma adicional.
   • El precio deberá ser cierto y definitivo. En caso de divergencia entre el precio cotizado en números y letras, prevalecerá este último.
   • El precio debe indicarse en colones costarricenses o en cualquier otro tipo de moneda de curso legal.
   • El oferente debe cotizar los precios unitarios y totales (impuestos incluidos).
   • El precio que debe presentarse en SICOP debe corresponder a la necesidad según se indique, todo conforme al objeto contractual, sea: precio unitario, total, mensual, por horas, u otro que se requiera de manera expresa en el pliego de condiciones.

 

Partida	Línea	Condición	Descripción	Monto mensual Imp incl.
Única	1	Obligatoria, principal	Arrendamiento de solución de telefonía y centro de contactos multicanal
	2	Complementaria	Módulo de Gestión de Calidad, Desempeño Operativo, Retroalimentación y Coaching — Quality Management / Performance Management
	3	Complementaria	Módulo de Gestión de Fuerza de Trabajo / Workforce Management, planificación, programación, adherencia y gestión intradía
	4	Complementaria	Módulo de Analítica Avanzada de Interacciones — Speech Analytics, transcripción, búsqueda y análisis de comunicaciones

 

Nota:      Ver Numeral 2.3. Precio y forma de pago

 

1. Vigencia de la oferta
   • La vigencia de la oferta deberá extenderse por el plazo que se solicita en el formulario SICOP (90 días hábiles) contado a partir del día siguiente de la fecha de apertura.

 

1. Estudio de ofertas y adjudicación
   • Toda oferta deberá suministrar la información completa y suficiente que permita su análisis y estudio comparativo para efectos de adjudicación.
   • El oferente está obligado a cotizar todas las líneas de una partida, pero la Administración aplicando el sistema de evaluación por línea, podrá adjudicar conforme el resultado de ésta.
   • La Administración resolverá la contratación en el plazo que se indica en el formulario SICOP, el cual no podrá ser superior al doble del plazo fijado en el pliego de condiciones para la recepción de ofertas. Sin embargo, se reserva el derecho de prorrogar este plazo en caso de considerarlo necesario, hasta por un plazo igual al de recibir ofertas.
   • El Sistema de Emergencias 9-1-1 se reserva la posibilidad de adjudicación total o parcial de una misma línea. Así mismo, podrá dictar un acto declarando infructuoso (no se presentaron ofertas o las que lo hicieron no se ajustaron a los elementos esenciales) o declarar desierto (por razones de protección al interés público, evidente falta de competencia o colusión).

 

1. Garantía de cumplimiento
   • Cuando así se requiera, el adjudicatario deberá extender una Garantía de Cumplimiento a nombre del contratante, dentro de los 5 días hábiles contados a partir de la fecha en que quede en firme la adjudicación.
   • Si el adjudicatario no presenta la Garantía de Cumplimiento dentro del plazo aquí estipulado, el contratante podrá revocar la adjudicación sin responsabilidad de su parte, dejar sin valor ni efecto la oferta del adjudicatario, en cuyo caso se podrá re- adjudicar la contratación o declararla desierta, según convenga a sus intereses.
   • Cuando así se requiera, la garantía de cumplimiento deberá otorgarse válidamente con una vigencia de hasta por dos meses adicionales a la fecha de terminación del plazo de la contratación (RLGCP art. 110, 111 y 114).

 

1. Gestiones de recepción (bienes/servicios) y pago:
   • Todo pago a cargo de la Administración se realizará luego de la recepción definitiva de los bienes y servicios. Para esto, el Contratista deberá tramitar desde la plataforma de SICOP la solicitud para la recepción de bienes y servicios; y posteriormente la solicitud para la gestión de pago (anexando las facturas y documentos que se requieran para gestionar el pago solicitado) (Art Nº285 RLGCP).

Complementariamente, con la finalidad de un adecuado control y seguimiento, se solicita el favor de remitir la documentación relacionada con la gestión de pago a la cuenta de correo proveeduria@911.go.cr

• Una vez emitida el acta de recepción definitiva y el Contratista tramite la solicitud de gestión de pago en el SICOP, la Administración procederá con el pago del precio al contratista según lo establecido en este contrato y dentro del plazo de 30 días naturales.
• El Sistema de Emergencias 9-1-1 realizará el pago por medio de transferencia bancaria, para lo cual el oferente deberá indicar en su oferta el número de cuenta bancaria correspondiente. Preferiblemente, esta Administración acreditará el pago mediante transferencia a las siguientes entidades bancarias: Banco de Costa Rica (BCR) o Banco Nacional de Costa Rica (BNCR).
• Al Contratista, por concepto del Impuesto sobre la Renta, se le retendrá el 2% del producto bruto sobre los ingresos o beneficios de fuente costarricense, generados en el territorio nacional provenientes de los bienes o servicios contratados; superiores al salario base que se encuentre vigente. (Ley 7092 – Impuesto sobre la renta, art. 23 g.; Ley 7337 art. 2)

 

1. Equilibrio económico del contrato

 

• Con el propósito de mantener el equilibrio económico de los contratos de conformidad con lo dispuesto en el artículo 43 de la Ley 9986, Ley General de Contratación Pública, y los artículos 107, 108 y 109 de su Reglamento, Decreto Ejecutivo Nº 43808, para la definición de los criterios técnicos relacionados con las fórmulas matemáticas, componentes de cálculo, procedimientos, requisitos de información y demás parámetros indispensables para cuantificar el aumento o disminución de los precios, según se demuestre la variación de los costos directos e indirectos, se aplicará según lo dispuesto en el “Reglamento para el Reajuste Precios en los Contratos de Obra Pública y la Revisión de Precios en los Contratos de Bienes y Servicios” del 29 de enero de 2025, publicado en el Alcance No. 46 al Diario Oficial La Gaceta No. 64 del jueves 03 de abril de 2025, cuyo rige se estableció cuatro meses después de su publicación en el Diario Oficial La Gaceta; es decir, a partir del 04 de agosto de 2025. De acuerdo con el artículo 107 del RLGCP, bajo ningún supuesto, serán objeto de reajuste ni revisión la utilidad ni el rubro de imprevistos.

 

 

1. Cláusula penal y Multas.

Aplicará lo dispuesto en la Ley General de Contratación Pública (art. 46 y 47) y su Reglamento (art. 116 y 117), El cobro por estos conceptos no podrá exceder el 25% del precio del contrato. En “Anexo: Estudio para cálculo de Cláusula Penal y Multas” se detallan y constan las consideraciones que determinan el porcentaje definido.

• Cláusula penal: Procede por ejecución tardía de las obligaciones contractuales.
• Multa: Ejecución defectuosa del contrato, debidamente tipificada en este pliego de condiciones, así como en los casos que expresamente se indiquen.
• El monto de la sanción económica se considerará sobre el mayor valor de cada línea y no sobre la totalidad del contrato, siempre que el incumplimiento de una línea no afecte el resto de las obligaciones.
• El cobro de la cláusula penal o de las multas podrá hacerse con cargo a las retenciones del pago, que se hubieran practicado como medida cautelar y los saldos pendientes de pago. En caso de que ninguna de esas dos alternativas resulte viable, se podrá ejecutar la garantía de cumplimiento hasta por el monto respectivo.
• En caso de que el Contratista infrinja 3 o más veces cualesquiera de los incumplimientos que originen el cobro de la sanción, la Administración podrá resolver unilateralmente el contrato por motivo de incumplimiento imputable al Contratista. Si el incumplimiento reiterado de los hechos anteriormente señalados se presenta de manera continua o alterna, en un plazo de hasta tres meses, la Administración podrá cobrar los daños y perjuicios del caso y resolver el contrato sin responsabilidad.

 

1. Contrato:

Forman parte del contrato entre el Sistema de Emergencias 9-1-1 y el adjudicatario los siguientes documentos:

• Las disposiciones legales y reglamentarias que lo afectan.
• El pliego de condiciones de la Licitación
• La oferta y sus complementos
• El contrato electrónico emitido a través de SICOP.
• Convenio de Confidencialidad.

 

1. Otras condiciones
   • Todo oferente y todo contratista se debe ajustar a las “Condiciones y Declaraciones” establecidas para esta contratación en el Sistema de Compras SICOP.

 

• Esta Administración se reserva el derecho de verificar por cualquier medio, la información aportada. De comprobarse que se aportó información falsa o inexacta, se procederá a descalificar inmediatamente la oferta, sin perjuicio de accionar los mecanismos sancionatorios que establece la normativa vigente.

 

• Todo documento que se adjunte al expediente electrónico de la contratación debe ser registrado “No Confidencial”. Si un participante considera que la información aportada es de carácter confidencial, deberá aportar los motivos y el sustento jurídico. Caso contrario, la Administración, una vez realizada la apertura del proceso en apego a los principios de Publicidad y Transparencia, queda facultada para hacer público cualquier información o documento. (LGCP art.15 y su Reglamento art. 30)

Lo anterior, según se establece en LGCP (art. 19) y su Reglamento (art. 25 y 28), Ley de información no divulgada N°7975 art. N°2 y 4; y Reglamento para la Utilización del Sistema Electrónico de Compras Públicas Mercado en Línea SICOP, art. N°3, inciso N°15 del, el cual a la letra indica: …“15) Documento confidencial: Documento calificado, mediante acto razonado por la institución usuaria, de oficio o a solicitud de la parte interesada, como secreto comercial, industrial o económico” ...

 

• Condiciones laborales: Es deber ineludible cumplir estrictamente las obligaciones laborales y de seguridad social, así como asegurar el cumplimiento por parte de las empresas subcontratadas, teniéndose su inobservancia como causal de incumplimiento del contrato respectivo.
  • Póliza de Riesgos del Trabajo: Es obligación del adjudicatario contar con póliza del riesgo del trabajo, acorde con las labores contratadas. En cualquier momento podrá el Administrador de Contrato requerirla para su debida verificación, como condición imprescindible. La póliza deberá estar al día; su vencimiento se considerará incumplimiento contractual. La institución está facultada a solicitar la póliza en cualquier momento, donde claramente se demuestre que quienes brindan el servicio a la institución se encuentran debidamente incluidos y al día en dicha planilla o póliza
  • Seguridad ocupacional: El Adjudicatario está obligado a implementar las medidas pertinentes para garantizar la salud y la seguridad de la persona trabajadora en el lugar de trabajo y en las tareas que realiza. El adjudicatario deberá cumplir lo establecido en el Reglamento de General de Seguridad e Higiene en el Trabajo.
  • Queda entendido que esta contratación no originará relación de empleo entre la Administración y el Contratista, ni con su personal.

 

• La Administración queda facultada, si es del caso, en readjudicar a la segunda oferta conforme al orden de prelación según la calificación que hayan obtenido los restantes oferentes elegibles; siempre y cuando el oferente manifieste por escrito su aceptación en las mismas condiciones en que presentó su oferta.

 

• El adjudicatario de esta contratación no podrá vender, ceder o traspasar su contrato a otra persona o sociedad sin la aprobación previa de la Administración. De comprobarse que el adjudicatario ha incurrido en algunas de las anteriores acciones de este punto, se iniciará el proceso de la resolución del contrato y se hará efectiva la garantía de cumplimiento.

 

• El oferente debe indicar el número de teléfono y correo electrónico de la persona de contacto para la coordinación efectiva de la ejecución contractual.

 

• Marco Jurídico Supletorio

En todo lo no previsto de forma expresa en este pliego, la contratación se regirá por el siguiente orden normativo:

• Constitución Política de la República de Costa Rica.
• Ley General de Contratación Pública (Ley No. 9986) y su Reglamento.
• Disposiciones y circulares de la Dirección General de Contratación Pública y la Contraloría General de la República.
• Código de Comercio y demás legislación nacional vigente que resulte aplicable.