banners
beforecontenttitle

Gestor de peticiones

Después del título del contenido
Antes del cuerpo del contenido
Trozos html editables
Trozos html editables

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 posibiliad 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. Algunos GPs actualmente 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. Algunos GPs actualmente en uso:


2. Posibilidades del GP

  • Peticiones autenticadas por idUMA.
  • Peticiones 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ática cuando se escribe a una dirección de correo electrónico concreta.
  • Etc.

El GP está siempre en continua mejora, como puede ver al final de esta página.


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

10. Historial de mejoras al gestor de peticiones

12/06/2015

  • Notificaciones a la App de la UMA. Las notificaciones que hasta ahora llegaban por email pueden notificar también a esta aplicación en el móvil.
     

27/02/2015

  • Se registra más información en el "Historial de cambios de estado” que se ve al final de una petición.
  • Posibilidad de obtener impresos en un formato específico, relleno ya con los datos indicados en la petición.
     

10/12/2014

  • Ahora los tiempos mostrados en la ficha de una petición son más reales, actualizados cada hora.
  • Encuesta de satisfacción en el mismo email de respuesta al usuario.
  • Posibilidad de desactivar el gestor por un tiempo determinado.

27/06/2014

  • Nueva interfaz.
    • Misma estética que la web de la UMA. Lo que hace que el peticionario no tenga sensación de que ha cambiado de web, y sepa encontrar el menú, botón de inicio de sesión y demás opciones de manera más fácil.
    • Adaptable a la pantalla del dispositivo con que se visualice. Así se puede maximizar para poder ver entera la tabla de peticiones, por ejemplo, o utilizar la web desde el móvil o tablet de manera cómoda.
    • Interfaz más intuitiva. 
  • Informes personalizados. Ahora en el punto de menú “Informes” se dispone de un informe personalizado donde se puede decidir qué rango de fechas se quieren ver (Hoy, últimos x días, desde fecha inicio a fecha fin, etc.), los filtros que se deseen (por peticionario, por tipo, estado, etc.) y, lo más novedoso, qué campos se quiere que aparezcan en el informe. Una vez obtenido el listado se puede imprimir o exportarlo a CSV para poder trabajar con él con Excel o LibreOffice.
  • Posibilidad de realizar peticiones a nombre de otro. Al realizar una petición se puede escoger el peticionario de una lista de todos los que han entrado alguna vez al gestor. 
  • Menú destacado. Ahora cada gestor puede tener un menú destacado a la derecha, al igual que en la web de la UMA, donde se pueden poner los enlaces que se quieran.


26/02/2014

  • Tipo de datos adicionales por columnas. Permite que los datos en vez de pedirse uno debajo de otro se puedan colocar como filas y columnas.
  • Reasignación de petición al realizar un cambio de estado. Permite que al pulsar en el botón de cambio de estado (Aceptar, Pasar a en curso, Pdte de dirección, etc.) se pida que se indique la reasignación a otro/s responsable/s. Así se facilita el flujo de peticiones entre los distintos responsables.


21/03/2013

  • Posibilidad de añadir un botón en la petición donde al pulsar se indica una o varias direcciones de correo a las que enviarle la información de la petición por email. Buena opción cuando queremos enviar la información a alguna cuenta que no está en el gestor.
  • Para evitar que los usuarios creen varias peticiones repetidas como ocurre a veces, ahora al pulsar el botón de "Crear", en "Nueva petición", éste se deshabilita mientras la orden se procesa, para que no puedan pulsarlo varias veces seguidas y crear varias peticiones iguales.

02/10/2012

  • Ahora se pueden obtener las estadísticas en CSV para exportar a Excel.
  • Los avisos periódicos pueden especificarse que sean solo para un número limitado de veces.
  • Creación de peticiones desde correo, de manera que cuando el usuario escriba a una determinada dirección se cree la petición automáticamente.
     

29/03/2012

  • Ahora se puede capturar, para el servicio que lo solicite, el DNI del peticionario (en caso de ser de la UMA).
  • Se pueden definir flujos de estados independientes según el tipo de la petición. Así podríamos hacer que fuese más corto o más largo según el tipo.

 

27/02/2012

  • Añadida la opción de no tener en cuenta determinados estados para las estadísticas, por ejemplo las denegadas (desde el 23-feb).
  • He eliminado el concepto de "subtipo", ahora se van eligiendo tipos anidados sin número mínimo ni máximo de anidamientos. Ya no dice "Tipo", "Subtipo" sino que se selecciona un número determinado de tipos. Así, se puede tener un solo tipo para algunos casos, tres niveles para otros, etc.

 

20/01/2012

Mejoras:

  • Nuevo tipo desplegable múltiple como posible "dato adicional". Pedido por Conserjerías.
  • Nuevo tipo check como posible "dato adicional". 
  • Ahora cuando se produce algún error en la introducción de los datos del formulario de "nueva petición" se mantienen todos los datos que el usuario hubiese introducido. Pedido por Conserjerías.

Correcciones:

  • Un problema por el que los "datos adicionales" no se mostraban en Internet Explorer. Detectado en el gestor de CTI y Conserjerías.
  • Los "datos adicionales" aparecían en orden inverso al introducido en la descripción de la petición. Detectado en el gestor de Conserjerías.
Después del cuerpo del contenido