Siamo stati tutti lì. Ricevete la chiamata per risolvere un problema del cliente, affrettatevi a risolverlo il più rapidamente possibile, ma in qualche modo il cliente è ancora infelice, perché pensa che ci sia voluto troppo tempo . O per quanto riguarda il tempo in cui hai risolto un problema che non faceva nemmeno parte dello scopo del lavoro che fai normalmente e non erano soddisfatti del lavoro, quindi in qualche modo sembri ancora un idiota incompetente.

Nessuno di noi vuole essere in questa situazione. E, in realtà, a volte il problema sicuramente non è il lavoro che fai; invece, si tratta della percezione del cliente del lavoro che fai, sia che pensino che sia stato risolto in modo tempestivo e professionale, ecc.

Il vero problema è semplicemente una disconnessione tra il modo in cui pensi che dovresti essere al servizio del cliente e il modo in cui lo fanno i clienti. La comunicazione è sicuramente la chiave qui — e può risolvere alcuni dei problemi — ma la memoria ci manca sempre e, prima o poi, tornerai in un punto in cui il tuo cliente dice: “Questo è stato incluso nel nostro accordo [verbale] “E stai dicendo” No, non lo è. ”

Ciò di cui hai bisogno è un accordo sul livello di servizio (SLA). Il Service Level Agreement o SLA funge da documento principale che definisce i servizi che fornirai e stabilirà le aspettative del cliente in merito a tali servizi. Al suo livello più elementare, lo SLA è la documentazione di ciò che ognuno di voi sta cercando di ottenere l’uno dall’altro.

In questo articolo, spiegheremo perché hai bisogno di uno SLA, quando dovresti – e non dovresti – averne uno, cosa dovrebbe essere incluso, considerazioni quando scrivi uno SLA e come rendere misurabile il tuo SLA.

Hai bisogno di uno SLA

Ora, nonostante tutti i cattivi scenari di supporto che abbiamo affrontato in un modo o nell’altro in cui il cliente è scontento, nonostante forniate loro un servizio come promesso, alcuni di voi potrebbero ancora pensare di poter gestire la propria attività senza uno SLA. Gli MSP di maggior successo non saranno assolutamente d’accordo con te. Ci sono alcuni motivi molto convincenti per cui hai bisogno di uno SLA:

  • Migliorare la percezione dei clienti
    Ci sono molte aziende di supporto IT non professionali che documentano male e non riescono a lavorare secondo le migliori pratiche. È improbabile che anche il cliente più piccolo veda la necessità di uno SLA come un esercizio in formalità eccessiva. Invece, distingue la tua azienda come un’azienda professionale che prende sul serio la propria attività ed i propri obblighi.
  • Chiarire gli obblighi dei partner
    Mentre, in qualità di MSP, siete probabilmente responsabili di tutte le principali infrastrutture hardware e software dei vostri clienti, è probabile che vi siano vari sistemi che non rientrano nelle vostre competenze. Questi potrebbero includere applicazioni line-of-business con contratti di supporto o dispositivi di stampa supportati da un fornitore di fotocopiatrici. Assicurandoti che il tuo SLA elenchi ciò che è incluso e dettaglia ciò che non lo è, puoi assicurarti che la tua azienda non sia chiamata a supportare elementi problematici che non sono di tua responsabilità.
  • Chiarire gli obblighi degli utenti
    Scrivere bene un contratto di servizio può contribuire a mitigare alcuni dei problemi più controversi tra IT e utenti. Questi possono includere l’installazione di software non autorizzato, l’importanza di registrare le chiamate problematiche nel modo corretto e la necessità di una comunicazione accurata dei messaggi di errore. Dopo tutto, con quale frequenza i tecnici iniziano a risolvere un problema senza più informazioni di “il mio computer non funziona correttamente?” Stabilire ciò che ci si aspetta dagli utenti contribuirà a garantire che il cliente stia facendo la propria parte per rendere il lavoro efficiente e produttivo.
  • Gli SLA proteggono il tuo tempo e il tuo buonsenso
    Ci sono invariabilmente uno o due utenti in ogni azienda che avranno aspettative non realistiche e porranno richieste ingiuste sul tuo tempo. Se i tuoi SLA chiariscono esattamente in quali giorni e ore hai accettato di fornire assistenza, puoi allontanarti da telefoni ed e-mail alla fine della giornata ed essere libero di goderti il ​​tuo tempo personale.
  • Gli SLA forniscono protezione 
    I buoni SLA possono offrirti protezione e tranquillità se la tua azienda è abbastanza sfortunata da rimanere coinvolta in una controversia legale con un cliente. Se, ad esempio, hai un cliente che non paga, troverai molto più semplice provare di aver soddisfatto tutti i tuoi obblighi se hai un accordo firmato che specifica i tuoi rapporti commerciali. Affinché il tuo SLA fornisca efficacemente questa protezione, un professionista legale qualificato dovrebbe verificarne il contenuto ed un consulente GDPR dovrebbe verificare la conformità al nuovo regolamento europeo.
  • Gli SLA ti aiutano a risolvere le controversie
    Quando si verificano occasionali disaccordi, avere uno SLA dettagliato che viene riportato in modo accurato ti aiuta a supportare il tuo caso. Ad esempio, se un utente problematico si lamenta del tuo servizio, potresti essere in grado di dimostrare che la tua azienda, infatti, risponde e risolve costantemente i problemi entro i tempi concordati. In caso di controversia grave con un cliente, un buon SLA potrebbe rappresentare la differenza tra una semplice risoluzione e una lunga battaglia legale o politica.
  • Gli SLA dimostrano il tuo valore
    Le opinioni dei clienti sul servizio della tua azienda possono variare di giorno in giorno in base allo stato d’animo attuale o a eventuali problemi di sistema in corso. Prestazione contro SLA concordati; purtroppo, i consulenti IT vengono spesso giudicati in base al problema di sistema più recente, anche se hanno garantito prestazioni del sistema costantemente perfette per mesi prima. Essere in grado di dimostrare ai tuoi clienti, in bianco e nero, che stai rispettando i tuoi obblighi e assicurando un eccellente tempo di attività del sistema, può essere sufficiente per riportarli al tuo fianco e impedire loro di fare acquisti per un nuovo fornitore di supporto.

