Hoe kan ik de technische ondersteuning subtiel laten weten dat ik bekwaam ben zonder te pronken?

Helaas zijn de tech support mensen die u spreekt waarschijnlijk net zo gefrustreerd als dat u door de basis dingen heen moet gaan met u.

Grote bedrijven hebben vooral te maken met het enorme volume aan tech support oproepen die ze ontvangen door wat personeel in dienst te nemen met een lager salaris als “buffer”, het omgaan met eenvoudige of “bekende” problemen zodat ze niet zoveel hoger betaald “tweede lijn” ondersteunend personeel in dienst hoeven te nemen. Heel vaak lezen de eerste mensen die u bereikt op de technische ondersteuningslijnen een script voor. Ze moeten u de domme vragen stellen, ofwel omdat hun werkgever dat eist, ofwel soms omdat hun computersysteem hen niet naar het volgende deel van het script laat gaan, tenzij ze de bal spelen. Wat niet wil zeggen dat mensen die op eerstelijnsondersteuning werken geen kennis hebben; mijn ervaring is dat veel overgekwalificeerde mensen minder geavanceerde banen in de IT moeten aannemen om in de industrie te komen. Maar ze moeten wel doen wat hun taakomschrijving hen opdraagt.

Dit verschilt wel van bedrijf tot bedrijf. Men zal idioten in dienst nemen die als idioten tegen je praten. Een ander zal slimme mensen in dienst nemen die zich tegenover jou verontschuldigen voor het feit dat ze alle zinloze stappen moeten doorlopen, maar dat is precies wat ze moeten doen! Misschien moet je maar eens rondkijken en er een vinden die met je omgaat zoals je dat wilt.

Maar ik waardeer het dat de prijs en de functionaliteit vaak dicteert met wie we omgaan. Dus mijn beste advies als je het bij hen moet houden is gewoon de behandeling te verwachten waaraan je gewend bent geraakt en ‘mee te spelen’. Eigenlijk vind ik sommige dingen vaak soepeler verlopen als je dommer doet dan je bent.

Laten we eerlijk zijn, als je al weet dat je ISP je vragen gaat stellen uit een script als je ze belt, waarom zou je uitleggen dat er een probleem is met de DHCP op je router omdat je computer zichzelf een APIPA-adres toewijst als je gewoon kunt zeggen “Ik kan niet op Google” en ze zullen precies hetzelfde doen? Plus, als je tech spreekt op iemand op de eerste lijn die het niet begrijpt is er een mogelijkheid dat ze zullen denken dat ze verondersteld zijn om te weten hoe dit op te lossen, en dan tijd te verspillen aan het proberen om. Terwijl als je gewoon domme termen als “lichten knipperen” gebruikt, dan zullen ze snel hun script uitputten en je doorsturen naar de tweede regel waar je met plezier tech-to-tech kunt praten.

Ik ben al een aantal jaren freelance webontwikkelaar en heb deze situatie ontelbare keren behandeld.

De beste manier van werken die ik heb gevonden is om ze te bellen in plaats van ze te e-mailen, ** het probleem zo eenvoudig mogelijk uit te leggen zoals je zou doen met een andere ontwikkelaar** en te vragen of het mogelijk is om de informatie van het sysadmin team te krijgen.

Deze aanpak lijkt (voor mij) te werken omdat je kennis van het vakgebied op een natuurlijke manier laat zien en je ze ook laat zien dat je weet hoe het systeembeheer in het algemeen werkt.

Het allerbelangrijkste is dat je er geen modewoorden voor inbrengt** , hierdoor kom je op het verkeerde been en heb je geen idee wat je doet.

Bellen via e-mail heeft een aantal voordelen, je kunt je inleven in de persoon en zij kunnen horen hoe comfortabel je bent met het onderwerp via de telefoon.

90% van de tijd verheffen ze je tot iemand die weet wat je moet doen, of ze nemen contact op met de juiste afdeling.

Als je ze e-mailt, krijg je waarschijnlijk een voorraad antwoord omdat de mensen (of AI) die op dit niveau van ondersteuning reageren, eerst een algemeen antwoord zullen kopiëren-plakken.

Ik werk momenteel voor een klein IT-bedrijf dat ondersteuning biedt aan bedrijven in de stad. Ik ben de technische support/helpdesk voor het bedrijf.

Proces

