ISP Billing Documentazione ISP Billing
English Torna al sito
Comunicazioni e assistenza

Ticket e assistenza

Manuale operativo per ricevere, classificare, lavorare, comunicare e chiudere le richieste di assistenza.

Ultimo aggiornamento: 2026-08-19

Ruolo del modulo Ticket

Il modulo Ticket riunisce le richieste provenienti da Area Clienti, ISP APP, e-mail e WhatsApp in un flusso unico. Ogni ticket conserva il richiedente, il canale di origine, il dipartimento, l’oggetto, la priorità, lo stato, la cronologia, gli allegati e gli eventuali collegamenti a cliente, servizio, articolo e operatore.

Un ticket non è soltanto un messaggio: è una pratica operativa. L’ISP deve poter distinguere cosa attende una presa in carico, cosa ha già ricevuto risposta, cosa richiede un nuovo intervento e cosa è concluso.

Accesso e permessi

Dal menu laterale apri Modulo Ticket e scegli Lista ticket oppure Crea ticket. Il codice applica un permesso di lettura alle pagine e alle consultazioni; modifica, assegnazione, chiusura, eliminazione e configurazione richiedono il permesso di scrittura del modulo.

La presenza del menu non autorizza automaticamente ogni azione. Ruoli di sola consultazione possono leggere ticket e PDF senza poter cambiare dati o stato.

Lista ticket e aggiornamento

La lista dichiara che i nuovi ticket vengono scaricati automaticamente ogni tre minuti. Scarica nuovi ticket manualmente forza il controllo delle caselle configurate e restituisce un riepilogo per dipartimento con connessione, messaggi trovati, importati, saltati e bloccati dalla blacklist.

Usa il controllo manuale per una verifica motivata, non come sostituto del processo pianificato. Un errore di connessione IMAP va risolto nella configurazione del dipartimento.

Lista amministrativa dei ticket
La lista combina stato, priorità, oggetto, cliente o mittente, dipartimento e ultima risposta.

Filtri, ricerca e origine

I filtri di stato comprendono Aperti, In lavorazione, Risposti dall’ISP, Risposti dal cliente, In lavorazione con nota interna e Chiusi. È possibile filtrare anche priorità, oggetto, cliente o mittente e dipartimento. La scelta degli stati viene conservata localmente dal browser.

Il cliente può essere identificato da anagrafica oppure dal mittente esterno. Le etichette di origine distinguono E-mail, WhatsApp, Area clienti e ISP APP; questa informazione è essenziale per capire come rispondere e quali recapiti siano disponibili.

Stati e significato operativo

  • Aperto: nuova pratica che richiede valutazione.
  • In lavorazione: un operatore ha iniziato a gestirla.
  • Risposto dall’ISP: l’ultima risposta utile è stata inviata dall’operatore.
  • Risposta del cliente: il cliente ha aggiunto informazioni e la pratica torna all’attenzione dell’ISP.
  • In lavorazione con nota interna: esiste un aggiornamento non destinato al cliente.
  • Chiuso: la conversazione è conclusa e può essere riaperta se necessario.

Gli stati descrivono chi deve compiere la prossima azione; non vanno usati come semplici etichette estetiche.

Priorità e selezione multipla

Le priorità disponibili sono Alta, Media e Bassa. Nel dettaglio la priorità può essere cambiata e salvata separatamente. Assegna Alta solo quando impatto e urgenza lo giustificano, così la coda resta affidabile.

La lista consente di selezionare più ticket per le azioni collettive previste, tra cui unione, chiusura ed eliminazione. Prima di un’azione multipla ricontrolla identificativi e clienti: unire o eliminare pratiche sbagliate compromette lo storico.

Ticket proveniente dall’Area Clienti

Un ticket aperto dall’Area Clienti compare nell’amministrazione con il cliente autenticato, l’eventuale servizio selezionato, il dipartimento destinatario e il canale Area Clienti. La cronologia conserva il messaggio iniziale e tutte le successive risposte inviate dal portale.

Se il cliente chiude la pratica, il dettaglio amministrativo mostra lo stato Chiuso e la relativa data. Operatore e cliente consultano così la stessa conversazione, pur disponendo di azioni e informazioni coerenti con i rispettivi permessi.

Dettaglio amministrativo del ticket aperto dall’Area Clienti
Il dettaglio collega conversazione, cliente, servizio, dipartimento, canale e stato.

Testata e collegamenti del ticket

L’operatore può modificare oggetto, servizio e articolo associato senza alterare i messaggi già registrati. I collegamenti devono rappresentare il caso reale: il servizio identifica la linea coinvolta, mentre l’articolo individua un apparato o bene assegnato.