Un contratto di servizio ha sicuramente uno scopo per far sì che l’MSP abbia successo, consentendo al contempo al cliente di ritenere responsabile l’MSP. Ma ci sono scenari in cui uno SLA non è necessario? Per scoprirlo, prima descriviamo quando si è prudenti e poi quando si può rinunciare a uno SLA.

Quando ho bisogno di uno SLA?

Per ridurlo, uno SLA è assolutamente necessario per la riparazione di computer nel mercato medio e nello spazio aziendale, e spesso nello spazio delle PMI dove il cliente lo richiede. Ma la tua piccola impresa tipica che cerca di coinvolgere un MSP specializzato in PMI può vedere uno SLA come più problemi di quanti ne valga la pena.

Le piccole imprese in genere hanno a che fare con piccoli MSP perché desiderano una relazione di fiducia. È certamente necessario che gli MSP definiscano le aspettative di un cliente in modo che non si aspettino che tu gestisca ogni richiesta di servizio in un batter d’occhio. Ciò significa che potrebbe essere necessario fornire uno SLA molto più semplice per le aziende molto piccole oppure attenersi a uno SLA standard per ogni cliente e correre il rischio di dover passare quel cliente SMB.

Quando NON dovresti usare uno SLA?

Può sembrare strano (dato che questo è un articolo sugli SLA) suggerire che, in alcuni casi, potrebbe essere meglio evitare gli SLA. Tuttavia, in alcune situazioni (e con alcuni clienti) questa può essere una strategia ragionevole. Ecco alcuni esempi:

  • Reti instabili
    Tutti i professionisti IT esperti sanno cosa significa assumere un’infrastruttura che è stata trascurata o gestita male. Se stai raccogliendo i pezzi dopo la partenza di un precedente fornitore di supporto, potrebbe essere meglio non accettare di lavorare con uno SLA, almeno non all’inizio. È giusto aspettarsi un certo periodo di tempo per ripristinare l’infrastruttura su una base uniforme. Molto spesso il cliente può dover spendere un po ‘di denaro per raggiungere questo obiettivo. In queste situazioni, potresti voler dichiarare che puoi lavorare con uno SLA solo quando sono soddisfatti determinati prerequisiti, altrimenti la tua vita potrebbe diventare inutilmente stressante mentre correggi gli errori del tuo predecessore.
  • Clienti difficili
    Tutti gli MSP si trovano a lavorare per clienti difficili in diverse occasioni. Alcuni clienti non sono mai soddisfatti e alcuni possono essere maleducati, troppo esigenti e armeggiare costantemente con impostazioni che non comprendono! Ironia della sorte, sono spesso questi clienti che pagano anche le fatture in ritardo! Quando ti ritrovi a fare affari con clienti come questi, vale la pena chiederti se vuoi davvero essere legato a uno SLA — dopo tutto, uno SLA è un accordo, non un bastone con cui batterti — ma i clienti come questo capiranno davvero? Quindi, se ritieni che uno SLA verrà utilizzato solo per spremere più lavoro da te, interagisci con questo tipo di cliente su base oraria o scrivi uno SLA con maggiori dettagli per delineare i livelli e i limiti del tuo servizio.
  • Accordi informali
    Potresti scoprire che la tua azienda finisce per fornire supporto IT ad alcune aziende su base informale, magari scambiando servizi con la tua società di contabilità o gestendo la rete del proprietario in cambio di un affitto ridotto. Questi clienti probabilmente non hanno bisogno di uno SLA data l’informalità dell’accordo. Ovviamente, dovresti assicurarti che i tuoi contratti e assicurazioni ti coprano per il lavoro che stai facendo sui loro sistemi, ma questi probabilmente non sono clienti con i quali devi definire chiaramente i livelli di servizio.

