Help desk multicliente per MSP: i requisiti

Chi assiste una sola azienda ha bisogno di ordine. Chi ne assiste dodici ha bisogno di confini: fra un cliente e l'altro, fra un tecnico e i clienti che non segue, fra un contratto che prevede una risposta rapida e uno che non la prevede. Un help desk che non li regge non si rompe subito — si rompe il giorno in cui un cliente legge il nome di un altro cliente.

Questa guida elenca i cinque requisiti su cui vale la pena essere intransigenti quando si sceglie uno strumento per un'attività multicliente, e i modi di verificarli in una prova invece che in un capitolato.

1. La separazione, il requisito da cui dipendono gli altri

Che i clienti non si vedano fra loro sembra scontato, e quasi nessun fornitore lo smentirebbe. La domanda che separa le risposte vere da quelle di cortesia è un'altra: dove è applicata la separazione.

Se un tecnico non abilitato su un cliente non ne vede i ticket nell'elenco ma li trova cercando, o li riceve in una notifica, o li ottiene da un'API, la separazione è un filtro dell'interfaccia. In una prova si verifica in cinque minuti: due clienti finti, un tecnico abilitato su uno solo, e una ricerca fatta dalla sua utenza con il nome dell'altro cliente. Un solo risultato è già la risposta.

La seconda metà del requisito riguarda i vostri clienti: il referente di un'azienda non deve poter raggiungere le richieste di un'altra nemmeno indovinando un indirizzo. Vale la pena provarlo davvero — aprire una richiesta con un'utenza e provare ad aprirne l'indirizzo con l'altra.

2. L'ambito dei tecnici, e chi lo decide

La separazione fra clienti è un asse; l'ambito di una persona è il secondo, e i due si moltiplicano. Un tecnico può essere abilitato su tre clienti e vedere, dentro quei tre, tutto oppure soltanto quello che gli è stato assegnato.

Le combinazioni che servono davvero a un'attività multicliente sono poche:

• Tutto su tutti i clienti — chi coordina e chi risponde di notte.
• Tutto su alcuni clienti — la configurazione normale di un tecnico che ha i suoi clienti.
• Solo le richieste assegnate — un collaboratore esterno, o qualcuno che è appena arrivato.
• Solo quelle che ha aperto lui — chi vi manda lavoro ma non lo lavora.

Quello che conta, più dell'elenco, è che l'ambito sia composto da due assi indipendenti e non da un ruolo unico con dentro tutto. Un prodotto che offre «tecnico junior» e «tecnico senior» come ruoli fissi vi costringerà, alla prima eccezione, a dare a qualcuno più visibilità di quella che volevate.

3. Tempi diversi per contratti diversi

Un'attività multicliente ha quasi sempre contratti diversi fra loro, e uno strumento che accetta un solo insieme di tempi vi costringe a scegliere il più stretto e a mancarlo, oppure il più largo e a non accorgervi di niente.

I tempi vanno quindi impostati per cliente e, dentro il cliente, per priorità. Tre cose da chiarire prima di firmare, perché cambiano il significato del numero:

• Da quando si conta. Se il conteggio è continuativo, dodici ore aperte il venerdì sera finiscono il sabato: legittimo, ma va saputo e va detto al cliente.
• L'attesa del cliente conta? Se state aspettando un'informazione da lui, quel tempo non è vostro. Uno strumento che non lo separa insegna al gruppo a chiudere le richieste in fretta.
• Che cosa succede alla soglia. Nella quasi totalità dei prodotti parte un avviso, e basta: nessuno chiude, riassegna o alza la priorità al posto vostro. È corretto, purché il fornitore lo dica e voi non abbiate promesso altro al cliente.

E il contratto resta una cosa diversa dal numero impostato nel software: il primo vale verso il cliente, il secondo è un promemoria interno che vi aiuta a mantenerlo. La differenza è svolta nella guida su priorità e tempi di risposta.

4. Lo storico non è di chi l'ha scritto

È il requisito che si scopre tardi e che costa più di tutti: quando il tecnico che seguiva tre clienti va in ferie, cambia lavoro o è malato, la conversazione con quei clienti non deve andarsene con lui.

