Uno dei modi per fare in modo che i ticket che vengono creati in zendesk, siano già correlati delle opportune informazioni che servono per una veloce gestione è quello di obbligare il richiedente a compilare un form online.
Spesso i form online sono anche usati per richiedere informazioni generiche o anche per una lead generation.
In tutti casi la domanda che spesso ci viene posta è : "Come faccio a far in modo che il form che ho sul mio sito crei direttamente il ticket in Zendesk?"
Le strade da seguire sono diverse in base anche alle proprie esigenze.
Cominciamo con quello che NON si deve fare: spesso i form dei siti mandano una mail con il contenuto del form compilato, e molte volte vediamo che la soluzione adottata per integrare il form con Zendesk è di mandare la mail a Zendesk! No, questa non è una buona integrazione e comporta molti limiti e spesso dei problemi.
Soluzione 1: usare i form nativi di Zendesk
Con Zendesk Support + Guide avete la possibilità di creare dei form personalizzati che compariranno nell'help center. Non mi soffermo qui sul come fare perchè non è scopo di questo articolo. Spesso questo metodo non piace ad alcuni utilizzatori di Zendesk per questi motivi:
1) non posso "embeddare" la form di Zendesk nel mio sito
2) la customizzazione grafica avanzata dell'help center Zendesk, se pur possibile, richiede competenze da sviluppatore html
Soluzione 2: usare un tool di generazione form nativamente integrato con Zendesk
Possiamo trovare sul mercato diversi tool per generare form e embeddarli poi dove li vogliamo che sono già nativamente integrabili con Zendesk, qui alcuni esempi:
Soluzione 3: modificare/realizzare un form ad hoc per il proprio sito
Se hai il tuo modulo di contatto sul tuo sito web, puoi integrarlo con Zendesk utilizzando le API.
In pratica potete creare (o modificare) il vostro form HTML facendo in modo che l'azione di INVIO del form esegua una opportuna chiamata API verso zendesk.
La strada più veloce e facile è l'uso di chiamate anonime.
Riferimenti principali per l'utilizzo delle API "Ticketing" di Zendesk
Qui di seguito i riferimenti da prendere in considerazione per l’uso della API di Zendesk:
- Autenticazione - Token
- Ticket
- https://developer.zendesk.com/api-reference/ticketing/tickets/tickets/
- https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_fields/
-
https://developer.zendesk.com/api-reference/ticketing/tickets/ticket-attachments/
NB: se si utilizzano dei custom fields (sia per gli user che per i ticket) bisogna tenere conto che sono gestiti tramite gli ID (quindi occorre creali in Zendesk e recuperare gli id dei campi che si vogliono utilizzare).
- Limiti/Paginazione (nella realizzazione dell’integrazione con Zendesk bisogna tenere conto delle limitazioni e della paginazione)
Scegliere l'API corretta per la CREAZIONE dei Ticket
È possibile utilizzare una delle seguenti API per creare ticket:
La differenza principale tra le due è che l'API Requests può essere utilizzata dagli utenti finali autenticati mentre l'API Tickets può essere utilizzata solo dagli agenti autenticati.
In altre parole, l'API Requests è progettata per la creazione di app rivolte verso l'esterno per gli utenti finali.
L'API Tickets è progettata per creare app interne per il tuo team di supporto.
Nella scelta di quale API usare, io consiglio però di porsi anche questo quesito sulla sicurezza: l'uso della Request API mi consente di fare delle richieste API "anonime" quindi non sono costretto a mettere nel codice del mio sito (e quindi magari a comunicare a sviluppatori esterni) token di accesso e/o login di accesso a Zendesk. Se questo tema per me è importante, suggerisco di valutare si usare la Request API in anonimo. Inoltre il form potrebbe essere realizzato anche in javascript con tecnologia totalmente lato client: in questo caso è OBBLIGATORIO NON USARE la modalità autenticata per non esporre il vostro Zendesk a una falla di sicurezza.
API Request (Anonima)
Questa è la scelta FORTEMENTE consigliata per i motivi di sicurezza sopra detti.
E' il metodo più semplice perchè può anche essere implementato lato javascript client, ma ha un limite importante : permette di creare form molto semplici che contengono solo questi campi:
- nominativo richiedente
- oggetto
- commento
Se ho necessità di usare altri campi, devo per forza pensare ad una request autenticata.
Per abilitare le richieste anonime
- Accedi a support e vai alla pagina Clienti (Admin > impostazioni > clienti)
- Abilita "Chiunque può inviare ticket"
- Disabilita "Chiedi agli utenti di registrarsi".
- Disabilita "Richiedi autenticazione per le API di richiesta e caricamento".
POST [urlzendek]/api/v2/requests
Passando nel body un json tipo questo:
{
"request": {
"requester": {"name": "Anonymous customer", "email": "test@email.cip"},
"subject": "Help!",
"comment": {"body": "My printer is on fire!" }
}
}
API Ticket (autenticata)
- Creazione di un ticket
- Upload di allegati
https://developer.zendesk.com/api-reference/ticketing/tickets/ticket-attachments/
Per inviare il ticket occorreranno invece i seguenti metodi :
- POST - Upload file per fare l’upload di file verso Zendesk (nella response viene tornato il token che poi dovrà essere usato nel JSON del ticket da creare, nell’array “uploads”)
- POST - Create Ticket with new requester è il metodo per creare il ticket passando anche l’utente richiedente (con eventuali custom fields, attachment)
Requester e Submitter
Ogni ticket ha un requester e un submitter. L'utente che chiede supporto tramite ticket è il requester. Per la maggior parte delle aziende che utilizzano Zendesk Support, il requester è un cliente, ma i requester possono anche essere agenti nella tua istanza di Zendesk Support.
Il submitter è l'utente che ha creato un ticket. Per impostazione predefinita, il requester di un ticket è il submitter. Ad esempio, se il tuo cliente invia un'e-mail al tuo indirizzo di supporto, questo crea un ticket con il cliente sia come requester che come submitter. Il requester apparirà anche come autore del primo commento del ticket.
Tuttavia, un agente di supporto può anche creare un ticket per conto di un cliente. Se un agente crea un ticket tramite l'interfaccia web, l'agente viene impostato come submitter. Ciò può essere ottenuto in modo equivalente tramite l'API passando l'ID utente dell'agente come submitter_id durante la creazione di un ticket. In questo caso, l'agente, che è il submitter, diventa l'autore del primo commento del ticket e il ticket mostra che l'agente ha creato il ticket "per conto" del cliente.
Esempio di FLUSSO per la creazione di un TICKET (autenticata)
- Verifica in Zendesk dell’esistenza dell’utente richiedente, tramite email
ES:
/api/v2/users/search.json?query=email:myname@mydomain.com
Se l’utente esiste
- Recuperare dal Json l’ID dell’utente
- Recuperare dal Json l’organization_id
Altrimenti:
- Creare l’utente, passando tutti i dati necessari
ES: [POST]
{
"user": {
"email": "emai@dominio.it",
"name": "nome utente",
"role": "end-user",
"user_fields": {
"type_of_client": "tipo_1",
"indirizzo": "Via .....",
"privacy": true
}
}
}
- Se il salvataggio va a buon fine
-
- Deve essere recuperato dal Json l’ID dell’utente
-
-
Se al punto 1 è stato recuperato correttamente l’ID dell’utente richiedente
-
- Se l'utente era già esistente e ci sono dei dati da aggiornare
- Aggiornare l’utente:
ES.:
[PUT]
/api/v2/users/{user_id}
{
"user": {
"name": "nome utente",
"user_fields": [{"id": 1234567890, "value": "222"}]
}
}
-
- Se il salvataggio va a buon fine
-
- Aggiornare l’utente:
- Se l'utente era già esistente e ci sono dei dati da aggiornare
-
-
-
-
-
-
-
- Passare al punto 3
-
-
-
-
-
Altrimenti:
-
- Gestire l’errore
- Uscire dal flusso
- Verifica in Zendesk dell’esistenza della Organization (ad es.: tramite P.Iva)
ES:
/api/v2/search.json?query=type:organization "P.IVA 03760290266"
Se l’organization esiste
- Recuperare dal Json l’ID della organization
Altrimenti:
- Creare l’organization, passando tutti i dati necessari
[POST]
/api/v2/organizations.json
ES:
{
"organization": {
"name": "Nome Azienda (P.IVA 1111111 – CodFisc 3333333)",
"organization_fields": [
{"id": 1234567890, "value": "11111111"},
{"id": 0987654321, "value": "33333333"}
]
}
}
- Se il salvataggio va a buon fine
- Deve essere recuperato dal Json l’ID della organization
- Se al punto 3 è stato recuperato correttamente l’ID della organization
-
-
- Passare al punto 5
-
Altrimenti:
-
- Gestire l’errore
- Uscire dal flusso
-
Se l’id organization dell’utente eventualmente recuperato al punto 1 è diverso da quello recuperato al punto 3 (oppure non esiste l’id organization dell’utente, perché è un utente nuovo)
-
- Aggiornare l’utente aggiungendo l’organizazion_id
-
ES.:
[PUT]
/api/v2/users/{user_id}
{
"user": {
"organization_id": {organization_id}
}
}
- Invio del Ticket
[POST]
/api/v2/ticket.json
ES:
{
"ticket": {
"requester_id": {id utente},
"submitter_id": {id utente},
"subject": "Titolo del ticket",
"comment": {
"body": "Testo del ticket",
"uploads": ["4bLLKSOU63CPqaIeOMXYyXzUh"]
},
"custom_fields": [
{"id": 1234567890, "value": "0001"},
{"id": 0987654321, "value": "valore custom field"}
…
…
…
]
}
}
NB: per la gestione degli attachment, occorre effettuare l’upload prima del salvataggio del ticket, come descritto qui:
- Recuperare l’ID del ticket
- Eventuale aggiornamento di un Ticket (avendo il suo ID)
-
- Es. aggiornamento dei TAG di un ticket (senza sovrascrivere eventuali tag già presenti)
[PUT]
/api/v2/tickets/update_many.json?ids={ticket_id}
ES:
{
"ticket": {
"additional_tags": ["tag_0001",”nome_tag_esempio”]
}
}
Commenti
0 commenti
Accedi per aggiungere un commento.