Come far sapere al supporto tecnico che sono competente senza mettersi in mostra?

Sfortunatamente il personale di supporto tecnico con cui state parlando è probabilmente frustrato quanto voi nel dover affrontare con voi le cose di base.

Le grandi aziende si occupano in particolare dell'enorme volume di chiamate di supporto tecnico che ricevono impiegando come “buffer” del personale con una retribuzione più bassa, occupandosi di questioni semplici o “conosciute”, in modo da non dover impiegare altrettante persone di supporto “di seconda linea” con una retribuzione più alta. Molto spesso le prime persone a cui ci si rivolge alle linee di supporto tecnico sono leggere da un copione. Devono farti delle domande stupide, o perché il loro datore di lavoro glielo chiede, o a volte perché il loro sistema informatico non permette loro di arrivare alla parte successiva dello script a meno che non stiano al gioco. Il che non vuol dire che le persone impiegate in prima linea non siano esperte; secondo la mia esperienza, molte persone troppo qualificate devono accettare lavori meno avanzati nel campo dell'informatica solo per entrare nel settore. Ma devono fare quello che la descrizione del loro lavoro dice loro di fare.

Questo varia da un'azienda all'altra. Uno assumerà degli idioti che si rivolgono a voi come degli idioti. Un'altra impiegherà persone intelligenti che si scuseranno abbondantemente con voi per aver dovuto fare tutti i passi inutili, ma è proprio quello che devono fare! Forse dovresti fare un po’ di shopping e trovarne uno che si occupi di te come vuoi tu.

Tuttavia apprezzo il fatto che il prezzo e la funzionalità spesso detengano il controllo su chi abbiamo a che fare. Quindi il mio consiglio migliore, se dovete continuare a trattare con loro, è di aspettarvi il trattamento a cui siete abituati e di “stare al gioco”. In realtà, trovo che alcune cose spesso funzionano meglio quando ti comporti in modo più stupido di quello che sei.

Ammettiamolo, se già sapete che il vostro ISP vi farà domande da uno script quando li chiamate, perché preoccuparsi di spiegare che c'è un problema con il DHCP sul vostro router perché il vostro computer si sta assegnando un indirizzo APIPA quando potete semplicemente dire “Non riesco a entrare su Google” e loro faranno esattamente la stessa cosa? Inoltre, se si usa il tech speak su qualcuno in prima linea che non lo capisce c'è la possibilità che pensino di essere supposto di sapere come risolvere il problema, per poi perdere tempo a provarci. Se invece si usano solo termini stupidi come “le luci lampeggiano”, allora si esaurisce rapidamente il loro script e si passa alla seconda riga dove si può tranquillamente parlare tech-to-tech.

Sono stato uno sviluppatore web freelance per un certo numero di anni e ho affrontato questa situazione innumerevoli volte.

La migliore linea d'azione che ho trovato è quella di chiamarli piuttosto che mandargli un'e-mail, spiegare il problema come si farebbe con un altro sviluppatore nel modo più semplice possibile e chiedere se è possibile ottenere le informazioni dal sysadmin team.

Questo approccio sembra funzionare (per me) perché si mostra la conoscenza del campo in modo naturale e si mostra anche che si sa come funziona l'amministrazione del sistema in generale.

La cosa più importante è che non ci metti le parole d'ordine per il gusto di farlo , questo ti farà uscire fuori strada e come se non avessi idea di quello che stai facendo.

Chiamare via e-mail ha una serie di vantaggi, sei in grado di entrare in empatia con la persona e loro sono in grado di sentire quanto ti senti a tuo agio con l'argomento al telefono.

Il 90% delle volte ti eleva a qualcuno che sa cosa fare, oppure si mette in contatto con il reparto corretto.

Se gli invii un'e-mail, è probabile che tu riceva una risposta in stock, perché le persone (o l'IA) che rispondono a questo livello di supporto si limiteranno a copiare-incollare una risposta generale prima.

Attualmente lavoro per una piccola azienda IT che fornisce supporto alle imprese in città. Sono il supporto tecnico/help desk per l'azienda.

Processo

