DeskFlow

SLA-status syns på fyra ställen: ärendesidan, dashboardens rutor, filtret i ärendelistan och en bakgrundsworker som flaggar ärenden i riskzonen eller över tiden. Om varje ställe räknade ut den själv skulle de förr eller senare visa olika – ett ärende ”i riskzonen” på dashboarden men som saknas i filtret.

Därför anropar alla fyra samma modul. Varje prioritet har ett mål för första svar och ett för lösning, sparade som deadlines på ärendet. När ett ärende sätts till Väntar pausas båda klockorna, och när det lämnar Väntar flyttas deadlines fram med den tid det väntade. Ett ärende är i riskzonen när 75 % av tiden har gått.

Avvägning: Klockorna går i kalendertid, inte arbetstid. Det höll reglerna enkla nog att testa ordentligt, men det är den största skillnaden mot en riktig servicedesk.

Varje ändring av ett ärende, en tillgång eller en artikel sparar vem som gjorde den och värdena före och efter, i samma databastransaktion som själva ändringen. En förfrågan som misslyckas lämnar inga spår, och en som lyckas kan inte hoppa över loggen. Poster läggs bara till, och de finns kvar efter att posterna de beskriver har tagits bort: en post om något som raderats visas som ”raderad” i stället för en trasig länk.

Den publika demon återställs varje natt så att besökare alltid möter en realistisk helpdesk. Första versionen av återställningen tömde granskningsloggen tillsammans med ärendena. Demon blev prydlig men loggen meningslös, så jag ändrade det: återställningen lägger bara till i loggen och skriver vad den tog bort och skapade, och id:n återanvänds aldrig, så en gammal post kan aldrig börja beskriva något nytt.

Assistenten föreslår felsökningssteg för ett ärende, men modellen får bara se upp till fyra publicerade artiklar ur kunskapsbasen, hittade med samma fulltextsökning som resten av appen. Om inget matchar anropas modellen inte alls.

Den måste ange vilka artiklar den använde. Id:n den hittat på tas bort, och ett svar som inte hänvisar till något den fått kastas och visas som ”täcks inte”. Ärendetexten skickas som data med en instruktion att inte följa något i den, svaret går genom samma sanering som artiklarna, och den utför aldrig något själv – det är råd för en människa att granska. Den körs bara när en handläggare ber om det, har en gräns för antal anrop och varje körning loggas.

Avvägning: Att hålla den så strikt till källorna gör att den ofta svarar ”täcks inte”. För en helpdesk är det rätt sätt att misslyckas: en felaktig lösning kostar mer än inget förslag.

Kunskapsbasen använder fulltextsökning i PostgreSQL: en genererad tsvector-kolumn med GIN-index, rubriker rankas högre än brödtext, böjningsformer matchas (”printers” hittar ”printer”) och den förstår ”exakta fraser” och -uteslutningar. Frågor går via websearch_to_tsquery, så konstig inmatning ger aldrig fel.

Träffarna markeras med egna avgränsningstecken i stället för HTML, så webbläsaren behöver aldrig lita på markup från databasen.

Avvägning: En tjänst mindre att drifta och hålla i synk, mot att man går miste om sådant en riktig sökmotor ger, som tolerans för stavfel.

Backendtesterna körs mot PostgreSQL, inte SQLite, var och en i en transaktion som rullas tillbaka efteråt. Det fångar det SQLite skulle dölja: constraints, sekvenser och fulltextsökning.

Det lärde mig också en fälla. Eftersom testerna delar en session som rullas tillbaka gick en route som glömt att spara sina ändringar ändå igenom. Routes som skriver har nu tester som uttryckligen kontrollerar att ändringen sparas.