Servicio de diseño, desarrollo, migración, implementación, hospedaje, mantenimiento y soporte del sitio web institucional de la página web del Sistema de Emergencias 9-1-1.

1. Requisitos de admisibilidad
   • Del Oferente:
     • El oferente deberá demostrar su participación en al menos cinco (5) proyectos de desarrollo de sitios web a partir del año 2021, que hayan involucrado labores de diseño, desarrollo e implementación. La información que se aporte como referencia debe incluir la siguiente documentación:
     • Nombre de la empresa, nombre del contacto técnico de la empresa, número telefónico, correo electrónico y descripción del proyecto desarrollado.
     • La referencia comercial debe ser firmada por el personero responsable de verificar el cumplimiento de las obligaciones del contratista en el contrato referenciado.
     • Las empresas que se aporten como referencia deberán presentar documentos comerciales originales escaneados o en copia certificada escaneada y las mismas deberán cumplir con indicar los datos de la empresa o institución que la brinda, razón social, dirección y número telefónico. Indicar los datos de la persona que suscribe la referencia como nombre, número de identificación, número telefónico, correo electrónico y puesto que desempeña. La referencia debe presentarse en papelería oficial de la empresa o institución que corresponda. Brindar información sobre el tipo de proyecto implementado, indicando si el servicio fue recibido a satisfacción.

 

 

 

 

• Del Equipo de trabajo

Para la ejecución y desarrollo de esta contratación, así como para el mantenimiento de éste, el oferente deberá disponer de un equipo de trabajo conformado por los siguientes roles y perfiles mínimos

 

• Desarrollador WEB.  

• Debe tener gado académico mínimo de Bachiller en alguno de las carreras de Ingeniería Informática, Diseño Gráfico, Publicidad, Mercadeo o carrera a fin con un mínimo de tres años de experiencia laboral comprobable.
• Se debe de entregar copia de los títulos académicos que evidencien su formación profesional. 
• El profesional ofertado debe de contar con experiencia en el desarrollo de mínimo tres proyectos de desarrollo Sitios WEB en los últimos 5 años. Para los cual debe de indicar: nombre empresa, año de desarrollo, tiempo de ejecución, nombre contacto, teléfono, correo electrónico. 
• La empresa 9-1-1, se reserva el derecho de validar los datos, cualquier información equivocada o no accesible dará por nula el referente. 

 

• Líder del Proyecto.

• Debe tener gado académico mínimo de Licenciatura o Master en Administración de Proyectos o bien en alguna de las carreras de Ingeniería Informática, Diseño Gráfico, Publicidad, Mercadeo o carrera a fin, certificado PMP con un mínimo de dos años de experiencia laboral comprobable.   
• El profesional ofertado debe de contar con experiencia en proyectos de desarrollo de software con un mínimo tres proyectos de desarrollo Sitios WEB en los últimos 5 años. Para los cual debe de indicar: nombre empresa, año de desarrollo, tiempo de ejecución, nombre contacto, teléfono, correo electrónico. 
• Mínimo tres años comprobables en dirección de equipos de proyecto aplicando metodologías ágiles como SCRUM, XP, Lean, etc.
• La empresa 9-1-1, se reserva el derecho de validar los datos, cualquier información equivocada o no accesible dará por nula el referente. 

 

• Profesional en Aseguramiento de la Calidad del Software.

• Debe tener grado académico mínimo de Licenciatura Aseguramiento de la Calidad del Software o bien en alguna de las carreras de Ingeniería Informática, Ingeniería Industrial o carrera a fin, certificado ISO9001 con un mínimo de dos años de experiencia laboral comprobable en testing de software.
• Deseable certificado en ISO/IEC/IEEE 29119: procesos, documentación y técnicas de prueba, con un mínimo de dos años de experiencia laboral comprobable en dicho campo.
• Deseable certificado en ISO/IEC 25010 (SQuaRE): modelo de calidad del producto (usabilidad, rendimiento, seguridad, etc.) con un mínimo de dos años de experiencia laboral comprobable en dicho campo.  
• El profesional ofertado debe de contar con experiencia en proyectos de desarrollo de software con un mínimo tres proyectos de desarrollo Sitios WEB en los últimos 5 años. Para los cual debe de indicar: nombre empresa, año de desarrollo, tiempo de ejecución, nombre contacto, teléfono, correo electrónico. 
• La empresa 9-1-1, se reserva el derecho de validar los datos, cualquier información equivocada o no accesible dará por nula el referente. 

CAPITULO II CONDICIONES PARTICULARES

 

Partida	Línea	Descripción	Código SICOP
1	1	Servicio de diseño, desarrollo, migración, implementación, hospedaje, mantenimiento y soporte del sitio web institucional de la página web del Sistema de Emergencias 9-1-1.	8111210392056297

 

Fase	Descripción
I	Desarrollo e Implementación Inicial
II	Soporte, Mantenimiento y Mejoras

 

Actividades	Descripción
1	Contratación de diseño, desarrollo, migración, implementación, hospedaje del sitio web
2	Soporte y mantenimiento sitio web institucional (mensual)
3	Soporte y mantenimiento sitio web institucional (según demanda – fuera de jornada ordinaria)
4	Mejoras (horas anuales estimadas, según demanda)

 

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 pliego de condiciones.

 

Especificaciones Técnicas:

 

1. Objeto contractual

El objeto de la contratación es la provisión del servicio de diseño, desarrollo, migración, implementación, hospedaje, mantenimiento y soporte del sitio web institucional de El Sitio Web del Sistema de Emergencias 9-1-1.

 

1. Requisitos de admisibilidad
   • Del Oferente:
     • El oferente deberá demostrar su participación en al menos cinco (5) proyectos de desarrollo de sitios web a partir del año 2021, que hayan involucrado labores de diseño, desarrollo e implementación. La información que se aporte como referencia debe incluir la siguiente documentación:
     • Nombre de la empresa, nombre del contacto técnico de la empresa, número telefónico, correo electrónico y descripción del proyecto desarrollado.
     • La referencia comercial debe ser firmada por el personero responsable de verificar el cumplimiento de las obligaciones del contratista en el contrato referenciado.
     • Las empresas que se aporten como referencia deberán presentar documentos comerciales originales escaneados o en copia certificada escaneada y las mismas deberán cumplir con indicar los datos de la empresa o institución que la brinda, razón social, dirección y número telefónico. Indicar los datos de la persona que suscribe la referencia como nombre, número de identificación, número telefónico, correo electrónico y puesto que desempeña. La referencia debe presentarse en papelería oficial de la empresa o institución que corresponda. Brindar información sobre el tipo de proyecto implementado, indicando si el servicio fue recibido a satisfacción.

 

 

 

 

• Del Equipo de trabajo

Para la ejecución y desarrollo de esta contratación, así como para el mantenimiento de éste, el oferente deberá disponer de un equipo de trabajo conformado por los siguientes roles y perfiles mínimos

 

• Desarrollador WEB.  

• Debe tener gado académico mínimo de Bachiller en alguno de las carreras de Ingeniería Informática, Diseño Gráfico, Publicidad, Mercadeo o carrera a fin con un mínimo de tres años de experiencia laboral comprobable.
• Se debe de entregar copia de los títulos académicos que evidencien su formación profesional. 
• El profesional ofertado debe de contar con experiencia en el desarrollo de mínimo tres proyectos de desarrollo Sitios WEB en los últimos 5 años. Para los cual debe de indicar: nombre empresa, año de desarrollo, tiempo de ejecución, nombre contacto, teléfono, correo electrónico. 
• La empresa 9-1-1, se reserva el derecho de validar los datos, cualquier información equivocada o no accesible dará por nula el referente. 

 

• Líder del Proyecto.

• Debe tener gado académico mínimo de Licenciatura o Master en Administración de Proyectos o bien en alguna de las carreras de Ingeniería Informática, Diseño Gráfico, Publicidad, Mercadeo o carrera a fin, certificado PMP con un mínimo de dos años de experiencia laboral comprobable.   
• El profesional ofertado debe de contar con experiencia en proyectos de desarrollo de software con un mínimo tres proyectos de desarrollo Sitios WEB en los últimos 5 años. Para los cual debe de indicar: nombre empresa, año de desarrollo, tiempo de ejecución, nombre contacto, teléfono, correo electrónico. 
• Mínimo tres años comprobables en dirección de equipos de proyecto aplicando metodologías ágiles como SCRUM, XP, Lean, etc.
• La empresa 9-1-1, se reserva el derecho de validar los datos, cualquier información equivocada o no accesible dará por nula el referente. 

 

• Profesional en Aseguramiento de la Calidad del Software.

• Debe tener grado académico mínimo de Licenciatura Aseguramiento de la Calidad del Software o bien en alguna de las carreras de Ingeniería Informática, Ingeniería Industrial o carrera a fin, certificado ISO9001 con un mínimo de dos años de experiencia laboral comprobable en testing de software.
• Deseable certificado en ISO/IEC/IEEE 29119: procesos, documentación y técnicas de prueba, con un mínimo de dos años de experiencia laboral comprobable en dicho campo.
• Deseable certificado en ISO/IEC 25010 (SQuaRE): modelo de calidad del producto (usabilidad, rendimiento, seguridad, etc.) con un mínimo de dos años de experiencia laboral comprobable en dicho campo.  
• El profesional ofertado debe de contar con experiencia en proyectos de desarrollo de software con un mínimo tres proyectos de desarrollo Sitios WEB en los últimos 5 años. Para los cual debe de indicar: nombre empresa, año de desarrollo, tiempo de ejecución, nombre contacto, teléfono, correo electrónico. 
• La empresa 9-1-1, se reserva el derecho de validar los datos, cualquier información equivocada o no accesible dará por nula el referente. 

 

 

 

 

 

1. Alcance

El Sitio WEB o la solución debe incluir:

1. Brindar una infraestructura del sitio web de hospedaje.
2. Migración del sitio actual.
3. Implementación del nuevo sitio web.
4. CMS completo.
5. Integración de módulos funcionales.
6. Seguridad, respaldo y continuidad.
7. Soporte y mantenimiento.

 

1. Estado actual del sitio web
   • Está desarrollado en WordPress/PHP con base de datos MySQL.
   • El repositorio tiene un volumen de datos de 904 MB.
   • El sitio web se encuentra alojado en un data center contratado por el 9-1-1, por lo que la migración debe ser desde este.

 

1. Requerimientos generales de la solución
   • Arquitectura de la solución
     • El Sitio Web o solución debe implementar una arquitectura web desacoplada entre frontend, backend y base de datos.
     • El Sitio Web o solución debe estar basada en una arquitectura modular desacoplada que permita la incorporación, modificación o eliminación de funcionalidades sin afectar la operación de los demás módulos.
     • El Sitio Web deberá garantizar una disponibilidad mensual mínima del 99,99 %, las 24 horas del día, los 7 días de la semana (24x7).

 

Para efectos del cálculo de disponibilidad, no se contabilizarán como indisponibilidad los períodos correspondientes a mantenimientos programados previamente coordinados y autorizados por la Administración, ni aquellos eventos cuya causa sea atribuible directamente a infraestructura o servicios bajo responsabilidad de la institución o a situaciones de fuerza mayor debidamente acreditadas.

 

El contratista deberá disponer de mecanismos de monitoreo que permitan verificar y documentar el cumplimiento mensual del nivel de disponibilidad establecido.

 

La disponibilidad mensual se calculará mediante la siguiente fórmula:

 

Disponibilidad (%) = [(Tiempo total del período – tiempo de indisponibilidad imputable al contratista) / Tiempo total del período] × 100.

 

• El Sitio Web o solución debe poder hacer la implementación de nuevos requerimientos funcionales mediante configuración o desarrollo adicional sin la necesidad de un rediseño completo de El Sitio Web.
• El Sitio Web o solución debe utilizar tecnologías vigentes y con soporte activo del fabricante durante toda la vigencia contractual.
• El Sitio Web o solución debe garantizar la compatibilidad con actualizaciones de frameworks, CMS o librerías sin afectar la integridad del Sitio Web.

 

• Infraestructura y alojamiento
  • El Sitio Web o solución debe alojarse en un servidor virtual dedicado que permita escalabilidad y migración controlada.
  • Cualquier elemento asociado a licencias, componentes o servicios adicionales no deben generar un costo adicional o diferenciado en la oferta.
  • El Sitio Web o solución debe soportar un ancho de banda mínimo de 25 Mbps simétrico, escalable en eventos de alta demanda.
  • El contratista debe garantizar el acceso controlado a servidores para validaciones técnicas por parte del 9-1-1, como al servidor de pruebas con el objetivo de estar realizando validaciones de rendimiento del CPU, memoria, almacenamiento, actualizaciones, entre otras.
  • El acceso brindado por la empresa contratista será establecido con los mínimos privilegios para efectuar las validaciones necesarias en temas de rendimiento de equipos y temas similares.
  • El oferente debe proponer la arquitectura de infraestructura (hardware o virtualización) necesaria para garantizar el cumplimiento de los requerimientos de rendimiento, disponibilidad y seguridad definidos en este documento.
  • La infraestructura propuesta debe ser dimensionada para soportar la carga de usuarios concurrentes, sin degradación del servicio.
  • El oferente debe documentar claramente las especificaciones técnicas mínimas de infraestructura, incluyendo como mínimo:

1. CPU (núcleos y capacidad)
2. Memoria RAM
3. Almacenamiento (tipo, capacidad y rendimiento)
4. Ancho de banda
5. Esquema de alta disponibilidad (si aplica)
   • El oferente debe justificar técnicamente el dimensionamiento de la infraestructura propuesta, relacionándolo con los requerimientos de rendimiento establecidos.
   • La infraestructura implementada debe permitir escalabilidad vertical y horizontal sin interrupción del servicio.

 

• Migración
  • El contratista debe realizar la migración total de los contenidos desde www.911.go.cr al nuevo entorno en su 100%.
  • El proceso de migración debe garantizar la integridad de datos sin pérdida de información.

 

• Accesos y administración
  • El Sitio Web o solución debe permitir acceso al CMS mediante autenticación individual para cada usuario.
  • El Sitio Web o solución debe permitir como mínimo los roles: editor, aprobador y publicador.
  • El Sitio Web o solución debe registrar en bitácora todas las acciones administrativas durante al menos 24 meses.

 