La nostra azienda probabilmente lavora in modo diverso rispetto alle grandi aziende - quando si invia un'e-mail all'helpdesk@ indirizzo e-mail della nostra azienda, l'e-mail va direttamente al nostro software di ticketing, che poi ci invia un'e-mail dicendoci che è stato inserito un ticket. Poiché il nostro reparto IT è composto da 5 persone (me compreso), quando arriva un ticket, chi ha già affrontato questo problema o chi sa come risolverlo sarà quello che vi contatterà. *** Vale la pena di notare che io sono un entry-level (supporto di livello 1), ma gli altri 4 ragazzi sarebbero considerati di livello 3.

Quando un biglietto viene inviato via e-mail in cerca di una password reimpostata, lo prendo. Oppure - e voglio sottolineare questo - quando un biglietto arriva con informazioni insufficienti, lo prendo. Per esempio, se si invia un'e-mail in un biglietto “Le mie prospettive non funzionano”, quel biglietto viene assegnato a me. Ti rispondo e passo attraverso il processo di

“Si apre? Avete internet? Conoscete la password giusta?”

E se le vostre risposte mi dicono che è qualcosa di troppo avanzato per me, solo allora lo intensificherei.

Putate tante informazioni sul problema stesso nell'e-mail, entro i limiti del ragionevole. Non c'è bisogno di scrivere un paragrafo, che toglie tempo a voi e a noi. I punti punti sono perfetti (preferibilmente).

Il nostro processo telefonico è diverso da quello delle e-mail. Se chiami l'help desk, ** mi ricevi.** Solo io. Questo è tutto. E io so nulla. Poiché siamo una piccola azienda, non ho lo script aziendale in sé, ma ho le stesse domande che faccio a tutti: quando è iniziato, sei l'unico ad avere il problema, eventuali messaggi di errore specifici, ecc. I clienti abituali che chiamano ora rispondono a ogni domanda in ordine prima che io debba chiedere (persone meravigliose). La maggior parte delle volte, quando le persone chiamano con un problema sono l'unico in ufficio - i tecnici sono occupati. Follemente occupati. Così, quando mi descrivete un problema al quale non ho idea di come risolvere, prendo appunti. Un sacco di appunti. E poi vi dico che inserirò un biglietto e qualcuno vi risponderà. Questo è tutto.

Recap

Se invii un'e-mail all'helpdesk (in particolare a noi), se usi dettagli tecnici appropriati, probabilmente riceverai qualcuno che sa quello che sta facendo e lo apprezzerà molto.

Se chiami, riceverai solo me. Vi farò un sacco di domande, con pause imbarazzanti nel mezzo, mentre scrivo i miei appunti, e alla fine probabilmente non sarò in grado di aiutarvi. I dettagli tecnici sono comunque benvenuti, ma ci sono alcune domande che vi farò comunque anche se vi sembreranno inutili (qualcun altro potrebbe aver avuto lo stesso problema nello stesso momento - bandiera rossa).

My Advice

Torna indietro attraverso le email che hai scambiato con l'helpdesk in precedenza. Cercate le domande che vi sono state poste ogni volta e inserite le risposte nell'e-mail iniziale che inviate sul nuovo problema. Cercate di aggiungere cose che facciano sembrare il potenziale problema locale. Più informazioni date loro che sapete che chiederanno nel loro script, più velocemente troverete qualcuno che possa aiutarvi. E vi ringrazieranno per questo.

Lavoravo nel supporto di web hosting, in modo da poter fornire una prospettiva dall'altro lato.

Una delle maggiori sfide del lavoro è la corretta misurazione del livello tecnico del cliente. A seconda dell'host, si ottengono biglietti da uno qualsiasi, da dilettanti totali a professionisti che sono più qualificati di te. Ovviamente devi adattare la tua risposta per renderla comprensibile a loro, e a volte ti sbagli.

Per esperienza posso dire che i professionisti saranno più indulgenti se passi attraverso le cose a livello base rispetto ai dilettanti che non hanno idea di cosa stai parlando, quindi le persone probabilmente sbaglieranno dalla parte della prudenza e non daranno per scontato che il cliente abbia un alto livello di competenza.

Allora cosa puoi fare per dimostrare la tua conoscenza tecnica? Beh, state facendo la cosa giusta utilizzando i termini tecnici corretti. Questo darà un'indicazione alla persona che gestisce il biglietto. Spiegare esplicitamente il vostro ruolo di amministratore o sviluppatore dovrebbe anche aiutare.