È importante essere chiari sul fatto che, nella maggior parte dei casi, l’uso degli SLA è una pratica commerciale saggia e che un MSP non dovrebbe ignorare. Tuttavia, ci sono sempre delle eccezioni alle regole. L’istinto è uno strumento potente nel mondo degli affari: se ti avverte di stare in guardia su un particolare cliente, è sensato prenderne atto.

Mentre la reazione corretta a questo istinto è di solito quella di mettere in atto uno SLA dettagliato, a volte la migliore strategia potrebbe essere l’esatto contrario!

Ora che hai una migliore comprensione di quando e dove uno SLA è appropriato, delineeremo ciò che deve essere incluso nel tuo SLA.

Cosa dovrebbe contenere uno SLA?

In generale, chiunque sia stato esposto al concetto di SLA ha un’idea di base di ciò che è incluso: elenchi di hardware / software supportati, tempi di risposta, ecc. Ma, come si suol dire, il diavolo è nei dettagli … e dovresti pianificare di avere un po ‘di dettagli nel tuo SLA per assicurarti che tutto sia esplicitato.

Definizione dei servizi

  • Portata dei servizi – È importante chiarire l’esatta portata dei servizi forniti nell’ambito di ogni SLA. Descrivi esattamente quali server e sistemi software rientrano nelle tue competenze e assicurati che tutte le esclusioni siano chiarite. Ad esempio, se un cliente ha un database o un sistema CRM su misura, può rivolgersi direttamente alla società di software per il supporto. Dedica del tempo alla definizione accurata del servizio per evitare disaccordi futuri.
  • Ore di supporto – Quali sono i normali orari di supporto per la tua azienda? Che dire di fuori? Saranno addebitati costi aggiuntivi se le chiamate vengono effettuate al di fuori del normale orario di assistenza?
  • Tempo di attività del sistema – I target di uptime del sistema sono una metrica comune da includere durante la scrittura degli SLA. Generalmente misurati in percentuale, le letture dei tempi di attività del sistema consentono ai clienti di verificare l’affidabilità della propria infrastruttura IT per un periodo di tempo. Può essere abbastanza difficile monitorare manualmente il tempo di attività del sistema. Per fortuna, sono disponibili soluzioni software che servono a questo scopo. È consigliabile monitorare i tempi di attività di tutti i sistemi chiave separatamente. Ad esempio, prova a fornire una percentuale di uptime per e-mail, servizi di file e accesso remoto separatamente, oltre a fornire ai clienti una cifra combinata. Questo aiuta te e il cliente a identificare se un determinato servizio sta causando problemi, il che può portare a riconoscere che sono necessari ulteriori lavori o investimenti.