Ons bedrijf werkt waarschijnlijk anders dan de grote bedrijven - wanneer je de helpdesk@ email adres voor ons bedrijf mailt, gaat de email direct naar onze ticketing software, die ons dan een email stuurt om ons te vertellen dat je een ticket hebt ingevoerd. Aangezien onze IT-afdeling bestaat uit 5 personen (waaronder ikzelf), is degene die dit probleem al eerder heeft aangepakt of weet op te lossen, degene die contact met u moet opnemen als er een ticket binnenkomt. **Het is de moeite waard om hier op te merken dat ik instapniveau (tier 1 support) ben, maar de andere 4 mensen zouden worden beschouwd als tier 3 niveau.

Wanneer een ticket wordt gemaild om een wachtwoord te resetten, neem ik het. Of - en ik wil dit benadrukken - ** wanneer een ticket binnenkomt met onvoldoende informatie, neem ik het.** Bijvoorbeeld, als je in een ticket “My outlook is not working” emailt, wordt dat ticket aan mij toegewezen. Ik neem contact met je op en ga door het proces van

“Gaat het open? Heb je internet? Weet je het juiste wachtwoord?”

En als je antwoorden mij vertellen dat het iets te geavanceerd is voor mij, alleen dan zou ik het laten escaleren.

Plaats zoveel mogelijk informatie over het probleem zelf in de e-mail, binnen de grenzen van het redelijke.Het is niet nodig om een paragraaf te schrijven, dat neemt tijd weg van jou en van ons. Bullet points zijn perfect (voorkeur).

Ons telefoonproces is anders dan dat van e-mails. Als je de helpdesk belt, ** krijg je me te pakken.** Alleen ik. Dat is het. En ik weet niets. Omdat we een klein bedrijf zijn, heb ik het bedrijfsscript op zich niet, maar ik heb wel dezelfde vragen die ik aan iedereen stel: wanneer is het begonnen, ben jij de enige die het probleem heeft, eventuele specifieke foutmeldingen, enz. Stamgasten die nu bellen beantwoorden elke vraag in volgorde voordat ik het moet vragen (geweldige mensen). Meestal, als mensen bellen met een probleem, ben ik de enige op kantoor - de technici hebben het druk. Waanzinnig druk. Dus als je me een probleem aanprijst waar ik geen idee van heb hoe ik het moet oplossen, maak ik aantekeningen. Veel aantekeningen. En dan vertel ik je dat ik een kaartje in zal voeren en dat iemand je terug zal bellen. Dat is het wel zo'n beetje.

Recap

Als je de helpdesk (ons in het bijzonder) mailt, krijg je waarschijnlijk iemand die weet wat hij doet, en die het erg op prijs stelt.

Als je belt, krijg je mij alleen. Ik zal u veel vragen stellen, met lastige pauzes tussendoor terwijl ik mijn notities schrijf, en aan het eind zal ik u waarschijnlijk niet kunnen helpen. Technische details zijn nog steeds welkom, maar er zijn enkele vragen die ik je toch zal stellen, ook al klinken ze nutteloos voor je (iemand anders zou op hetzelfde moment hetzelfde probleem kunnen hebben gehad - rode vlag).

Mijn advies

Ga terug door de e-mails die je eerder met de helpdesk hebt uitgewisseld. Zoek elke keer naar bepaalde vragen die zijn gesteld, en zet die antwoorden in de eerste e-mail die u stuurt over het nieuwe probleem. Probeer dingen toe te voegen die het potentiële probleem lokaal laten klinken. Hoe meer informatie je ze geeft waarvan je weet dat ze in hun script zullen vragen, hoe sneller je iemand krijgt die je kan helpen. En ze zullen u er dankbaar voor zijn.

Vroeger werkte ik in webhosting support, zodat ik een perspectief kan bieden vanuit de andere kant.

Een van de grootste uitdagingen in de baan is het goed meten van het technische niveau van de klant. Afhankelijk van de host, krijg je tickets van eender wie van de totale amateurs naar professionals die meer gekwalificeerd zijn dan jij. Uiteraard moet je je reactie op maat maken om het voor hen begrijpelijk te maken, en soms heb je het mis.

Uit ervaring kan ik zeggen dat professionals vergevingsgezinder zullen zijn als je dingen op een basisniveau doorneemt dan amateurs die geen idee hebben waar je het over hebt, dus mensen zullen zich waarschijnlijk vergissen aan de kant van de voorzichtigheid en er niet van uitgaan dat de klant een hoog niveau van expertise heeft.

Dus wat kun je doen om je technische kennis te demonstreren? Wel, je doet het juiste door de juiste technische termen te gebruiken. Dat geeft een indicatie voor de persoon die het ticket afhandelt. Het expliciet uitleggen van je rol als beheerder of ontwikkelaar zou ook moeten helpen.