Spiegare ciò che avete fatto prima di sollevare il ticket. Se siete subito dopo i log potete dire “Ho controllato il pannello di controllo e la directory principale FTP e non ho trovato alcun modo per accedere ai log di errore”. Questo darà un'ulteriore indicazione del fatto che sapete come funzionano le cose.

Fate riferimento ai ticket precedenti in cui avete chiesto la stessa cosa, se possibile con un ID del ticket. Supponendo che abbiate a che fare con lo stesso host, questo dovrebbe risolvere il vostro ticket in un unico aggiornamento (supponendo che il supporto sia quasi competente). Dovrebbero semplicemente leggere il ticket precedente e sapere esattamente di cosa avete bisogno.

Questo potrebbe non essere possibile, ma sarebbe d'aiuto se investiste nell'hosting per rivenditori che è progettato per gli sviluppatori che ospitano molti siti web e spostano i siti che gestite sotto di esso. L'host dovrebbe essere in grado di capire facilmente dal tuo account che sei un professionista. Anche tali servizi di hosting probabilmente rendere i registri disponibili senza dover chiedere supporto.

Le cose da non fare includono la richiesta di escalation al supporto di seconda linea nel vostro primo aggiornamento. Questo non succederà. I lavoratori del supporto di prima linea sono probabilmente valutati in base al numero di biglietti che escalano e non lo faranno a meno che non siano certi di averne bisogno. Non arrabbiatevi e iniziate a dare valutazioni negative, perché questo può rendere le persone meno collaborative.

Spero che possiate fare un respiro profondo……

Il supporto tecnico funziona con gli script. Basta conoscere questi script a memoria e rispondere a tutte le domande dello script in una lunga frase, prima che lo chiedano.

Come in “Ciao ho un problema con questo e quello….. Ho riavviato il router, ho controllato i cavi, la luce rossa è accesa, la luce verde è spenta, non lampeggiano altre luci…….etc.etc.etc.etc.

In questo modo la persona all'altro capo della linea può semplicemente fare click-click-click e tu sarai 10 passi più avanti nel suo script in 5 secondi.

Spesso non vi aiuterà. Molte hotline di supporto hanno uno script da utilizzare. Quindi, se hai un problema con la tua connessione internet e il tuo router ti dice il motivo esatto, ti chiederanno comunque di riavviare il tuo router.

Puoi stare al gioco e farlo e basta, oppure gli dici che l'hai già fatto. Poi possono fare il segno di spunta “il cliente ha riavviato il router, il problema persiste” e fare la domanda successiva. Forse misurano la linea (e noteranno che la linea è perfettamente a posto, proprio come ti dice il tuo router internet nella sua interfaccia). Il segno di spunta successivo. L'obiezione non sarà d'aiuto, se il loro protocollo richiede di effettuare questo controllo. Quindi lasciate che lo facciano. Meno si obietta, più velocemente finiranno tutti i test e arriveranno al problema reale.

Sì, certo che è frustrante. E forse anche per la persona di supporto. Il supporto di primo livello è un lavoro frustrante. Ma d'altra parte bisogna capirli. Ci sono davvero un sacco di persone che chiamano il loro internet non funziona quando scollegano il router per collegare l'aspirapolvere. E chiedere loro se pensano di sapere quello che stanno facendo non sarà d'aiuto, perché molte persone sopravvaluteranno le loro conoscenze, rendendo il supporto ancora più complicato perché il tecnico all'inizio potrebbe credergli e scoprire solo in seguito che hanno detto cose sbagliate perché in realtà non sanno quello che fanno finta di sapere.

Potresti avere fortuna e ottenere la prossima volta la stessa persona di supporto o qualcuno che ha un protocollo dell'ultima chiamata e che conosce già i soliti problemi che stai avendo e come risolverli.

Sono particolarmente interessato alle opinioni di persone che hanno lavorato/lavorano nel supporto tecnico e conoscono l'altro lato della recinzione.

Check.

Come posso dimostrare al supporto tecnico che sono abbastanza qualificato per ricevere direttamente le informazioni richieste senza sembrare arrogante?

Per citare I soliti sospetti: “Secondo me, non si può fare”.