Tre cose rendono una struttura a prova di assenza. La conversazione con il cliente sta in un posto solo, non in una casella personale. Le note che il gruppo si è scambiato stanno nella stessa richiesta, marcate come interne. E i passaggi di mano restano scritti con la data, così chi subentra ricostruisce la storia leggendo invece che telefonando.

Il corollario riguarda anche i vostri clienti: quando cambia il loro referente, le richieste aperte restano dell'azienda e non della persona che le ha scritte. Verificatelo, perché non tutti i prodotti lo fanno.

5. Il tuo marchio, che è un requisito e non un vezzo

Chi rivende assistenza ha bisogno che il cliente finale veda il proprio nome: sull'indirizzo, nel portale e nelle notifiche che riceve. Non è una questione estetica — è che un fornitore sconosciuto che scrive al vostro cliente genera una telefonata a voi.

Qui è una sezione corta di proposito: che cosa chiedere esattamente su indirizzo, email, informativa e coerenza fra le due facce è svolto nella guida su come valutare un help desk a proprio marchio. Quello che rende utilizzabile uno strumento con dodici clienti sono i quattro requisiti precedenti; il marchio è quello che rende utilizzabile la vostra offerta.

Quando un help desk non basta

Metà delle delusioni di chi assiste più aziende nasce dal fatto che «help desk» e «piattaforma per fornitori IT» vengono cercati con le stesse parole e non sono la stessa cosa. Queste funzioni stanno quasi sempre fuori da un sistema di ticketing, e se vi servono conviene saperlo prima:

• Monitoraggio: un allarme di un server che apre una richiesta da solo. È un prodotto diverso, e l'integrazione va costruita.
• Inventario dei dispositivi e accesso remoto: altri due prodotti ancora.
• Email in ingresso: trasformare in richieste i messaggi che arrivano alla casella di assistenza che usate già.
• Ore e fatturazione a consuntivo a partire dalla richiesta.
• Più canali: telefono, chat e social nello stesso posto delle richieste scritte.

Le piattaforme che coprono tutto esistono, costano di più per persona e chiedono settimane di avviamento. La domanda da farsi è se oggi il vostro problema è la mancanza di quelle funzioni o il fatto che le richieste dei clienti stanno in tre caselle diverse: nel secondo caso una piattaforma completa è un modo costoso di non risolverlo.

Che cosa puoi verificare in OglutTicket

Sui primi quattro requisiti la verifica si fa nella prova, e questi sono i fatti da mettere alla prova. La separazione passa dal progetto — uno per cliente — e il filtro è nella query: un tecnico abilitato su tre clienti non trova gli altri nemmeno con la ricerca o dalla REST API. L'ambito è composto da due assi, i progetti e quanto vede dentro ciascuno, e i ruoli sono sei e fissi invece di essere un editor di permessi.

I tempi si accendono per progetto e per priorità, quindi per cliente: il contratto di uno può avere una soglia più stretta di quella di un altro. Le ore sono continuative e non ore d'ufficio, l'attesa di una risposta del cliente ha un tempo separato, e alla soglia parte un avviso — il software non chiude, non riassegna e non cambia priorità. Il cliente non vede mai che una soglia è stata superata.

Sulla continuità: lo storico sta sulla richiesta e non in una casella, le note interne non raggiungono il browser del cliente, e togliendo a una persona l'abilitazione a un progetto le sue assegnazioni aperte lì si azzerano mentre i ticket restano. C'è un registro non modificabile di chi ha fatto che cosa.

I limiti sono esattamente quelli della sezione precedente: niente monitoraggio, niente inventario, niente accesso remoto, niente email in ingresso, niente ore da fatturare e nessun canale oltre il portale e il modulo pubblico. Le integrazioni passano da una REST API e dai webhook, che vanno scritti.

La pagina che entra nel merito, con le catture e le condizioni, è l'help desk per chi assiste più clienti. Chi sviluppa software propri invece di assistere quello di altri trova il taglio giusto in ticketing per software house.