Leg uit wat je hebt gedaan voordat je het ticket ophaalt. Als je net achter de logs zit kun je zeggen “Ik heb het controlepaneel en de FTP root directory gecontroleerd en ik heb geen manier gevonden om bij de foutlogs te komen”. Dat geeft een verdere indicatie dat je weet hoe de dingen werken.

Verwijs naar eerdere tickets waar je hetzelfde hebt gevraagd, met een ticket ID indien mogelijk. Ervan uitgaande dat je met dezelfde host te maken hebt, zou dit je ticket in een enkele update moeten oplossen (ervan uitgaande dat de ondersteuning in de buurt van de competentie ligt). Ze moeten gewoon het vorige ticket doorlezen en precies weten wat je nodig hebt.

Dit is misschien niet mogelijk, maar het zou helpen als je investeerde in reseller hosting die is ontworpen voor ontwikkelaars die veel websites hosten en de sites die je beheert onder het te verplaatsen. De host moet gemakkelijk in staat zijn om van uw account te zien dat u een professional bent. Ook dergelijke hosting diensten waarschijnlijk de logs beschikbaar te maken zonder te vragen om ondersteuning.

Dingen niet te doen omvatten het vragen om escalatie naar de tweede lijn ondersteuning in uw eerste update. Dat gaat gewoon niet gebeuren. Eerste-lijn support medewerkers worden waarschijnlijk beoordeeld op hoeveel tickets ze escaleren en zullen dat niet doen, tenzij ze zeker weten dat ze dat nodig hebben. Word niet boos en begin met het geven van slechte beoordelingen, want dat kan mensen minder coöperatief maken.

Ik hoop dat je diep adem kunt halen….

Tech support werkt met scripts. Leer deze scripts gewoon uit je hoofd kennen en beantwoord alle vragen uit het script in één lange zin, voordat ze het vragen.

Zoals in “Hi I have a problem with this and that… Ik heb de router opnieuw opgestart, ik heb de kabels gecontroleerd, het rode lampje brandt, het groene lampje is uit, geen andere lampjes knipperen…..etc.etc.

Op die manier kan de persoon aan de andere kant van de lijn gewoon gaan klikken-klik-klikken en ben je 10 stappen verder in hun script in 5 seconden.

Vaak zal het je niet helpen. Veel support hotlines hebben een script, die ze moeten gebruiken. Dus als je een probleem hebt met je internetverbinding en je router vertelt je de exacte reden, zullen ze je toch vragen om je router te herstarten.

Je kunt ofwel meespelen en het gewoon doen of je vertelt ze dat je het al gedaan hebt. Dan kunnen ze het vinkje “klant herstart de router, probleem blijft bestaan” zetten en de volgende vraag stellen. Misschien meten ze de lijn (en zullen ze merken dat de lijn perfect in orde is, net zoals je internetrouter je vertelt in zijn interface). Volgende vinkje. Bezwaar maken zal niet helpen, als ze verplicht zijn om deze controle te doen door hun protocol. Laat ze dat maar doen. Hoe minder je bezwaar maakt, hoe sneller ze alle tests afmaken en naar het eigenlijke probleem komen.

Ja natuurlijk is het frustrerend. En mogelijk ook voor de supportmedewerker. Eerste niveau ondersteuning is een frustrerend karwei. Maar aan de andere kant moet je ze wel begrijpen. Er zijn echt veel mensen die bellen naar hun internet werkt niet als ze de stekker van de router uit het stopcontact halen om de stofzuiger aan te sluiten. En hen vragen of ze denken dat ze weten wat ze doen zal niet helpen, omdat veel mensen zullen overschatten hun kennis, waardoor de ondersteuning nog ingewikkelder als de tech man kan in eerste instantie geloven ze en pas later te weten komen dat ze verkeerde dingen verteld omdat ze niet echt weten wat ze doen alsof ze weten.

U kunt geluk hebben en krijgen de volgende keer dezelfde ondersteuning persoon of iemand die heeft een protocol van de laatste oproep en weet al de gebruikelijke problemen die je hebt en hoe om ze op te lossen.

Ik ben vooral geïnteresseerd in de mening van mensen die hebben gewerkt/werken in technische ondersteuning en de andere kant van het hek kennen.

Check.

Hoe toon ik technische ondersteuning dat ik gekwalificeerd genoeg ben om direct de benodigde informatie te krijgen zonder arrogant te worden?

Om De gebruikelijke verdachten te citeren: “Naar mijn mening kan het niet”.