1. Requerimientos funcionales
   • Gestión de contenidos (CMS)
     • El Sitio Web o solución debe implementar un Sistema de Gestión de Contenidos (CMS) accesible mediante un panel de administración web.
     • El CMS debe operar en idioma español como idioma base de administración, incluyendo menús, opciones, mensajes del sistema, etiquetas, validaciones, ayudas contextuales y demás elementos de la interfaz.
     • El sistema debe mantener una única lógica de navegación para todos los idiomas habilitados, de forma que las traducciones afecten únicamente los contenidos visibles al usuario final y no la estructura del flujo conversacional.
     • El acceso al CMS debe realizarse mediante autenticación individual, utilizando credenciales únicas (usuario y contraseña) para cada persona autorizada.
     • El Sitio Web o solución debe permitir crear, editar, eliminar y publicar contenido.
     • El Sitio Web o solución debe permitir programar publicaciones (fecha y hora). También debe tener la opción de eliminar publicaciones en una hora y fecha preestablecida automáticamente, es decir que existan publicaciones que expiran.
     • El Sitio Web o solución debe permitir versionamiento de contenido.
     • El Sitio Web o solución debe soportar al menos 15 usuarios ingresando simultáneamente.
     • El Sitio Web debe permitir gestionar archivos multimedia.
     • El Sitio Web debe permitir la gestión de usuarios y roles con diferentes niveles de permisos, incluyendo como mínimo:

1. Administrador
2. Editor
3. Publicador
   • El Sitio Web debe impedir el acceso no autorizado mediante validación de credenciales y control de sesión.
   • El Sitio Web debe permitir la revocación inmediata de accesos de usuarios autorizados.
   • El Sitio Web debe implementar un flujo de aprobación de contenidos previo a su publicación, el cual debe permitir controlar el estado de cada documento o contenido antes de ser visible en el sitio web público.
   • El Sitio Web debe manejar obligatoriamente los siguientes estados para cada documento o contenido gestionado dentro del CMS:
4. Pendiente
5. Aprobado
6. Rechazado
7. Publicado
   • El Sitio Web debe permitir el cambio de estado de un documento únicamente a usuarios con permisos definidos según su rol.
   • El Sitio Web debe impedir la publicación de documentos cuyo estado no sea “Aprobado”.
   • El Sitio Web debe enviar notificaciones automáticas por correo electrónico cuando ocurra alguno de los siguientes eventos:
8. Creación de contenido en estado “Pendiente”
9. Cambio de estado a “Aprobado”
10. Cambio de estado a “Rechazado”
11. Publicación de contenido
    • Cada notificación enviada por correo electrónico debe incluir como mínimo:
12. Identificación del documento o contenido
13. Nombre del usuario que realizó la acción
14. Fecha y hora del evento
15. Estado anterior y estado nuevo
16. Enlace directo al contenido en el CMS
    • El Sitio Web debe registrar en una bitácora todas las acciones realizadas por los usuarios del CMS por al menos 24 meses, incluyendo como mínimo:
17. Usuario
18. Fecha y hora
19. Acción realizada

 

• El Sitio Web debe permitir copiar, modificar o eliminar archivos e imágenes de forma sencilla y que se encuentren publicados en el sitio en los diferentes formatos (.doc, .docx, .xls, .xlsx, .ppt, .pptx, .pdf, .jpg, .gif y otros) con un tamaño máximo de 100 MB, para lo que, cada uno de los documentos deberán contar con un ícono que identifique el tipo de documento por su extensión.
  • El Sitio Web debe permitir publicaciones que sean vinculadas a nuevos sitios, archivos y páginas externas enfocados en el gestor de contenidos.

 

• El Sitio Web deberá permitir la creación y administración de páginas sin restricciones de cantidad impuestas por licenciamiento o por la solución tecnológica utilizada, sujeto únicamente a la capacidad de la infraestructura contratada y al cumplimiento de los niveles de rendimiento y disponibilidad establecidos en este documento.

 

Las páginas deberán poder editarse de forma fácil y ágil, permitiendo incorporar formato, estilos y elementos multimedia.

 

• El Sitio Web deberá permitir la creación y administración de galerías de imágenes sin restricciones de cantidad impuestas por licenciamiento o por la solución tecnológica utilizada, sujeto a la capacidad de la infraestructura contratada y al cumplimiento de los niveles de rendimiento establecidos.

 

Las galerías deberán permitir su presentación dinámica, incluyendo carruseles, generación de miniaturas, ampliación de imágenes y diferentes modalidades de visualización

 

• La URL del portal de pagos debe ser configurable desde el portal de administración.
• Chatbot CMS
  • El CMS debe ofrecer una vista gráfica y/o estructurada navegable que permita visualizar la relación entre nodos, rutas, bifurcaciones y nodos finales, así como identificar visualmente el nodo raíz, los nodos inactivos, los nodos huérfanos y las referencias rotas.
  • Debe contemplar los roles de Administrador, Editor y Agente, de acuerdo con lo que establezca la institución, sin perjuicio de que esta pueda definir roles adicionales según sus necesidades operativas.
  • El sistema debe proveer una interfaz de administración para la creación, edición y gestión de nodos conversacionales. Cada nodo debe incluir obligatoriamente, como mínimo, los siguientes atributos:

1. identificador único autogenerado por el sistema;
2. etiqueta de referencia interna para fines de administración y trazabilidad; y
3. contenido del mensaje a presentar al usuario final mediante un editor de texto enriquecido con soporte mínimo para formato en negrita, saltos de línea y emojis.
   • El sistema debe permitir que cada nodo contenga múltiples opciones de respuesta en formato de botones. Para cada botón, el administrador debe poder definir, como mínimo:
4. el texto que visualizará el usuario final; y
5. el nodo de destino asociado, seleccionado mediante un mecanismo de vinculación a un identificador único de nodo previamente existente en el flujo conversacional.
   • El administrador debe poder modificar desde el panel (sin programar ni requerir soporte técnico) los elementos estéticos del Widget: el color principal (mediante selector hexadecimal), el logotipo del encabezado, el nombre del asistente y el icono de la burbuja flotante.
   • El sistema debe permitir la incorporación de archivos adjuntos en los nodos conversacionales, para su visualización o descarga por parte del usuario final desde el widget de interacción. La solución debe soportar, como mínimo, archivos de imagen en formatos .jpg y .png, así como documentos en formato .pdf.
   • El sistema debe incorporar en el CMS una ventana o módulo de simulación que permita al administrador probar el flujo conversacional configurado, verificar su comportamiento y validar su navegación antes de su publicación definitiva en el ambiente de producción.
   • El sistema debe validar automáticamente, previo a la publicación, la integridad estructural del flujo, identificando al menos: referencias inválidas, rutas sin salida no intencionales, nodos inaccesibles desde el nodo raíz, ciclos no controlados y elementos desactivados que afecten la continuidad del flujo.
   • El CMS debe poder realizar la búsqueda, filtrado, duplicación, reordenamiento, activación y desactivación de nodos y opciones de respuesta, con el fin de facilitar la administración, mantenimiento y actualización de flujos conversacionales extensos.
   • El administrador debe poder configurar reglas de validación por campo, obligatoriedad, longitud, formato y mensajes de error personalizados para los nodos de captura.
   • El sistema debe poder definir distintos tipos de nodo dentro del flujo conversacional, incluyendo como mínimo: mensajes informativos, selección de opciones, captura de datos, transferencia a agente humano, cierre de conversación, encuesta de satisfacción y envío o presentación de archivos, enlaces o documentos.
   • El sistema debe poder facilitar al administrador definir, desde el CMS, el tiempo de expiración de la sesión conversacional y parametrizar el comportamiento del widget al vencerse dicho plazo, incluyendo al menos la finalización, reinicio o redirección controlada de la interacción, según la configuración establecida.
   • El sistema debe poder facilitar al administrador editar, desde el CMS y sin necesidad de programación, los mensajes predeterminados del sistema que se muestran al usuario durante la interacción conversacional, incluyendo, entre otros, mensajes como “Opción no válida”, “Gracias por contactarnos” y “Cargando...”.
   • El sistema debe registrar automáticamente un historial de acciones que detalle, como mínimo, qué usuario realizó la acción, en qué fecha y hora, qué tipo de cambio efectuó y sobre qué nodo, flujo o configuración se aplicó, para garantizar la trazabilidad ante errores o modificaciones no autorizadas.
   • El sistema debe poder administrar el versionamiento de los flujos conversacionales, incluyendo como mínimo la creación de borradores, publicación controlada, historial de versiones y restauración de versiones anteriores.
   • El CMS debe poder configurar encuestas de satisfacción asociadas al cierre de conversaciones automatizadas o atendidas por agentes humanos, permitiendo definir preguntas, tipos de respuesta, escalas de calificación, campos de comentario, obligatoriedad, mensajes de agradecimiento, condiciones de visualización y activación o desactivación de la encuesta sin necesidad de programación.

 

• Navegación y estructura del sitio
  • El sitio debe incluir un menú horizontal con estructura jerárquica configurable. Este debe permitir un crecimiento en las opciones que se desplieguen en forma vertical, incluyendo la creación de submenús. El menú debe contener al menos la siguiente estructura de información:

1. Quienes somos
   1. Estructura funcional
   2. Reseña histórica

• Ley de creación del 9-1-1.

1. Filosofía empresarial (misión, visión, objetivos)
2. Nombres y cargos de los funcionarios (incluyendo contratistas con su rol), junto con breve trayectoria

1. Cómo funciona el 9-1-1
2. Uso del 9-1-1
3. Preguntas frecuentes

• Accesibilidad de la información

1. App de Emergencias
2. Servicios
3. Certificaciones
4. Servicio de multas

• Atención al usuario

1. Datos estadísticos
2. Participación Ciudadana
3. Charlas Educativas
4. Transparencia
5. Bolsa de empleo
6. Contáctenos
7. Espacio para lista de correos y números telefónicos institucionales.
8. Formulario de consultas

• Identificación legal: nombre de la institución, dirección física, teléfono, correo electrónico
  • El Sitio Web debe implementar un componente de navegación tipo “Menú de rastros” (breadcrumbs) en todas las páginas de contenido.
  • El “Menú de rastros” debe mostrar la ruta jerárquica desde la página principal hasta la ubicación actual del usuario dentro del sitio.
  • La estructura del “Menú de rastros” debe seguir el formato: Portada > Sección > Sub-sección > Página actual
  • El “Menú de rastros” debe ubicarse debajo del encabezado de la sección o categoría y antes del título principal del contenido.
  • Cada elemento del “Menú de rastros”, excepto la página actual, debe ser un enlace navegable que permita regresar a niveles anteriores.
  • El sitio web debe incluir un menú con al menos:

1. Inicio
2. Mapa del sitio
3. Contacto
4. Ayuda
   • El sitio debe poder hacer enlaces a redes sociales y compartir contenido.
   • El sitio web debe poder hacer interacción con redes sociales (Facebook, X, Instagram, YouTube, entre otros).
   • El sitio web debe poder hacer que los usuarios publiquen contenido y que elijan si se comparte automáticamente en redes sociales o no este.
   • El sitio web debe contar con enlaces que dirijan al usuario a los perfiles sociales del Sistema de Emergencias 9-1-1.
   • Accesos directos en portada:
5. El Sitio Web debe poder configurar accesos directos en la página principal.
6. El Sitio Web debe mostrar como mínimo tres accesos directos a contenidos definidos por la institución.
   • Elementos de navegación persistentes
7. El Sitio Web debe incluir un botón de contacto para enviar un mensaje al encargado del sitio.
8. El Sitio Web debe poder hacer una llamada rápida al 9-1-1 en dispositivos móviles.
9. El Sitio Web debe incluir un módulo de chatbot para consultas no urgentes.
10. El Sitio Web debe hacer la incorporación de identidad visual institucional (logos, colores, tipografía).
11. El Sitio Web debe poder imprimir contenido en formato simplificado.
12. El Sitio Web debe incluir un pie de página persistente con:
13. Datos institucionales
14. Política de privacidad

• Información de contacto
  • Galerías multimedia

1. El Sitio Web debe poder hacer la creación de galerías de imágenes ilimitadas.
2. El Sitio Web debe generar automáticamente miniaturas (thumbnails).

• El Sitio Web debe poder hacer visualización ampliada de imágenes.

1. El Sitio Web debe permitir múltiples formatos de presentación de galerías.

 

• Formularios
  • Todos los formularios deben validar campos obligatorios antes del envío.
  • El Sitio Web debe validar formatos (correo, teléfono).
  • El Sitio Web debe poder adjuntar archivos (mínimo 10MB y máximo 100MB).
  • El Sitio Web debe implementar CAPTCHA visual y audible en todos los formularios.
  • Los formularios deben incorporar botones de enviar y limpiar.
  • El Sitio Web debe mostrar mensaje de confirmación en pantalla y enviar correo de confirmación en menos de 5 segundos tras el envío.
  • Debe registrar el envío en base de datos.
  • Debe existir un formulario para la clasificación del uso del sitio web, que registre información asociada a conocer la experiencia de uso del sitio web a los diferentes usuarios.
  • Se deberá contar con la facilidad de generar códigos QR que le permitan al usuario ingresar a los diferentes formularios.

 

 

• Búsqueda
  • El Sitio Web debe incluir motor de búsqueda visible en todas las secciones.
  • El Sitio Web debe mostrar resultados en menos de 3 segundos el 95% de las veces.
  • El Sitio Web debe mostrar resultados en forma de lista con enlaces.
  • Debe resaltar palabras clave buscadas.
  • Debe registrar búsquedas exitosas y fallidas.
  • Debe almacenar búsquedas realizadas para análisis estadístico.

 

• Avisos legales
  • El Sitio Web debe incorporar una sección de aviso legal accesible desde todas las páginas del sitio web.
  • El aviso legal debe contener como mínimo la siguiente información:

1. Identificación de la institución
2. Condiciones de uso del sitio web
3. Limitaciones de responsabilidad
4. Política de propiedad intelectual
5. Aviso de protección de datos personales (si aplica)
   • El contenido del aviso legal debe ser editable a través del CMS por personal autorizado.
   • El Sitio Web debe garantizar la persistencia del acceso al aviso legal mediante un enlace visible en el pie de página del sitio.

 

 

• Propiedad Intelectual y Plan de Salida:

