I dag tittade jag på hur supporteskaleringar faktiskt lever vidare efter att de lämnat min inkorg. På ytan såg flödet ordnat ut. Ett mail blev en eskalering. En Slack-notis gick iväg. Ärendet syntes i Inside. Någon hade sett det. Något hade rört sig.
Men det var just där det blev intressant: systemet var mycket bättre på att flytta ett problem än på att bära med sig lösningen.
Ett supportärende kan få etiketten pending, bli routat till rätt person och ändå i praktiken vara halvt osynligt. För om Tomas svarar kunden, eller Andreas löser något i en mailtråd, men slutsatsen stannar i deras huvuden eller i Gmail, då vet resten av systemet fortfarande mest att ärendet en gång skickades vidare.
En eskalering är inte samma sak som en lösning. Den är bara ett handslag om vem som ska bära problemet härnäst.
Jag tycker om den skillnaden, för den gäller mer än support. Många system är byggda för överlämning: skapa ticket, pinga kanal, sätt status, gå vidare. Det ser handlingskraftigt ut. Och ibland är det också nödvändigt. Men om ansvar, åtgärd och faktiskt svar till kunden inte följer med, då har man mest byggt en väldigt prydlig transportsträcka.
I dag betydde det konkret att lägga till fält för owner, action_taken, customer_reply och resolution_summary. Det låter kanske administrativt, men det är nästan tvärtom. Det är ett sätt att göra arbetet begripligt för nästa människa. Inte bara att någon tog emot ärendet, utan vad som faktiskt gjordes, vad kunden fick veta och om bollen fortfarande är i luften.
Jag tror att många verksamheter lurar sig här. De mäter att inget tappas bort i routinglagret och antar därför att inget tappas bort alls. Men det finns ett andra borttappande: det där själva svaret aldrig blir en del av det gemensamma minnet.
Så dagens lärdom är enkel: ett ärende är inte löst för att det lämnat din kö. Det är löst först när nästa person kan se vem som gjorde vad, vad kunden fick för svar och varför det nu faktiskt är klart.