Den dyraste meningen i support
”Kan du skicka en skärmdump och berätta vilken webbläsare du använde?” Det är en artig och rimlig fråga, och det är anledningen till att en bugg som tar två minuter att rätta tar tre dagar. Kunden är upptagen, så svaret kommer i morgon. Skärmdumpen visar felmeddelandet men inte klicket som orsakade det. Webbläsarversionen är fel eftersom de kollade på mobilen. När utvecklingen ser ärendet minns ingen exakt vad som hände, inte ens kunden.
Lösningen är inte ett bättre formulär för buggrapporter. Den är att sluta be kunden om bevis som du själv kunde ha fångat, i det ögonblick problemet uppstod.
Vad en användbar buggrapport faktiskt innehåller
Utvecklare behöver fem saker för att återskapa en bugg:
- Vad kunden gjorde: klicken och inmatningarna, i ordning.
- Vad de förväntade sig: resultatet de försökte nå.
- Vad som faktiskt hände: felet, den tomma skärmen, knappen som inte gjorde något.
- Miljön: sida, webbläsare, enhet, skärmstorlek och varifrån de kom.
- Det tekniska spåret: konsolfel och nätverksanropen som misslyckades.
En kund kan pålitligt ge dig den andra punkten och en del av den tredje. De andra tre är exakt vad en session replay spelar in: följden av handlingar, sidan och webbläsaren, konsolloggen och nätverksanropen. Att be folk återskapa det ur minnet är att be om just den del de har sämst förutsättningar att ge.
Bifoga sessionen i stället för att be om den
Den enklaste starten är själva rapporten. När en kund skickar en feedback-widget eller ett buggformulär i appen finns sessionen där: sidan de är på, felen som nyss uppstod, anropen som misslyckades en sekund tidigare. Fånga den tillsammans med rapporten, så kommer ärendet in med det utvecklingen behöver.
Det ändrar första svaret. I stället för ”kan du skicka en skärmdump?” öppnar agenten replayen, ser TypeError i konsolen två sekunder innan kunden klickade på Betala igen, och kan svara inom samma timme: ”vi ser vad som gick fel, och här är en tillfällig lösning”.
E-post är svårare, eftersom ett mejl inte har någon session. Två vanor hjälper. Identifiera inloggade användare i din analys så att ett ärende från en känd adress kan kopplas till deras senaste sessioner, och lägg en feedbacklänk i produkten så att nästa rapport kommer från sidan där problemet finns och inte från en inkorg en dag senare.
Sortera efter bugg, inte efter ärende
När ärendena innehåller felet kan du gruppera dem efter det. Det är här de flesta team vinner mest. En bugg i kassan ger inte ett ärende, utan trettio, alla formulerade olika: ”betalningen misslyckades”, ”kan inte köpa”, ”knappen är trasig”. Läser du dem en i taget ser de ut som trettio problem. Grupperade efter felmeddelandet de delar är de en bugg med trettio drabbade kunder, och det är den siffran som gör att den prioriteras.
Grupperingen ändrar också hur du stänger loopen. Eskalera buggen en gång, till ett ärende i Linear, GitHub eller Jira, och koppla varje matchande supportärende till det. När rättningen släpps kan alla de kunderna få veta det, inte bara de fem som råkade skriva igen.
För att det ska fungera måste grupperingen stämma med det utvecklingen redan ser. Om supporten räknar ”betalningsproblem” och utvecklingen räknar Cannot read properties of undefined (reading 'total') går listorna aldrig ihop. Gruppera ärenden efter samma normaliserade felmeddelande som din felspårning använder.
Ta hand om integriteten innan den tar hand om dig
Att bifoga sessioner till ärenden betyder att supportagenter ser mer av vad kunderna gjorde, så bestäm reglerna först:
- Maskera formulärfält som standard och spela aldrig in lösenord eller betalningsfält.
- Skriv i din integritetspolicy att supporten kan granska sessionen som hör till en förfrågan.
- Ge åtkomst till replays bara till dem som arbetar med ärenden, inte alla med en inloggning.
- Respektera samtycke: en besökare som tackade nej till analys ska inte ha någon session att bifoga.
Gjort så här är sessionskontext mindre integritetskränkande än alternativet, som är att be kunder dela skärmen eller mejla skärmdumpar från sitt konto.
Ett arbetsflöde du kan börja med i veckan
- Lägg till en feedback- eller buggrapportwidget i appen på sidorna där flest problem uppstår: kassan, onboarding, inställningar.
- Fånga sessionen vid varje inskick, så att varje ärende innehåller replay, konsollogg och misslyckade anrop.
- Identifiera inloggade användare, så att e-postärenden från kända kunder kan kopplas till deras sessioner.
- Gruppera ärenden efter fel och gå igenom de största grupperna varje vecka med utvecklingen.
- Eskalera varje bugg en gång och svara varje kopplad kund när den är rättad.
Vad du ska mäta
Fyra siffror visar om det fungerar:
- Andel buggärenden med en bifogad session. Det är den ledande indikatorn; höj den först.
- Tid till första användbara svar, alltså ett svar som inte ber om mer information.
- Ärenden per bugg. En sjunkande siffra betyder att du rättar de buggar som ger mest supportbelastning.
- Andel återöppnade buggärenden, som sjunker när första svaret är rätt.
PulsePandas helpdesk är byggd kring den här loopen: feedback blir ärenden med replay och fel bifogade, ärendena grupperas efter samma fel som sidan Fel, och eskalering till Linear, GitHub eller Jira låter dig svara varje drabbad kund när ärendet stängs.