El Contratista no puede utilizar, vender o implementar de manera parcial o total el código fuente propiedad del Sistema de Emergencias 9-1-1 del Sitio Web contratado, este código es exclusivo del Sistema de Emergencias 9-1-1. De comprobarse, se aplicarán todas las medidas legales correspondientes a dicha violación de derechos de autoría de CR.  

 

 

• Secciones principales
  • Se estructuran como módulos en la sección de servicios:
    • Certificaciones
      • Esta sección debe incorporar un enlace para que el usuario descargue un documento de guía de uso del servicio, el cual se encuentra en el Anexo 1 G-OP-001, Guía para la solicitud de certificaciones.
      • Debe permitir completar un formulario que incluya la siguiente información como campos obligatorios:

1. Número de identificación
2. Correo electrónico
3. Número telefónico del servicio sobre el cual desea la certificación
4. Dirección donde ocurrieron los hechos
5. Fecha y hora aproximada en que ocurrieron los hechos
6. Breve descripción de los hechos
7. Debe existir un espacio para seleccionar estas opciones:
8. Requiero el incidente.
9. Requiero las grabaciones.

• No requiero ninguna.
  • El formulario debe generar de forma automática un campo con la fecha de la solicitud.
  • Debe de existir un espacio para indicaciones al usuario sobre la entrega de incidentes y grabaciones.
  • El formulario debe permitir adjuntar archivos.
  • El formulario una vez completo debe generar una respuesta automática que muestre la fecha en que se estaría entregando aproximadamente la certificación, el cual debe tener un contador automático de 10 días hábiles a partir de la fecha generada en el 5.7.1.3. e indicar “No obstante la certificación podría llegar a su correo antes del tiempo estimado, por lo cual se le recomienda, revisar su bandeja de entrada frecuentemente.”

 

• Atención al usuario
  • Debe permitir completar un formulario para el registro de una queja con al menos la siguiente información:

1. Nombre completo (campo obligatorio)
2. Teléfono de contacto (campo obligatorio)
3. Teléfono de donde se originó la llamada
4. Fecha del evento
5. Hora aproximada del evento
6. Motivo de la queja (campo obligatorio)
7. Medio para notificaciones (campo obligatorio)

 

• Datos estadísticos
  • Esta sección debe hacer la visualización interactiva de datos estadísticos integrando dashboards interactivos (Power BI, Fabric, Tableau, o equivalente).
  • Se debe poder hacer la actualización automática desde los distintos orígenes de datos.
  • El usuario debe poder pueda interactuar con los datos estadísticos que se publiquen, como filtrar datos o cruzar variables.
  • Cada entrada debe mostrar: Título del reporte, Descripción breve, Fecha de publicación y un botón de descarga o acceso al archivo.
  • El Sitio Web debe poder hacer visualización previa de archivos antes de la descarga.
  • Se debe tener compatibilidad con Framework web (React, Angular o Blazor)
  • Se debe poder realizar la compatibilidad de contenedores de visualización embebidos mediante iframe seguro o API de integración nativa.

 

• Participación ciudadana
  • En esta sección deben existir las siguientes secciones:
    • Canales de opinión:

1. En esta sección se debe completar un formulario con las siguientes opciones:
2. Comentario
3. Sugerencia

• Consulta

1. Otro
2. El formulario debe generar los siguientes campos:
3. Datos de contacto (no obligatorios): Nombre, correo electrónico, número de teléfono.
4. Campo de texto libre con al menos 1.000 caracteres, campo obligatorio.
   • Consulta pública:
5. Debe poder hacer que se publique un tema o problemática en particular y las personas puedan dar su opinión o propuesta de solución.
6. A partir de lo que se publique, debe generar un formulario con los siguientes campos:
7. Datos de contacto (no obligatorios): Nombre, correo electrónico, número de teléfono.
8. Campo de texto libre con al menos 1.000 caracteres.
   • Se debe configurar para que, dependiendo de las opciones de cada sección, se envíe a un correo electrónico definido por la institución y debe incluir la información asociada a fecha y hora de envío.
   • Se requiere una opción que permita generar encuestas cortas, tipo pop-up, en donde los resultados sean acumulativos y que puedan ser consultados en la web y exportados a Excel, con un número de consecutivo, fecha y hora. Además, se envíe al correo electrónico que defina la Institución.
9. Debe poder programar las encuestas, para definir fecha, hora y sección de la página donde se requiere que aparezcan.

 

• Charlas Educativas
  • En esta sección se debe generar un formulario con los siguientes campos obligatorios:

1. Nombre de la persona, institución o centro educativo
2. Cédula
3. Teléfonos
4. Lugar para realizar la charla: Provincia (campo con lista desplegable pre cargada), Cantón (campo con lista desplegable pre cargada, tomando en consideración la provincia seleccionada), Distrito (campo con lista desplegable pre cargada, tomando en consideración el cantón seleccionado), Otras señas.

 

• Se estructuran además los siguientes módulos:
  • Transparencia
    • El Sitio Web debe implementar una sección única de transparencia para lo cual debe utilizar la estructura que se plantea en el Índice de Transparencia del Sector Público de la Defensoría de los Habitantes (Anexo 2 Metodología ITSP 2.0.DHR 2025) que tenga las siguientes secciones:

1. Información institucional: Evalúa información general que define y describe a la institución, así como la disponibilidad de herramientas para acceder a los contenidos y para conocer condiciones especiales referentes a la accesibilidad e inteligencia artificial.
2. Rendición de cuentas: Evalúa los diferentes documentos y datos que demuestran las actividades realizadas por la institución, contenidas en planes, informes u otros.
3. Participación y solicitudes de información: Evalúa los espacios que la ciudadanía dispone para participar en asuntos de interés del quehacer institucional, así como las condiciones para solicitar y recibir información pública, junto con la disponibilidad de estadísticas asociadas con estas solicitudes.
4. Presupuestos, puestos y contratación pública: Evalúa la disponibilidad de información y datos que visibilizan las principales formas de uso de recursos públicos.
   • Las secciones indicadas anteriormente deben contener todos los apartados definidos en la “Guía para la creación de sitios web transparentes” (Anexo 3 Guía para la creación de sitios web transparentes), puesto a disposición del CICAP-UCR para el uso abierto por parte de las instituciones del estado.
   • Estos datos deben cumplir especificaciones de calidad para realizar análisis profundos y para conectar datos de diferentes instituciones. Así como con los siguientes documentos normativos y regulatorios:
5. Ley 10240, Ley para promover la transparencia en el suministro de información en el sector público.
6. Ley 10554, Ley marco de acceso a la información pública.
7. Decreto Ejecutivo N° 40199-MP del 27 de abril de 2017 datos abiertos.
8. Guía Nacional para la publicación de datos abiertos.
   • La sección debe poder agregar un texto introductorio editable.
   • La sección debe poder hacer la modificación de la estructura sugerida, por cualquier cambio que surja en las normativas de referencia.
   • Toda la documentación que sea cargada o descargada debe permitir formatos no editables tipo PDF o similares, así como también en formatos tipo DOC, DOCX, XLS, XLSX, XML o similares.

 

• Bolsa de empleo
  • Se estructuran las siguientes secciones:
    • Plazas vacantes:

1. Debe solicitar al usuario
2. Debe poder generar un formulario que incluya la siguiente información como campos obligatorios:
3. Nombre
4. Cédula

• Teléfono

1. Lugar de residencia: Provincia (campo con lista desplegable pre cargada), Cantón (campo con lista desplegable pre cargada, tomando en consideración la provincia seleccionada), Distrito (campo con lista desplegable pre cargada, tomando en consideración el cantón seleccionado), Otras señas.
2. Estudios Universitarios (indicar los más recientes): Centro de estudios, título obtenido, año. Debe estar en formato tipo tabla.
3. Experiencia Laboral (últimos dos lugares donde ha laborado): Nombre de la empresa o institución, puesto ocupado, con las fechas respectivas de ingreso y finalización, indicar al menos tres funciones que realiza o realizaba. Debe estar en formato tipo tabla.
   • Reclutamiento y selección
4. El Sitio Web debe mostrar línea de tiempo con fechas específicas de cada proceso que contemple la siguiente información:
5. Recepción de documentos
6. Verificación de atestados

• Entrevista inicial

1. Aplicación de pruebas
2. Entrevista conductual
3. Selección del candidato

• Nombramiento en la plaza

 

• Chatbot
  • Diseño, desarrollo e implementación de una plataforma integral tipo Chatbot CMS para la creación, administración y mantenimiento de flujos conversacionales automatizados basados en lógica de árboles de decisión, con capacidad de derivación a chat atendido por agentes humanos cuando la institución así lo configure.
  • El Chatbot debe indicar que no se permite reportar emergencias por ese medio y que, en caso de que tenga una, se deberá remitir automáticamente a los canales establecidos por la institución.
  • El Chatbot debe poder traducir las preguntas o información solicitada por el usuario, teniendo traducción de manera automática de español a inglés o viceversa.
  • El sistema debe poder facilitar a la organización la administración autónoma del 100% de los contenidos, flujos de navegación y lógica de respuesta, de forma que, una vez concluido el contrato, la institución pueda operar, actualizar y mantener la solución con sus propios recursos, sin dependencia funcional obligatoria del proveedor.
  • El sistema debe estar compuesto obligatoriamente por tres interfaces o módulos independientes:

