Sommario
Categorie, Ambiti e Sottoambiti
La categoria è un contenitore di ambiti appartenenti alla stessa area
Ad esempio nel caso fosse necessario avere supporto sul processo di Immatricolazione, sarà SERVIZI STUDENTI E DIDATTICA
L’ambito è a sua volta un raggruppamento di sottoambiti che hanno la stessa attinenza
Seguendo l’esempio precedente l’ambito è SD Segreteria studenti.
Il sottoambito è a sua volta un raggruppamento ben definito di funzionalità che costituiscono, nel loro insieme, un flusso operativo che trova riscontro in un processo specifico.
In questo caso, sempre proseguendo nell'esempio, il sottoambitorelativo al processo è Immatricolazione che raggrupperà diverse funzionalità quali la registrazione dell’anagrafica, la scelta del corso di studi, la dichiarazione dei titoli di accesso, la preimmatricolazione e l’immatricolazione definitiva.
L’utente che accede al Customer Portal potrebbe non trovare direttamente il prodotto o il servizio a lui noto ma deve specificare il processo sul quale effettuare la richiesta specificando ambito e sottoambito.
Il valore aggiunto dell’approccio per ambito è quello di superare il concetto di prodotto con l’obiettivo ultimo di gestire al meglio i ticket così detti “di integrazione” cioè segnalazioni di errore che si manifestano su un' interfaccia ma che sono causati da un motore che risiede su un applicativo diverso da quello a cui l’interfaccia appartiene.
Macro tipologia e Tipologia
In fase di inserimento l’utente dovrà scegliere la macro tipologia di ticket che intende sottomettere. Le tre principali macro tipologie di ticket sono:
- Anomalia (errore o incidente)
- Richiesta (nuova implementazione, consulenza, modifica di configurazione o interventi specifici per esempio sui dati)
- Chiarimento (assistenza funzionale )
L’utente sarà supportato nella scelta della tipologia attraverso delle descrizioni esemplificative.
Ad ogni macro tipologia corrispondono delle tipologie che hanno lo scopo di chiarire al meglio il tipo di lavorazione che il ticket dovrà avere. Nel caso in cui la scelta della macro tipologia/tipologia non sarà conforme al contenuto del ticket, l’operatore potrà modificarla in fase di lavorazione.
Ad ognuna delle tre macro tipologie corrisponde un workflow predefinito.
Le possibili coppie di macro tipologie e tipologie sono:
Macto Tipologia | Tipologia |
|---|---|
Anomalia | Anomalia software/funzionale |
Anomalia infrastrutturale | |
Richiesta | Richiesta evolutiva |
Richiesta di modifica dati | |
Richiesta di estrazione dati | |
Richiesta di configurazione | |
| Consulenza | |
Chiarimento | Assistenza funzionale |
Assistenza tecnica |
Gravità, Urgenza e Priorità
In fase di inserimento del ticket, l’utente specifica con due campi distinti il livello di gravità ed urgenza. Sono previsti 4 livelli di gravità:
- Blocker (Bloccante)
- Critical (Alta)
- Medium (Media)
- Trivial (Bassa)
L’urgenza prevede invece l'indicazione:
- Urgente
- Non Urgente
La combinazione delle due informazioni determina la priorità interna di evasione del ticket secondo la seguente tabella
Gravità | Urgenza | Priorità |
|---|---|---|
Bloccante | Urgente | Red Code |
Bloccante | Non Urgente | Very High |
Alta | Urgente | Very High |
Alta | Non Urgente | High |
Media | Urgente | High |
Media | Non Urgente | Medium |
Bassa | Urgente | Medium |
Bassa | Non Urgente | Low |
Tracciatura delle regressioni
In caso di ticket di tipo Anomalia, è possibile indicare se la segnalazione è percepita come una regressione.
Tale indicatore potrà essere modificato dall’operatore che lavora il ticket al termine delle azioni relative alla diagnosi dello stesso. Verrà mantenuta traccia nell’history della modifica del valore che assume il campo.
Data di fabbisogno
In caso di ticket di tipo Richiesta, è necessario indicare una data di fabbisogno ovvero la data entro cui l'utente desidera che la richiesta venga completata.
Tale indicatore è importante nel caso di richieste che portano alla creazione di requisiti cliente in quanto entrano in gioco nella determinazione della data di prevista consegna.
Workflow di un ticket
Il workflow generico di un ticket prevede i seguenti stati:
APERTO Rappresenta lo stato di partenza di un ticket. L’operatore lo prende in carico (Start Investigating) ed il ticket passa in ATTESA SUPPORTO ATTESA SUPPORTO In questo stato il ticket è in carico all'operatore. L’operatore può fornire una risposta a suo parere esaustiva (Resolve this Issue) passando il ticket allo stato RISOLTO, oppure può chiedere informazioni aggiuntive all’utente che ha inserito il ticket (Request for Customer) mettendo il ticket in stato ATTESA CLIENTE. ATTESA CLIENTE In questo stato si è in attesa della risposta da parte del cliente. Se il cliente commenta il ticket questo passa nello stato ATTESA SUPPORTO. Se il cliente non risponde al ticket dopo10gg viene inviata una notifica che ricorda che la segnalazione è in attesa di risposta. Se dopo altri 10 gg non è ancora stato inserito nessun commento, il ticket passa automaticamente nello stato RISOLTO con l'invio di un messaggio di cortesia. IN LAVORAZIONE (Solo per Anomalie e Richiesta) In questo stato il ticket è in attesa che un intervento sul prodotto venga completato. Quando l'intervento viene completato e la verione che lo contiene viena installata il ticket passa nello stato RISOLTO. RISOLTO Questo stato determina una pre-chiusura. L’utente può commentare il ticket nel caso in cui non sia d’accordo con la pre-chiusura, riportandolo nello stato ATTESA SUPPORTO. Se non viene inserito nessun ulteriore commento nel segnlazione, dopo 10gg questa passa automaticamente in stato CHIUSO. CHIUSO E' uno stato terminale del ticket. In questo stato non è possibile riaprire o modificare il ticket. |