1. Loro potrebbero non essere qualificati per conoscere le informazioni richieste.
2. 2. Se le conoscono, è probabile che non siano autorizzati a darne comunicazione.
3. Se in qualche modo non gli è stato proibito di dare certe informazioni, non c'è ancora modo di convincerli che ci si può fidare di te.
4. Se la società di hosting (o qualsiasi organizzazione da cui stai cercando di ottenere supporto) volesse farti sapere qualcosa, te lo avrebbe già detto o reso disponibile.

Francamente, le persone che si sentono “qualificate” a guardare dietro le quinte (e questo include soprattutto gli sviluppatori) sono una delle principali categorie di clienti fastidiosi per gli addetti all'assistenza tecnica. Il sipario c'è per molte buone ragioni, non solo perché la maggior parte delle persone non capirebbe cosa c'è dietro. Il fatto che tu voglia sapere più di quanto ti è già stato detto mi suggerisce che potresti avere meno comprensione del quadro generale di quanto tu possa pensare.

C'è una soluzione al tuo problema. Se avete davvero bisogno di avere la conoscenza e il controllo dei sistemi che ospitano il sito o i siti web che state supportando, allora dovrete scegliere di gestire quei sistemi da soli. Questo non significa acquistare server costosi o pagare un sacco per una larghezza di banda incredibile da qualche parte. Vi suggerisco di provare un servizio cloud pubblico come Microsoft Azure o Amazon AWS e vedere se questo si adatta meglio alle vostre esigenze. Con servizi come questo, puoi scegliere quanto controllo hai (più controllo è più costoso). Un modo per guardare alla vostra situazione attuale è che non siete pagati abbastanza per dirvi i dettagli cruenti, non che non siete abbastanza informati.

Una soluzione che ha risolto questo problema con il mio ISP è stata che quando sono passato attraverso la prima e la seconda linea e mi sono messo in contatto con le persone che hanno risolto il mio problema, ho chiesto loro se potevano darmi uno dei loro numeri personali nel caso in cui lo stesso problema si fosse verificato di nuovo.

Il problema si è verificato un altro paio di volte, e ho appena chiamato direttamente lo stesso tizio.

La risposta semplice è che non si può - non ci sono parole che permettono di eludere il processo di checklist che la maggior parte dei team di supporto di prima linea utilizzano. Beh, oltre a conoscere le risposte da dare che vi permettono di attraversare la catena più breve fino al punto in cui devono passare alla seconda linea…

Invece, guardate se offrono un'opzione di supporto in cui si dispone di un contatto dedicato di seconda linea. Questo sarà più costoso, ma potenzialmente ne vale la pena.

Sentitevi liberi di accennare, vantarvi o entrambe le cose! I migliori rappresentanti della CS dovrebbero facilmente prendere un suggerimento da un linguaggio chiaro e da una firma come John Appleseed, JavaScript/Ruby Developer, ma qualsiasi persona può capire una semplice frase come “So quello che sto facendo, quindi apprezzerei una spiegazione extra-tecnica!”

Considerate che molti clienti sono maleducati o arroganti, quindi potete tranquillamente vantarvi un po’ e apparire ancora come relativamente meravigliosi! Aiutateli ad aiutarvi con questo breve vanto e vi saranno solo riconoscenti. E ricordate: sii gentile e va bene perdere la modestia per una frase o due!

Fonte: Sono un rappresentante della CS in un'azienda tecnologica, e apprezzo quando i clienti esperti mi danno un indizio!

Prima di tutto, vorrei iniziare presentandovi:

Caro team di supporto XYZ

Sono lo sviluppatore web responsabile del sito web example.com.

Presentandovi in questo modo, state stabilendo la cornice per trattarvi, suggerendo che si dovrebbe presupporre che siate qualcosa abile, in modo da poter scegliere di rispondere in un dettaglio più tecnico. Notate che se in realtà è stata la vostra colpa (come ad esempio non trovare i cambiamenti perché vi stavate connettendo al webhost sbagliato), la maggiore conoscenza che avete sottinteso di avere, è più probabile che vi considereranno probabilmente non un buon “esperto” (anche se tutti commettiamo errori stupidi di tanto in tanto). ¹

Non credo che dire loro che sei l’“amministratore” del sito lo trasmetta, dato che questo potrebbe valere per chiunque abbia un account di amministratore sul CMS, indipendentemente dalla sua competenza.