1. Panel de Administración o CMS, destinado a la gestión, configuración y mantenimiento de los árboles de decisión, contenidos, opciones de navegación y parámetros generales de la solución.
2. Widget de Interacción para el usuario final, integrado al sitio web institucional, mediante el cual las personas usuarias podrán interactuar con el chatbot y, cuando corresponda, ser derivadas a la atención de un agente humano.
3. Módulo de Atención para Agentes, destinado a la recepción, gestión y respuesta de conversaciones transferidas desde el chatbot, permitiendo la atención en tiempo real, consulta del historial de interacción, cierre de conversaciones y registro de trazabilidad.
   • El sistema no debe estar sujeto a pagos mensuales, anuales o cobros por volumen de uso (mensajes o usuarios) tras la firma del acta de recepción definitiva.
   • La comunicación en tiempo real requerida para el chat entre usuarios finales y agentes humanos debe implementarse mediante ASP.NET Core SignalR o tecnologías similares, integrado con la plataforma Microsoft .NET, o mediante un componente equivalente del mismo ecosistema previamente aprobado por la organización.
   • En el anexo 4 se detallan los flujos de información.
   • La plataforma debe incluir un Módulo de Atención para Agentes, destinado a la recepción, gestión, respuesta y cierre de conversaciones transferidas desde el chatbot hacia atención humana, para lo cual debe permitir lo siguiente:
     • Que una conversación iniciada en el Widget de Interacción pueda ser derivada a un agente humano, ya sea por selección del usuario final, por configuración de un nodo específico del flujo conversacional o por reglas definidas por la institución.
     • Configurar, desde el CMS, los nodos o condiciones bajo las cuales una conversación podrá ser transferida a atención por agente humano.
     • Visualizar una bandeja de conversaciones entrantes, pendientes, activas, finalizadas y, cuando aplique, conversaciones no atendidas.
     • Que los agentes autorizados puedan aceptar, tomar o recibir conversaciones asignadas, responder mensajes al usuario final y finalizar la atención cuando corresponda.
     • Consultar el historial de la conversación antes y durante la atención por agente, incluyendo las opciones seleccionadas por el usuario, mensajes intercambiados con el chatbot, datos capturados y motivo de transferencia, cuando dicha información exista.
     • Identificar claramente el estado de cada conversación, incluyendo como mínimo: en chatbot, pendiente de atención, en atención por agente, finalizada, abandonada o expirada.
     • Que el agente visualice la información básica capturada del usuario, tales como nombre, correo electrónico, teléfono u otros campos configurados por la institución, cuando estos hayan sido solicitados dentro del flujo conversacional.
     • Que el agente envíe mensajes de texto al usuario final desde una interfaz de conversación en tiempo real, manteniendo la continuidad de la interacción iniciada en el widget web.
     • Registrar la fecha y hora de inicio de la atención humana, agente que atendió la conversación, fecha y hora de cierre, duración de la atención y estado final de la conversación.
     • Que el agente finalice una conversación indicando, cuando la institución así lo configure, una categoría, motivo de cierre, observación o resultado de la atención.
     • Configurar horarios de atención para agentes humanos y definir el comportamiento del widget cuando la solicitud de atención se realice fuera del horario establecido, incluyendo al menos la presentación de un mensaje informativo, regreso al flujo automatizado o registro de solicitud pendiente.
     • Configurar mensajes automáticos asociados a la atención por agente, incluyendo como mínimo mensajes de espera, agente no disponible, conversación transferida, conversación finalizada y atención fuera de horario.
     • Gestionar la disponibilidad de los agentes, diferenciando como mínimo entre estados disponible, ocupado, ausente o desconectado.
     • Asignar conversaciones a agentes de forma manual o automática, según la configuración establecida por la institución.
     • Que un usuario con rol Administrador o Supervisor pueda visualizar el estado general de las conversaciones en atención, agentes conectados, conversaciones pendientes y conversaciones finalizadas.
     • Reasignación o transferencia de una conversación entre agentes autorizados, manteniendo el historial completo de la interacción y registrando la trazabilidad del cambio.
     • Trazabilidad de las acciones realizadas, incluyendo como mínimo aceptación de conversación, asignación, reasignación, envío de mensajes, cierre, cambios de estado y usuario responsable de cada acción.
     • Consulta y exportación de reportes relacionados con la atención por agentes, incluyendo como mínimo cantidad de conversaciones atendidas, conversaciones no atendidas, tiempos de espera, tiempos de atención, agente responsable, estado final y rango de fechas.
     • Garantizar que las conversaciones atendidas por agentes humanos queden almacenadas y disponibles para consulta histórica, auditoría, respaldo y exportación por parte de la institución.
     • Controlar el acceso de los agentes únicamente a las conversaciones que les hayan sido asignadas o que correspondan a su rol, grupo, área o permisos definidos por la institución.
     • Que la atención por agente humano opere sin requerir plataformas externas del proveedor, servicios de terceros obligatorios o pagos adicionales por cantidad de agentes, conversaciones, mensajes o usuarios atendidos, salvo que la institución expresamente autorice una integración adicional.
     • Finalizar una conversación indicando el resultado de la atención y, cuando la institución así lo configure, generar un resumen o constancia de la interacción, enviar dicho resumen al correo electrónico del usuario y activar una encuesta de satisfacción posterior al cierre.
     • Consultar y exportar los resultados de las encuestas de satisfacción de acuerdo con las preguntas, variables, campos y tipos de respuesta configurados por la institución desde el CMS. La consulta y exportación debe incluir, como mínimo, la fecha de respuesta, canal de atención, flujo asociado, conversación relacionada, agente responsable cuando aplique, estado final de la conversación, calificaciones, comentarios u otras respuestas registradas según la configuración de la encuesta, permitiendo filtrar la información por rango de fechas y demás criterios disponibles en la solución.
   • El Widget de Interacción (Usuario Final) debe cumplir con lo siguiente:
     • 100% responsive, adaptando automáticamente su tamaño y tipografía para una visualización óptima en dispositivos móviles (iOS/Android) y computadoras de escritorio.
     • Compatible con los navegadores y dispositivos definidos por la organización, incluyendo como mínimo Chrome, Edge, Firefox y Safari, así como con dispositivos móviles Android e iOS, y con los motores de navegación asociados a dichas plataformas, en sus versiones vigentes oficialmente soportadas al momento de la implementación.
     • Abrir enlaces y archivos adjuntos de forma segura, evitando comportamientos que afecten la navegación del usuario o la seguridad del sitio institucional.
     • Mostrar indicadores visibles de carga o procesamiento cuando una respuesta no pueda ser presentada de forma inmediata.
     • Poder hacer que el usuario reinicie la conversación de forma manual en cualquier momento, retornando al nodo inicial configurado y descartando el contexto conversacional activo para la nueva interacción, sin eliminar los registros históricos, trazabilidad o datos almacenados conforme a la configuración y políticas de conservación definidas por la organización.
     • Poder reflejar la configuración definida desde el CMS para el mensaje de bienvenida inicial, así como el comportamiento de apertura automática o manual del chat.
     • Cuando el flujo contemple captura de datos personales, el Widget debe mostrar los avisos informativos o mensajes de consentimiento que defina la organización antes de solicitar dicha información.
     • Mantener la continuidad de la conversación durante la vigencia de la sesión configurada por la organización. Para ello, el Widget podrá utilizar mecanismos de persistencia del navegador, tales como cookies o almacenamiento local, únicamente para conservar identificadores de sesión, preferencias o estado mínimo necesario, evitando almacenar innecesariamente datos personales, sensibles o contenido completo de la conversación en el navegador. El historial conversacional deberá mantenerse de forma segura en la solución cuando corresponda.
     • Durante la vigencia de la sesión configurada por la institución, el sistema debe conservar y restaurar el historial visible y el estado de la conversación cuando el usuario minimice, cierre o vuelva a abrir el Widget, incluyendo las opciones seleccionadas, los datos suministrados previamente y, cuando aplique, el estado de transferencia o atención por agente humano, sin reiniciar el flujo de manera automática.
     • Criterios de accesibilidad digital que permitan su uso por personas con discapacidad, incluyendo, como mínimo, navegación completa por teclado, compatibilidad con lectores de pantalla, contraste visual adecuado, estructura semántica correcta, etiquetas accesibles en botones, enlaces y campos de captura, y mecanismos que permitan identificar mensajes, errores, validaciones y cambios de estado mediante tecnologías asistivas.
     • Gestionar adecuadamente fallos de conexión o errores de servicio, mostrando mensajes comprensibles al usuario sin afectar el sitio institucional.
     • Mostrar indicadores visuales de escritura, procesamiento o espera, incluyendo animación entre mensajes del chatbot y, cuando aplique, indicadores asociados a la atención por agente humano, tales como “conectando con un agente”, “agente escribiendo” o “esperando respuesta”.
     • El script del Widget debe cargarse de manera asíncrona. En ninguna circunstancia la ejecución o la latencia del servidor del Chatbot debe bloquear el renderizado o la disponibilidad de los contenidos del sitio web principal de la organización.
     • Poder hacer que al usuario minimizar o cerrar la ventana de chat en cualquier momento. El sistema debe recordar el estado del Widget (si estaba abierto o cerrado) al navegar entre las diferentes secciones del sitio web para no interrumpir la experiencia de navegación del usuario.
     • Cuando el Widget se encuentre minimizado y se genere un nuevo mensaje automático del chatbot o una respuesta de un agente humano, el sistema debe mostrar un indicador visual, como globo de notificación, contador de mensajes o cambio en el icono, que alerte al usuario sobre la recepción de un nuevo mensaje sin necesidad de abrir la ventana de chat.
     • Poder hacer que el Widget renderice correctamente los contenidos enviados desde el CMS, incluyendo hipervínculos, emojis, imágenes y documentos PDF, de forma que el usuario pueda visualizarlos, previsualizarlos cuando corresponda, abrirlos en una nueva pestaña o descargarlos directamente desde la interfaz del chat.
     • En dispositivos móviles, el Widget debe adaptarse de forma que sus controles, botones, campos de entrada y contenidos sigan siendo legibles y utilizables sin superponerse indebidamente con otros elementos del sitio o del sistema operativo.
     • Mostrar al usuario los contenidos en el idioma configurado por la organización o seleccionado por el usuario, utilizando una única estructura de flujo conversacional y presentando la traducción correspondiente de textos, botones, mensajes del sistema, validaciones y avisos informativos.
     • Cuando el usuario seleccione un idioma, el Widget debe conservar dicha preferencia durante la vigencia de la sesión o conforme a la configuración definida por la organización.
     • Debe soportar correctamente caracteres especiales, tildes, eñes, símbolos, emojis y codificación estándar para todos los idiomas habilitados.
     • Cuando el flujo contemple captura de datos, el Widget debe presentar campos con etiquetas claras, instrucciones visibles, indicación de obligatoriedad y formato esperado, de forma comprensible para el usuario final.
     • Los campos de captura del Widget deben ser accesibles para tecnologías asistidas, incluyendo compatibilidad con lectores de pantalla, nombres accesibles coherentes con la etiqueta visible, orden lógico de foco y navegación completa por teclado.
     • Presentar campos de captura con tipos apropiados según el dato solicitado y conforme a la configuración definida desde el CMS, incluyendo al menos texto, correo electrónico y teléfono, favoreciendo la validación, accesibilidad y autocompletado cuando aplique.
     • La solución no debe almacenar innecesariamente datos personales o sensibles capturados en mecanismos de almacenamiento del navegador de persistencia prolongada; cuando sea indispensable conservar estado de sesión en el cliente, debe limitarse al mínimo necesario conforme a criterios de seguridad definidos por la organización.
     • Una vez completada la captura de datos o finalizada una etapa del flujo, el Widget debe mostrar al usuario una confirmación clara de recepción o registro, así como el mensaje de continuidad, transferencia a agente humano o cierre que corresponda según el flujo configurado.
     • Poder hacer que el usuario final solicite o acepte la derivación hacia atención por agente humano, cuando dicha opción se encuentre habilitada por la institución dentro del flujo conversacional.
     • Cuando una conversación sea transferida a atención por agente humano, el Widget debe informar claramente al usuario el cambio de modalidad, indicando que la interacción pasará de atención automatizada a atención humana.
     • Mostrar al usuario el estado de la atención por agente humano, incluyendo como mínimo estados tales como solicitud enviada, en espera de agente, agente asignado, agente escribiendo, conversación en atención, conversación finalizada o agente no disponible.
     • La comunicación en tiempo real entre el usuario final y el agente humano asignado, manteniendo la continuidad del historial de interacción iniciado con el chatbot.
     • Poder hacer que el usuario visualice, durante la atención por agente, los mensajes previos relevantes de la conversación, incluyendo las respuestas generadas por el chatbot, las opciones seleccionadas y los datos suministrados previamente, cuando corresponda.
     • Mostrar al usuario una identificación básica del agente humano asignado, según la configuración definida por la institución, pudiendo incluir nombre, alias institucional, área de atención o mensaje equivalente.
     • Cuando no existan agentes disponibles o la solicitud se realice fuera del horario de atención configurado, el Widget debe mostrar un mensaje claro al usuario y permitir, según la configuración institucional, continuar con el flujo automatizado, registrar una solicitud pendiente o finalizar la conversación.
     • Poder hacer que el usuario reciba un mensaje claro de cierre cuando el agente humano finalice la conversación desde el módulo correspondiente, incluyendo, cuando aplique, confirmación, resumen de la atención, número de gestión, indicación final o encuesta de satisfacción. La solución debe permitir, según la configuración definida por la institución, ofrecer al usuario la opción de recibir por correo electrónico una constancia o resumen de la conversación. Cuando el correo electrónico no haya sido capturado previamente, el Widget debe permitir solicitarlo de forma opcional al cierre de la interacción, validar su formato y requerir la confirmación del usuario antes del envío, conforme a las políticas de privacidad y conservación de información establecidas por los entes reguladores.
     • Gestionar adecuadamente interrupciones durante la atención por agente humano, tales como pérdida de conexión, recarga de página, cierre accidental del navegador o expiración de sesión, procurando conservar la continuidad de la conversación conforme a la configuración y políticas de seguridad definidas por la organización.
     • La solución debe garantizar que la transferencia hacia agente humano no exponga información interna del sistema, identificadores técnicos, errores de aplicación, datos de otros usuarios ni información no autorizada dentro del Widget de Interacción.

 

• Acceso a pagos en línea
  • El proveedor del sitio web institucional debe implementar un acceso visible, permanente y de fácil identificación denominado “Pagos en línea”, desde el cual se permita acceder al portal o a los portales de pago oficiales definidos por la institución. El acceso debe poder ubicarse en una o varias secciones del sitio web institucional, según lo defina la institución.
  • El alcance del sitio web institucional se limita a la publicación del acceso, la redirección segura hacia los portales de pago oficiales definidos por la institución, la configuración controlada de las URLs correspondientes y el cumplimiento de criterios generales de usabilidad, accesibilidad y compatibilidad.
  • La redirección hacia el portal de pagos debe realizarse mediante una URL segura definida y autorizada por la institución, bajo protocolo HTTPS y contar con un certificado digital válido y vigente al momento de su publicación, este debe ser cubierto por el proveedor de la solución.
  • El portal de pagos deberá publicarse mediante un dominio o subdominio institucional, por ejemplo: https://pagos.911.go.cr, o mediante la dirección oficial que la institución determine.
  • El sitio web institucional debe utilizar únicamente la URL oficial autorizada por la institución para el acceso al portal de pagos.
  • La actualización de la URL no debe requerir modificaciones estructurales al sitio web ni desarrollos complejos adicionales.
  • El sistema debe poder configurar un mensaje informativo previo a la redirección de pagos o un mensaje institucional en caso de que el portal financiero esté fuera de servicio.
  • El sitio web institucional no debe incrustar el portal de pagos mediante iframe, marcos embebidos o mecanismos similares, estos podrán permitirse si existe aprobación expresa de la institución.
  • El sitio web debe poder mostrar un mensaje informativo previo a la redirección, indicando al usuario que será dirigido al portal seguro de pagos definido por la institución.
  • El sitio web debe poder mostrar un mensaje institucional en caso de que el portal de pagos se encuentre temporalmente fuera de servicio.
  • El mensaje de indisponibilidad debe incluir canales alternativos de atención o pago cuando la institución así lo defina.
  • Cuando la institución lo requiera, el proveedor del sitio web deberá participar en sesiones de coordinación técnica con las unidades institucionales y otros proveedores involucrados, con el fin de validar los aspectos necesarios para la publicación, configuración e integración del acceso.

 

1. Requerimientos no funcionales
   • Lenguaje de desarrollo.
     • El Sitio Web debe ser desarrollado en el lenguaje de programación de Microsoft .Net Maui.

 

• Rendimiento
  • El Sitio Web debe cargar páginas en menos de 3 segundos en el 95% de las solicitudes.
  • Debe mantener disponibilidad mínima del 99.5%.
  • Debe soportar alta concurrencia sin degradación perceptible.

 

• Métricas
  • El CMS debe integrar un tablero de métricas que permita, como mínimo, consultar sesiones iniciadas, sesiones finalizadas, secciones más visitadas, frecuencia de selección por botón, rutas más recorridas, puntos de abandono y tasa de finalización por flujo o versión publicada
  • El tablero de métricas y los registros de interacción deben permitir identificar el idioma utilizado en cada sesión, cuando esta funcionalidad esté habilitada por la organización.
  • El tablero de métricas debe poder filtrar la información, como mínimo, por rango de fechas, flujo, versión publicada, idioma, canal de atención, estado de finalización de la sesión y tipo de atención brindada, ya sea automatizada o por agente humano.
  • El sistema debe poder exportar los reportes y métricas consultadas en formatos reutilizables, como mínimo Excel (.xlsx) y CSV UTF-8.
  • El tablero debe poder visualizar la evolución temporal de los principales indicadores, incluyendo sesiones iniciadas, sesiones finalizadas, tasa de abandono, tasa de finalización, transferencias a agente humano, conversaciones atendidas y conversaciones no atendidas, por día, semana y mes.
  • El sistema debe poder medir, como mínimo, la duración promedio de las sesiones, el tiempo de permanencia por nodo o por flujo, el tiempo de espera para atención por agente humano, el tiempo promedio de atención y la duración total de la conversación, cuando la arquitectura de la solución lo permita.
  • El sistema debe poder consultar métricas relacionadas con la transferencia hacia agentes humanos, incluyendo como mínimo cantidad de solicitudes de transferencia, transferencias exitosas, transferencias no atendidas, transferencias fuera de horario, abandonos durante la espera y conversaciones retornadas al flujo automatizado.
  • El sistema debe poder consultar métricas por agente, incluyendo como mínimo conversaciones asignadas, conversaciones atendidas, conversaciones finalizadas, tiempo promedio de respuesta, tiempo promedio de atención, estado final de las conversaciones y cantidad de reasignaciones realizadas.
  • El sistema debe poder consultar reportes de conversaciones, incluyendo como mínimo identificador técnico de sesión o conversación, fecha y hora de inicio, fecha y hora de finalización, flujo ejecutado, versión del flujo, idioma utilizado, estado final, agente responsable cuando aplique y resultado de la atención.
  • El sistema debe poder consultar y exportar los resultados de las encuestas de satisfacción de acuerdo con las preguntas, variables, campos y tipos de respuesta configurados por la institución desde el CMS, permitiendo filtrar la información por rango de fechas, flujo, canal de atención, agente responsable cuando aplique y estado final de la conversación.
  • El sistema debe poder generar reportes sobre puntos de abandono dentro del flujo conversacional, identificando el nodo, opción, idioma, fecha, versión del flujo y condición en la que se produjo el abandono, con el fin de apoyar la mejora continua del servicio.
  • El sistema debe poder consultar trazabilidad básica de una conversación específica, incluyendo nodos recorridos, opciones seleccionadas, datos capturados cuando corresponda, transferencia a agente humano, mensajes intercambiados, cierre de conversación, envío de resumen por correo cuando aplique y encuesta de satisfacción asociada
  • Los reportes y métricas deben respetar los perfiles, roles y permisos definidos por la organización, de forma que únicamente usuarios autorizados puedan consultar, exportar o visualizar información operativa, histórica, personal o sensible.
  • El sistema debe hacer que los reportes exportados incluyan los campos configurados por la institución, cuando corresponda, tales como variables capturadas en el flujo, campos de encuesta, estados personalizados, motivos de cierre o resultados de atención
  • El sistema debe poder conservar la información histórica necesaria para reportes, auditoría, análisis de uso y mejora continua, conforme a los plazos de retención, políticas de privacidad y criterios de seguridad definidos por la organización.

 

