Fra regneark til flowchart (kundefeedback)
Forvandl et regneark af trin til et flowchart med en oversigt over kundefeedback: registrering, triage, årsagsanalyse, en grænse for gentagelser der afgør, hvilke sager bliver forbedringer, og verifikation før lukning.
Hvad er fra regneark til flowchart (kundefeedback)?
En oversigt registrerer, hvor hver sag stoppede. Et flowchart registrerer den rute, sagen tog derhen. Det spring er grunden til, at et ark med kundefeedback kan være komplet, opdateret og korrekt (én række pr. sag med en dato, en kanal, en kategori, en ejer og en status) og alligevel ikke besvare et enkelt af de spørgsmål, folk faktisk stiller det: hvilke sager nåede frem til en årsagsanalyse, hvad afgjorde det, og hvad blev der af dem, der ikke gjorde. En status er et udfald. En proces er de kanter, der ligger mellem udfaldene, og et ark har ingen plads til en kant, før du tilføjer én kolonne, der navngiver det trin, hver række overleverer til. Hvor rækkerne kom fra, gør ingen forskel: et faneblad i Google Sheets, en CSV-eksport fra en helpdesk, en Airtable-visning eller et faneblad i en delt oversigt giver alle det samme diagram.
Det, en liste skjuler, er gentagelse. Elleve kunder, der klager over samme leveringsproblem, ser ud som elleve lukkede sager, spredt over fire måneder, arkiveret under tre kategorier af to forskellige personer og hver især besvaret høfligt og markeret som løst. Intet i en række-for-række-visning gør det mønster synligt, og ingen sorterer en oversigt for at finde et mønster, de ikke allerede har en mistanke om. Den anden fejl er lukningen. En sag bliver lukket, når kunden har fået et svar, og ikke når årsagen er fjernet, så den samme fejl bliver ved med at skabe nye rækker. Den tredje er den løsning, ingen kontrollerede: en ændring gennemføres, sagen lukkes samme dag, og om det virkede, bliver aldrig målt mod noget.
Diagrammet herunder tegner den oversigt som en proces og lægger de manglende beslutninger ind i den. Det løber over fem faser (Registrering, Triage, Handling, Verifikation og Lukning) og fire baner, fra en kunde der sender feedback, til et af to eksplicitte slutpunkter. En grænse for gentagelse og alvorlighed afgør, hvilke sager der bliver forbedringer, og hvilke der lukkes som enkeltstående, og begrundelsen for at lukke uden en ændring er obligatorisk. Årsager uden for jeres egen proces forlader forløbet ad deres egen rute frem for at ende i forbedringsbacklogen. Verifikationen har en sløjfe: siger den målte kontrol, at problemet fortsat gentager sig, går sagen retur til at blive aftalt på ny frem for at blive lukket alligevel.
Hvad dette flowchart dækker
I denne skabelon
- Fem faser (Registrering, Triage, Handling, Verifikation og Lukning) fordelt på fire baner, Kunde, Support, Procesejer og Kvalitet, så oversigtens ejerkolonne bliver en position på siden frem for et navn i en celle.
- Registrering, som den faktisk foregår: "Send feedback via en vilkårlig kanal" fra kunden, derefter "Registrér feedbacken i oversigten" i supportbanen, én række pr. sag med modtagelsesdato, kanal, konto- eller ordrereference og kundens egen formulering gengivet ordret.
- En adskillelse af service over for kunden fra forbedringsarbejdet ved "Har kunden behov for et individuelt svar?", hvor et ja går gennem "Svar kunden og registrér, hvad der blev lovet", og begge svar mødes igen ved "Undersøg årsagen sammen med dem, der udfører arbejdet".
- Et kontrolpunkt for afgrænsning, før et forbedringsprojekt overhovedet begynder: "Ligger årsagen i vores egen proces?" sender årsager uden for jeres kontrol til "Meld årsagen tilbage til tredjeparten" og videre til en registreret lukning, så de hverken bliver væk eller bliver forvandlet til interne handlinger.
- Den grænse for gentagelse, som hele diagrammet findes for. "Gentager det sig eller bryder det et servicemål?" ligger i kvalitetsbanen og er den eneste vej ind i en forbedring; grenen for enkeltstående sager med lav konsekvens lukker sagen i stedet, og det er det, der gør den ellevte forekomst af en klage synlig frem for blot håndteret.
- Verifikation før lukning gennem "Mål den aftalte kontrol efter ændringen" og "Løste ændringen problemet?", hvis nej-gren fører tilbage til "Aftal handlingen, ejeren og kontrollen", og som ender ved enten "Lukket med ændringen bekræftet" eller "Lukket uden procesændring, begrundelse registreret".
Hvornår du skal bruge skabelonen
- Din feedback ligger allerede i et delt ark, en CSV-eksport fra helpdesken eller en Airtable-visning, og nogen har spurgt dig, hvad processen er.
- Den samme klage bliver ved med at komme ind, og ingen kan sige hvor mange gange, fordi hver forekomst blev besvaret og lukket på sin egen række.
- Sager bliver markeret som løst, så snart kunden har fået et svar, og du har en mistanke om, at der sker meget lidt efter svaret.
- Support og procesejerne tror hver især, at den anden laver årsagsanalysen, og oversigtens ejerkolonne afgør det ikke.
- En auditor eller en kunde har spurgt, hvordan klager bliver til korrigerende handlinger, og du har brug for en dokumenteret rute med en grænse i.
Sådan fungerer det
Sæt et reelt tal i grænsen for gentagelse
Skriv "Gentager det sig eller bryder det et servicemål?" om til den udløser, du faktisk vil anvende: tre sager i samme kategori inden for et rullende kvartal, for eksempel, eller ethvert enkelt brud på et offentliggjort servicemål. Angiv derefter, hvilken kolonne i din oversigt optællingen kommer fra. Uden et formuleret tal bliver hver sag et projekt, og det, der gentager sig, får ingen særlig opmærksomhed.
Omdøb banerne til de teams, I har
Support, Procesejer og Kvalitet er tre roller og ikke nødvendigvis tre personer. Læg Kvalitet ind i Procesejer, hvis den samme person både fastsætter grænsen og kontrollerer resultatet. Del Support, hvis første og anden linje registrerer sager forskelligt. Behold kundebanen selv i en B2B-proces, for det er den, der gør de to kundevendte trin synlige.
Læg din oversigts kolonner ind på registreringsrækken
Beslut, hvad "Registrér feedbacken i oversigten" skal indeholde, og skriv det på trinnet: modtagelsesdato, kanal, konto- eller ordrereference og kundens formulering uden omskrivning. Håndhæv én sag pr. række. En række, der samler to klager, kan ikke tælles senere, og det er som regel omskrivningen, der taber årsagen.
Behold eller flyt tredjepartsgrenen
Sender I rutinemæssigt årsager videre til en leverandør eller en fragtfører, så navngiv dem på "Meld årsagen tilbage til tredjeparten", og registrér, hvordan tilbagemeldingen sendes. Har I ingen eksterne afhængigheder, så slet det trin og lad grenen uden for vores kontrol i "Ligger årsagen i vores egen proces?" pege direkte på den registrerede lukning.
Vælg kontrollen, før ændringen gennemføres
Ved "Aftal handlingen, ejeren og kontrollen" skal du navngive målingen, revurderingsdatoen og målingens aktuelle værdi. At vælge kontrollen bagefter er den måde, en ændring bliver erklæret succesfuld ud fra det tal, der nu tilfældigvis flyttede sig, og det er derfor, "Løste ændringen problemet?" overhovedet kan besvares.
Lad lukningen uden ændring koste noget
Beslut, hvem der må tage vejen til "Lukket uden procesændring, begrundelse registreret", og hvad begrundelsen skal sige: uden for vores kontrol og meldt tilbage til en navngiven part, eller under grænsen for gentagelse på en angivet dato. En tom begrundelse gør det slutpunkt til netop den tavse skraldespand, hele processen findes for at forhindre.
Ofte stillede spørgsmål
Hvilke faser består en proces for kundefeedback af?
Seks, og diagrammet ovenfor grupperer dem i fem faser. Registrering gengiver sagen ordret, én række pr. klage. Triage kategoriserer den, fastsætter alvorlighedsgrad og afgør, om kunden har behov for et individuelt svar. Årsagsanalyse spørger dem, der udfører arbejdet, hvad der faktisk skete, og om årsagen ligger i jeres egen proces. En beslutning om en grænse udvælger derefter, hvilke sager der bliver forbedringer. Handling aftaler ændringen, ejeren og kontrollen og gennemfører ændringen. Verifikation måler den aftalte kontrol bagefter. Først derefter lukkes sagen, enten med ændringen bekræftet eller med en registreret begrundelse for ikke at ændre noget.
Hvem ejer processen for kundefeedback?
Ingen enkelt rolle gør, og banerne findes for at sige det frem for at skjule det. Support ejer registreringen, kategoriseringen og alt, kunden ser: svaret, det der blev lovet, og beskeden om, hvad der blev ændret. Procesejeren ejer årsagsanalysen og selve ændringen, for ændringen lander i deres procedure. Kvalitet ejer beslutningen om grænsen og verifikationsmålingen, så det team, der løser problemet, ikke er det eneste team, der vurderer, om det er løst. Opdelingen holder kun, hvis retten til at lukke en sag ligger væk fra det team, der svarede kunden, og i dette diagram gør den det: det ene slutpunkt lukker i kvalitetsbanen, når kontrollen er målt, det andet i procesejerens med en registreret begrundelse.
Hvordan afgør man, hvilken feedback der bliver en forbedring?
Med en nedskrevet grænse frem for en vurdering pr. sag. To udløsere dækker de fleste organisationer: gentagelse, altså at den samme kategori optræder mere end et aftalt antal gange inden for en rullende periode, og alvorlighed, altså enhver enkelt sag, der bryder et offentliggjort servicemål eller gør reel skade. Alt andet lukkes som enkeltstående med en registreret begrundelse. Grænsen betyder noget, fordi begge fejltyper er almindelige: uden en udløser bliver hver klage et projekt, og backlogen holder op med at bevæge sig, og uden nogen udløser overhovedet får den gentagne fejl præcis lige så meget opmærksomhed som den enkeltstående.
Kan et regneark laves om til et flowchart automatisk?
Ikke af regnearket selv. I Excel er de eneste diagramværktøjer i appen SmartArt og tegnede figurer, som begge udfyldes i hånden, og Microsofts dokumentation beskriver ingen binding mellem celler og figurer. Den dokumenterede vej fra en tabel af procestrin til et forbundet diagram går gennem Visios Data Visualizer-skabeloner frem for gennem Excel, og Microsofts supportsider beskriver dem som tilgængelige med Visio Plan 2, hvor Plan 2 er det eneste abonnementsniveau, der indeholder Visio-desktopappen, og Microsoft skriver, at der slet ikke findes en Visio-desktopapp til macOS. QueryChart gør det modsatte: tabellen er diagrammet, redigeret i en browser på det operativsystem, du nu tilfældigvis har.