Impara con un Esempio

Questa pagina presenta alcuni esempi di flussi di lavoro principali. Per conoscere i flussi di lavoro principali in dettaglio, vai prima a Come funzionano?.

Fondamenti

Tutti gli esempi di flussi di lavoro principali di seguito sono configurati nello stesso sistema. Rispetto a un’installazione fresca di Zammad, il sistema ha alcuni gruppi aggiuntivi e alcuni attributi oggetto personalizzati che puoi trovare negli esempi rispettivi. Considera questi esempi come ispirazione e adatta i flussi di lavoro ai tuoi processi.

Campi Basati sul Gruppo

Spesso, team diversi (come vendite, supporto o secondo livello) necessitano di flussi di lavoro leggermente diversi per gestire efficacemente i ticket. I flussi di lavoro basati sui gruppi ti consentono di personalizzare l’esperienza del ticket definendo i campi visualizzati, l’input richiesto e le opzioni disponibili in base al gruppo assegnato al ticket.

Problema/scenario

Quando un ticket viene creato o spostato nel gruppo 2nd Level, il campo categoria deve essere limitato, alcuni campi devono essere mostrati e campi specifici sono obbligatori per avere tutte le informazioni pertinenti per il supporto di secondo livello presenti nel ticket.

Configurazione del flusso di lavoro

Area	Configurazione	Nota
Oggetto	Ticket
Contesto	Maschera di creazione Maschera di modifica
Condizioni selezionate	Gruppo è 2nd Level
Condizioni salvate		Non utilizzato perché l’interfaccia utente deve cambiare immediatamente quando il gruppo è impostato su 2nd Level.
Azione	Categoria mostra Categoria imposta fisso a 2nd Level (e tutte le sottocategorie) Sistema Operativo e Software utilizzato mostra Sistema Operativo e Software utilizzato imposta obbligatorio

Configurazione nell’interfaccia utente

Processo di Approvazione

In molte organizzazioni, è richiesta un’approvazione per avviare processi successivi. Questa approvazione è solitamente limitata a un gruppo specifico di persone per garantire che tutti i requisiti per il processo successivo siano soddisfatti.

Problema/scenario

L’approvazione di un problema del cliente può essere effettuata solo da utenti con il ruolo Persona di Approvazione. Finché questa approvazione non è stata effettuata, il valore deve essere impostato fisso su no, a meno che la persona di approvazione non visualizzi il ticket.

In base allo stato di approvazione, possono essere stabiliti processi di automazione aggiuntivi (ad es. un trigger per aumentare la priorità o assegnare un agente specifico).

Configurazione del flusso di lavoro

Area	Configurazione	Nota
Oggetto	Ticket
Contesto	Maschera di creazione Maschera di modifica
Condizioni selezionate	Ruolo non è Persona di Approvazione	Verifica se il ruolo non è Persona di Approvazione per modifiche non salvate nel ticket.
Condizioni salvate	Approvato non è yes	Verifica se l’approvazione non è ancora impostata su yes.
Azione	Approvato imposta fisso a no	Impedisce modifiche quando le condizioni sopra sono soddisfatte.

Configurazione nell’interfaccia utente

Imposizione della Categorizzazione dei Ticket

Per avere numeri convincenti per le tue statistiche, può essere una buona idea imporre che determinati attributi vengano popolati prima che il ticket possa essere chiuso.

Problema/scenario

Il campo Categoria deve essere impostato come obbligatorio se un agente vuole impostare gli stati chiuso o in attesa di chiusura per imporre la categorizzazione.

Configurazione del flusso di lavoro

Area	Configurazione	Nota
Oggetto	Ticket
Contesto	Maschera di creazione Maschera di modifica
Condizioni selezionate	Stato è chiuso o in attesa di chiusura	Condizione selezionata perché deve essere controllata prima che le modifiche vengano salvate.
Azione	Categoria imposta obbligatorio

Configurazione nell’interfaccia utente

Procedura di Consegna Ticket

Una consegna da un agente all’altro potrebbe richiedere più di un semplice cambio di proprietario. A seconda del problema o del processo, può essere molto utile che l’agente originale lasci una piccola nota in modo che il nuovo agente sappia immediatamente qual è il motivo della consegna e da dove iniziare.

Problema/scenario

Gli agenti devono scrivere un piccolo commento quando vogliono cambiare il proprietario del ticket. Esiste un attributo ticket personalizzato chiamato Handover in cui può essere inserito un testo. Questo campo è nascosto per impostazione predefinita (Flusso di lavoro 1) e appare solo quando il proprietario cambia. Inoltre, deve essere impostato come obbligatorio in tal caso (Flusso di lavoro 2).

Poiché il campo è nascosto dopo aver salvato la modifica del proprietario del ticket, il testo del campo deve essere scritto nel ticket come articolo tramite un trigger. Altrimenti, il nuovo agente non lo vedrebbe affatto.

Configurazione del flusso di lavoro

Workflow 1Workflow 2Trigger

Questo flusso di lavoro nasconde il campo in generale. Si prega di notare la priorità inferiore che indica a Zammad di eseguire prima questo flusso di lavoro.

Area	Configurazione	Nota
Oggetto	Ticket
Contesto	Maschera di creazione Maschera di modifica
Condizioni selezionate		Nessuna condizione necessaria, perché dovrebbe essere sempre nascosto.
Condizioni salvate		Nessuna condizione necessaria, perché dovrebbe essere sempre nascosto.
Azione	Handover nascondi

Configurazione nell’interfaccia utente

Workflow 1Workflow 2Trigger

Di conseguenza, il ticket include un articolo di tipo nota che contiene il testo predefinito e il commento di consegna.