• Seguridad
  • Protección Perimetral y Seguridad de Aplicaciones Web:
    • El contratista deberá implementar mecanismos de protección perimetral y seguridad de aplicaciones web que permitan proteger la confidencialidad, integridad y disponibilidad de los servicios ofrecidos.
    • La solución deberá contemplar, como mínimo, las siguientes capacidades:

1. Protección de Aplicaciones Web: El Sitio Web deberá contar con mecanismos de protección de aplicaciones web tipo Web Application Firewall (WAF), administrado o autogestionado, para la detección, prevención y mitigación de amenazas comunes en aplicaciones y servicios web.
2. Protección del Tráfico Seguro: El Sitio Web deberá implementar mecanismos de protección para las comunicaciones seguras mediante HTTPS, el cual deberá ser asumido por el proveedor.
3. Protección contra Ataques de Denegación de Servicio: El Sitio Web deberá contar con capacidades razonables de mitigación ante ataques de denegación de servicio (DoS/DDoS), según la arquitectura y modalidad del servicio ofrecido.
4. Alta Disponibilidad, Redundancia y Continuidad Operativa: Cuando la arquitectura de la solución lo requiera en su 100%.
5. El Sitio Web debe disponer de mecanismos de continuidad operativa y disponibilidad del servicio.
6. Protección DNS: Cuando el servicio incluya componentes DNS administrados por el contratista, este deberá implementar medidas de protección contra amenazas comunes asociadas a servicios DNS.
7. Monitoreo y Detección de Amenazas: El Sitio Web deberá disponer de capacidades de monitoreo y detección de eventos de seguridad relevantes.
   • Gestión de Vulnerabilidades y Hardening
     • El contratista deberá implementar controles preventivos y correctivos orientados a reducir riesgos de seguridad sobre aplicaciones, plataformas, sistemas operativos y componentes asociados.
     • Gestión de Vulnerabilidades: El contratista deberá contar con procedimientos para la identificación, análisis y remediación de vulnerabilidades de seguridad. La Administración podrá solicitar evidencia documental del proceso aplicado.
     • Gestión de Configuraciones Seguras: El Sitio Web deberá implementar prácticas de configuración segura y hardening sobre los componentes administrados por el contratista.
     • Protección Antimalware: Cuando aplique según la arquitectura tecnológica ofertada, El Sitio Web deberá implementar mecanismos de protección contra software malicioso.
     • Seguridad en el Desarrollo y Aplicaciones: Cuando el oferente administre o desarrolle componentes de software asociados al servicio, deberá aplicar prácticas seguras de desarrollo y validación.
     • Control de Acceso y Autenticación: El Sitio Web deberá implementar mecanismos de autenticación y control de acceso acordes con el nivel de riesgo del servicio.
   • Cumplimiento de Buenas Prácticas y Estándares
     • El Sitio Web deberá alinearse con buenas prácticas internacionales de seguridad de la información y ciberseguridad aplicables al servicio ofrecido, tales como:

1. ISO/IEC 27001
2. ISO/IEC 27002
3. OWASP
4. CIS Controls
5. NIST Cybersecurity Framework
6. Estándares de seguridad aplicables a servicios en la nube, cuando corresponda.
   • El sitio web debe implementar controles contra inyección SQL, Cross-Site Scripting (XSS) y Cross-Site Request Forgery (CSRF).
   • El sitio web institucional no debe capturar, procesar, validar, almacenar ni transmitir información relacionada con medios de pago o datos financieros sensibles.
   • El sitio web institucional no debe desarrollar formularios propios para ingreso de datos de pago, salvo solicitud expresa y formal de la institución.
   • El sitio web no debe implementar mecanismos de redirección dinámica mediante parámetros manipulables por el usuario, tales como: “?url= “, “?redirect=”, “?returnUrl=”, “?next=”, Otros similares.
   • En caso de requerirse redirección parametrizada, esta debe validar el destino contra una lista de URLs autorizadas por la institución.
   • El acceso al portal de pagos no debe depender de ventanas emergentes bloqueables por el navegador, salvo aprobación expresa de la institución.
   • El sitio web debe permitir redirigir únicamente hacia dominios previamente autorizados.
   • No se deben utilizar enlaces temporales, dominios no validados o URLs no aprobadas por la institución.
   • El CMS debe incluir controles de seguridad para la administración de usuarios, tales como políticas de contraseña, bloqueo temporal por intentos fallidos, expiración de sesión por inactividad y activación o desactivación de cuentas.
   • El sistema debe aplicar controles seguros de gestión de sesión, incluyendo expiración por inactividad, cierre de sesión explícito, invalidación segura de sesiones, protección contra reutilización de sesión y manejo seguro de identificadores de sesión.
   • El sitio web debe mantenerse actualizada y libre de componentes vulnerables, obsoletos o descontinuados, incluyendo bibliotecas, dependencias de terceros, frameworks, motores de base de datos, componentes del lado cliente y mecanismos de actualización.

 

• Accesibilidad
  • El Sitio Web debe cumplir WCAG 2.1 nivel AA.
  • Los componentes del chatbot (CMS, Widget y Módulo de Agentes) deben alinearse con WCAG 2.2 nivel AA o equivalente.
  • Debe permitir navegación por teclado y lectores de pantalla.
  • El Sitio Web debe cumplir con la siguiente normativa:
    1. Ley N°7600 de Igualdad de Oportunidades para las Personas con Discapacidad.
    2. Ley N°8642 Ley General de Telecomunicaciones
    3. Directriz N°051-MTSS-MICITT Implementación de Sitios Web Accesibles en el Sector Costarricense.
    4. Ley 8661, Convención sobre los Derechos de las Persona con Discapacidad.
    5. El Sitio Web debe cumplir con los lineamientos del World Wide Web Consortium (W3C).
  • El sitio web institucional debe actuar únicamente como punto de acceso y redireccionamiento hacia el portal o los portales de pago oficiales definidos por la institución.

 

• Compatibilidad
  • El sitio web debe funcionar en un ambiente WEB compatible con todos los navegadores disponibles en el mercado, tanto para computadoras (Google, Microsoft Edge, Brave, Chrome Safari, Mozilla Firefox, Nightly, entre otros), teléfonos móviles, tablets y otros dispositivos que permitan al usuario el acceso a internet.

 

• Control de Excepciones y errores en el sitio
  • Ante el acceso de usuarios a páginas no existentes en el contenido del sitio web, el contratista debe proporcionar el control y manejo de estos accesos, mediante una ventana en la cual se le indique al usuario la situación.
  • Para las situaciones indicadas en el punto anterior, se debe contar con una página de error estándar, que incorpore al menos los siguientes elementos:
    1. Logotipo del Sistema de Emergencias 9-1-1
    2. Sistema de navegación en el sitio: menú, botones, entre otros.
    3. Título que explique el sentido de la página.
    4. Un párrafo describiendo el error en lenguaje no técnico (no más de dos líneas).
  • Entre los errores más frecuentes y que deben ser atendidos están:
    1. Error 401: Acceso no autorizado a una página, no se ingresó la contraseña.
    2. Error 403: Acceso prohibido; normalmente aparece cuando la página que se busca no tiene permiso para ser mostrada.
    3. Error 404: La página no existe y no puede ser mostrada.
    4. Error 500: Error en el servidor debido a un problema de software.
    5. Error 503: El servicio web no está disponible.
    6. Error 504: Tiempo de respuesta excede lo normal y por lo tanto la página no se muestra.
  • El contratista debe garantizar el control sobre enlaces (vínculo) rotos, para lo cual, debe realizar la respectiva verificación de estos. Se debe mostrar al usuario la página de error estándar solicitada anteriormente y almacenar el error presentado.
  • Todos los eventos que se registren correspondientes a excepciones o errores en la navegación del sitio Web, deben ser almacenados con la siguiente información.
    1. Fecha y hora
    2. Identificación del error o excepción
    3. Descripción del error o excepción
    4. Dirección IP
  • Todos los eventos deben ser registrados en una base gestionada por el sitio web.
  • El sitio debe indicar en los mensajes de error, opciones que ayuden al usuario a encontrar la información, debe traer el vínculo correspondiente y el contenido del mensaje no deberá revelar ninguna información del sistema. Por ejemplo, indicar al usuario que utilice el buscador del sitio, o ingrese al mapa del sitio o bien que ingrese a la página de "contáctenos" del sitio o por medio de redes sociales.

 

• Entorno de pruebas
  • El contratista debe implementar un entorno de pruebas independiente del entorno de producción, destinado exclusivamente a la validación funcional, técnica y operativa del sistema.
  • El entorno de pruebas debe constituir una réplica funcional del entorno de producción, incluyendo como mínimo:
    1. Misma versión del sistema operativo
    2. Misma versión del CMS
    3. Misma versión de frameworks y librerías
    4. Misma configuración de base de datos
    5. Misma configuración de servidor web
    6. Misma arquitectura lógica del sistema
  • El entorno de pruebas debe poder realizar la reproducción controlada de errores reportados en producción, de forma que puedan ser analizados, diagnosticados y corregidos sin afectar la operación del sitio en producción.
  • El entorno de pruebas debe poder hacer la ejecución de procesos de migración (contenidos, base de datos y configuraciones), validando previamente su correcto funcionamiento antes de su despliegue en producción.
  • El entorno de pruebas debe poder hacer la ejecución de pruebas de regresión, garantizando que los cambios implementados no introduzcan errores en funcionalidades existentes.
  • El entorno de pruebas debe poder hacer la ejecución de escaneos de vulnerabilidades sobre la aplicación web y sus componentes.
  • El entorno de pruebas debe poder realizar la validación de configuraciones de seguridad, incluyendo:
    1. Configuración del servidor web
    2. Configuración de certificados SSL/TLS
    3. Configuración de encabezados de seguridad
    4. Políticas de autenticación
  • El entorno de pruebas debe poder hacer la ejecución de pruebas de recuperación ante desastres, incluyendo:
    1. Restauración de respaldos
    2. Recuperación de base de datos
    3. Restauración de archivos del sistema
  • El sistema debe poder medir y validar los tiempos de recuperación (RTO) y pérdida de datos aceptable (RPO), conforme a los objetivos que defina la institución.
  • El entorno de pruebas debe estar completamente aislado del entorno de producción, lo que implica que no debe compartir:
    1. Redes
    2. Recursos de procesamiento (CPU)
    3. Memoria
    4. Almacenamiento
    5. Volúmenes
    6. Servicios activos
  • El entorno de pruebas no debe afectar el rendimiento, disponibilidad o seguridad del entorno de producción en ningún escenario operativo.
  • El entorno de pruebas debe tener acceso restringido únicamente a usuarios autorizados por la institución.
  • El sistema debe registrar en bitácora todas las acciones realizadas en el entorno de pruebas, incluyendo:
    1. Usuario
    2. Fecha y hora
    3. Acción realizada
    4. Recurso afectado
  • El entorno de pruebas debe garantizar la protección de la información sensible, evitando el uso de datos reales cuando no sea estrictamente necesario, o aplicando enmascaramiento cuando corresponda.
  • Todo cambio, mejora, actualización o corrección debe ser validado previamente en el entorno de pruebas antes de su despliegue en producción.
  • No se debe permitir la implementación directa de cambios en producción sin haber sido probados previamente en el entorno de pruebas.
• Antes de publicar el acceso en el sitio web institucional, el proveedor del sitio web debe validar que la URL autorizada abra correctamente y no presente advertencias de seguridad del navegador.
• La URL de pruebas debe poder validar: Redirección, Visualización, Navegación, Compatibilidad, funcionamiento general del acceso hacia el portal de pagos.
• La URL de producción debe ser distinta de la URL de pruebas.
• La URL de producción debe ser aprobada formalmente por la institución antes de su publicación en el sitio web institucional.
• El CMS debe validar automáticamente la integridad estructural del flujo (nodos huérfanos o rutas sin salida) previo a su publicación.
• El proveedor debe entregar evidencia de pruebas que incluyan capturas de pantalla, navegadores y dispositivos utilizados para validar el acceso y la operatividad.

 

• Auditoría y registros
  • El Sitio Web debe registrar logs de acceso, cambios y eventos de seguridad.
  • Los registros deberán conservarse por un período mínimo de 6 meses o el plazo superior que establezca la normativa institucional aplicable.
  • Debe permitir auditorías periódicas de seguridad.
  • El Sitio Web deberá generar registros de eventos relevantes asociados a:
    1. Accesos y autenticaciones.
    2. Actividades administrativas.
    3. Eventos de seguridad.
    4. Fallos relevantes del sistema.
    5. Acciones privilegiadas.
    6. Accesos de usuarios.
    7. Cambios en archivos y configuraciones.
    8. Eventos de seguridad.
    9. Eventos de interacción del chatbot (nodos recorridos, nodos más visitados, transferencias a agentes, abandonos, tiempos promedio de atención humana).
    10. Cambios en la configuración de las URLs de pagos en línea, incluyendo: usuario que realizó el cambio, fecha y hora, valor anterior, nuevo valor configurado.
    11. Clics en el botón de "Pagos en línea".
    12. Acciones ejecutadas en el Módulo de Atención para Agentes, incluyendo como mínimo, el usuario responsable de la acción, fecha y hora de ejecución, tipo de acción realizada, módulo utilizado, elemento afectado y detalle del cambio efectuado.
  • La bitácora debe registrar los errores funcionales o técnicos ocurridos durante la interacción, así como la apertura de enlaces, descarga de archivos o eventos equivalentes cuando sean relevantes para la trazabilidad operativa.
  • Los registros deben mantenerse protegidos contra alteraciones, eliminaciones o accesos no autorizados.
  • La Administración puede solicitar revisiones, validaciones o auditorías relacionadas con los controles de seguridad implementados sobre la solución contratada.
  • El contratista debe suministrar, cuando sea requerido por la Administración, información y evidencias relacionadas con los controles de seguridad implementados sobre la solución contratada.

 