Cosa fare quando c’è un problema

  • Segnalazione dei problemi – Cosa fa il cliente in caso di problemi? Mandano una mail? Fax? Piccione viaggiatore? Qualunque sia il metodo, assicurati di essere specifico.
  • Tempi di risposta ai problemi – I tempi di risposta dello SLA di solito si riferiscono alla velocità con cui risponderai a un problema tecnico sollevato via telefono, e-mail o altri metodi. Gli obiettivi di risposta del telefono vengono talvolta misurati in numero di squilli. In alternativa, e forse più rilevante per il MSP più piccolo, i tempi di risposta possono riferirsi alla rapidità con cui ti impegni a rispondere a un’e-mail o a richiamare per rispondere a un messaggio di posta vocale. Quando si concordano tempi di risposta adeguati, è importante definire chiaramente l’orario di lavoro e assicurarsi che i clienti sappiano che solo questi orari di lavoro sono inclusi in un tempo di risposta. Ad esempio, se gli orari di apertura sono dalle 9 alle 17, dal lunedì al venerdì, e una chiamata viene registrata alle 4.55 di un venerdì sera, una risposta a ciò alle 9.05 del lunedì mattina successivo è un tempo di risposta di 10 minuti, piuttosto di tre giorni, perché si basa sull’orario di lavoro. Il tipo di risposta che puoi offrire dipende davvero dalla natura del tuo business MSP. Maggiore è il tuo livello di personale, più è probabile che tu possa promettere una risposta entro un numero di squilli o minuti.
  • Tempi di risoluzione dei problemi  – Definire la velocità con cui i problemi devono essere risolti dal momento in cui un problema viene registrato fino a quando non viene risolto completamente è una parte importante di ogni SLA. Di solito, ha senso assegnare un livello di gravità a ciascun problema che si presenta, che va da priorità urgenti a problemi urgenti, che di solito comportano l’impossibilità di lavorare di uno o più membri del personale, fino a rendere piacevole il miglioramento del sistema. Una volta definite le priorità, è necessario concordare un tempo di risoluzione realistico per ciascun tipo di problema. Ad esempio, quattro ore per un problema urgente e 72 ore per una richiesta a bassa priorità. Dopo aver concordato questi tempi, è necessario utilizzare un sistema di registrazione delle chiamate per tenere traccia dell’avanzamento di ciascun problema e riportare le prestazioni rispetto allo SLA. Come per i tempi di risposta, è importante assicurarsi che i tempi di risoluzione siano calcolati solo in base all’orario di lavoro concordato. È anche consigliabile stabilire che un tempo di risoluzione inizia solo dal momento in cui una chiamata viene registrata correttamente utilizzando un metodo concordato. Affinché la risoluzione dei problemi sia accuratamente tracciata e misurata come parte di un accordo sul livello di servizio, è essenziale che tutti gli utenti conoscano il modo corretto di segnalare e dare priorità ai problemi. A volte far capire ai singoli utenti che un problema di flusso di posta a livello di sistema ha una priorità maggiore rispetto alla loro cartuccia di toner in esaurimento può essere scomodo! La cosa più importante è concordare obiettivi raggiungibili. Ad esempio, se si intende offrire un tempo di riparazione di quattro ore per problemi urgenti del server, è necessario disporre di personale, contratti di servizio hardware e ridondanza di sistema adeguati per renderlo possibile. Se il cliente non dispone di un’infrastruttura sufficientemente solida per facilitare ciò, non è saggio concordare un obiettivo non realistico. L’impostazione degli obiettivi SLA ti offre una preziosa opportunità per gestire le aspettative dei tuoi clienti e proteggere la tua attività. Dire a un cliente che non puoi accettare una risoluzione di quattro ore perché i suoi server non hanno abbastanza funzionalità di resilienza potrebbe persino spingerli ad aggiornare la loro infrastruttura! Ancora più importante, tuttavia, ti dà la possibilità di presentare una visione realistica di ciò che ci si può aspettare da te.

Altre questioni da affrontare

  • Vincoli di supporto – A volte, le specifiche di un determinato cliente non ti permetteranno di rispettare i tempi di risposta o risoluzione. Ad esempio, se la domenica non è possibile accedere all’edificio del cliente, è necessario annotare nello SLA che è necessario rispettare i tempi di risposta e risoluzione modificati in caso di problemi di domenica. Un altro esempio è se la garanzia hardware del cliente include parti di ricambio il giorno successivo, ovviamente non è possibile soddisfare uno SLA critico di quattro ore per un server se le parti non saranno presenti fino a domani.
  • Responsabilità del cliente – Che tipo di onere grava sul cliente? Ti servono per mantenere aggiornati i loro sistemi per prevenire il malware? O lo farai come un’altra parte del tuo servizio? Che tipo di contenuto possono scaricare / ospitare sui loro siti Web?
  • Informazioni riservate / protezione dei dati – Per quanto tempo verranno conservate le registrazioni? Cosa succede loro quando non sono più necessari? Come proteggerai i dati personali e finanziari dei tuoi clienti?

