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.
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.