• Supervisión, monitoreo y alertas del servicio
  • El Sitio Web debe contar con monitoreo continuo de disponibilidad (24/7).
  • El Sitio Web debe validar el estado del sitio desde múltiples ubicaciones geográficas.
  • El Sitio Web debe generar alertas automáticas cuando la disponibilidad sea inferior al 40%.
  • El Sitio Web debe tener un monitoreo que debe ejecutarse con una frecuencia máxima de 1 minuto.
  • El Sitio Web debe registrar datos históricos de disponibilidad por al menos 12 meses.
  • El Sitio Web como solución debe incluir herramientas de monitoreo de rendimiento de aplicaciones (APM) y debe medir como mínimo:
    1. Tiempo de carga de página (frontend)
    2. Tiempo de respuesta del servidor (backend)
    3. Tiempo de consultas a base de datos
    4. Uso de CPU, memoria y almacenamiento
  • El Sitio Web debe poder identificar cuellos de botella y degradaciones del servicio y generar alertas.
  • El Sitio Web debe poder generar métricas alineadas con el requerimiento de carga de datos de 3 segundos en el 95% de los casos.
  • El Sitio Web debe capturar métricas reales de navegación del usuario final.
  • El Sitio Web debe poder visualizar:
    1. Tiempo de carga por tipo de dispositivo
    2. Ubicación geográfica de usuarios
    3. Errores en navegación (ej. fallos JavaScript)
  • El Sitio Web debe poder análisis de comportamiento para mejora continua del sitio.
  • El Sitio Web como solución debe poder centralizar los logs de:
    1. Servidor web
    2. Aplicación (CMS)
    3. Base de datos
    4. Seguridad
  • El Sitio Web debe poder realizar:
    1. Búsqueda y análisis de logs
    2. Correlación de eventos
    3. Detección de anomalías
  • Los logs de El Sitio Web deben integrarse con el esquema de auditoría ya definido en el documento.
  • El Sitio Web debe monitorear eventos de seguridad en tiempo real:
    1. Intentos de acceso no autorizados
    2. Ataques (DDoS, XSS, SQL Injection)
    3. Cambios sospechosos en archivos o configuraciones
  • El Sitio Web debe integrarse con el WAF definido en la sección de seguridad.
  • El Sitio Web debe generar alertas críticas ante incidentes de ciberseguridad.
  • El Sitio Web debe monitorear eventos de seguridad en tiempo real:
    1. Intentos de acceso no autorizados
    2. Ataques (DDoS, XSS, SQL Injection)
    3. Cambios sospechosos en archivos o configuraciones
  • El Sitio Web debe integrarse con el WAF definido en la sección de seguridad.
  • El Sitio Web debe generar alertas críticas ante incidentes de ciberseguridad.
  • El Sitio Web debe generar alertas automáticas ante:
    1. Caídas del servicio
    2. Degradación de rendimiento
    3. Incidentes de seguridad
    4. Fallos en integraciones
  • El Sitio Web debe generar alertas y enviarse mediante:
    1. Correo electrónico
    2. SMS o mensajería (opcional)
    3. Integraciones con herramientas como Teams, Slack o similares
  • El Sitio Web debe poder permitir configuración de niveles de severidad:
    1. Informativo
    2. Advertencia
    3. Crítico
  • El Sitio Web debe incluir paneles de monitoreo en tiempo real.
  • El Sitio Web debe poder visualizar:
    1. Disponibilidad
    2. Rendimiento
    3. Tráfico
    4. Incidentes
  • El Sitio Web debe generar debe poder hacer exportación de reportes a Excel u otros.
  • El Sitio Web debe poder realizar la integración con herramientas como Power BI.
  • El Sitio Web debe poder ejecutar pruebas automatizadas simulando comportamiento de usuarios:
    1. Navegación en páginas críticas
    2. Envío de formularios
    3. Acceso a servicios clave
  • El Sitio Web debe poder ejecutarse periódicamente para validar su disponibilidad funcional.

 

• Respaldos y continuidad
  • El Sitio Web debe generar respaldos automáticos diarios.
  • Debe mantener histórico mínimo de 90 días.
  • Debe poder recuperación completa de El Sitio Web.
  • El 100% de la información capturada, registros de conversación, estructuras de los árboles de decisión, configuraciones y demás datos generados o administrados por la solución serán propiedad exclusiva de la institución, la cual debe tener acceso completo a su consulta, respaldo, exportación y administración aun después de finalizado el contrato.
  • El sistema debe contar con mecanismos de auditoría y trazabilidad sobre las acciones ejecutadas en el Panel de Administración y en el Módulo de Atención para Agentes.

 

• Soporte y mantenimiento
  • El oferente debe indicar cual es el mantenimiento regular incluido en la administración del sitio a partir de la aceptación del producto.
  • El contratista debe responder incidentes en máximo 2 horas.
  • El contratista debe mantener la solución actualizada y libre de componentes vulnerables, obsoletos o descontinuados, incluyendo bibliotecas, dependencias de terceros, frameworks, motores de base de datos, componentes del lado cliente y mecanismos de actualización. Esto no deberá representar ningún costo adicional.
  • Debe entregar informe técnico por cada incidente resuelto.
  • El servicio debe incluir mantenimiento por 12 meses prorrogable hasta por 1 periodo igual.

 

• Mejoras bajo demanda
  • El oferente debe poder presentar el costo por hora del requerimiento y la disponibilidad para las mejoras o nuevas versiones del Sitio Web cuando se le solicite. (Para la presente actividad contractual se estima una cantidad de 200 horas anuales. Además, se aclara que dicha cantidad es un estimado y que la institución cancelará únicamente las horas efectivamente ejecutadas y recibidas a satisfacción, sin obligación de agotar la totalidad del presupuesto.)
  • El oferente debe tener original y copia de los permisos y accesos necesarios para ejecutas las mejoras solicitadas para El Sitio Web.

 

• Gestión de incidentes y SLA
  • Ante la ocurrencia de un evento que afecte la funcionalidad normal de la página y sus componentes de software incluidos en esta contratación, el personal técnico de la Institución realizará una revisión general de la situación. Si se determina que la afectación se debe a un fallo en la página o sus componentes de software, se generará una notificación al contratista con el reporte del evento detectado a los medios de contacto establecidos.
  • El personal técnico del contratista debe dedicarse de inmediato a la atención del incidente, con la finalidad de diagnosticar el problema y a las acciones para solucionar lo reportado.
  • El contratista debe brindar el servicio de soporte técnico en horario hábil de lunes a jueves de 07:00 am a 05:00 pm y viernes de 7:00 am a 3:00 pm; ejecutando las acciones necesarias y realizar un seguimiento del problema hasta su solución.

 

El contratista deberá brindar el servicio ordinario de soporte técnico en horario hábil, de lunes a jueves de 7:00 a. m. a 5:00 p. m. y los viernes de 7:00 a. m. a 3:00 p. m.

 

Sin perjuicio de lo anterior, los incidentes que provoquen la indisponibilidad total del sitio web institucional o comprometan de forma grave su seguridad, y aquellos casos en los que la Administración estime necesarios, deberán ser atendidos bajo un esquema de disponibilidad fuera de la jornada ordinaria señalada anteriormente.

 

Para los incidentes citados en el párrafo anterior, los tiempos máximos de respuesta y restablecimiento establecidos comenzarán a contabilizarse a partir de la notificación realizada al contratista mediante los canales oficialmente establecidos.

 

Para los incidentes que se deban atender en horario ordinario, los tiempos de atención se contabilizarán únicamente dentro del horario hábil definido contractualmente

 

• El contratista debe responder incidentes en máximo 2 horas a partir de la notificación o identificación de este e informar el tiempo de solución.
• El contratista debe poner a disposición del 9-1-1 una dirección de correo electrónico, número telefónico local o una mesa de servicio, para la atención de los reportes de averías.
• El Sitio Web debe restablecer servicios críticos en máximo 8 horas.
• Debe entregar informe técnico detallado una vez solucionado el incidente, en máximo 3 días hábiles.

 

 

• Transferencia del conocimiento
  • El contratista debe llevar a cabo una transferencia de conocimiento para las personas funcionarias de la Unidad de Tecnologías de Información que defina la Administración, sobre las nuevas funcionalidades por incorporar en El Sitio Web.
  • El contratista debe elaborar y ejecutar un plan de capacitación y transferencia de conocimiento dirigido al personal que defina la organización, con el propósito de garantizar la correcta administración, operación, supervisión, mantenimiento y continuidad del sitio web institucional y de todos sus componentes y servicios asociados.
  • El plan de capacitación debe ser presentado para revisión y aprobación de la organización antes de su ejecución e incluir, como mínimo, objetivos, contenidos, perfiles participantes, modalidad, metodología, duración, cronograma, recursos requeridos y mecanismos de evaluación.
  • Las actividades de capacitación deben realizarse durante la implementación y antes de la puesta en producción de la solución. Cuando se incorporen cambios relevantes, nuevos módulos, actualizaciones o ampliaciones durante la vigencia del contrato, el contratista debe impartir las capacitaciones complementarias correspondientes.
  • La capacitación debe contemplar sesiones teóricas y prácticas, ejercicios guiados, demostraciones sobre la solución implementada y actividades que permitan a los participantes ejecutar directamente las funciones correspondientes a su perfil.
  • El contratista debe impartir capacitación funcional para el personal administrador y editor, incluyendo como mínimo:

1. Administración de contenidos del sitio web institucional.
2. Creación, edición y publicación de contenidos.
3. Administración de nodos y flujos conversacionales.
4. Configuración del Widget de Interacción.
5. Configuración de idiomas, mensajes y archivos.
6. Administración de encuestas de satisfacción.
7. Gestión de usuarios, roles y permisos.
8. Uso del simulador y validación de flujos.
9. Consulta y exportación de reportes y métricas.
10. Consulta de bitácoras y trazabilidad.

 

 

• El contratista debe impartir capacitación operativa al personal que la Administración defina (como máximo 07 funcionarios), incluyendo como mínimo:

1. Ingreso y uso del Módulo de Atención para Agentes;
2. Gestión de disponibilidad;
3. Recepción, aceptación y asignación de conversaciones;
4. Transferencia y reasignación de conversaciones;
5. Consulta del historial conversacional;
6. Atención en tiempo real;
7. Registro de resultados, categorías y motivos de cierre;
8. Cierre de conversaciones;
9. Activación de encuestas y envío opcional de constancias o resúmenes; y
10. Consulta de métricas operativas.
    • El contratista debe impartir capacitación técnica al personal designado por la organización (como máximo 04 funcionarios), incluyendo como mínimo:
11. Arquitectura general de la solución.
12. Infraestructura, servidores, servicios y componentes instalados.
13. Administración, configuración, operación y mantenimiento técnico del sitio web institucional y de los componentes desarrollados mediante los productos o tecnologías empleadas, incluyendo el sistema de gestión de contenidos, servicios internos, API, integraciones, módulos asociados, archivos de configuración y parámetros de funcionamiento.
14. Estructura general de la base de datos (si aplica) utilizada por el sitio web institucional y sus servicios asociados, incluyendo esquemas, tablas, relaciones, vistas, procedimientos almacenados, funciones, índices, bitácoras, configuraciones y demás objetos relevantes para su administración, respaldo, restauración y mantenimiento.
15. Configuración de ambientes de desarrollo, pruebas y producción.
16. Estructura, organización y ubicación del código fuente del sitio web institucional y de sus componentes asociados, incluyendo la identificación de cada proyecto, solución, módulo, carpeta, servicio, API, integración, archivo de configuración, dependencia, scripts utilizados y demás elementos que conforman la solución.
    • La transferencia de conocimiento debe permitir identificar claramente dónde se encuentra cada componente, cuál es su función, cómo se relaciona con los demás elementos, qué dependencias utiliza, cómo se configura y qué procedimiento debe seguirse para su compilación, publicación, despliegue, actualización y mantenimiento.
17. Procedimientos de compilación, publicación y despliegue.
18. Configuración de integraciones, API y servicios.
19. Administración de certificados, configuraciones y secretos.
20. Monitoreo, observabilidad, registros y diagnóstico de errores.
21. Procedimientos de respaldo y restauración.
22. Actualización y reversión de versiones.
23. Mantenimiento preventivo y correctivo.
24. Procedimientos de recuperación y continuidad operativa.
    • Desde la implementación y durante toda la vigencia del contrato, el contratista debe transferir de forma continua el conocimiento asociado con los cambios realizados en la infraestructura, aplicaciones, código fuente, bases de datos, integraciones, configuraciones, procedimientos operativos y componentes tecnológicos de la solución.
    • Toda la documentación y el material de capacitación deben entregarse en formatos digitales editables, reutilizables y accesibles definidos por la organización, sin restricciones que impidan su modificación, reproducción o utilización interna.
    • El contratista debe poder autorizar que la organización designe participantes adicionales o sustitutos dentro del límite y condiciones establecidos contractualmente, procurando que el conocimiento no quede concentrado en una única persona o dependencia.
    • El contratista debe registrar la asistencia a cada actividad de capacitación y entregar evidencia de su ejecución, incluyendo como mínimo fecha, duración, contenidos impartidos, personas participantes, materiales utilizados y responsable de la capacitación.
    • La capacitación y transferencia de conocimiento no sustituyen la obligación del contratista de administrar, operar, mantener y brindar soporte técnico sobre la solución y la infraestructura durante la vigencia del servicio.
    • El conocimiento, los manuales, materiales, procedimientos, diagramas, grabaciones y demás documentos elaborados específicamente para la implementación deben quedar a disposición de la organización para su uso, actualización y reutilización interna, sin dependencia del contratista.
    • La capacitación y transferencia de conocimiento deben permitir que la organización, aun cuando el contratista continúe administrando técnicamente la solución durante la vigencia del servicio, pueda supervisar su operación, comprender su arquitectura, verificar los procedimientos aplicados y prepararse para asumir su administración directamente o mediante un tercero autorizado.

 