1. Ze zijn misschien niet gekwalificeerd om de vereiste informatie te kennen.
2. Als ze het weten, mogen ze het waarschijnlijk niet uitgeven.
3. 3. Als het hen op de een of andere manier niet verboden is om bepaalde informatie te geven, is er nog steeds geen manier om hen te overtuigen dat u er mee vertrouwd kunt worden.
4. Als het hostingbedrijf (of een organisatie waar u ondersteuning van probeert te krijgen) u iets wilde laten weten, zouden ze het u al verteld hebben of die informatie beschikbaar hebben gesteld.

Eerlijk gezegd, mensen die zich “gekwalificeerd” voelen om achter het gordijn te kijken (en dit omvat vooral ontwikkelaars) zijn een van de hoofdcategorieën van vervelende klanten voor technische ondersteuningsmensen. Het gordijn is er om vele goede redenen, niet alleen omdat de meeste mensen niet zouden begrijpen wat er achter zit. Het feit dat je meer wilt weten dan je al verteld is, suggereert me eigenlijk dat je misschien minder inzicht hebt in het grote geheel dan je zou denken.

Er is een oplossing voor je probleem. Als je echt kennis en controle moet hebben over de systemen die de website(s) hosten die je ondersteunt, dan zul je ervoor moeten kiezen om die systemen zelf te beheren. Dat betekent niet dat je dure servers moet kopen of dat je ergens veel moet betalen voor geweldige bandbreedte. Ik stel voor dat u een publieke cloud service zoals Microsoft Azure of Amazon AWS uitprobeert en kijkt of dat beter past bij uw behoeften. Met dat soort diensten kunt u zelf kiezen hoeveel controle u heeft (meer controle is duurder). Een manier om naar uw huidige situatie te kijken is dat u ze niet genoeg betaalt om u de bloederige details te vertellen, niet dat u niet goed genoeg geïnformeerd bent.

Een oplossing die dit probleem oploste met mijn ISP was dat toen ik door de eerste en tweede lijn ging en in contact kwam met de mensen die mijn probleem oplosten, ik hen vroeg of ze me een van hun persoonlijke nummers konden geven voor het geval hetzelfde probleem zich opnieuw zou voordoen.

Het probleem deed zich nog een paar keer voor, en ik belde gewoon rechtstreeks naar dezelfde kerel.

Het eenvoudige antwoord is dat u dat niet kunt - er zijn geen woorden die u het proces van de checklist laten omzeilen die de meeste eerstelijnsondersteuningsteams gebruiken. Nou, naast het kennen van de antwoorden die je moet geven om door de kortste keten te komen tot een punt waar ze moeten escaleren naar de tweede lijn…

In plaats daarvan, kijk of ze een ondersteuningsoptie bieden waar je een toegewijd tweedelijnscontact hebt. Dit zal duurder zijn, maar potentieel de moeite waard.

Voel je vrij om te hinten, op te scheppen, of beide! De beste CS-reps zouden gemakkelijk een hint moeten nemen van duidelijke taal en een handtekening zoals John Appleseed, JavaScript/Ruby Developer, maar elk zal aanspreken met een simpele regel als “_Ik weet wat ik doe, dus ik zou een extra-technische uitleg op prijs stellen! _”

Bedenk dat veel klanten onbeleefd of arrogant zijn, dus je kunt veilig een beetje opscheppen en toch nog steeds als relatief geweldig uit de bus komen! Help ze je met die korte opschepperij en ze zullen je alleen maar waarderen. En onthoud: zou leuk zijn en het is oké om de bescheidenheid te verliezen voor een zin of twee!

Source: Ik ben een CS-er bij een technisch bedrijf, en ik waardeer het als slimme klanten me erin luizen!

Allereerst zou ik beginnen met jezelf te presenteren:

Beste XYZ support team

Ik ben de webontwikkelaar die verantwoordelijk is voor example.com website.

Door je op deze manier te presenteren, stel je het kader vast om je te behandelen, waarbij je laat doorschemeren dat je enigszins vakkundig moet zijn, zodat ze zouden kunnen kiezen om in een meer technisch detail te antwoorden. Merk op dat als het eigenlijk je fout was (zoals het niet vinden van de wijzigingen omdat je verbinding maakte met de verkeerde webhost), hoe meer kennis je impliceerde te hebben, het waarschijnlijker is dat ze op je neerkijken als geen goede “expert” (ook al maken we allemaal wel eens domme fouten). ¹

Ik denk niet dat het hen vertelt dat jij de “beheerder” van de website bent, want dat zou kunnen gelden voor iedereen met een beheerdersaccount op het CMS, ongeacht hun vaardigheid.

¹ Niet dat het veel zal uitmaken nadat ze het ticket hebben gesloten. Tenzij je zo vaak contact met ze opneemt dat ze herinner je, wat leuk zou zijn als ze een goede mening hebben, en waarschijnlijk betekent dat ze nog meer dom zullen zijn als ze denken dat je helemaal geen idee hebt.