Gli argomenti di cui sopra non sono affatto un elenco dell’immaginazione. Potrebbero esserci delle sezioni aggiuntive che rispondono a un’esigenza specifica del cliente. Ogni SLA è diverso e ciò che potrebbe essere importante in alcuni SLA non sarà necessario in altri. La cosa più importante è assicurarsi che tutto ciò che tu e il cliente state concordando siano nel vostro SLA.

Considerazioni quando si scrive il proprio SLA

Molte volte un MSP è desideroso di firmare un altro cliente, facendo promesse di cosa, come e quando consegnerai senza mai guardare alle specifiche coinvolte nel supportare quel nuovo cliente. Distribuire ciecamente uno SLA, anche se è il tuo SLA standard, a un cliente non è intelligente. Ciò potrebbe farti ritrovare in una posizione in cui non puoi realizzare ciò che hai promesso.

Pertanto, sia mentre scrivi il tuo SLA, sia prima di considerare di dare lo SLA standard a un nuovo cliente, considera i seguenti fattori SLA:

  • Livelli di personale
    Il tipo di servizio che è possibile fornire, in particolare in termini di tempi di risposta e risoluzione, differirà notevolmente in base ai livelli di personale. Se, ad esempio, sei una band di uno o due uomini, è improbabile che tu possa offrire lo stesso tempo di risposta di un’azienda più grande, perché l’impresa più grande probabilmente ha un team di persone che gestisce permanentemente il proprio helpdesk.
  • La stabilità della rete del cliente
    Immagina due infrastrutture del cliente: una con server quasi nuovi e ben configurati, molteplici funzionalità di ridondanza e una soluzione di recupero di emergenza collaudata, e un’altra che mostra la sua età, con un file server che spesso cade e vari problemi di stabilità . Non ha molto senso concordare la stessa percentuale di uptime e tempi di risoluzione su entrambe le reti, in quanto il raggiungimento degli obiettivi SLA sulla prima rete sarebbe chiaramente più realistico rispetto al raggiungimento della seconda.
  • Le pratiche di lavoro del cliente
  • Ogni cliente lavora in modo diverso e ha priorità diverse. Una ditta tradizionale di commercialisti o geometri può lavorare religiosamente dalle 9 alle 17, dal lunedì al venerdì, e non avere interesse per il lavoro a domicilio e a distanza. Una società di media all’avanguardia può avere persone che desiderano effettuare hot-desking e accedere dagli aeroporti e richiedere supporto durante orari piuttosto non sociali. Come puoi vedere, è improbabile che lo stesso SLA sia realistico per entrambe queste società.

Una volta che hai una buona idea di questi fattori, sei in grado di discutere esattamente cosa puoi offrire realisticamente al tuo cliente.

È probabile che siano necessari alcuni compromessi. Solo le più grandi aziende possono offrire assistenza 24 ore su 24, 7 giorni su 7, e anche le aziende che ne hanno bisogno devono essere pronte a pagare. È di vitale importanza offrire solo ciò che è possibile offrire: ciò salverà angoscia e potenziale disaccordo più avanti.

Dopo aver definito correttamente ciò che dovrebbe essere nel tuo SLA, è tempo di pensare a come farlo funzionare per te. Nella sezione successiva, discuteremo come è possibile utilizzare il contratto di servizio come base per misurare la qualità del servizio fornito.

Rendere misurabile il tuo SLA

I clienti che ti coinvolgono nella gestione della loro rete non vogliono solo che i problemi vengano risolti rapidamente; vogliono anche sapere che stai fornendo i servizi promessi per i soldi che ti pagano ogni mese. In sostanza, vogliono un modo per renderti responsabile. Invece di considerare lo SLA come uno strumento che il cliente può usare a tuo danno, invece scriverlo in modo proattivo in modo da poter utilizzare le definizioni di servizio per misurare correttamente il tuo prodotto di lavoro e dimostrare che stai fornendo un servizio eccellente.

Quindi, come si può misurare il proprio SLA? Definiamo alcuni passaggi fondamentali:

Passaggio 1: definire con precisione gli SLA

Affinché gli SLA siano veramente misurabili, è necessario andare oltre le dichiarazioni vaghe come uptime del 99% e tempo di risoluzione di quattro ore . Ad esempio, che cos’è esattamente il 99% di uptime? Il 99% di TUTTI i tempi o il 99% delle ore lavorative? Se si tratta di ore lavorative, quali sono esattamente le ore lavorative concordate? Ci sono alcune finestre di manutenzione e di aggiornamento concordate che sono escluse?