• Garantías

El Oferente debe rendir una garantía de 12 meses, sobre el funcionamiento, actualización y operación de la plataforma a partir de la recepción definitiva de la plataforma por parte de la Administración.

 

 

• Criterios de aceptación
  • Cada requerimiento debe ser verificable mediante pruebas.
  • El Sitio Web será aceptado únicamente si cumple el 100% de los requerimientos obligatorios.
  • Se realizarán pruebas en ambiente de prueba antes de producción.

 

 

1. Entregables
   • Código fuente completo, que incluya como mínimo
     1. Proyectos y soluciones en base al producto o tecnología utilizada.
     2. Código del sitio web institucional y de su sistema de administración de contenidos.
     3. Código de las aplicaciones, servicios, API, integraciones y módulos asociados.
     4. Código del chatbot y del Módulo de Atención para Agentes.
     5. Archivos de configuración.
     6. Scripts y objetos utilizados
     7. Dependencias requeridas.
     8. Scripts de instalación y despliegue.
     9. Demás elementos necesarios para reproducir técnicamente la solución.
   • Documentación técnica.
   • Manual de usuario y administrador.
   • Plan de respaldo y recuperación.
   • Manuales y materiales de capacitación en idioma español, debidamente actualizados y alineados con la versión instalada de la solución, que deben incluir, como mínimo:
2. Manual de administración del sitio web y del CMS.
3. Manual de administración del chatbot y sus flujos.
4. Manual de operación para agentes y supervisores.
5. Manual técnico de instalación, configuración y mantenimiento.
6. Manual de respaldo y restauración.
7. Manual de monitoreo y atención de incidentes.
8. Guía de compilación, despliegue y reversión.
9. Diagramas de arquitectura e infraestructura.
10. Presentaciones, guías prácticas y ejercicios utilizados.
11. Grabaciones de las sesiones, cuando así lo requiera la organización

 

1. Reversibilidad y transición del servicio.

Al finalizar el contrato, por cualquier causa, el contratista deberá garantizar la reversibilidad de la solución y colaborar con la Administración en la transferencia ordenada del servicio hacia infraestructura institucional o hacia un tercero autorizado por el Sistema de Emergencias 9-1-1.

 

Para estos efectos, deberá entregar, en formatos utilizables y sin restricciones técnicas que impidan su posterior utilización, como mínimo: código fuente actualizado, bases de datos, contenidos, archivos, respaldos, configuraciones, documentación técnica, scripts de instalación y despliegue, configuraciones de infraestructura, certificados cuya titularidad corresponda a la institución, integraciones, API, dependencias, bitácoras y demás elementos necesarios para la operación y continuidad de la solución.

 

El contratista deberá brindar la asistencia técnica razonablemente necesaria durante el proceso de transición, de manera que la migración pueda realizarse sin pérdida de información y procurando minimizar la afectación o interrupción del servicio.

 

La finalización del contrato no deberá generar dependencia tecnológica obligatoria del contratista ni impedir que la institución administre directamente la solución o designe a un tercero para hacerlo.

 

 

 

 

1. Otros Requisitos:

 

• Literatura técnica:

El Oferente deberá adjuntar la literatura técnica (catálogos, fichas técnicas o manuales) y demás documentación que respalde su propuesta, la cual formará parte integral de la oferta. Dichos documentos deberán presentarse en idioma español; en caso de aportar documentación en otro idioma, deberá adjuntarse su correspondiente traducción al español bajo la absoluta responsabilidad del Oferente, de conformidad con el artículo 118 del Reglamento a la Ley General de Contratación Pública (RLGCP). Asimismo, se deberá indicar expresamente la marca y el modelo del bien ofrecido, los cuales deberán coincidir fielmente con la literatura aportada.

 

Toda mención a marcas, modelos, catálogos, fabricantes o especificaciones de casas comerciales en este pliego se hace únicamente a título de referencia para definir con mayor claridad las características mínimas del bien requerido. Por ende, se aceptarán bienes equivalentes o con especificaciones superiores que se adecuen de mejor manera a los intereses de la Administración.

 

 

• Plazo de entrega:

Para la Línea N°1 - Diseño, Desarrollo, Migración e Implementación Inicial

El plazo de entrega no podrá ser superior a 60 días hábiles.

El oferente deberá indicar para cada partida el plazo de entrega ofrecido (en días hábiles). En caso de omisión se entenderá que el oferente se ajusta al plazo máximo señalado. Las ofertas que sobrepase dicho plazo no serán consideradas. Se entenderá, para todo efecto, por “plazo de entrega inmediato” el día hábil posterior a la notificación del contrato electrónico u orden de pedido.

 

Condiciones de entrega y ejecución de las actividades

El objeto contractual se ejecutará bajo la modalidad de entregables y servicios según demanda, conforme al siguiente detalle por línea:

1. Línea 1: Diseño, Desarrollo, Migración e Implementación Inicial (Precio Cerrado / Llave en Mano)

• Modalidad de Entrega: El plazo de entrega no podrá ser superior a 60 días hábiles.

Se ejecutará conforme al Cronograma de Trabajo aprobado en la Fase I del proyecto. La entrega será integral y por fases (Análisis/Diseño, Desarrollo, Migración de Contenidos, Pruebas y Puesta en Producción).

• Condición de Aceptación y Pago: El pago de esta línea será único y se tramitará únicamente tras la Puesta en Producción satisfactoria del portal web y la firma del Acta de Recepción Definitiva a Satisfacción emitida por la Administración.

1. Línea 2: Soporte y Mantenimiento Ordinario (Servicio Continuado / Fijo)

• Modalidad de Entrega: Servicio de ejecución continuada y recurrente para garantizar la disponibilidad, estabilidad, seguridad, respaldos y mantenimiento preventivo/correctivo del portal web en horario hábil institucional.
• Condición de Aceptación y Pago: Se facturará y cancelará de manera mensual a mes vencido. El pago estará sujeto a la presentación del Informe Mensual de Mantenimiento y Cumplimiento de SLA por parte del contratista y la posterior emisión del Acta de Aceptación Mensual del Servicio.

1. Línea 3: Soporte fuera de Jornada Ordinaria (Según Demanda / Eventual)

• Modalidad de Entrega: Atención de contingencias, incidentes o mantenimiento extraordinario fuera del horario hábil institucional, activado únicamente mediante solicitud formal o tiquete de requerimiento expreso emitido por el Administrador del Contrato.
• Condición de Aceptación y Pago: Se facturará de forma eventual a la tarifa hora/evento adjudicada, contra la presentación del reporte técnico del incidente atendido, la verificación de los tiempos de respuesta y la firma del acta de recepción correspondiente. Si en un periodo mensual no se requieren atenciones fuera de jornada, no se generará cobro ni factura por este concepto.

1. Línea 4: Mejoras Continuas (Según Demanda / Bolsa de Horas Estimada)

• Modalidad de Entrega: Desarrollo de nuevas funcionalidades, ajustes de diseño o adaptaciones evolutivas del sitio web. Se ejecutará por órdenes de trabajo específicas, donde la Administración solicitará la mejora y el contratista estimará las horas requeridas según la tarifa hora adjudicada para aprobación previa.
• Condición de Aceptación y Pago: Se facturará según la demanda real de horas ejecutadas, tras la entrega, pruebas y aprobación del producto/mejora solicitado. El volumen de 200 horas es una estimación anual máxima de referencia; la Administración pagará únicamente las horas efectivamente requeridas, autorizadas y recibidas a satisfacción.

 

 

1. Otras condiciones:

 

• Forma de pago:

Todo pago a cargo de la Administración se realizará luego de la recepción definitiva de los bienes y servicios.

 

• Vigencia del contrato:

• Ejecución por Fases:
• Fase I (Desarrollo e Implementación - Línea 1): Tendrá un plazo máximo de 60 días hábiles, o bien el ofrecido por el oferente que resulte adjudicatario, a partir de la Orden de Inicio. Finaliza con la Puesta en Producción y el Acta de Recepción Definitiva.
• Fase II (Soporte, Mantenimiento y Mejoras - Líneas 2, 3 y 4): Regirá por un plazo inicial de un (1) año a partir de la recepción definitiva de la Fase I.

 

• Prórrogas Contractuales: Los servicios de la Fase II (Soporte, Mantenimiento y Mejoras - Líneas 2, 3 y 4) podrán prorrogarse hasta por tres (3) periodos similares, sujeto a la evaluación satisfactoria del servicio y a la disponibilidad presupuestaria anual de la Administración.

 

• Garantía de cumplimiento

El adjudicatario deberá extender una Garantía de Cumplimiento a nombre del contratante, dentro de los 3 días hábiles contados a partir de la fecha en que quede en firme la adjudicación. 

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)..

 

1. Cláusula penal. (Ver Anexo 1)

 

• Cláusula penal: Por ejecución tardía (cada día hábil de atraso respecto del plazo de entrega ofrecido) del requerimiento solicitado, se aplicará un 2.00% sobre el valor de la línea respectiva, hasta un máximo del 25%.
• Multa: Para efectos de la presente contratación, se tipifican como ejecución defectuosa los siguientes incumplimientos técnicos que, por su naturaleza, pueden generar atrasos en el desarrollo e implementación del Sitio Web (Fase I). Detectado el incumplimiento, el Administrador de Contrato lo notificará por escrito al Contratista y le otorgará un plazo para su corrección; vencido dicho plazo sin que el defecto haya sido subsanado a satisfacción de la Administración, se aplicará el porcentaje indicado en cada caso por cada día hábil en que persista el incumplimiento.

El puntaje de cada aspecto se obtuvo aplicando la metodología del “Anexo N°1: Estudio para cálculo de Cláusula Penal y Multas” (Factor N°1 Repercusión, Factor N°2 Riesgo, Factor N°3 Preponderancia del plazo y Factor N°4 Monto del contrato), y el porcentaje corresponde a la tabla de Calificación de importancia de dicho anexo: más de 70 hasta 90 puntos, importancia Alta (2.00 % por día); más de 50 hasta 70 puntos, importancia Media (1.00 % por día); menos de 50 puntos, importancia Baja (0.50 % por día). No se considerarán imputables al Contratista los atrasos originados en causas atribuibles a la Administración, a terceros proveedores de la institución o a situaciones de fuerza mayor debidamente acreditadas. Un mismo hecho y período no dará lugar al cobro simultáneo de multa y cláusula penal, y la suma de ambas sanciones no podrá exceder el 25 % del precio del contrato.

• Infraestructura de hospedaje y ambientes de trabajo. No disponer, en el plazo requerido, del servidor virtual dedicado, del ancho de banda mínimo de 25 Mbps simétrico y de los ambientes de pruebas y producción aislados entre sí, con el dimensionamiento ofertado y los accesos de validación requeridos por el Sistema de Emergencias 9-1-1, o ponerlos a disposición con deficiencias que impidan su uso (Capítulo II, puntos 5.2, 7.8.1, 7.8.2 y 7.8.10).

Incidencia en el plazo: Sin infraestructura ni entorno de pruebas no es posible iniciar la construcción, la migración ni las pruebas, por lo que el atraso se traslada a todas las actividades posteriores.

Puntaje: 75 puntos – Importancia: Alta – Multa: 2.00 % por día hábil.

• Migración del sitio web actual. Migrar menos del 100 % de los contenidos de www.911.go.cr (WordPress/PHP con base de datos MySQL, 904 MB, alojado en el data center contratado por el 9-1-1), o hacerlo con pérdida, corrupción o alteración de información, archivos, enlaces o metadatos, o sin la validación previa del proceso en el entorno de pruebas (Capítulo II, puntos 4, 5.3 y 7.8.4).

Incidencia en el plazo: La conversión de contenidos desde WordPress hacia la nueva plataforma es una actividad de ruta crítica; cada ciclo de migración fallido obliga a repetir la extracción, transformación, carga y validación de la información, y posterga la puesta en producción.

Puntaje: 85 puntos – Importancia: Alta – Multa: 2.00 % por día hábil.

• Arquitectura y plataforma tecnológica. Implementar una solución que no respete la arquitectura desacoplada entre frontend, backend y base de datos, la arquitectura modular, la plataforma de desarrollo establecida o el uso de tecnologías vigentes y con soporte activo del fabricante, de modo que la Administración deba rechazar componentes ya construidos (Capítulo II, puntos 5.1, 6.7.1.3.6 y 7.1).

Incidencia en el plazo: Un error de arquitectura detectado tardíamente obliga a rehacer la base sobre la que se construyen el CMS, los módulos y el chatbot, con el mayor impacto sobre el cronograma.

Puntaje: 80 puntos – Importancia: Alta – Multa: 2.00 % por día hábil.

• Sistema de gestión de contenidos (CMS) y flujo de aprobación. Entregar el CMS sin alguna de sus funciones obligatorias: autenticación individual, roles y permisos, flujo de aprobación con los estados Pendiente, Aprobado, Rechazado y Publicado, notificaciones automáticas por correo electrónico, versionamiento, programación y expiración de publicaciones, gestión de archivos multimedia y bitácora de acciones (Capítulo II, puntos 5.4 y 6.1).

Incidencia en el plazo: El CMS es requisito para cargar y validar los contenidos migrados y para que la institución apruebe las publicaciones; sus defectos detienen la carga de contenidos y las pruebas de aceptación.

Puntaje: 65 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Plataforma Chatbot (CMS del chatbot, Widget de Interacción y Módulo de Atención para Agentes). Entregar la plataforma sin alguno de sus tres módulos independientes o sin las funciones obligatorias de administración de nodos y flujos, validación estructural y simulador, versionamiento, comunicación en tiempo real mediante ASP.NET Core SignalR o tecnología equivalente aprobada, traducción automática español-inglés, derivación a agentes humanos y encuestas de satisfacción (Capítulo II, puntos 6.2.5 y 6.8).

Incidencia en el plazo: Es el componente de mayor complejidad funcional del proyecto; la interdependencia de sus módulos y la comunicación en tiempo real exigen ciclos de prueba adicionales que, si fallan, desplazan la entrega integral.