¹ Non che importi molto dopo la chiusura del ticket. A meno che non li contattiate così spesso che ricordino voi, il che sarebbe bello se avessero una buona opinione, e probabilmente significa che si intontiranno ancora di più se pensano che non ne abbiate la minima idea.

In secondo luogo, spiegate chiaramente il problema:

Il mio cliente sta riscontrando un problema in cui il suo WordPress 4.9.4 installato non mostra il contenuto aggiornato dopo la modifica. Egli sostiene che ciò accade su diversi computer e browser. Alla fine, però, verrà mostrato.

Sto affermando il problema, la tecnologia utilizzata fino alla versione attuale. E anche i fatti che non avete verificato voi stessi vengono qualificati come tali (non sarebbe improbabile che vi sia stato detto qualcosa di sbagliato).

In terzo luogo, dichiarate la risoluzione dei problemi già eseguita e i loro risultati:

Non è installato alcun plugin di caching, e l'opzione “Mostra contenuto stantio” disponibile sulle preferenze del sito è disabilitata.

Allora, potete avanzare la vostra ipotesi:

Avete qualche altro livello di caching che potrebbe influenzare il cliente? C'è un proxy di caching (come il calamaro o la vernice) che serve le pagine prima di essere servite da Apache?

Qui si ipotizza che ci sia un proxy che serve le pagine in cache. La menzione di pacchetti reali può essere utile nel caso in cui il team di supporto non conoscesse i “proxy caching”, ma ricorda che c'è qualcosa chiamato “varnish” installato lì.

Grazie per la vostra attenzione

Siate gentili nei vostri biglietti, tenete gli identificatori dei biglietti sull'argomento, occupatevi della vostra ortografia, organizzate il testo in paragrafi. Un testo bello da leggere sarà più facile da gestire di uno in cui bisogna indovinare di cosa parla, e proprio per questo probabilmente la risposta sarà più rapida. Inoltre lo sforzo risparmiato nella comprensione può essere indirizzato al problema reale.

Includere screenshot se necessario (e supportato dal sistema di biglietteria). In questi stessi casi possono mostrare il problema meglio di una descrizione testuale (a volte, c'è un suggerimento cruciale che può essere ottenuto). Se si utilizza la riga di comando, fornire sia il comando che il suo output.

Attenzione che rendere un testo troppo lungo può avere anche l'effetto opposto. Se pensate che la spiegazione lunga possa effettivamente scoraggiare la risposta, potete organizzarvi diversamente:

Caro team di supporto XYZ

Avete qualche livello di caching davanti al vostro pacchetto FooWebsites?

Il problema che mi trovo ad affrontare è che il cliente non vede immediatamente le modifiche che ha eseguito in WordPress 4.9.4.

Ho già controllato le seguenti cose:

(…)

Se alcuni dati sono lunghi (come un file di debug), potete fornirli su un allegato. In questo modo, se irrilevante, può essere saltato non aprendolo. A seconda della piattaforma di ticket, potrebbero altrimenti avere bisogno di scorrere sette pagine di log prima di leggere la risposta successiva.

Se c'è qualche informazione in più di cui probabilmente non avranno bisogno, potete semplicemente offrire di fornirla (“Ho registrato un video che esegue le fasi di pubblicazione e dove si può vedere il problema, sareste interessati su di esso?”).

Dovreste a volte fare un follow-up riconoscendo che la loro soluzione ha funzionato. Soprattutto se avete fatto avanti e indietro con il supporto tecnico. Piuttosto che presentare una lista di possibilità per risolvere il problema del contenuto stantio e non sentirvi rispondere, è bello ricevere:

Grazie mille, cambiando questa opzione in cPanel l'avete risolto. Sei il migliore!

In questo modo, l'HelpDesk può notare il problema così come è stato risolto e chiuderlo. Prendetelo con un granello di sale, però, poiché potrebbe essere che il biglietto sia già stato chiuso dopo la loro risposta, e ringraziandoli lo riaprirà (generando altro lavoro). Quindi, se pensate che questo sarà il caso, potrebbe essere auspicabile non farlo (specialmente se è stata una risposta facile per loro). Se non conoscete lo stato del biglietto al loro fianco, vi consiglio di sbagliare sul lato del riconoscimento della soluzione e ringraziando, pero’. Le persone che vi rispondono sono esseri umani (si spera), e meritano di essere trattate come tali. In generale, è molto semplice ri-chiudere un messaggio di ringraziamento di questo tipo.

In generale, cercate di seguire le linee guida per porre domande tecniche, come il famoso Eric S. Raymond How To Ask Questions The Smart Way .

Potrebbe essere necessario un po’ più di tempo per dichiarare ciò che avete provato invece di dire semplicemente “WordPress non funziona”, ma in questo modo presentate la vostra abilità con il vostro lavoro. E può anche risparmiarvi del tutto la domanda (affermare il problema può suggerire una soluzione, o fornire un modo per ottenere una conferma di ciò che sta accadendo da soli). Sarà comunque più veloce che se dovessero iniziare a chiedervi “_In che modo non funziona, cosa avete provato? _” seguendo uno script.

Raccomando di inviare una e-mail/biglietto invece di chiamare. A meno che non abbiate un costoso contratto di assistenza (e probabilmente anche in quel caso), le chiamate saranno gestite dal livello più basso, e potrebbe effettivamente essere necessario convertirlo in un biglietto in caso di escalation come notato da Gypsy ). Se si contatta via e-mail, le informazioni fornite (non il modo in cui il primo livello ha capito alcune parti di ciò che hai detto) sono disponibili a chiunque gestisca il biglietto (anche a te stesso!), il che permette una comunicazione meno rumorosa. Inoltre ti risparmia di dover spiegare tutto dall'inizio ad ogni agente ogni volta che vieni trasferito.

