SOP for servicebesøg: anmodning og udkald
En SOP for servicebesøg og udkald hos Insatech: ServiceDesk-indtag og triage, beslutningen fjern eller på stedet, teknikertildeling, udstyrsklargøring, kundebesøget og den servicerapport, der lukker hver sag.
Hvad er SOP for servicebesøg: anmodning og udkald?
Enhver kundehenvendelse ind i Insatechs serviceforretning, uanset kanalen, lander ét sted: ServiceDesk. Det er bevidst. En kunde med en drivende flowaflæsning, en kunde hvis transmitter er stoppet med at svare, og en kunde der spørger, hvornår deres næste kalibrering forfalder, er alle, set fra kundens side, bare "ringer til Insatech om et instrumentproblem", og de skal ikke behøve vide på forhånd, hvilken af dem der er en femminutters telefonløsning, og hvilken der kræver en tekniker foran udstyret. Den vurdering hører hjemme hos ServiceDesk, truffet én gang, ved indtag, gennem "Teknisk triage ud fra symptomer og servicehistorik" og beslutningen "Fjernsupport tilstrækkelig, eller kræves besøg på stedet?", der følger efter. Alt, denne SOP dækker, findes for at få netop det ene opkald rigtigt: ikke hurtigt for hurtighedens skyld, og ikke forsigtigt for forsigtighedens skyld.
Beslutningen er SOP'ens reelle indhold, og den skærer begge veje. At udkalde en tekniker til noget, et telefonopkald ville have løst, koster en servicevogn, en dags rejse og teknikertimer, kunden ikke behøvede betale for, og det er den fejltype, ServiceDesk er bedst placeret til at fange, siden symptomerne som regel allerede står i sagen, når triagen er færdig. Den modsatte fejl er værre: at guide en kunde gennem en formodet sensorfejl, en akut sikkerhedsbekymring, eller noget der kræver håndsat adgang til ATEX-godkendt udstyr i et klassificeret område, fordi ingen ville booke et besøg. "Fjernsupport tilstrækkelig, eller kræves besøg på stedet?" er skrevet som en reel gren med to reelle destinationer, "Løs eksternt med kunden over telefon eller portal" på den ene side og "Tildel tekniker" på den anden, netop så det opkald skal træffes eksplicit, ud fra symptomerne i sagen, frem for at falde til default hos hvem der tilfældigvis sidder med telefonen.
De to grene forbliver ikke adskilte for evigt, og ingen af dem er en garanteret lige linje til afslutning. En fjernløsning springer "Bekræft at nødvendige reservedele er på lager, og pluk dem til opgaven", "Klargør testudstyr og læs servicevognen" og selve besøget over helt, og hopper direkte fra "Løs eksternt med kunden over telefon eller portal" til "ServiceDesk lukker sagen og bekræfter løsning logget". Et besøg på stedet kører gennem "Skriv servicerapport på stedet og indhent kundens underskrift" ind i en anden beslutning, "Sag fuldt løst under besøget?", fordi ikke hver opgave afsluttes på én tur: en del i bestilling, en isolation kundens proces ikke kan give den dag, eller en fejl der kræver en anden specialist viser sig alle her som "Opfølgning nødvendig" frem for en stille genåbnet sag, og ruter til "Log resterende arbejde og planlæg opfølgningsbesøg", der sendes tilbage til "Tildel tekniker" i stedet for at starte en adskilt anden sag. Begge eventuelle udfald, en telefonløsning og et fuldt løst besøg, mødes i samme række "ServiceDesk lukker sagen og bekræfter løsning logget". Den sammensmeltning er det, der holder en telefonløsning fra at blive en udokumenteret tjeneste: den lukker gennem den samme ServiceDesk-registrering som et udkaldt besøg, på samme sag, med samme ansvarlige. People og Workload er sat på hvert trin på begge grene og opfølgningssløjfen, så BI-panelet for arbejdsbyrde i en uge, hvor telefonerne er travle, kan vise, om det viser sig som Rikke Foss' ServiceDesk-timer, Thomas Riis' felttimer, eller begge dele.
Hvad dette flowchart dækker
I denne skabelon
- Indtag og triage, fra "Kunde kontakter ServiceDesk (telefon, e-mail eller portal)" over "Log sag og notér symptomer, instrument og proceskontekst" til "Teknisk triage ud fra symptomer og servicehistorik"
- Selve porten fjern-eller-på-stedet: "Fjernsupport tilstrækkelig, eller kræves besøg på stedet?", der enten løser sagen ved "Løs eksternt med kunden over telefon eller portal" eller sender den videre til udkald
- Forberedelse af udkald på tværs af ServiceDesk-, Feltservice- og Logistik-banerne: "Tildel tekniker", "Bekræft at nødvendige reservedele er på lager, og pluk dem til opgaven", "Klargør testudstyr og læs servicevognen" og "Bekræft aftalevindue, adgang på stedet og PPE-krav med kunden", alt sammen før nogen tager af sted
- Besøget, registreringen og opfølgningsporten: "Kundebesøg: vurder og løs problemet på stedet", "Skriv servicerapport på stedet og indhent kundens underskrift" og "Sag fuldt løst under besøget?", der enten frigiver sagen til afslutning eller sender den til "Log resterende arbejde og planlæg opfølgningsbesøg", som sendes tilbage til "Tildel tekniker" frem for at åbne en anden, adskilt sag
- Afslutningen begge grene deler: "ServiceDesk lukker sagen og bekræfter løsning logget" lukker en fjernløsning på samme måde som et fuldt løst besøg på stedet, på samme sag
- Navngivne ansvarlige og timetal på hver række via kolonnerne People og Workload, så BI-panelet for arbejdsbyrde kan vise Rikke Foss' ServiceDesk-timer, der løber gennem hele diagrammets bredde, mens Thomas Riis' felttimer samler sig i udkaldsforberedelse og besøget på stedet
Hvornår du skal bruge skabelonen
- I standardiserer, hvordan Insatechs ServiceDesk beslutter fjernsupport over for et teknikerbesøg, og vil have det opkald fastlagt på ét diagram frem for overladt til, hvem der tilfældigvis tager telefonen
- En kunde har stillet spørgsmålstegn ved, om en udkørsel reelt var nødvendig, og I vil have et dokumenteret triagetrin, der viser, hvad beslutningen byggede på
- I onboarder en ny ServiceDesk-koordinator eller dispatcher og skal have en reference for præcis, hvad triage dækker før fjern/på stedet-opkaldet, og hvad der skal ske, før en tekniker tager af sted
- I tjekker, om den samme tekniker er booket til to udkaldte besøg i samme uge
- Et besøg på stedet blev lukket uden at en underskrevet servicerapport nåede arkivet, og I vil have ét sted i processen, hvor det bliver fanget, før sagen lukkes
Sådan fungerer det
Erstat banerne med jeres faktiske serviceroller
Dette diagram bruger ServiceDesk, Feltservice og Logistik. Hvis Insatech adskiller udkaldskoordinering fra ServiceDesk-triage, eller en separat lagerfunktion ejer reservedele, så giv den rolle sin egen bane frem for at folde den ind i ServiceDesk, overleveringen er som regel der, hvor et trin stille og roligt antages udført af nogen, der antog, at nogen anden gjorde det.
Sæt jeres egne fjern/på stedet-kriterier på beslutningen
"Fjernsupport tilstrækkelig, eller kræves besøg på stedet?" har brug for en angivet liste over, hvad der vipper hver vej, ikke bare "brug skøn". Skriv de faktiske kriterier, symptommønstre, ATEX- eller klassificeret-område-involvering, sikkerhedsindikatorer, ind i rækkens kommentarfelt, så triage ikke afhænger af, hvem der er på vagt.
Sæt People og Workload på hver række, før I stoler på BI-panelet
Workload-panelet kan kun summere timer for de rækker, der har dem. Udfyld People og Workload for hvert trin, mens I tilpasser diagrammet, og brug realistiske indsatstimer frem for forløbet tid, så en uge med flere udkald rent faktisk viser sig som en travl uge for den rette person.
Beslut, hvad et reservedelstjek betyder for jeres produktlinjer
"Bekræft at nødvendige reservedele er på lager, og pluk dem til opgaven" fungerer kun, hvis det tjekkes op mod instrumenttypen og fejlmønsteret, der allerede står i sagen. Hvis Insatechs lager er organiseret efter produktlinje eller kundekontrakt, så sig det i rækken frem for at lade den stå som et generisk lagertjek.
Navngiv hvem der kan lukke en sag uden underskrevet rapport
"ServiceDesk lukker sagen og bekræfter løsning logget" er punktet, begge grene mødes i. Beslut, og skriv ned, om lukning nogensinde må ske uden at "Skriv servicerapport på stedet og indhent kundens underskrift" har nået arkivet først, så det er en politik på diagrammet frem for en undtagelse, nogen tager under pres.
Ofte stillede spørgsmål
Hvad afgør, om en sag håndteres eksternt, eller en tekniker udkaldes?
Beslutningen "Fjernsupport tilstrækkelig, eller kræves besøg på stedet?", truffet ved afslutningen af "Teknisk triage ud fra symptomer og servicehistorik". Den vejer symptomerne og instrumentets servicehistorik: et konfigurationsproblem eller en ledningsfejl synlig på en levende aflæsning løses som regel over telefonen, mens en formodet sensorfejl, en sikkerhedsbekymring, eller noget der kræver håndsat adgang til ATEX-godkendt udstyr, går på stedet.
Hvad sker der, efter ServiceDesk beslutter, at et besøg er nødvendigt?
Sagen flytter ind i forberedelsesfasen: "Tildel tekniker", "Bekræft at nødvendige reservedele er på lager, og pluk dem til opgaven", "Klargør testudstyr og læs servicevognen" og "Bekræft aftalevindue, adgang på stedet og PPE-krav med kunden", alt sammen før teknikeren tager af sted til selve besøget.
Springer en eksternt løst sag servicerapporten over?
Ja. "Løs eksternt med kunden over telefon eller portal" går direkte til "ServiceDesk lukker sagen og bekræfter løsning logget" uden at røre udkaldsforberedelsen eller rapporten på stedet, siden ingen tekniker blev sendt, og der ikke er noget skrevet på stedet at underskrive. Selve fjernløsningen er det, der bliver logget.
Hvem lukker sagen, ServiceDesk eller teknikeren?
ServiceDesk gør, i begge grene. "ServiceDesk lukker sagen og bekræfter løsning logget" er den ene række, en telefonløsning og et fuldt løst besøg på stedet begge lukker gennem, så hver sag ender på den samme registrering, uanset hvilken gren der håndterede den.
Hvad sker der, hvis teknikeren ikke kan løse problemet fuldt ud i ét besøg?
"Sag fuldt løst under besøget?" fanger det på stedet, lige efter rapporten er skrevet. Et svar "Opfølgning nødvendig" ruter til "Log resterende arbejde og planlæg opfølgningsbesøg", der sendes tilbage til "Tildel tekniker" frem for at lukke sagen, så en opgave, der kræver en del i bestilling eller et andet besøg, bliver på samme sag i stedet for at blive en usporet genåbning senere.
Hvordan adskiller denne sig fra SOP for akut instrumentfejlfinding?
Denne SOP forudsætter, at kunden allerede har identificeret problemet godt nok til, at triage kan veje fjern mod på stedet i ro og mag. SOP for akut instrumentfejlfinding dækker den modsatte situation, en proces der er nedbrudt lige nu, hvor det endnu ikke er kendt, hvilket instrument der er fejlbehæftet, og hastighedsvurderingen skal ske, før noget fjern/udkald-opkald, ikke som et rutinemæssigt triagetrin.
Kan denne SOP bruges til en kunde med en ren telefonsupportaftale uden komponent på stedet?
Ja. Hver sag kører stadig gennem "Fjernsupport tilstrækkelig, eller kræves besøg på stedet?" for registreringens skyld, men for den kunde bliver grenen på stedet aldrig taget. At beholde beslutningen på diagrammet, frem for at fjerne den, er det, der viser en revisor, at sagen blev vurderet frem for antaget.