Avisos múltiples e incidencias colectivas

Marca las filas en la lista de tickets y pulsa «Multiple report». El botón se puede usar a partir de dos filas marcadas.

El diálogo pregunta primero: «Which ticket stays?» El ticket más antiguo viene preseleccionado, de modo que el plazo corre desde el primer contacto de quien solicitó y no desde su segundo intento. Puedes elegir otro.

Debajo consta la dirección con ambos números: «#11 will be closed and moved into #10.» Así, antes del clic queda claro qué ticket se queda.

Todo viene con él: comentarios, adjuntos y la descripción del segundo aviso. La descripción se convierte en un comentario del original, con su autor y su fecha originales. El diálogo indica las cifras de antemano.

El tiempo registrado se traslada, no se copia. De lo contrario, el mismo esfuerzo estaría en dos tickets y se facturaría dos veces.

El segundo aviso no se borra. Se cierra y a partir de entonces apunta al original, y su número sigue siendo válido.

Quien solicitó no recibe un correo aparte. Está en el original y ahí lo ve todo. El aviso cerrado lleva un comentario que nombra el original y que puede leer.

No hay deshacer. Por eso todo consta en el diálogo antes de que pulses «Merge».

Después, el historial de ambos tickets registra quién fusionó qué y cuándo.

Quien solicitó tiene el número de ticket antiguo en su buzón. No sabe nada de que se hayan fusionado dos avisos y responde al correo que tiene.

Esa respuesta llega al original. El sistema sigue la referencia que lleva el aviso cerrado.

Por eso un aviso fusionado no se borra nunca. Sin él no existiría la referencia y la respuesta no llegaría a ninguna parte.

Quien participó en el aviso antiguo puede escribir también en el original. La comprobación se hace sobre el ticket nombrado en el correo.

Si seleccionas tickets de personas distintas, el diálogo no los toma. Nombra cada fila rechazada y su motivo antes de que pulses.

El motivo dice: «Different requester — this is an incident, not a multiple report.» Y además te indica adónde ir en su lugar.

Este es el guardián más importante de toda la función. Si fusionaras treinta avisos de treinta personas, veintinueve perderían su ticket y no volverían a saber nada.

Quién solicita lo decide primero la dirección de correo del ticket. Si no la hay, decide un nombre ajeno en el campo «User», y el mismo nombre cuenta como la misma persona. Si no, cuenta la cuenta que creó el ticket.

Por eso el guardián vale también para las llamadas. Si un agente registra dos llamadas, ambos tickets los creó él. Aun así, quienes llamaron siguen siendo personas distintas, porque sus nombres están en el campo.

Si en un lado no se puede determinar quién solicita, también se rechaza. Desconocido no es lo mismo que la misma persona.

En ese mismo recuadro aparecen más motivos. Una incidencia colectiva no se puede fusionar. Un original cerrado ya no admite nada. Y un aviso que ya tiene avisos propios no viene, para que no se formen cadenas.

Cuando cae el servidor de archivos, veinte personas avisan. Cada uno de esos avisos es un caso propio con su propia persona solicitante. Aquí fusionar sería un error, porque diecinueve personas perderían su ticket.

Marca los avisos y pulsa «Group into incident». El diálogo ofrece tres vías: añadirlos a una incidencia colectiva ya abierta, declarar incidencia colectiva a uno de los tickets seleccionados, o crear una incidencia colectiva nueva con su propio título.

Si el equipo ya tiene una incidencia colectiva abierta, esa vía viene preseleccionada. Es la más habitual: la avería se conoce desde hace rato y lo único que sigue llegando son avisos nuevos.

Cada ticket enlazado conserva a quien solicitó, su estado y su propio plazo. No desaparece nada. La incidencia colectiva solo agrupa la respuesta.

Todos los avisos de una incidencia colectiva tienen que pertenecer al mismo equipo. Si una avería afecta a dos equipos, cada uno recibe su propia incidencia colectiva. De lo contrario, la resolución de un equipo vaciaría la cola del otro.

También puedes enganchar a los rezagados desde el ticket individual. Si el equipo tiene una incidencia colectiva abierta, arriba aparece una indicación con «Assign» y «Not related». El sistema no engancha nunca nada por su cuenta: un ticket mal enganchado recibiría una resolución que no le concierne y se cerraría de paso.

El ticket de incidencia colectiva indica cuántos avisos tiene enganchados. A su vez, los tickets enlazados llevan el número de su incidencia colectiva, en la lista y en la tarjeta de la derecha.

«Resolve incident» cierra la incidencia colectiva y responde a todos los avisos de una vez. El texto de la resolución es obligatorio: es todo el sentido de la función, porque va a todas las personas afectadas.

Cada ticket enlazado recibe el texto como comentario público, pasa al estado elegido y quien solicitó recibe su propio correo. Sin correo colectivo, porque eso expondría las direcciones de todas las personas afectadas.

El mensaje posterior indica cuántos tickets se cerraron y a cuántas personas se avisó. Ambas cifras van por separado, porque un ticket sin una dirección alcanzable recibe un comentario y un estado, pero ningún correo.

Un ticket que hayas respondido y cerrado tú mismo mientras tanto no se toca. No se cierra por segunda vez ni se le vuelve a escribir.

Mientras cuelguen avisos abiertos de una incidencia colectiva, esta no puede cerrarse mediante el cambio de estado normal. De lo contrario, veinte personas se quedarían en silencio sin respuesta.

Tanto el diálogo como el ticket de incidencia colectiva llevan la casilla «Also show as a banner on the sign-in page». Con ella, todo el mundo se entera de la avería antes de escribir otro ticket.

La banda está en la página de inicio de sesión y dentro del sistema una vez dentro. Nombra «Known incident» y el título de la incidencia colectiva, así que ese título es un texto para clientes.

Si hay varios avisos activos, se colocan uno debajo de otro. Un mantenimiento anunciado para el sábado no desplaza la avería de hoy, ni al revés.

Si alguien crea igualmente un ticket nuevo, la respuesta automática nombra la incidencia colectiva. Eso vale tanto para un ticket ya enlazado como para cada ticket nuevo de ese equipo, mientras la incidencia colectiva esté abierta y anunciada. Esto necesita el envío de correo.

Cuando la incidencia colectiva se resuelve, la banda desaparece sola. Nadie tiene que acordarse de apagarla.

En la página «Maintenance and incident notices» puedes ver qué incidencia colectiva se está mostrando ahora mismo como banda. El interruptor de esa página pertenece al mantenimiento planificado y no se aplica a las incidencias colectivas.