Accenni al fatto che _ scrivi molte di queste email e che sono una perdita di tempo per te e per tutti gli altri_. Direi che c'è qualcosa che non va se hai bisogno di spendere troppo tempo in relazione al lavoro “normale” per mantenere la situazione. Forse non siete così abili [nel modo in cui i vostri amici WordPress sono installati], il webhost sta facendo cose non comuni, il loro supporto tecnico è incompetente… A un certo punto potrebbe avere senso cambiare fornitore.

Potreste scoprire che anche se la vostra domanda è chiarissima, vi vengono fornite risposte lunghe con molti punti non troppo rilevanti per il vostro problema, “sprecando il loro tempo”. Ad esempio, dopo aver chiesto a quale host si dovrebbe ssh a, non solo indicano dove trovarlo, ma anche come accedere via FTP e spiegano come scaricare ed eseguire PuTTY.

Ciò non significa che non capendo che siete abili hanno speso molto tempo per spiegarvi i concetti di base. Quando c'è una domanda frequente, ci sarà un modello per la soluzione, ed è in realtà più veloce rispondere spiegando tutto piuttosto che limitarsi a ciò che è stato chiesto. Quindi, se c'è un caso in cui il resto può essere utile, ha senso lasciarlo anche se può essere un po’ ridondante per il vostro profilo.

Avere una comunicazione scritta va in entrambi i sensi, in quanto si può scremare la risposta alla parte in cui si spiega ciò che si voleva. Tuttavia, se avete bisogno di chiedere indietro, non leggete tutto e confermate che non era in un'altra parte della loro risposta.

Ciononostante, non importa quanto ben spiegato sia tutto, a volte vi metterete in contatto con un supporto tecnico che non riuscirà a rispondere correttamente alla vostra richiesta la prima volta.

Sono uno studente di CS e ho chiamato più volte il nostro ISP a causa di problemi di rete, ma mai con successo. Hanno detto solo di riavviare il router e di chiamare di nuovo se il problema persiste per qualche giorno. A un certo punto ho notato un messaggio di errore nel registro dei router che implicava fortemente che il problema era all'interno della loro rete. Quello che ho fatto allora, per aggirare il supporto tecnico telefonico che non sembra sapere molto, è stato di tweet a loro.

Questo ha molteplici effetti:

• Se non rispondono, è una cattiva PR
• Possono rispondere quando trovano il tempo di farlo
• Possono andare a prendere le persone che dovrebbero effettivamente sapere come rispondere

Nel mio caso, mi è stato chiesto di dare un po’ più di informazioni su Twitter Direct Messaging ed è stato circa una settimana dopo chiamato da un esperto.

Ma se non stai segnalando un problema dalla loro parte; se stai solo facendo una domanda, allora il supporto telefonico sarebbe probabilmente la scelta migliore perché non hai provato alcune delle soluzioni ridicolmente semplici (almeno mi dimentico sempre di provarne una) e a volte semplicemente non conosciamo la loro architettura interna. In questo caso, le altre risposte sono più adatte. Tuttavia, cosa c'è di sbagliato nel dire loro che stai lavorando come [Inserisci il titolo della tua posizione] e sai di cosa stai parlando?