Aggiungi come Attività su Calendario trasforma il seguito in un impegno pianificato. Lista ticket torna alla coda; Stampa ticket produce una rappresentazione PDF della pratica.

Rispondere al cliente

Scrivi il messaggio nell’editor e aggiungi soltanto allegati pertinenti. Prima di inviare controlla i destinatari abilitati: il pannello mostra separatamente e-mail e WhatsApp e consente di deselezionare i contatti che non devono ricevere l’aggiornamento.

Invia risposta al cliente registra il messaggio e attiva i canali configurati. Una risposta predefinita può accelerare testi ricorrenti, ma deve essere adattata al caso. ISPINO può proporre una bozza: l’operatore resta responsabile della verifica prima dell’invio.

Note interne e tag dei colleghi

Salva nota interna registra un aggiornamento visibile agli operatori ma non al cliente. Il testo può usare @ per richiamare un collega; la lista mostra gli account taggati quando il ticket assume lo stato con nota interna.

Non inserire in una nota informazioni eccedenti o non necessarie. Prima di premere un comando, distingue sempre risposta esterna e nota interna: inviare al cliente un testo operativo interno può esporre dati o istruzioni riservate.

Presa in carico e assegnazione

La presa in carico imposta il ticket In lavorazione e registra l’account che lo sta gestendo, riducendo il rischio di lavoro duplicato. I dipartimenti possono avere operatori assegnati e il dettaglio mostra chi ha iniziato la lavorazione.

Cambia dipartimento trasferisce la pratica alla squadra competente. Cambia cliente collega un mittente non riconosciuto o corregge l’associazione; il codice prevede anche assegnazione a fornitore e rimozione dell’associazione cliente.

Notifiche differite e annullamento

Alcune notifiche agli operatori vengono preparate come elementi pendenti per evitare invii immediati non necessari o per rispettare il flusso del ticket. Nel dettaglio, quando previsto, Annulla notifica rimuove la notifica ancora pendente senza cancellare il messaggio o il ticket.

Prima di annullare identifica destinatario, evento e stato. Un invio già consegnato non può essere richiamato; l’annullamento agisce soltanto sull’elemento non ancora elaborato.

Bozza ISPINO e impostazioni dell’assistente

Il comando di generazione legge la cronologia completa dal messaggio più vecchio al più recente, distingue cliente e ISP ed esclude le note interne. La bozza deve rispondere all’ultima richiesta ancora aperta e non può trasformare la ricezione di una domanda in una presa in carico, lavorazione o risoluzione già avvenuta.

Risposta risolutiva conferma un esito soltanto quando un messaggio dell’ISP lo attesta esplicitamente; in caso contrario produce un testo prudente che comunica la ricezione e la successiva verifica. Presa in carico e Richiesta informazioni mantengono lo stesso vincolo sui fatti. Le bozze ticket non mostrano immagini del manuale.

Il testo rimane una bozza: rileggi fatti, tono, destinatari, allegati e azioni promesse prima di inviarlo. Le impostazioni dell’assistente richiedono permessi adeguati; non inserire chiavi o dati riservati per migliorare la risposta.

Chiusura, riapertura ed eliminazione

La chiusura conclude la pratica; quando sono configurati pacchetti o tempi di assistenza può essere disponibile una chiusura con registrazione del tempo di servizio. Un ticket chiuso conserva cronologia e PDF e può essere riaperto.

Eliminare è diverso da chiudere: rimuove la pratica secondo il comportamento applicativo e deve essere riservato a duplicati o dati creati per errore, con i permessi previsti. Per lo storico ordinario usa Chiuso.

Creare un ticket dall’amministrazione

Crea ticket parte dalla scelta del cliente. Dopo la selezione vengono caricati i dati utili per dipartimento, servizio, oggetto, messaggio, destinatari e allegati. Il ticket creato dall’operatore viene marcato come tale nella lista.

Se il contatto non appartiene a un cliente, valuta il percorso e-mail o l’associazione successiva. Non creare anagrafiche duplicate soltanto per aprire una richiesta.

Pagina di creazione ticket dall’amministrazione
La creazione amministrativa inizia dalla selezione del cliente interessato.

Dipartimenti e caselle IMAP

Ogni dipartimento definisce nome interno, nome mostrato nei messaggi ed e-mail. La casella IMAP è facoltativa; se si inizia a configurarla, host, porta, username e password devono essere completati e la connessione viene verificata al salvataggio. Le porte proposte sono 993 SSL/TLS e 143 non sicura.