Ten tweede, leg het probleem duidelijk uit:

Mijn klant ervaart een probleem waarbij zijn WordPress 4.9.4 installatie de bijgewerkte inhoud niet laat zien na het bewerken. Hij beweert dat dit op verschillende computers en browsers gebeurt. Het zal uiteindelijk wel getoond worden.

Ik geef het probleem aan, de gebruikte technologie tot aan de eigenlijke versie. En ook de feiten dat je jezelf niet hebt gecontroleerd worden als zodanig gekwalificeerd (het zou niet onwaarschijnlijk zijn dat je iets werd verteld dat verkeerd was).

Ten derde, vermeld de probleemoplossing die je al hebt uitgevoerd en hun resultaten:

Er is geen caching plugin geïnstalleerd, en de optie “Toon muffe inhoud” die beschikbaar is op de voorkeuren van de site is uitgeschakeld.

Dan mag je je hypothese:

Heb je nog een andere caching laag die de klant kan beïnvloeden? Is er een caching proxy (zoals inktvis of vernis) die de pagina’s bedient voordat ze door Apache worden geserveerd?

Hier gok je dat er een proxy is die de pagina’s in de cache bedient. De vermelding van daadwerkelijke pakketten kan nuttig zijn in het geval dat het support team niet op de hoogte was van “caching proxies”, maar onthoudt dat er iets genaamd “vernis” is geïnstalleerd.

Bedankt voor je aandacht

Wees beleefd in je tickets, houd de ticket identifiers over het onderwerp, zorg voor je orthografie, organiseer de tekst in alinea’s. Een tekst die leuk is om te lezen zal makkelijker te hanteren zijn dan een tekst waar je moet raden waar het over gaat, en alleen daarvoor zal het waarschijnlijk sneller beantwoord worden. Plus de moeite gespaard om het te begrijpen kan worden gericht op het eigenlijke probleem.

Neem screenshots op indien nodig (en ondersteund door het ticketing systeem). In dezelfde gevallen kunnen ze het probleem beter laten zien dan een tekstbeschrijving (soms is er een cruciale hint die kan worden verkregen). Als u de opdrachtregel gebruikt, geef dan zowel het commando als de uitvoer ervan.

Pas op dat een te lange tekst ook het tegenovergestelde effect kan hebben. Als u denkt dat de lange uitleg het antwoord daadwerkelijk kan ontmoedigen, kunt u het anders regelen:

Beste XYZ-ondersteuningsteam

Heeft u een cachinglaag voor uw FooWebsites pakket?

Het probleem waar ik mee te maken heb is dat de klant niet direct de wijzigingen ziet die hij in WordPress 4.9.4.

Ik heb de volgende zaken al gecontroleerd:

(…)

Als een deel van de gegevens lang is (zoals een debug-bestand), kunt u dat op een bijlage vermelden. Op deze manier, als het niet relevant is, kan het worden overgeslagen door het niet te openen. Afhankelijk van het ticketplatform kan het zijn dat ze anders zeven pagina’s met logs naar beneden moeten scrollen voordat ze het volgende antwoord lezen.

Als er wat extra informatie is die ze waarschijnlijk niet nodig hebben, kunt u gewoon aanbieden om die te verstrekken (“Ik heb een video opgenomen die de publicatiestappen uitvoert en waar het probleem te zien is, zou u daar geïnteresseerd in zijn?”).

U moet sometimes follow-up erkennen dat hun oplossing heeft gewerkt. Vooral als u heen en weer bent geweest met de technische ondersteuning. In plaats van een lijst met mogelijkheden te presenteren om het muffe inhoudelijke probleem op te lossen en niet terug te horen, is het leuk om te ontvangen:

Hartelijk dank, het veranderen van die optie in cPanel loste het op. U bent de beste!

Op deze manier kan de HelpDesk het probleem zo gerepareerd als mogelijk noteren en afsluiten. Neem het echter met een korreltje zout, want het kan zijn dat het ticket al gesloten was na hun antwoord, en het bedanken zou het heropenen (wat meer werk oplevert). Dus als je denkt dat dit het geval zal zijn, kan het wenselijk zijn om het niet te doen (vooral als het een gemakkelijk antwoord was voor hen). Als je de status van het ticket aan hun kant niet weet, zou ik aanraden om de oplossing te erkennen en Dank je wel. De mensen die je antwoorden zijn mensen (hopelijk), en verdienen het om als zodanig behandeld te worden. Het is over het algemeen heel eenvoudig om zo'n “Bedankt”-boodschap te onthouden.