Di solito inizio con qualcosa come:

Ehi, sono un dottorando di ricerca in [field] e faccio [qualcosa] professionalmente. Prima di chiamarvi, ho ristretto il problema a [qualcosa da parte loro], quindi è questo che deve essere affrontato. Se potessi parlare con un ingegnere di [problema specifico], sarebbe fantastico; ma se dobbiamo esaminare il copione, facciamolo in fretta.

Se alla fine hanno bisogno del copione, allora il modo migliore per usare la vostra esperienza è di esaminarlo rapidamente. Mantenete le chiacchiere al minimo e fate le cose in modo efficiente. Se iniziano a descrivere come eseguire qualche passo, potreste interromperli con “Got it, just a sec.”, poi fateglielo sapere una volta che siete pronti per il passo successivo.

O se il supporto tecnico è via e-mail, allora potreste scrivere una descrizione del problema per loro con i dati che avete raccolto e una lista di cose da controllare. Questo può permettere loro di inoltrarla ad un ingegnere.

Trovo che la maggior parte del supporto tecnico sia pieno di personale inesperto e frustrato che ha appena eseguito un copione. Non sono pagati bene. Sono un supporto di primo livello per filtrare la maggior parte delle chiamate in arrivo. Il supporto tecnico è progettato a livelli.

Di solito chiedo di parlare con un ingegnere quando mi trovo a rilevare una persona di supporto inesperta. Non è colpa loro. Stanno solo facendo il loro lavoro al meglio e spesso la loro azienda gli impedisce di fare altro se non seguire lo script.

Dovete capire che il supporto tecnico viene costantemente bombardato da chiamate di persone che si rifiutano di imparare o di accettare soluzioni reali. Mentre allo stesso tempo alcuni di loro sono così inesperti che spesso non forniscono buone soluzioni e non lo sanno. Inoltre molti di loro sono pagati o valutati in base al numero di biglietti che chiudono, non alle soluzioni. È una pessima ricetta e purtroppo è diventata la norma.

Prendiamo ad esempio lo stack-exchange. È come un supporto tecnico. Ha un sacco di persone esperte ma è afflitto da collaboratori che non sono efficaci nel trattare con i dilettanti in modo professionale. Ora aggiungete il sistema di voto nel mix ed è molto simile a farsi valutare per la chiusura dei biglietti invece di fornire soluzioni.

Alcune persone, indipendentemente dal loro livello di esperienza, sono orribili come insegnanti. A un insegnante scolastico viene posta la stessa domanda ogni anno. Ogni anno gli risponde, anche se sembra ridondante, e le risposte sono semplici per Loro.

L'insegnamento richiede pazienza e l'accettazione di essere sottoposto ripetutamente a “domande stupide”. Se non riescono a sopportarlo, allora non dovrebbero semplicemente insegnare o fingere di essere insegnanti. Lo scambio di pile non è insegnamento o educazione. È solo dare risposte per gli upvotes. Proprio come per il supporto tecnico si tratta di chiudere i biglietti.

Date a un uomo un pesce e mangia per un giorno. Insegnategli a pescare e mangia per tutta la vita.

Il mio consiglio è che se siete alla ricerca di una risposta rapida e precisa chiedete di far alzare immediatamente il ticket di difficoltà e di parlare con un ingegnere che riconosca le vostre conoscenze e parli con voi al vostro livello.

Ho lavorato nel supporto tecnico di 1°, 2° e 3° livello per una banca internet, nello sviluppo informatico per varie aziende e nello sviluppo web come freelance. Mi sono occupato di tutto, dalla reimpostazione delle password fino allo sviluppo di sistemi aziendali complessi utilizzando una varietà di linguaggi su diverse piattaforme. Spero che non pensiate che io mi metta in mostra!

Comunque, anche quando ho iniziato ed ero relativamente inesperto, il 95% dei clienti aveva un livello di conoscenza inferiore a quello che avevo io quando si trattava di computer, quindi si cercava per default di non usare il gergo, si supponeva che non avessero fatto nulla per risolvere il problema ecc. Con l'esperienza si arriva ad avere un'idea di quanto fosse competente il cliente solo parlandogli per qualche secondo, ma bisogna stare attenti a non dare per scontato.