Visibile in Area Clienti determina se il reparto può essere scelto dal portale. Auto-risponditore invia la conferma di ricezione. È inoltre possibile scegliere lo SMTP per le risposte, assegnare operatori e definire la firma.

Configurazione dei dipartimenti Ticket
Identità, ricezione IMAP, visibilità, SMTP, operatori e firma compongono il dipartimento.

Mittente predefinito e indirizzi del modulo

Oltre allo SMTP generale, la configurazione conserva l’indirizzo e-mail predefinito usato dove un evento non dispone di un mittente più specifico. Dipartimento, SMTP e indirizzo visibile devono essere coerenti per evitare risposte a un account non monitorato.

Prima di salvare controllare nome mittente, dominio, capacità di ricezione e instradamento delle risposte. Un indirizzo valido sintatticamente non prova che la casella venga letta o che SPF, DKIM e reputazione siano corretti.

Impostazioni generali e chiusura automatica

La scheda Impostazioni sceglie lo SMTP predefinito del modulo. L’opzione Chiudi ticket senza risposta del cliente offre Mai, dopo 48 ore e dopo 72 ore: riguarda ticket che attendono il cliente e viene applicata dal processo pianificato.

La configurazione prevede anche l’abilitazione globale delle notifiche WhatsApp Meta agli operatori. Se disabilitata, la scelta relativa non appare nei profili operatore e gli invii vengono bloccati a monte.

Impostazioni generali del modulo Ticket
SMTP e politica di chiusura automatica influenzano tutte le pratiche del tenant.

Blacklist e protezione dall’importazione

La Blacklist contiene indirizzi e-mail i cui messaggi vengono eliminati per impostazione predefinita durante l’importazione. Va usata per mittenti indesiderati accertati, non per nascondere reclami o problemi ricorrenti.

Prima di aggiungere un indirizzo verifica che non sia condiviso da più clienti o sistemi legittimi. Il controllo manuale delle caselle riporta quante e-mail sono state intercettate dalla blacklist.

Blacklist e-mail del modulo Ticket
La blacklist agisce a monte sulla trasformazione delle e-mail in ticket.

Risposte predefinite

Le risposte predefinite sono organizzate in categorie. Prima crea una categoria, poi aggiungi le risposte riutilizzabili. Nel dettaglio ticket il comando Risposte Predefinite permette di inserire una bozza nell’editor.

Questi contenuti devono rimanere generici, aggiornati e privi di credenziali. L’inserimento non equivale all’invio: personalizza e ricontrolla sempre destinatari e allegati.

Categorie e risposte predefinite Ticket
Categorie e testi riutilizzabili riducono i tempi senza eliminare la verifica dell’operatore.

Template multicanale e variabili

I template automatici coprono apertura al cliente, apertura da WhatsApp, nuova risposta del cliente, chiusura, notifica di nuovo ticket agli operatori e nuova risposta agli operatori. Ogni evento può avere contenuti per E-mail, SMS, WhatsApp e ISP APP.

I tag disponibili includono nome cliente, numero ticket, oggetto, dipartimento, messaggio, URL, operatore, firma e avviso allegati non validi. WhatsApp Meta usa template approvati e mostra un’anteprima; se non si salva un override, resta attivo il testo predefinito.

Template multicanale delle notifiche Ticket
Eventi, canali e variabili devono produrre messaggi coerenti senza esporre dati non necessari.

Automazioni e canali

Il cron Ticket viene eseguito da script CLI: importa nuove e-mail e può chiudere automaticamente le pratiche in attesa secondo la soglia configurata. La precedente route HTTP risulta disattivata nel codice. Area Clienti, ISP APP ed e-mail convergono nello stesso modello di ticket.

Gli invii dipendono dalle preferenze dei contatti e degli operatori, dagli account assegnati al dipartimento e dalla disponibilità dei provider. Una notifica fallita non deve far presumere che il messaggio sia stato ricevuto.

Checklist dell’operatore

  • Controllare stato, priorità e canale di origine
  • Verificare cliente, servizio e articolo collegati
  • Prendere in carico prima di iniziare il lavoro
  • Trasferire al dipartimento competente quando necessario
  • Distinguere risposta al cliente e nota interna
  • Controllare destinatari e allegati prima dell’invio
  • Usare risposte predefinite come bozze
  • Registrare attività o tempo di assistenza quando previsto
  • Chiudere invece di eliminare lo storico ordinario
  • Verificare IMAP, SMTP e automazioni dai rispettivi risultati
  • Non pubblicare credenziali, chiavi o contenuti dei clienti