Coberturas de soporte de Athento

Siempre contarás con nuestro respaldo y apoyo técnico.
Cuando contratas nuestro servicio, recibes también las coberturas de soporte de Athento.

Todos los planes incluyen

  • Backups
  • Actualizaciones
  • Documentación de producto

Plus

Todo lo del Starter +

Standard

Todo lo del Plus +
  • Atención 10-17 LV
  • Acceso al centro de soporte
  • Hasta 4 contactos autorizados
  • Hasta 50 tickets incluidos al año
Popular

Company

Todo lo del Standard +
  • Atención 9-20 LV
  • Soporte telefónico
  • Hasta 10 contactos autorizados
  • Hasta 125 tickets incluidos al año

ANS de atención y resolución de incidencias

Tiempos de Respuesta.
De acuerdo con tu plan y el tipo de incidente reportado, responderemos a tus incidentes en...

Tipo de incidente

  • Bloqueante
  • Critica
  • Mayor
  • Trivial

Plus

  • 8 horas
  • 3 días
  • 4 días
  • > 5 días

Standard

  • 6 horas
  • 2 días
  • 3 días
  • > 4 días

Company

  • 4 horas
  • 8 horas
  • 2 días
  • > 3 días

Tiempos de Resolución.
De acuerdo con tu plan y el tipo de incidente reportado, resolveremos a tus incidentes en...

Tipo de incidente

Plus

  •  
  •  
  •  
  •  

Standard

  • 10 horas
  • 5 días
  • 10 días
  • < 30 días

Company

  • 7 horas
  • 2 días
  • 5 días
  • < 15 días

Preguntas frecuentes

Sí, todos los planes de Athento incluyen un servicio de soporte que incluye al menos el mantenimiento de la herramienta, la corrección de incidencias detectadas en el producto y la actualización de la herramienta. 

El soporte de Athento es de carácter preventivo y correctivo porque:

  • Ayudará al cliente a solucionar incidencias o problemas reales con la aplicación. (Correctivo).
  • Solucionará bugs o problemas que hayan sido detectados aunque el cliente no haya reportado aún la incidencias con el software. Es decir, tratará de evitar que se produzcan incidencias.(Preventivo)

El tiempo de respuesta es el tiempo que toma el reconocimiento del problema de un cliente de una forma no automática.

Se mide desde el momento en que se hace el registro de la incidencia por uno de los canales autorizados (email, teléfono, centro de soporte), hasta el momento en que se informa al cliente que su problema ha sido recibido y está siendo abordado.

El tiempo de respuesta no es sólo la confirmación de que el ticket ha sido recibido, sino que también incluye un primer paso hacia la resolución del ticket, por ejemplo, una sugerencia o la solicitud de más información.

En el ciclo de vida del ticket, este paso cambia la incidencia de “Nueva” a “Abierta”. Los tiempos de respuesta no son tiempos de resolución. La resolución dependerá de la complejidad de la issue y de su prioridad de atención.

Es el tiempo que se tarda en resolver una incidencia o responder una pregunta del cliente. Están asociados a la criticidad de la incidencia. A mayor criticidad, menor es el tiempo de resolución propuesto en las SLAs. La resolución de una incidencia puede implicar la comunicación al cliente de que no es posible ofrecer una resolución o al menos una resolución inmediata a su problema para casos como:

  • Tickets que requieren intervención del departamento de desarrollo: En este caso, la resolución del ticket es la generación de una tarea para el equipo de desarrollo. Si bien el ticket se cierra, el cliente obtendrá el código de la tarea de desarrollo creada y fechas aproximadas en las que el equipo de desarrollo acometerá los trabajos. Estos desarrollos pueden ser para correcciones de errores en el software o para evolutivos asociados al roadmap de producto.
  • La resolución de la incidencia no depende de Athento: Son los casos en los que la incidencia está relacionada con un servicio asociado y Athento no cuenta con control sobre la misma. Estos servicios asociados incluyen -pero no se limitan a- fallos de la infraestructura cuya resolución no dependa de Athento, disponibilidad de internet, centros de datos, bugs en sistemas operativos, bases de datos, frameworks usados, etc.  Por ejemplo, caídas de Azure, o situaciones que requieren parches o hotfixes de terceros. En estos casos, se ofrecerá información al cliente sobre la situación.
  • No se obtiene información necesaria para resolver el ticket o reproducir la incidencia: Si se solicita información al cliente pero no se obtiene en un tiempo prudencial, un ticket en estado pending se cerrará. Los tickets en pending no se cerrarán sin previa notificación al cliente.

Este tiempo sólo aplicará en el caso de que la solución dependa al 100% de Athento y el ticket se haya reportado originalmente de manera correcta.

No se aceptarán solicitudes por soporte que correspondan realmente a ajustes o parametrizaciones de proyecto.

Son las personas que están habilitadas para reportar incidencias por los canales habilitados para ello.

Los tickets de servicio son el número de peticiones que se realizan al servicio de soporte. Estos tickets se contemplan de forma anual. El cliente puede saber en cada momento su consumo de tickets desde el Centro de Soporte o preguntando a nuestro equipo de soporte. Los tickets generados durante los dos primeros meses tras la puesta en producción de un proyecto, no se descuentan del número de tickets de servicio incluidos. Si el cliente se pasa de su número de tickets de servicio incluidos, tiene la posibilidad de pasarse a un plan superior de soporte o de contratar bolsas de tickets. 

Una incidencia Blocker indica que el sistema en producción se encuentra totalmente fuera de servicio. Se incluyen en esta categoría aquellas vulnerabilidades de seguridad que afecten a la privacidad de los datos por un agujero de seguridad del producto y que se hayan materializado.

En este caso, el sistema en producción funciona, pero servicios u operaciones críticas del sistema se encuentran interrumpidos. El impacto en el sistema es severo y limita funcionalidad vital del sistema (por ejemplo, crear documentos o consultar documentos de forma generalizada). Se incluyen en este punto vulnerabilidades que afecten a la privacidad de los datos pero que no se hayan materializado o ataques DoS que afecten a la disponibilidad del servicio.

Existe una afectación moderada del sistema. Puede referirse también a inestabilidad en el sistema con interrupciones periódicas del servicio o pérdida de funcionalidad del producto. Esta categoría también puede recoger errores de desarrollo que afectan el performance del producto. El cliente en este caso, puede perfectamente operar con el sistema. Estas solicitudes de soporte se solucionarán mediante hotfixes o nuevas releases, pero tienen menos prioridad que las incidencias Critical. Se incluyen en este punto vulnerabilidades que afecten al performance de la plataforma, generen lentitud o caídas puntuales.

Existe una afectación pequeña del sistema. Plugins o funcionalidades concretas no se encuentran funcionando con normalidad, pero el cliente es completamente capaz de operar con el sistema. Estas incidencias se resolverán mediante hotfixes y releases, pero tienen menos prioridad que incidencias Major o Critical. Se incluyen en este punto vulnerabilidades que, sin afectar a la privacidad o disponibilidad de la plataforma, requieran de una especial atención. Entrarían en este punto aquellas evidencias encontradas mediante la aplicación de técnicas de hacking ético, así como  preguntas sobre uso del sistema, solicitudes de información en general, reporte de errores en la documentación, recomendaciones, solicitudes de mejoras, etc.

PHP Code Snippets Powered By : XYZScripts.com