Probeer in het algemeen de richtlijnen te volgen voor het stellen van technische vragen, zoals de beroemde Eric S. Raymond How To Ask Questions The Smart Way .

Het kan wat langer duren om te zeggen wat je hebt geprobeerd in plaats van gewoon te zeggen “WordPress werkt niet”, maar op die manier presenteer je je vakbekwaamheid door je werk. En het kan zelfs spaar je de vraag volledig (met vermelding van het probleem kan je een oplossing laten doorschemeren, of een manier bieden waarop je zelf een bevestiging kunt krijgen van wat er gebeurt). Het zal in ieder geval sneller gaan dan wanneer ze je zouden moeten vragen “_Op welke manier werkt het niet, wat heb je geprobeerd? _” volgens een script.

Ik raad aan om een e-mail/ticket te sturen in plaats van te bellen. Tenzij je een duur supportcontract hebt (en waarschijnlijk zelfs dan), zullen de telefoontjes worden afgehandeld door het laagste niveau, en kan het nodig zijn om dat om te zetten in een ticket als het escaleert zoals opgemerkt door Gypsy ). Als u contact opneemt via e-mail, is de door u verstrekte informatie (niet de manier waarop het eerste niveau sommige delen van wat u zei heeft begrepen) beschikbaar voor iedereen die het ticket afhandelt (zelfs voor uzelf!), wat een minder luidruchtige communicatie mogelijk maakt. Het spaart u ook uit om alles van het begin af aan aan elke agent uit te leggen wanneer u wordt overgeplaatst.

U vermeldt dat je veel van deze e-mails schrijft en ze zijn een verspilling van uw en iedereen els tijd. Ik zou zeggen dat er iets mis is als je te veel tijd moet besteden aan het “normale” werk om het ding bij te houden. Misschien bent u niet zo bedreven [in de manier waarop uw vrienden WordPress is geïnstalleerd], de webhost doet een aantal ongewone dingen, hun technische ondersteuning is incompetent… Op een gegeven moment kan het zinvol zijn om van aanbieder te wisselen.

U kunt erachter komen dat zelfs als uw vraag kristalhelder is, u lange antwoorden krijgt met veel punten die niet al te relevant zijn voor uw probleem, “hun tijd verspillen”. Bijvoorbeeld, na te hebben gevraagd naar welke host je moet sshen, geven ze niet alleen aan waar je het moet vinden, maar ook hoe je toegang kunt krijgen via FTP en hoe je PuTTY kunt downloaden en uitvoeren.

Dit betekent niet dat ze, door niet te begrijpen dat je bekwaam bent, veel tijd besteden aan het uitleggen van je basisconcepten. Wanneer er een veel voorkomende vraag is, zal er een sjabloon voor de oplossing zijn, en het is eigenlijk sneller om alles uit te leggen dan om te knippen naar wat er precies gevraagd is. Dus, als er een geval is dat de rest nuttig kan zijn, is het zinvol om het te laten, zelfs als het een beetje overbodig is voor uw profiel.

Het hebben van een schriftelijke communicatie gaat twee kanten op, want u kunt het antwoord afschuimen naar het deel waar ze uitleggen wat u wilde. Echter, als u het terug moet vragen, lees dan alles en bevestig dat het niet bij een ander deel van hun antwoord lag.

Desalniettemin, het maakt niet uit hoe goed alles uitgelegd is, soms zult u in contact komen met een techneut die de eerste keer uw verzoek goed zal falen te behandelen.

Ik ben een CS student en heb onze ISP meerdere malen gebeld vanwege netwerkproblemen, maar nooit tot enig nut. Ze zeiden net dat de router opnieuw te starten en opnieuw te bellen als het probleem aanhoudt gedurende een paar dagen. Op een gegeven moment merkte ik een foutmelding op in het logboek van de routers die sterk suggereerde dat het probleem zich binnen hun netwerk bevond. Wat ik toen deed, om de telefoon tech-support te omzeilen die niet veel lijkt te weten, is om tweet op hen.

Dit heeft meerdere effecten:

• Als ze niet reageren, is het slechte PR
• Ze kunnen reageren als ze de tijd vinden om dit te doen
• Ze kunnen de mensen die eigenlijk verondersteld worden te weten hoe ze

moeten beantwoorden halen In mijn geval werd mij gevraagd om wat meer informatie te geven over Twitter Direct Messaging en werd ongeveer een week later gebeld door een expert.