Le aziende tendono ad usare gli script, ma quelli buoni permetteranno al loro personale di allontanarsi dallo script una volta che hanno abbastanza esperienza per farlo, purché ciò vada a beneficio del cliente e dell'azienda, di solito questo comporta una soluzione più rapida del problema.

Al giorno d'oggi, quando voglio supporto tecnico, invio un'e-mail al mio web host e fornisco loro tutte le informazioni necessarie, cioè cosa ho cercato di fare per risolvere, cosa penso che il problema sia ecc. e di solito viene risolto per la prima volta entro poche ore. Se ho bisogno di assistenza urgente li chiamerò, ma il 99% delle volte l'e-mail è sufficiente e meno stressante, raramente ho bisogno di inviare una seconda e-mail.

Potreste voler considerare un nuovo webhost, in quanto il servizio può variare molto nella mia esperienza.

Sono particolarmente interessato alle opinioni di persone che … conoscono l'altro lato della barricata.

Sì, al college e subito dopo, ho avuto il titolo TS (supporto tecnico). Da allora, nel corso degli anni, ho scoperto che tutti gli sviluppatori fanno in qualche modo CS (assistenza clienti) - e più sei bravo, più sei considerato… ma questo è fuori tema.

Come faccio a dimostrare che sono abbastanza qualificato… senza risultare [nel modo sbagliato]?

Standard disclaimer che in realtà SI DIPENDE: (1) sull'azienda con cui hai a che fare, (2) sul rappresentante con cui lavori e (3) su come interagisci con loro.

** PRIMO TEMPO** con QUESTO PROCESSO (poca o nessuna storia con l'azienda)

La risposta breve è che la tua soluzione più rapida è fare TUTTO quanto segue: 1. 1. essere gentile con il rappresentante 2. rispondere educatamente alle loro domande 3. fare quello che vi hanno chiesto di fare, 4. anche se questo significa fare la stessa cosa di nuovo 5. rispondere brevemente, poi smettere di parlare

NOTA you can combine those: {1} {2} “Ok, dammi un momento, {3} Mi alzo per farlo. {4} Come ho detto prima, ho già fatto girare il mio router, ma {3} # We will give it another shot.# # We will give it another shot.# {3} Ho appena staccato di nuovo la spina, ho contato fino a dieci e {3} l'ho ricollegata”. {5}

Se scegli di dire ‘Te l'ho già detto’ {4} allora il tuo tono di voce è fondamentale.

Se dici quanto sopra con un tono di rimprovero, il rappresentante non vorrà aiutarti. E questo conta.

Sorridi tra una risposta e l'altra - specialmente se sei stanco o infastidito.

Il mio primo lavoro per la ST c'era un altro rappresentante che usava un linguaggio (sia maledetto che sessista) che però lo avrebbe fatto licenziare - ma aveva alcune delle migliori recensioni dei clienti… e non so se ha MAI avuto una lamentela contro di lui - sorrideva SEMPRE quando trattava con i clienti, e tutti evidentemente lo prendevano come uno scherzo. (Non ci proverei… ma per lui ha funzionato)

Il mio punto di vista nel precedente è che non importa così tanto esattamente ciò che dici. Your purpose is to get the rep on your side, quindi s/vuole aiutarti - quindi ottieni ciò che vuoi. E, in effetti, il rappresentante vuole la stessa cosa: una soluzione rapida.

REPEAT ISSUE (o qualche storia)

Hai dei dati aggiuntivi. Usate questo a vostro vantaggio! Diciamo che avete bisogno di registri; non potete procurarveli da soli, ma li avete già ottenuti: - Ehi, questo è di nuovo Bananenaffe. - Sto avendo lo stesso problema che avevo in Nov 2017. - Potreste fornirmi i registri di nuovo? Erano esattamente quello di cui avevo bisogno! - Ho parlato con <whoever> su Nov <day and time>. Mi ha dato i log con il ticket <number>.

Questo dimostra le DUE cose che la maggior parte dei rappresentanti vuole sentire:

1. non è una violazione delle regole ( qualcuno l'ha fatto )
2. c'è un vicino veloce a questo ticket.

Spero che questo aiuti