Quando si tratta di risolvere i problemi, il tempo di risoluzione inizia quando inizia il problema o quando viene segnalato? L’orologio di risoluzione quindi spunta fino al momento in cui il problema è stato risolto o si interrompe alle 17:00 di venerdì e si riavvia la settimana successiva?

Fino a quando questi dettagli non saranno determinati, è impossibile misurare le prestazioni in qualcosa di diverso da un modo soggettivo.

Passaggio 2: coinvolgere il cliente

Vale la pena dedicare del tempo per garantire che i clienti comprendano i motivi degli SLA e gli aspetti tecnici coinvolti nella loro consegna. Ad esempio, pochi clienti si rendono conto che, con un solo backup notturno, esiste spesso il rischio di perdere un giorno di dati in caso di errore del sistema nel momento peggiore esatto. Probabilmente non si rendono conto che se un’unità si guasta, il produttore del server potrebbe impiegare un giorno per consegnare una sostituzione.

Spiegando queste cose ai clienti, possono acquisire una comprensione delle sfide che devono affrontare il reparto IT medio e quindi decidere se è necessario effettuare ulteriori acquisti o modifiche alle operazioni IT. Ad esempio, se il cliente decide che la perdita dei dati di un giorno o 24 ore di inattività sono troppo rischiose per l’azienda, possono quindi supportare la spesa in conto capitale necessaria per sviluppare ulteriormente l’infrastruttura di backup, aumentando la frequenza di backup e creando ridondanza Caratteristiche.

Passaggio 3: utilizzare il software

La misurazione delle prestazioni degli SLA richiede davvero un software; in caso contrario, passerai molto tempo a calcolare i tempi di attività e i tempi di risoluzione. I due software essenziali sono un helpdesk / sistema di registrazione delle chiamate e un sistema di monitoraggio SLA. Ci sono molte soluzioni disponibili per entrambi, la maggior parte delle quali sono relativamente economiche.

Passaggio 4: segnalare e adattare

La segnalazione a un cliente mensile o trimestrale delle prestazioni del contratto di servizio può essere un efficace strumento di soddisfazione del cliente. Se il tuo SLA contiene obiettivi prestazionali raggiungibili e li raggiungi costantemente in tutta la tua base di clienti, puoi utilizzare queste statistiche per dimostrare la tua competenza e valore per il tuo cliente.

I dati sulle prestazioni degli SLA possono anche essere utilizzati come strumento di marketing efficace quando mostrati ai potenziali clienti. Se un potenziale cliente sta confrontando due società di servizi e la tua può mostrare una prova documentata della conformità coerente agli SLA, è probabile che ti dia un vantaggio significativo.

Se scopri che non stai rispettando gli SLA, rapporti SLA misurabili e dettagliati ti permetteranno almeno di individuare dove esistono problemi sull’infrastruttura, evidenziando dove i problemi devono essere risolti, dove il sistema ha bisogno di ulteriori spese o sviluppo, o dove la tua azienda può migliorare il suo servizio.

Devi solo eseguire il processo di creazione di SLA completamente misurabili una volta. Successivamente, definirli per altri clienti dovrebbe essere molto più semplice, poiché avrai già un processo in atto, così come software collaudato che puoi usare per misurarli.

Conclusione

Il tuo obiettivo è un cliente soddisfatto e un’azienda di servizi felice e redditizia. Per realizzare entrambi, è necessario stabilire le aspettative su ciò che è possibile fare, ciò che si farà, come lo si farà e ciò di cui si ha bisogno dal cliente per avere successo. Costruire uno SLA è la base per un rapporto duraturo e proficuo tra te e il tuo cliente.

Uno SLA ti consentirà di stabilire efficacemente con il cliente quali servizi saranno forniti, insieme ai limiti e ai vincoli della fornitura. Ti consentirà inoltre di misurare la tua stessa esecuzione, fungendo da base sia per migliorare quando necessario, sia per dimostrare il valore che stai offrendo al cliente.

Prendendo in considerazione le capacità della tua organizzazione, le esigenze della rete del tuo cliente e spiegando dove i due si intersecano (nel modo più dettagliato possibile), imposterai te e il tuo cliente per il successo.

FONTE: Solarwinds MSP BLOG

Traduzione N4B SRL – Distributore Autorizzato Solarwinds MSP