Maar als je geen probleem meldt aan hun kant; als je alleen maar een vraag stelt, dan zou telefonische ondersteuning waarschijnlijk de betere keuze zijn omdat je sommige belachelijk eenvoudige oplossingen niet hebt geprobeerd (ik vergeet er tenminste altijd een te proberen) en soms weten we gewoon hun interne architectuur niet. In dit geval zijn de andere antwoorden beter passend. Wat spreekt er echter tegen om hen gewoon rechtop te vertellen dat je werkt als [titel van je functie invoegen] en je weet waar je het over hebt?

Ik begin meestal met iets als:

Hé, ik ben gepromoveerd in [field] en doe [whatever] professioneel. Voordat ik je bel, heb ik het probleem vernauwd tot [iets aan hun kant], dus dat is wat er aangepakt moet worden. Als ik met een ingenieur zou kunnen praten over [specifiek probleem], zou dat geweldig zijn; maar als we door het script moeten lopen, laten we het dan snel uitpraten.

Als ze uiteindelijk het script nodig hebben, dan is de beste manier om je expertise te gebruiken om het snel door te nemen. Houd de chit-chat tot een minimum en doe de dingen gewoon efficiënt. Als ze beginnen te beschrijven hoe ze een bepaalde stap moeten uitvoeren, kunt u ze onderbreken met, “Got it, just a sec.”, laat ze dan weten wanneer u klaar bent voor de volgende stap.

Of als de technische ondersteuning via e-mail is, dan kunt u een probleemomschrijving voor ze schrijven met de gegevens die u hebt verzameld en een lijst van dingen voor hen om te controleren op hun kant. Dit kan hen in staat stellen om het door te sturen naar een ingenieur.

Ik vind dat de meeste technische ondersteuning gevuld is met onervaren en gefrustreerd personeel dat gewoon een script afloopt. Ze worden niet goed betaald. Ze zijn Tier One support om de meeste inkomende gesprekken uit te filteren. Tech support is ontworpen in niveaus.

Ik vraag meestal om met een engineer te spreken als ik een onervaren supportmedewerker aantref. Het is niet hun fout. Ze doen gewoon hun werk zo goed mogelijk en worden vaak door hun bedrijf beperkt in het doen van iets anders dan het volgen van het script.

Je moet begrijpen dat technische ondersteuning voortdurend wordt gebombardeerd door telefoontjes van mensen die weigeren om te leren of echte oplossingen te accepteren. Terwijl sommige van hen tegelijkertijd zo onervaren zijn dat ze vaak geen goede oplossingen bieden en het niet weten. Bovendien worden velen van hen betaald of beoordeeld op het aantal tickets dat ze sluiten, niet op oplossingen. Het is een slecht recept en helaas is het de norm geworden.

Neem stack-ruil als voorbeeld. Het is als een technische ondersteuning. Het heeft veel ervaren mensen, maar wordt geplaagd door medewerkers die niet effectief zijn in de omgang met amateurs op een professionele manier. Voeg nu het stemsysteem toe aan de mix en het is net zoiets als geëvalueerd worden voor het sluiten van tickets in plaats van het leveren van oplossingen.

Sommige mensen, ongeacht hun ervaringsniveau, zijn verschrikkelijk als leerkracht. Een schoolleraar krijgt elk jaar dezelfde vraag gesteld. Elk jaar geven ze antwoord, zelfs als het overbodig lijkt, en de antwoorden zijn eenvoudig te geven.

Onderwijs vereist geduld en de acceptatie van het herhaaldelijk gesteld worden van “domme vragen”. Als ze dat niet aankunnen, dan moeten ze gewoonweg niet lesgeven of doen alsof ze een leraar zijn. Stapeluitwisseling is geen lesgeven of onderwijs. Het is gewoon het geven van antwoorden voor upvotes. Net zoals wat technische ondersteuning gaat over het sluiten van tickets.

Geef een man een vis en hij eet voor een dag. Leer hem hoe hij moet vissen en hij eet een leven lang.

Mijn advies is als je op zoek bent naar een snel en accuraat antwoord vraag dan om het trouble ticket onmiddellijk te laten verhogen en te spreken met een ingenieur die je kennis zal herkennen en met je zal spreken op je niveau.

Ik heb gewerkt in 1e, 2e en 3e niveau technische ondersteuning voor een internetbank, IT-ontwikkeling voor diverse bedrijven en webontwikkeling als freelancer. Ik heb alles behandeld, van het resetten van wachtwoorden tot het ontwikkelen van complexe bedrijfssystemen met behulp van verschillende talen op verschillende platformen. Hopelijk denk je dat ik niet opschepperig ben!