Puntaje: 70 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Integraciones con servicios y plataformas externas. No implementar, o implementar con fallas, las integraciones requeridas: tableros estadísticos (Power BI, Fabric, Tableau o equivalente) con actualización automática, servicio de correo para notificaciones y confirmaciones en menos de 5 segundos, redes sociales, acceso a pagos en línea con URL configurable, protocolo HTTPS y certificado vigente, y envío de alertas a herramientas de mensajería (Capítulo II, puntos 6.1.17, 6.3.8 a 6.3.11, 6.4.6, 6.7.1.3, 6.9 y 7.16.22).

Incidencia en el plazo: Las integraciones requieren coordinación con otras unidades y proveedores; su configuración tardía o defectuosa bloquea las pruebas de extremo a extremo.

Puntaje: 60 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Formularios y módulos de servicios. Entregar formularios y secciones de servicios que no cumplan las validaciones de campos y formatos, el CAPTCHA visual y audible, la carga de adjuntos de hasta 100 MB, el registro en base de datos y la generación de códigos QR, ni la lógica específica de Certificaciones (cálculo automático de 10 días hábiles), Atención al usuario, Participación ciudadana (encuestas emergentes programables), Charlas educativas (listas dependientes de provincia, cantón y distrito) y Bolsa de empleo (Capítulo II, puntos 6.4, 6.7.1 y 6.7.2.2).

Incidencia en el plazo: Son desarrollos acotados pero numerosos; sus defectos generan rechazos parciales en las pruebas de aceptación.

Puntaje: 50 puntos – Importancia: Baja – Multa: 0.50 % por día hábil.

• Sección de Transparencia. Implementar la sección de Transparencia sin la estructura del Índice de Transparencia del Sector Público (Metodología ITSP 2.0 DHR 2025), sin los apartados de la Guía para la creación de sitios web transparentes del CICAP-UCR o sin los formatos de datos abiertos exigidos por la normativa citada (Capítulo II, punto 6.7.2.1).

Incidencia en el plazo: La estructura debe validarse contra la metodología oficial y la normativa de transparencia y datos abiertos; los ajustes posteriores obligan a reorganizar contenidos ya migrados.

Puntaje: 60 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Seguridad de la información. Mantener sin remediar, dentro del plazo otorgado, vulnerabilidades de severidad crítica o alta identificadas en escaneos o pruebas de seguridad previos a la puesta en producción, o no implementar los controles obligatorios: WAF, mitigación de ataques DoS/DDoS, HTTPS con certificado válido, hardening, controles contra inyección SQL, XSS y CSRF, políticas de contraseña y gestión segura de sesiones (Capítulo II, puntos 7.4, 7.8.6 y 7.8.7).

Incidencia en el plazo: La Administración no puede autorizar el paso a producción de un sitio con vulnerabilidades críticas o altas abiertas, por lo que la puesta en producción queda detenida hasta su corrección.

Puntaje: 85 puntos – Importancia: Alta – Multa: 2.00 % por día hábil.

• Rendimiento, concurrencia y disponibilidad. No superar las pruebas de rendimiento y carga: tiempo de carga de páginas y de resultados de búsqueda menor a 3 segundos en el 95 % de las solicitudes, soporte de alta concurrencia (incluidos 15 usuarios simultáneos en el CMS), escalabilidad sin interrupción del servicio y niveles de disponibilidad requeridos (Capítulo II, puntos 5.1.3, 5.2.7, 5.2.10, 6.1.8, 6.5.2 y 7.2).

Incidencia en el plazo: Los problemas de rendimiento suelen detectarse al final, con el contenido real cargado, y su corrección puede requerir redimensionar la infraestructura u optimizar el código y la base de datos.

Puntaje: 70 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Accesibilidad digital y compatibilidad. Incumplir WCAG 2.1 nivel AA en el sitio o WCAG 2.2 nivel AA en los componentes del chatbot, la Ley N°7600 y la Directriz N°051-MTSS-MICITT, o presentar fallas de visualización o funcionamiento en los navegadores y dispositivos requeridos (Capítulo II, puntos 6.8.10, 7.5 y 7.6).

Incidencia en el plazo: Los hallazgos de accesibilidad y compatibilidad son transversales a todas las plantillas y componentes, por lo que su corrección tardía implica rehacer partes del frontend.

Puntaje: 60 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Monitoreo, bitácoras, respaldos y recuperación. No tener operativos, antes de la puesta en producción, el monitoreo continuo 24/7 con frecuencia máxima de 1 minuto, la herramienta de monitoreo de rendimiento (APM), la centralización de logs, las alertas y las bitácoras de auditoría, así como los respaldos automáticos diarios con prueba de restauración exitosa y validación de RTO y RPO (Capítulo II, puntos 7.8.8, 7.8.9, 7.15, 7.16 y 7.17).

Incidencia en el plazo: Sin estos mecanismos no es posible verificar los niveles de servicio ni garantizar la continuidad, por lo que la Administración no puede dar por aceptada la solución.

Puntaje: 70 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Gestión de pruebas, corrección de defectos y despliegue. No corregir, en el plazo otorgado, los defectos imputables al Contratista reportados en las pruebas de aceptación; desplegar cambios en producción sin validación previa en el entorno de pruebas; o no entregar la evidencia de pruebas (capturas de pantalla, navegadores y dispositivos utilizados), las páginas de error estándar y el control de enlaces rotos (Capítulo II, puntos 7.7, 7.8.15, 7.8.16, 7.14 y 7.23).

Incidencia en el plazo: La aceptación exige el cumplimiento del 100 % de los requerimientos obligatorios; cada ciclo de corrección no atendido a tiempo posterga la recepción y la puesta en producción.

Puntaje: 80 puntos – Importancia: Alta – Multa: 2.00 % por día hábil.

• Equipo técnico del proyecto. Sustituir personal técnico ofrecido sin la notificación previa de tres días hábiles o por personas que no cumplan los requisitos establecidos, o dejar sin cobertura roles técnicos de forma que se paralicen las actividades del proyecto (Capítulo II, puntos 2.1.4 a 2.1.8).

Incidencia en el plazo: La rotación o ausencia del personal clave interrumpe la continuidad técnica y exige curvas de aprendizaje que se trasladan al plazo.

Puntaje: 50 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

• Capacitación, transferencia de conocimiento y entregables. No presentar para aprobación el plan de capacitación, no ejecutarlo antes de la puesta en producción, o no entregar el código fuente completo, la documentación técnica, los manuales y los materiales requeridos (Capítulo II, puntos 7.21 y 8 Entregables).

Incidencia en el plazo: Estos entregables son condición para la recepción definitiva y para que la institución opere la solución; su atraso impide el cierre de la Fase I.

Puntaje: 60 puntos – Importancia: Media – Multa: 1.00 % por día hábil.

Resumen de valoración de los aspectos técnicos tipificados en los puntos 8.2.1 a 8.2.15:

VALORACIÓN DE MULTAS POR ASPECTO TÉCNICO (metodología del Anexo N°1)
N°	Aspecto técnico	F1 Repercusión	F2 Riesgo	F3 Plazo	F4 Monto	Total	Importancia	Multa por día hábil
8.2.1	Infraestructura de hospedaje y ambientes	Alta (30)	Media (20)	Alta (15)	Baja (10)	75	Alta	2.00 %
8.2.2	Migración del sitio web actual	Alta (30)	Alta (30)	Alta (15)	Baja (10)	85	Alta	2.00 %
8.2.3	Arquitectura y plataforma tecnológica	Alta (30)	Alta (30)	Media (10)	Baja (10)	80	Alta	2.00 %
8.2.4	CMS y flujo de aprobación	Media (20)	Media (20)	Alta (15)	Baja (10)	65	Media	1.00 %
8.2.5	Plataforma Chatbot y Módulo de Agentes	Media (20)	Alta (30)	Media (10)	Baja (10)	70	Media	1.00 %
8.2.6	Integraciones con servicios externos	Media (20)	Media (20)	Media (10)	Baja (10)	60	Media	1.00 %
8.2.7	Formularios y módulos de servicios	Media (20)	Baja (10)	Media (10)	Baja (10)	50	Baja	0.50 %
8.2.8	Sección de Transparencia	Media (20)	Media (20)	Media (10)	Baja (10)	60	Media	1.00 %
8.2.9	Seguridad de la información	Alta (30)	Alta (30)	Alta (15)	Baja (10)	85	Alta	2.00 %
8.2.10	Rendimiento, concurrencia y disponibilidad	Alta (30)	Media (20)	Media (10)	Baja (10)	70	Media	1.00 %
8.2.11	Accesibilidad digital y compatibilidad	Media (20)	Media (20)	Media (10)	Baja (10)	60	Media	1.00 %
8.2.12	Monitoreo, bitácoras y respaldos	Media (20)	Alta (30)	Media (10)	Baja (10)	70	Media	1.00 %
8.2.13	Pruebas, corrección de defectos y despliegue	Alta (30)	Alta (30)	Alta (15)	Baja (10)	80	Alta	2.00 %
8.2.14	Equipo técnico del proyecto	Baja (10)	Media (20)	Media (10)	Baja (10)	50	Baja	0.50 %
8.2.15	Capacitación, transferencia y entregables	Media (20)	Media (20)	Media (10)	Media (10)	60	Media	1.00 %

Nota: F1 = Repercusión; F2 = Riesgo; F3 = Preponderancia del plazo; F4 = Monto del contrato. El Factor N°4 se mantiene en valoración Baja (10 puntos) para todos los aspectos, conforme a la Valoración Final del Anexo N°1.

 

• Fase II (Atraso en Entregables de Mejoras - Línea 4):

• Tipificación: Incumplimiento en la fecha pactada para la entrega de una orden de trabajo de mejora solicitada.
• Monto: 2% diario sobre el valor de la orden de trabajo específica por cada día hábil de atraso.

• (Incumplimientos Técnicos y de SLA - por faltas a la calidad o niveles de servicio)

• Incumplimiento de Disponibilidad (Uptime del Portal):
  • Tipificación: Cuando la disponibilidad mensual del sitio web sea inferior al estipulado (excluyendo mantenimientos programados autorizados).
  • Monto: 2% de la factura mensual de soporte (Línea 2) por cada caída por debajo del límite.
• Incumplimiento en Tiempos de Respuesta a Incidentes (SLA Correctivo):
  • Tipificación: Superar los tiempos máximos de atención/resolución fijados para incidentes de criticidad Alta, Media o Baja.
  • Monto: 2% de la factura mensual de soporte por cada hora de retraso en incidentes de Criticidad Alta, y por cada día de retraso en Criticidad Media/Baja.
• Incumplimiento de Estándares de Accesibilidad o Seguridad:
  • Tipificación: Inobservancia de la norma WCAG 2.1 AA o la reaparición de vulnerabilidades críticas previamente reportadas.

Monto: 2% de la factura mensual de soporte por cada hallazgo no corregido dentro del plazo de subsanación otorgado

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	Descripción	Código SICOP
1	1	Servicio de diseño, desarrollo, migración, implementación, hospedaje, mantenimiento y soporte del sitio web institucional de la página web del Sistema de Emergencias 9-1-1.	8111210392056297

 

Partida	Línea	Cantidad	Descripción	Costo unitario IVAi	Costo total IVAi
1	1	1	Contratación de diseño, desarrollo, migración, implementación, hospedaje del sitio web
	2	12	Soporte y mantenimiento sitio web institucional (mensual)
	3	1	Soporte y mantenimiento sitio web institucional (según demanda – fuera de jornada ordinaria)
	4	200	Mejoras (horas anuales estimadas, según demanda)

 

Notas importantes:

Se aclara que el Sistema de Emergencias 9-1-1 no goza de exención del Impuesto sobre el Valor Agregado (IVA). En consecuencia, será responsabilidad exclusiva de cada oferente determinar y desglosar en su oferta la tarifa tributaria que legalmente corresponda al bien o servicio cotizado (13%, tarifas reducidas o exenciones aplicables a la naturaleza del producto), conforme a la Ley N.º 9635 y su Reglamento.)

 

1. Desglose Fijo de Cotización (Formulario de Oferta Adjunto): Todo oferente deberá adjuntar a su propuesta en SICOP el cuadro de desglose económico debidamente completado conforme al detalle indicado.
2. Regulación y Alcance de las Líneas de Cotización:

• Línea 1 (Desarrollo e Implementación Inicial): Precio cerrado (llave en mano) para el diseño, desarrollo, migración, implementación y hospedaje inicial del sitio web.
• Línea 2 (Soporte y Mantenimiento Ordinario): Tarifa fija mensual. Para efectos de la proyección anual, el costo unitario mensual se multiplicará por la cantidad de 12 meses.
• Línea 3 (Soporte fuera de jornada ordinaria): Corresponde a la cotización del costo por hora (tarifa unitaria) para la atención eventual de incidentes o emergencias fuera del horario hábil. Para efectos de la proyección y evaluación económica de la oferta, se considerará el monto unitario por hora ofertado por la cantidad de 1 evento/unidad de referencia. La facturación de esta línea se realizará estrictamente según la demanda real y efectiva requerida por la Administración.
• Línea 4 (Mejoras continuas): El oferente deberá indicar el costo por hora de desarrollo. Para efectos de evaluación y proyección presupuestaria, se multiplicará dicho costo por hora por el volumen estimado de 200 horas anuales. La ejecución de estas horas se realizará de forma fragmentada y según la demanda requerida formalmente por la Administración.

1. Firmeza de Precios Unitarios: Las tarifas unitarias ofertadas en las Líneas 2, 3 y 4 se mantendrán firmes e inalterables como precios adjudicados para la facturación mensual y la emisión de órdenes de trabajo durante la vigencia del contrato y sus eventuales prórrogas.

 

1. Vigencia de la oferta
   • La vigencia de la oferta deberá extenderse por el plazo que se solicita en el formulario SICOP 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.
   • De conformidad con el reciente cambio de criterio emitido por la Contraloría General de la República en la resolución R-DCP-SICOP-01324-2025, se establece que la obligatoriedad de incluir 'imprevistos' en la estructura de precios aplica exclusivamente para contratos de obra y servicios, quedando los contratos de bienes exentos de dicho rubro.

 

 

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.

 

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.

 

• Constancia Municipal:

El oferente debe aportar constancia emitida por la Municipalidad respectiva, donde expresamente se haga constar que la actividad económica que se autoriza en la licencia Municipal, le permite ofrecer el objeto contractual y que se encuentre al día con su pago. No será de recibo la copia de la patente Municipal.

 

• 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.