Tipificación de Incidencias

Introducción.

Este documento tiene por objetivo describir el proceso de creación, tipificación y seguimiento de issues que van a trabajarse bajo el el concepto de "Tech Data Support". El mismo surge de la fusión entre los tableros Tech Support (ST) y Audiencies & Report Support (ARS). Los responsables primarios según el tipo de incidencia serán Gabriel Dominguez y Mathias Longo quienes asignaran a responsables secundarios si se necesitaran y establecerán que los requisitos para la resolución se cumplan como así también los tiempos de demora en cada caso.

De esta manera se determinará un proceso sencillo que le permita:

1. Establecer tiempos de gestión según origen y prioridad.
2. Establecer escala de responsabilidad y seguimiento.
3. Brindar información concisa al usuario / cliente.

Flow de Proceso.

• Tablero Tech Data Support.

1. Pending: Instancia de parking en donde los issues creados serán revisados por el responsable primario, el cual verificará:

- Tipificación.

- Criterios de aceptación (ver "Tipificación de Issues")

- Asignación.

En caso de encontrar falta de información se solicitará al informador que complete la ficha. Esto modificará los tiempos estipulados para la resolución. Si el issue esta derivado de forma incorrecta, se procederá a recategorizar y derivar a un nuevo responsable primario.

1. Diagnostic: Parking de trabajo para issues que fueron aceptadas por el responsable primario (cumplieron los requisitos) pero han sido derivadas a otro miembro del equipo (responsable secundario).
2. In Progress: Issues que se encuentran en instancia de ejecución / trabajo.
3. Populating: En caso que el issue requiera ingesta de data para una audiencia o segmento, quedara en esta columna mientras el proceso se cumple.
4. Sprint: Issues que requieran desarrollos o tareas a cumplir por el/los desarrolladores que sean asignados. La incidencia permanecerá en esta columna mientras ese proceso este corriendo o enlazarse con tareas de otros tableros si así correspondiera.
5. Review: Issues solucionados que deben tener una validación por parte del usuario informador, previo a su cierre. En caso de no tener acciones en esta instancias, la incidencia procederá a cerrarse posterior a los 3 días hábiles.
6. Done: Issues que poseen un resultado satisfactorio de trabajo.

Se utilizarán dos niveles de prioridad, highest y medium. Tomando en cuenta los tiempos de gestión establecidos para cada issue, esta segmentación posibilitará una gestión ordenada de los pendientes.

El "Informante" puede modificar el alcance de la tareas sin alterar los tiempo de resolución, en las instancias 1 y 2. En caso de ampliar el alcance en la instancia 3, los tiempos de resolución pueden ser modificados según el análisis que realice el "Responsable" asignado.

No se admiten modificaciones que alteren el alcance de la tarea, cuando ésta se encuentra en las instancias 4 y 5, por lo cual se deberá proceder a la apertura de un issue nuevo.

Tipificación de Issues.

Todo issue deberá ser encuadrado bajo un modelo, el cual contará con un esquema de criterios de aceptación necesarios con el objeto de poder proceder a resolver la tarea en los tiempos estimados.

1. Taxonomía.

-Archivo de taxonomía (2. Definición de taxonomía).

-Data provider (cient id).

-Plataforma/s.

-Precio/s.

1. Activaciones. Procesos de creación de segmentos y visualización de alcance.

-Client id.

-Segment id/s.

-Plataforma/s.

1. Licencias. Proceso de empujar un segmento / audiencia a las plataformas disponibles. Disponibilidad de audiencias y segmentos en plataformas. Revisión de licencias con errores.

-Plataforma/s. Indicar la/s plataforams a las cuales se quiere licenciar.

-Retargetly segment id.

-Seat id.

-Client id.

-Partner id. Requisito para DV360.

1. Data-In. Proceso de alta e ingesta de datos por medio de dispositivos S3 / SFTP / AWS.

(3. Ingesta de archivos de data)

• Creación de un Nuevo SFTP.

-Data provider

-Id Cleinte

-Tipo (sftp / aws)

• SFTP nuevo o existente?

- SI / NO

• Cargar credenciales

SFTP:

- usuario

- Contraseña / key

- host

- carpeta donde van a tirar los archivos

AWS:

- secret access key

- access key id.

- name.

- región.

- carpeta donde van a tirar los archivos.

• Si se debe habilitar ingesta automática:

- Estimado de la cantidad de data (cantidad de usuarios por mes).

- Prioridad del cliente.

- Frecuencia (mensual / esporádica). Ej = startapp (taxo general / custom).

- Archivo encriptado (key pública).

1. Reportes & Insights. Reporte solicitados a través de la sección en el DMP. Discrepancias detectadas en las métricas expuestas en la sección insights del DMP.

-Client id.

-Reporte Solicitado.

-Tipo de Reporte (Grupal / Individual).

-Retargetly segment id. Únicamente para los reportes de tipo individual.

1. Error.

Ficha genérica que permite detallar toda issue que no encuadre dentro de las categorías disponibles.

1. Taggeo. Revisión de los tags en sources del cliente o errores relacionados a la implementacion del pixel de Retergetly

-URL's afectadas

-Client Id

-Mensajes de error si los hubiera

-Segmentos afectados

1. Planner DMP. Revisión de inconvenientes con la cantidad de devices para uno o un grupo de segmentos y comparación con el estimado del planner.

Debe tenerse en cuenta la diferencia entre los datos que se muestran en el planner del DMP y el listado que se ve a la hora de crear el segmento. Para revisar posibles problemas:

-Segmentos a revisar

-Client Id

1. CRM. Revisión de inconvenientes utilizando este tipo de data source

-Client Id

-Archivo que se cargó/se quiere cargar (si el tamaño del archivo supera el limite se procederá a la resolución del issue)

1. Nueva Audiencia Creación de una nueva audiencia

-Nombre de la audiencia

-País

1. Popular segmento. Incorporación de devices a un segmento

-Segment Id

-País

1. Otro. Incidencia o issue que no haya sido especificado en el listado

Cualquier información relevante para el caso a verificar.

Cuadro de Responsables.

Cabe aclarar que pueden asignarse otros responsables si se necesitaran para la resolución del issue.

Los tk que se consideren resueltos pasaran a la columna DONE para archivarse posteriormente. En caso que el issue no haya sido resuelto o se siga presentando puede retomarse. Si se presentara una incidencia similar o una tarea derivada, debe generarse un nuevo ticket que puede relacionarse con el primero y de esta manera se resolverá por separado para no afectar el tiempo de resolución del issue original.

(Ejemplo dentro de un ticket ya creado)

(Ejemplo dentro de un ticket a crear)

Se les solicitara a los informantes de las incidencias que completen una pequeña encuesta de satisfacción antes de cerrar el issue. La misma deberá responderse puntuando del 1 al 5 (1 es el valor mas bajo y 5 el mas alto) y formara parte de los campos que configuran cada incidencia. Es importante que se evalúe la atención de la manera mas sincera posible para que podamos mejorarla de ser necesario modificando los aspectos bajos.