Hoe dan ook, zelfs toen ik voor het eerst begon en ik relatief onervaren was, had 95% van de klanten een lager kennisniveau dan ik toen het om computers ging, dus je zou standaard proberen geen jargon te gebruiken, aannemen dat ze niets hadden gedaan om het probleem op te lossen, enz. Met ervaring zou je een idee krijgen over hoe kundig de klant was door gewoon een paar seconden met ze te praten, maar je moet voorzichtig zijn om niet te veronderstellen dat dingen.

Bedrijven hebben de neiging om scripts te gebruiken, maar de goede zullen hun personeel toestaan om af te dwalen van het script als ze eenmaal ervaren genoeg zijn om dat te doen, zolang het maar ten goede komt aan de klant en het bedrijf, meestal gaat het om het oplossen van het probleem sneller.

Als ik tegenwoordig technische ondersteuning wil, zal ik mijn webhost mailen en hen alle nodige informatie geven, d.w.z. wat ik heb geprobeerd op te lossen, wat ik denk dat het probleem is, etc. en meestal wordt het de eerste keer binnen een paar uur verholpen. Als ik dringend hulp nodig heb zal ik ze bellen, maar 99% van de tijd is e-mail voldoende en minder stressvol, zelden moet ik een tweede e-mail sturen.

U wilt misschien een nieuwe webhost overwegen, omdat de service nogal kan variëren in mijn ervaring.

Ik ben vooral geïnteresseerd in de opvattingen van mensen die… de andere kant van het hek kennen.

Yep, op de universiteit en net daarna had ik de titel TS (tech support). Sindsdien heb ik gemerkt dat alle ontwikkelaars CS (customer support) op de een of andere manier doen - en hoe beter je het doet, hoe beter je wordt beschouwd… maar dat is off topic.

Hoe laat ik zien dat ik gekwalificeerd genoeg ben… zonder er [verkeerd] vanaf te komen?

Standard disclaimer dat het eigenlijk DEPEND is: (1) op het bedrijf waar je mee te maken hebt, (2) op de reputatie waar je mee werkt, en (3) hoe je met hen omgaat.

• * FIRST TIME met THIS ISSUE (weinig of geen geschiedenis met het bedrijf)
• * Het korte antwoord is dat je snelste oplossing is om ALLE van de volgende dingen te doen:
• 1. wees aardig voor de rep
• beantwoord beleefd hun vragen
• doe wat ze je gevraagd hebben te doen,
• zelfs als dit betekent dat je hetzelfde opnieuw moet doen
• antwoord kort, stop dan met praten

OPMERKING je kan deze combineren: {1} {2} “Oké, geef me een momentje, {3} Ik sta op om dat te doen. {4} Zoals ik al eerder zei, ik heb mijn router al gefietst, maar {3} **We zullen het nog een keer proberen. Ik heb hem net weer losgekoppeld, geteld tot tien, en {3} weer ingeplugd.” {5}

Als je kiest om te zeggen ‘Ik heb je dat al gezegd’ {4} dan uw stemgeluid is kritisch.

Als je het bovenstaande op een snauwerige/beledigende toon zegt dan zal de rep je niet willen helpen. En dat doet er wel toe.

Glimlach tussen elke reactie - vooral als je moe of geïrriteerd bent.

Mijn eerste TS job was er een andere rep die taal gebruikte (zowel vloekend als seksistisch) die je wel zou hebben, maar hij had een aantal van de beste klantenbeoordelingen… en ik ben me er niet van bewust dat hij ooit een klacht tegen hem had - hij was ALTIJD aan het glimlachen toen hij met klanten omging, en ze namen het blijkbaar allemaal als een grapje mee. (Ik zou het niet proberen… maar het werkte voor hem)

Mijn punt in het vorige is dat het maakt niet uit zo veel precies wat je zegt. Your purpose is to get the rep on your side, dus hij wil je helpen - dat is wanneer je krijgt wat je wilt. En, in feite, de rep wil hetzelfde: een snelle oplossing.

• * REPEAT ISSUE (of wat geschiedenis)
• * Je hebt extra gegevens. Gebruik dit in je voordeel! Laten we zeggen dat je logs nodig hebt; je kunt ze zelf niet krijgen, maar je hebt ze al eerder gekregen:
• Hé dit is Bananenaffe weer.
• Ik heb hetzelfde probleem als in Nov 2017.
• Kun je me de logs ** opnieuw** geven? Ze waren precies wat ik nodig had!
• Ik sprak met <whoever> op Nov <day and time>. Hij/zij gaf me de logs met ticket <number>.

Dit demonstreert de TWEE dingen die de rep MOST wil horen:

1. het is geen overtreding van de regels ( sommige anderen deden het )
2. er is een snelle **sluiting bij dit ticket.

Hoop dat dit helpt