banners
beforecontenttitle

Requests manager

After content title
Before content body
Chunks
Chunks

En esta página se explica las posibilidades que ofrece el Gestor de Peticiones del SCI que puede solicitar cualquier responsable de unidad funcional de la UMA para sus propios fines escribiendo a cau@uma.es.

Con Gestor de Peticiones (a partir de ahora GP) hacemos referencia a una aplicación web alojada en la UMA, con posibilidad de acceso identificado idUMA, donde los usuarios puedan realizar peticiones y realizar un seguimiento de ellas bien por la web o por correo electrónico.

El GP está pensado para poder adaptarse a sus necesidades, por lo que es imprescindible una reunión con el SCI para poder conocerlas y asesorarle.

Índice

  1. Gestores de Peticiones en uso.
  2. Posibilidades del GP.
  3. Acceso y usuarios permitidos.
  4. Campos de una petición.
  5. Transiciones entre estados.
  6. Tiempos estadísticos de una petición.
  7. Búsquedas.
  8. Informes disponibles.
  9. Peticiones y avisos automáticos.
  10. Historial de mejoras al gestor de peticiones.


1. Gestores de Peticiones en uso:

(Listado actualizado a 17/06/2022)

2. Posibilidades del GP

  • Peticiones autenticadas por idUMA, por certificado digital o anónimas.
  • Posibilidad de adjuntar ficheros en la petición.
  • Notificaciones por correo electrónico.
  • Encuestas de calidad al usuario una vez finalizada la petición.
  • Búsqueda avanzada de peticiones.
  • Estadísticas de números de peticiones, satisfacción y tiempos de respuesta.
  • Anotaciones en la petición para comunicación con el usuario o dejar constancia de lo realizado.
  • Diferentes estados para poder realizar un mejor seguimiento de la petición.
  • Asignación automática a las personas responsables de su resolución.
  • Distintas actuaciones según el usuario que sea: encargado, responsable de resolver, usuario, etc.
  • Creación automática de peticiones periódicas.
  • Avisos automáticos por correo electrónico.
  • Creación de peticiones automáticas cuando se escribe a una dirección de correo electrónico concreta.
  • Etc.


3. Acceso y usuarios permitidos

El acceso a la aplicación se puede realizar desde cualquier ordenador con conexión a Internet, sin necesidad de estar dentro de la red de la UMA.

El GP se puede configurar de manera que puedan realizar peticiones:

  1. Solo los usuarios de la comunidad universitaria que queramos.
  2. Toda la comunidad universitaria.
  3. Usuarios externos autenticados con certificado digital.
  4. Cualquier persona que indique un correo electrónico. Esa dirección de correo deberá ser validada por el usuario a fin de confirmar su pertenencia y facilitar la comunicación.


4. Campos de una petición

El formulario de una petición pide al usuario los siguientes campos:

  • Tipo de petición (desplegable jerárquico personalizable de varios niveles).
  • Ubicación/Centro (desplegable personalizable).
  • Nombre, email y teléfono de contacto.
  • Descripción de la petición.
  • Archivos adjuntos.

 

Y cualquier otro campo que se necesite, según el tipo de cada petición. Así, por ejemplo, se puede especificar que si la petición es de tipo "Problema con el teléfono" se deba especificar el número de teléfono afectado.

El campo tipo es el que le ayuda a reconocer la naturaleza de la petición, realizar asignaciones automáticas a los responsables, sacar estadísticas diferenciadas, etc.

Además de estos campos el sistema almacena otros de uso interno como: un número de referencia identificativo, estado de la petición, tiempos de respuesta, responsable asignado, personas interesadas, etc.


5. Transiciones entre estados

Una de las ventajas de disponer de un GP es el control del flujo de cada petición.

Pongamos un ejemplo:

  1. El usuario crea una solicitud de tipo "Telefónica".
  2. Esa petición entra en estado "abierta" y se asigna automáticamente al responsable de telefonía.
  3. El responsable de telefonía es notificado por correo electrónico, entra en el GP y marca esa solictud como "solucionada" indicando en el mismo GP la respuesta para el usuario.
  4. El usuario recibe en su correo electrónico la respuesta y se le solicita que responda la encuesta de satisfacción mediante un enlace.
  5. El usuario entra mediante el enlace al GP e indica su satisfacción con el trato recibido.

Esto es solo un ejemplo, obviamente esto se puede alargar como queramos, mandar o no correo al responsable, hacer la asignación de manera manual por un encargado, etc.


6. Tiempos estadísticos de una petición

Los tiempos se miden en horas, y se definen como el tiempo que la petición está en determinados estados. Estos tiempos se miden para cada petición o bien por rango de fechas.

Pongamos un ejemplo, imaginemos que los estados posibles son:

  • Sin asignar: petición creada, falta que el encargado la asigne.
  • En ejecución: ya está asignada, a falta de cerrarse.
  • Pendiente de usuario: estando en alguno de los estados anteriores el encargado o responsable ha solicitado más información al usuario.
  • Cerrada: petición satisfecha.

 

Así, podríamos definir los siguientes tiempos:

  • Tiempo de asignación: el que está la petición en estado "Sin asignar".
  • Tiempo pendiente: el que está en estado "Pendiente de usuario".
  • Tiempo de ejecución: el que está en estado "En ejecución".


7. Búsquedas

Al estar todas las peticiones en una base de datos se pueden realizar búsquedas según su número de referencia, estado, el responsable asignado, un rango de fechas, etc. De manera que no se nos pierda ninguna petición.


8. Informes disponibles

Existen una serie de informes que nos ayudan a visualizar las peticiones de manera agrupada facilitando la gestión:

  • Peticiones por cada estado.
  • Peticiones abiertas por cada tipo.
  • Todas las peticiones por cada tipo.
  • Peticiones abiertas de cada responsable.
  • Informe personalizado a especificar rango de fechas y datos a obtener. Exportable a Excel.


9. Peticiones y avisos automáticos

El GP brinda la opción de insertar peticiones de manera automática, de manera que cada X tiempo se cree una petición del tipo que queramos. Esto permite programar acciones preventivas, por ejemplo.

Así mismo se pueden realizar avisos automáticos, de manera que si una petición está X tiempo en un estado se avise a quien queramos (usuario, responsable, encargado, ...) y pudiendo también cambiar la petición de estado. Esto permite recordar al usuario solicitudes que están pendientes de modificación por su parte, avisar de peticiones que llevan demasiado tiempo abiertas, denegar peticiones que llevan demasiado tiempo pendientes de usuario, etc.

After content body