Handbok

Du skapar ett nytt ärende med ”New Ticket” i vänsterlisten. Formuläret heter ”Create new ticket”. Som agent registrerar du även andras förfrågningar med det — det är vad fältet ”User” är till för: det säger vem fallet gäller, inte vem som skriver in det.

Allt med en stjärna är obligatoriskt: ”Title”, ”User”, ”Main category” och ”Description”. En till som är lätt att missa: formuläret sparar inte utan en underkategori, trots att ”Subcategory” inte bär någon stjärna — en huvud- och en underkategori hör ihop och sätts alltid parvis.

Vilka fält som är obligatoriska ställs in under ”Settings → Ticket Settings”. Kortet ”Admin / Agent Field Settings” har för detta bara reglaget ”Field is mandatory”. Kortet ”Customer Field Settings” har dessutom ”Is hidden for Customer” och ”Is not editable”. Därför kan en kund se ett kortare formulär än du gör, utan att någon behöver underhålla två formulär. ”Title” och ”Description” är alltid obligatoriska. Det går inte att stänga av.

Efteråt kan du ändra nästan allt: till höger om ärendet sitter kortet ”Details” med anmälare, telefon, e-post, plats, kategori och referensnummer. Du ändrar fältet självt och bekräftar med ”Save” under det. Status, tilldelning, prioritet, kanal och bevakare sitter ett kort högre upp under ”Actions”. Status och tilldelning får verkan omedelbart. Prioritet, kanal och bevakare sparas först med ”Save” i kortet ”Details”.

Bara agenter och administratörer får ändra detta. Anmälaren kan läsa fallet, kommentera det och bifoga filer — men inte ändra den klassificering din rapportering bygger på.

En sidoeffekt värd att känna till en gång: redigerar du ett ärende som ännu inte tillhör någon, tillhör det dig efteråt. Systemet skriver in dig som agent och flyttar statusen från ”Open” till ”Assigned” — båda hamnar i historiken. Ville du inte det, tilldela det någon annan efteråt.

Var och en av de här ändringarna hamnar i ärendets historik, med namn, tid, gammalt värde och nytt värde. Du behöver inte slå på något för det.

Kvar står frågan hur man blir av med ärenden igen. Under ”Settings → Archive” väljer du ett datumintervall, ser med ”Preview” hur många stängda ärenden det innehåller, och skapar en ZIP-fil med ”Create archive”: ärenden, kommentarer, historik, anpassade fält och bilagor, allt i en fil. Att skapa den tar inte bort något. Ärendena lämnar den körande databasen först med det separata steget ”Delete from live DB” i listan ”Existing archives” — och de kan återställas ur samma fil.

Beskrivningen och kommentarerna är inga nakna textrutor. Var och en har ett verktygsfält ovanför sig, och knapparna säger vad de gör när du pekar på dem: ”Bold”, ”Italic”, ”Underline”, ”Strikethrough”, ”Text color”, ”Highlight color”, ”Bullet list”, ”Numbered list”, ”Quote”, ”Link” och ”Clear formatting”.

Så här gör du en länk: markera texten, klicka på ”Link”, skriv adressen i den lilla rutan. En tom inmatning tar bort länken igen. Webb- och e-postadresser är tillåtna (http, https, mailto) — allt annat kastas bort vid sparandet, så att en kommentar inte kan smuggla något förbi någon.

Bilder kommer in via urklipp: ta en skärmbild och klistra in den direkt i redigeraren med Ctrl+V. Först visar texten bara en markering som ”[inline-image:1]”. När du sparar laddar systemet upp bilden och visar den exakt där — och den hamnar också i fliken ”Attachments”, där alla filer i fallet ligger. Att klistra in bilder fungerar i beskrivningen av ett befintligt ärende och i en ny kommentar. Det fungerar inte i formuläret ”Create new ticket” och inte heller medan du redigerar en kommentar.

Det du ser är det andra ser: formatering, listor och länkar behålls i ärendet, och i meddelandet till anmälaren också. Främmande markering — från en kopierad webbsida eller ett inkommande e-postmeddelande, till exempel — beskärs till den här tillåtna uppsättningen. Ingen av din text går förlorad på vägen, bara omslaget.

En kommentar kan märkas som intern med ”Internal note (not visible to the customer)”. Den bär då märkningen ”Internal” och är osynlig för anmälaren — inte ens sökningen tar fram den.

Alla kan ändra och radera sina egna kommentarer. Det som en kund har skrivit kan bara den kunden eller en administratör ändra eller radera. Det gäller även kundens e-postmeddelanden. Kommentarer från kollegor kan ändras och raderas av varje agent som får arbeta med ärendet. Det gäller även ett team som hade ärendet tidigare.

Filer hör till fallet, inte till en enskild kommentar. På ärendet leder fliken ”Attachments” till listan: ”Upload file” lägger till en, varje rad nämner filen, dess storlek och dess datum. Alla som är inblandade i ärendet får bifoga något — anmälaren inräknad, så att ingen behöver mejla dig sin skärmbild. En kund kan bara radera bilagor som de själva har laddat upp. När ett underärende stängs kopieras dess bilagor till huvudärendet, där de bär märkningen ”Internal”. Agenter ser dem; kunder varken ser eller laddar ner dem.

Ett klick på namnet öppnar förhandsgranskningen, utan att du behöver ladda ner filen. För bilder kan du zooma in, zooma ut och rotera där inne — praktiskt för en display som fotograferats snett. En PDF visas i samma fönster, med sidöversikt, zoom och utskrift. Textfiler visas som text. Med ”Open in new tab” öppnar du filen i ett eget fönster.

En bilaga hör till fallet och följer med det: den syns i historiken (”File uploaded: …”), överlever ett överlämnande till ett annat team, och hamnar inuti arkivfilen när ärendet arkiveras.

Fliken ”History” på ärendet svarar på frågan bakom varje uppföljning: vem ändrade vad, och när? Varje rad nämner personen, fältet, det gamla värdet överstruket, det nya efter det och tiden på sekunden. Den nyaste posten står överst.

Poster skrivs utan din medverkan — vid statusändringar, prioritet, tilldelning, kategori, plats, bevakare, titel och beskrivning, liksom vid skapandet (”Ticket opened”), vid varje kommentar och vid varje uppladdad fil. Siffran på fliken säger i förväg hur mycket rörelse det var i fallet.

Historiken går inte att redigera och inte att stänga av. Det är precis det som gör den användbar: den är skälet till att ett ärende inte kan raderas ett i taget, och den följer med in i arkivfilen när ärendet arkiveras.

För en kommentar registrerar historiken bara att den har lagts till, redigerats eller raderats. Lydelsen finns i fliken ”Comments”. En intern kommentar dyker också upp i historiken, men bara för agenter och administratörer.

Statusen säger var ett ärende står just nu. Tolv statusar följer med systemet — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed och fler. Du hittar dem under ”Settings → General Settings” i avsnittet ”Drop-down lists” bakom fliken ”Status”. ”+ Add status” skapar en egen, ”Edit status” öppnar en befintlig.

Det viktiga är skillnaden mellan namnet och betydelsen. I redigeraren för en status, under ”Meaning of this status”, finns tre reglage: ”Counts as resolved”, ”Counts as closed” och ”Waiting for the requester”. Bara de här reglagen talar om för systemet hur en status ska behandlas.

Du får byta namn på varje status, inklusive dem som följer med systemet: längst ned i redigeraren, under ”Translations”, finns ett ”Name”-fält per språk — skriv in där vad dina medarbetare ska läsa. Det tekniska namnet bakom förblir orört, och det är precis därför ingenting går sönder: automatisering, rapportering och reglagen ovanför hänger på det namnet, inte på din etikett. Så ”Resolved” kan bli ”Klart”.

Att radera fungerar däremot inte för alla. Åtta statusar bär märkningen ”Mandatory” i listan — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval och Rejected. De kan byta namn och ordning, men inte tas bort. Ett försök slutar med ett tydligt meddelande. Det finns inte där för att irritera dig: på dem hänger processer som annars skulle sluta fungera utan ett ord — till exempel den automatiska stängningen, som behöver en ”resolved”-status som utgångspunkt.

Två statusar hör till systemet självt: ”Waiting for approval” och ”Rejected” bär märkningen ”System only”. De kommer ur en godkännandeprocess, och ingen ska kunna påstå för hand att något avslogs som aldrig gick upp till beslut.

Vad de tre gör: en status som räknas som löst stänger ärendet av sig självt efter 24 timmar. En status som räknas som stängd är sluttillståndet ärendet flyttas till. Och ”Waiting for the requester” betyder exakt det: vi väntar på anmälaren — inte på ett annat team och inte på en leverantör. Det är flaggan SLA-klockan stannar på, om du ställer in det så.

Under det sitter ”Allowed transitions to new status”. Här bockar du i vilka statusar som går att nå från den här. Lämnar du allt tomt begränsas ingenting. Bockar du i något stängs varje annan väg. Så bygger du ett flöde som inte går att hoppa över — till exempel: från ”Open” kommer du bara till ”In Progress” eller ”Assigned”, men inte rakt till ”Closed”.

De återstående reglagen i redigeraren är småsaker med stor verkan: färgen för listan, ”Sort order” för ordningen, ”Show status in new ticket form” (ska den här statusen över huvud taget gå att välja när ett ärende skapas?), ”Requires comment in dialog” (tvinga fram ett skäl) och ”System only” för statusar som bara systemet självt får sätta.

Upp till fyra statusar visas på ärendet som knappar under ”Change Status to:”. Du väljer dem i redigeraren med reglaget ”Set as primary status (max. 4)”. I fabriksinställningen är det In Progress, Waiting for User Response, Waiting for Service Provider Response och Resolved. Alla andra statusar finns under ”More statuses”.

Allt som visas som en rullgardinslista i ett ärende tillhör dig. Under ”Settings → General Settings” sitter kortet ”Drop-down lists” med sex flikar: ”Department”, ”Position”, ”Location”, ”Role”, ”Status” och ”Priority”. Hanteringen skiljer sig från lista till lista.

En i taget: skriv det engelska namnet i det tomma fältet och klicka på knappen bredvid — den är uppkallad efter listan, alltså ”+ Add location”, ”+ Add department” och så vidare. Raderna nedanför är de befintliga posterna. I ”Department”, ”Position” och ”Location” är det där du ändrar ett namn och bekräftar med ”Save” bredvid.

För många poster på en gång erbjuder ”Department”, ”Position” och ”Location” även ”Export JSON” och ”Import JSON”. På ett nyinstallerat system laddar du ner den tomma strukturen med ”Export JSON”, fyller i den och importerar den igen. Det är ingen väg att byta namn — kortet säger det självt.

Vissa poster bär märkningen ”Mandatory”. De tre rollerna ”Admin”, ”Agent” och ”Customer” hör dit, åtta av statusarna som följer med systemet, och en platshållare vardera i listorna Location, Position och Department (”None selected or available”). Ingen av dem kan raderas: på dem hänger behörigheter och processer som annars skulle sluta fungera utan ett ord. Statusarna kan ändå byta namn i sin redigerare. Rollerna och platshållarna kan inte byta namn. Vad som är tillåtet beror på listan. ”Role” är låst: en roll kan varken läggas till eller byta namn. I ”Priority” lägger du till och raderar poster, men det finns ingen fil och inget namnbyte. ”Status” har en egen redigerare och ingen fil heller.

Här översätter du inte till de andra språken, utan i ett svep på översättningssidan. Det engelska namnet räcker här — det är ankaret som översättningarna fäster vid senare.

Statusen är den enda posten med en egen redigerare, eftersom mer hänger på den än ett namn. Den har ett eget kort längre ned.

Kategorier är det som anmälaren eller agenten väljer när ett ärende skapas — och det du grupperar dina rapporter efter senare. Varje team har sina egna: en helpdesk sorterar efter andra saker än en nätverksavdelning, och ingen av dem ser det andra teamets listor.

Du hittar dem under ”Settings” som posten ”<teamnamn> Categories”. I exemplet heter teamet ”Helpdesk”, så posten lyder ”Helpdesk Categories”.

Sidan har tre kort: ”Main categories”, ”Subcategories” och ”Links”. Snabbaste starten: skriv det engelska namnet i fältet ”EN (required)” och klicka på ”+ New main category” eller ”+ New subcategory”. Allt annat översätter du senare i ett svep på översättningssidan — ingenting behöver förberedas för det här.

Har du många kategorier framför dig, ta vägen via filen: ”Export JSON” laddar ner strukturen — på ett nyinstallerat system är filen tom och visar dig bara upplägget. Du fyller i den (för hand eller med hjälp av en AI), sparar den och laddar upp den igen via ”Import JSON”. Det är ingen väg att byta namn: du ändrar ett namn i den kategorins fält och bekräftar med ”Save” bredvid — sidan säger det också.

Det tredje kortet, ”Links”, är där det egentliga arbetet sker. Välj en huvudkategori överst, bocka i underkategorierna som hör till den nedanför, och spara med ”Save links”. Knepet: en underkategori får hänga på flera huvudkategorier. Så behöver du ”Malfunction” bara en gång och återanvänder den för Printer, Network, Meeting-Room och Notebook.

Från och med då finns kategorierna tillgängliga i ärendet. Att radera kan misslyckas så länge ärenden fortfarande använder en kategori — det är avsiktligt, annars skulle gamla ärenden tappa sin klassificering. Tar du bort en koppling kan ärenden som använder det paret fortfarande sparas. Bara en nyvald kategori kontrolleras mot kopplingarna.

Lämnar du över ett ärende till ett annat team står klassificeringen kvar — även när det nya teamet inte har de kategorierna alls. Den ligger då i fältet tillsammans med sitt ursprung, till exempel ”Meeting-Room · from Helpdesk”, och är gråtonad: det nya teamet ser vad fallet gått under hittills, men kan inte tilldela den posten själv. För att sortera om det väljer du ur din egen lista — och systemet vill då ha en huvud- och en underkategori tillsammans.

Varje ärende bär en kanal. Den sitter i formuläret och senare på kortet ”Actions” under ”How the request came in”, och den svarar på en fråga som snabbt blir viktig i rapporteringen: kommer arbetet in via portalen eller per telefon?

Du kan bara välja det en människa vet och systemet inte: ”Phone” och ”Entered by an agent”. De andra två värdena sätter systemet självt — ”Self-service” när anmälaren skapade ärendet i portalen, och ”E-mail” när det växte fram ur ett inkommande meddelande. När en agent skapar ett ärende startar formuläret med ”Entered by an agent”.

En kanal som systemet har satt kan ingen ändra i efterhand. Fältet säger då ”Recorded by the system. It cannot be changed.” Annars skulle fältet förlora precis det besked det finns till för. Tvärtom får du på ett ärende som registrerats per telefon ändå ändra allt annat.

Bara en agent eller en administratör får sätta kanalen. För anmälaren vore det ett besked om det egna fallet — och rapporteringen skulle bero på att alla är ärliga.

”E-mail” kräver en kopplad brevlåda, vilket ingår i utgåvan Professional. De andra tre kanalerna finns i båda utgåvorna.

Ovanför varje ärendelista finns fältet ”Search tickets…”. Det söker inte bara i titlar utan i hela fallet: titel, beskrivning, anmälarens namn, e-postadress och telefonnummer, plats, referensärendenummer, alla kommentarer och textvärdena i dina egna anpassade fält.

Exemplet visar det: ”coffee” står i ingen titel, bara i beskrivningen av ett ärende — och det hittas ändå. Så du behöver inte minnas hur ett ärende rubricerades. Ett ord ur fallet räcker.

Stora och små bokstäver spelar ingen roll. Sökningen gäller alltid listan du befinner dig i just då och kan kombineras med ”Filter” bredvid. ”Reset” rensar sökning och filter igen. Listan kommer ihåg dina filter, separat för varje teamlista. De finns kvar när du kommer tillbaka från ett ärende, laddar om sidan eller loggar in på en annan dator. Söktexten kommer den inte ihåg. För kunder finns en gräns du inte ser men bör känna till: de söker inte i interna kommentarer — annars skulle de kunna sluta sig till vad som diskuterats internt ur träfflistan. Inte heller söker de i anpassade fält som är dolda för kunder.

Var och en sätter ihop sin egen ärendelista. För det finns knappen ”Columns” bredvid ”Filter”. Den öppnar dialogen ”Choose columns”.

I dialogen bockar du för varje kolumn du vill se. Pilarna bredvid bestämmer ordningen. ”#” och ”Title” är alltid med. Bredden på en kolumn ändrar du i själva listan genom att dra i kanten på dess rubrik.

”Save” sparar ditt val med ditt användarkonto. Därför gäller det på varje dator och finns kvar efter att du loggat ut. ”Default columns” återställer listan till fabriksinställningen.

När det inte finns plats för alla kolumner försvinner de längst till höger först. ”#”, ”Title” och ”Status” stannar alltid kvar. Så du flyttar det som är viktigast för dig längst fram.

Med Professional erbjuds även dina anpassade fält. De visas i dialogen under sitt eget namn, här till exempel ”Asset tag”.

Kunder kan ställa in sin lista på samma sätt men erbjuds färre kolumner. ”Team”, ”Created by”, ”Last activity”, ”Status changed at”, ”Deadline”, ”Follow-up” och ”Time” är inte tillgängliga för dem. Fält som du har dolt för kunder visas inte heller som kolumn.

På en mobil visas inte knappen. Där visar listan de kolumner som får plats.

Ärendet erbjuder två knappar bredvid varandra för det här, och skillnaden står tryckt under dem med liten text. ”Involve another team”: du förblir ansvarig, det andra teamet arbetar vid din sida i ett kopplat ärende. ”Escalate to another team”: det andra teamet tar över.

När du lämnar över flyttar ansvaret utan att ett andra ärende uppstår. Ditt team behåller läsåtkomst och får fortfarande kommentera, men kan inte ändra något längre — vilket är precis vad dialogen säger dig innan du bekräftar. Där väljer du målteam och kan lägga till ett skäl.

När du kopplar in ett team stannar ditt ärende i dina händer och får ett underärende i det andra teamet. Ditt flyttas till statusen ”Waiting for other team”. När det andra teamet stänger sitt kommer ditt tillbaka som ”Back from other team”. Så behöver du inte fråga om något har hänt där borta. Underärendets bilagor kopieras till ditt ärende med märkningen ”Internal”, och kunden ser dem inte.

Vad klassificeringen beträffar: det överlämnande teamets kategorier står kvar på ärendet, även när det nya teamet inte har dem alls — de visas där med sitt ursprung, gråtonade. Så ser det nya teamet vad fallet gått under hittills, och kan vid behov sortera om det i sin egen lista.

Bara den som är ansvarig just nu får lämna ett ärende vidare. En tidigare station ser fortfarande fallet men kan inte skicka det vidare en andra gång. Den kan kommentera, men den kan inte ta tillbaka ärendet till sig själv.

I ditt teams lista visar ärendet sedan ”Waiting for other team” så länge det andra teamet arbetar med det. Bocken ”Also show tickets this team handed over” är ibockad som fabriksinställning, och varje användares eget val sparas. För det andra teamet börjar ärendet som ”Open”.

Den som lämnar över blir bevakare av ärendet. Dialogen säger det innan du bekräftar. Som bevakare får du ett e-postmeddelande när statusen ändras, ärendet stängs eller någon kommenterar. Som varje bevakare tar du bort dig själv med ”Stop observing”.

Saknas en uppgift i dina ärenden — inventarienumret, garantins slut, kostnadsstället — lägger du till den själv. Under ”Settings → Ticket Settings”, längst ned, sitter kortet ”Custom fields”. Knappen heter ”Add custom field”.

I dialogen ger du ett namn och en fälttyp: ”Text”, ”Multiline text”, ”Integer”, ”Decimal”, ”Date” eller ”Yes / No”. Typen avgör vad som kan matas in — ett datumfält tar inte emot ”nästa vecka”, och det är precis därför du kan rapportera på det senare.

Under ”Scope” bestämmer du var fältet gäller: ”All teams (including new ones)” eller ”Selected teams only”. Det första valet täcker även team som ännu inte finns — den sortens skillnad man märker först ett halvår senare.

De tre reglagen under ”Defaults” är ”Mandatory by default”, ”Hidden for customer by default” och ”Not editable by customer by default”. De gäller bara för ett fält så länge ingenting har sparats för det fältet i fältinställningarna på samma sida. Så snart du ställer in det där avgör fältinställningarna.

På ärendet sitter de anpassade fälten i ett eget kort, ”Additional information”, mellan beskrivningen och kommentarerna. Utan en mall visar formuläret alla teamets anpassade fält. Väljer du en mall när du skapar ett ärende visar det exakt de fält som mallen listar, i dess ordning — ”bara fälten det här fallet behöver”.

En mall kan dessutom göra ett fält obligatoriskt. Det administratören har dolt för kunder förblir dolt, även när en mall listar det. Ett obligatoriskt fält som en mall inte listar efterfrågas inte, så det kravet gäller inte för ärenden som skapas med den här mallen.

Hur många anpassade fält ett team får ha ställs in under ”Settings → General Settings” i kortet ”Custom fields limit”. Du blir av med ett fält med ”Deactivate”: det försvinner från formuläret, men dess värden står kvar på de gamla ärendena — reglaget ”Show deactivated” tar tillbaka det i listan.

Ibland ska någon följa ett fall utan att arbeta med det: teamledaren i en känslig fråga, kollegan som tar över nästa vecka. Det är vad bevakare är till för. På ärendet sitter fältet ”Observers” på kortet ”Actions”, knappen heter ”Add observer”. Formuläret ”Create new ticket” har samma fält. På ärendet sparas en ändring där med ”Save” i kortet ”Details”.

Bara agenter och administratörer i det team som ärendet tillhör går att välja. En kund kan inte vara bevakare — de skulle annars få post om internt arbete.

En bevakare får ett e-postmeddelande när något händer på ärendet: en ny kommentar, en ändrad status, en ny tilldelning, ändrade fält. Det skickas inte omedelbart utan buntat: efter den sista ändringen väntar systemet en minut och skickar sedan ETT meddelande som täcker allt som hände under den tiden. Så utlöser det inte sju meddelanden att beta av ett ärende i ett svep. Kommer flera kommentarer in under den tiden finns alla med i meddelandet.

Vem som bevakar hör till historiken: en ändring registreras som varje annan, med det gamla och det nya läget.

Att ange bevakare ingår i Basic. E-posten till bevakare ingår i Professional, eftersom den behöver utgående post. Utan det kan du ange bevakare, men ingenting går ut. En bevakare kan ta bort sig själv med knappen ”Stop observing”. Det kräver ingen rätt att ändra ärendet.

En bevakare läggs också till automatiskt: den som lämnar över ett ärende med ”Escalate to another team” blir bevakare. Så får de veta vad det andra teamet gör med det.

När två personer arbetar i samma ärende samtidigt kan den senare sparningen skriva över den tidigare, och ingen skulle märka det. Därför visar ärendet vem mer som har det öppet. Dessutom avvisar det en sparning som bygger på ett inaktuellt läge.

Notisen står i ärendets huvud. ”Marco Rossi is viewing this ticket” betyder att Marco har ärendet öppet. ”Marco Rossi is actively editing this ticket” betyder att Marco har osparade inmatningar i det. Det kan vara ett påbörjat svar, en kommentar som håller på att ändras, rubriken eller beskrivningen i redigeringsläge, en påminnelse, ett anpassat fält eller en tidspost. Ändrade fält i korten ”Actions” och ”Details” räknas också, så länge de inte har sparats med ”Save”. Ett öppet fönster i ärendet räknas också. Det är fönstren ”Involve another team?”, ”Escalate to another team?”, ”Close ticket”, ”Resolve incident” och ”Start a workflow”, plus fönstret för kommentaren vid ett statusbyte. Efter två minuter utan inmatning visar notisen ”viewing” igen, även om utkastet fortfarande finns kvar.

Om flera kollegor har ärendet öppet sammanfattar notisen dem, till exempel ”Marco Rossi and 2 more are viewing this ticket”. Peka på notisen för att se alla namn. Så snart någon redigerar aktivt räknar raden bara de personer som redigerar. Dig själv ser du aldrig. Har du ärendet öppet i två flikar räknas du en gång. Är ärendet bara öppet i en dold flik försvinner du ur de andras notis efter ungefär en minut.

När en kollega sparar en ändring står det ”Marco Rossi changed this ticket”, med knappen ”Refresh” bredvid. En ny kommentar från någon annan visar ”Marco Rossi added a comment”. Om ingen person gjorde ändringen, till exempel en automatiseringsregel eller ett inkommande e-postmeddelande, står det ”This ticket was changed”. Notisen står kvar tills du laddar om.

”Refresh” läser in ärendets aktuella läge, till exempel status, tilldelning, fält och historik. Hela sidan laddas inte om. Dina osparade inmatningar finns kvar. Ett påbörjat svar står kvar i svarsrutan, och en öppen rubrik eller beskrivning behåller din text. Om den sparade texten har ändrats under tiden visas ”The saved text has changed in the meantime.” under fältet. Sparar du då ersätter din text den sparade. Knappen ”Refresh” i ärendets huvud gör samma sak.

Sparar du ändå på ett inaktuellt läge avvisas sparningen. Fönstret ”Ticket changed in the meantime” öppnas. Om en person gjorde ändringen anger fönstret hens namn. Din ändring har inte sparats. Klicka på ”Refresh”, stäm av din ändring mot det aktuella läget och spara igen. Det gäller varje ändring av själva ärendet, till exempel status, tilldelning, prioritet, kortet ”Details” och anpassade fält.

Kommentarer avvisas aldrig. Två svar skriver inte över varandra. Båda hamnar i ärendet. Detsamma gäller bilagor och tidsposter. Inte heller massåtgärder på ärendelistan och automatiseringsregler kontrolleras mot läget. De ändrar ärendet direkt. Den som har det öppet ser notisen efteråt.

Kunderna ser inget av detta. De visas inte i notisen. De ser inte heller vem som arbetar med deras ärende.

Vem som har ett ärende öppet finns bara i serverns arbetsminne. Ungefär en minut efter att personen har lämnat ärendet är posten borta. Inget av det skrivs till någon logg. Ärendet sparar vem som ändrade det senast. Den uppgiften ingår i dataexporten för den personen. När personen anonymiseras tas den bort.

E-postkanalen är en väg med två riktningar, och de hör ihop: ett inkommande meddelande blir ett ärende, ditt svar går ut som post, och anmälarens svar hamnar som en kommentar på samma ärende — inte på ett andra.

Matchningen görs inte på känsla: ett svar hamnar på det befintliga ärendet bara när meddelandet bär fallets referens i ämnesraden eller för med sig e-postprogrammets svarshuvuden. Ett meddelande med varken eller startar ett nytt fall — hellre ett ärende för mycket än två orelaterade fall sammanslagna bara för att ämnesraden råkade stämma.

Allt för det sitter under ”Settings → E-Mail Settings”. Det övre kortet, ”SMTP settings”, är vägen ut: värd, port, ”Use SSL”, användare och lösenord, plus avsändaradress och avsändarnamn. Med ”Send test e-mail” skickar du ett prov till dig själv — spara först, testa sedan, som kortet säger självt.

Kortet ”IMAP settings” är vägen in: värd, port, hämtningsintervallet och de två mapparna. Du behöver inte gissa mappnamnet: ”Read from server” hämtar mapparna som verkligen finns i din brevlåda, ”Create on server” skapar en ny. Fältet tar då den sökväg din e-postserver använder för den — en server skriver ”INBOX/Processed”, nästa ”INBOX.Processed”, och båda betyder samma sak.

”Processed folder” tar emot de meddelanden som systemet lägger åt sidan: meddelanden från blockerade avsändare, automatiskt genererade meddelanden och meddelanden som ett arbetsflöde flyttar med ”Move to folder” utan en egen mapp. Lämnar du den tom stannar de i inkorgen. Under det ställer du in när rensningen körs (”Hour”, ”Minute”) och hur gammalt ett meddelande får bli (”Retention (days)”) — annars växer brevlådan tyst.

Brevlådor hör till teamet, inte till systemet: under ”Team mailboxes” anger varje team sin egen adress med ett lösenord. Den adressen är samtidigt avsändare för det teamets post — så anmälaren svarar till samma ställe som posten hämtas från.

Och nu delen som ingenting av detta händer utan: arbetsflödet. En konfigurerad brevlåda gör i sig ingenting alls. Har ett team inget aktiverat arbetsflöde hämtas brevlådan inte ens — inget ärende, ingen bekräftelse, meddelandena blir bara liggande. Det automatiska svaret till dina kunder finns bara här, och du sätter upp det själv. Det är avsiktligt: ett system som skriver till varje avsändaradress oombett vore sämre än ett som håller tyst.

Under ”E-Mail workflows” väljer du teamet överst och skapar ett arbetsflöde med ”+ Add workflow”. Det får ett namn (bara för dig), ett reglage ”Enabled” och två besked om när det gäller: ”Match” bestämmer om alla villkor måste stämma (”All conditions”) eller om ett räcker, och ”Stop after match” avslutar körningen så snart det här arbetsflödet har matchat — ett arbetsflöde längre ned kommer då aldrig till tals. Ordningen ändrar du med pilarna bredvid.

Under ”When?” sitter själva villkoret. ”Every e-mail in this mailbox” tar varje meddelande. ”Only when subject or text contains” kräver ett ord i ämnesraden eller i texten. ”Advanced” gör det exakt: där väljer du vad som granskas — ”Subject or body”, ”Subject”, ”Body”, ”Sender (From)” eller ”Recipient (To/Cc)” — och hur det jämförs: ”Contains”, ”Equals” eller ”Regex”. Så skiljer du till exempel anmälningar till en delad adress från allt annat.

Under det sitter fem åtgärder som reglage. De är arbetsflödets egentliga innehåll — det som inte är påslaget händer inte:

”Create or append ticket” gör meddelandet till ett ärende — eller lägger det som en kommentar på ett befintligt när referensen står i ämnesraden. Utan den här åtgärden blir ett meddelande aldrig ett fall.

”Set fields” sätter prioritet, status, huvud- och underkategori, ägande team och handläggare redan när ärendet skapas. Allt som står kvar på ”— Keep default —” förblir som det vore utan ett arbetsflöde.

”Auto-reply” är bekräftelsen till avsändaren. Med det här reglaget av får din kund ingen bekräftelse, hur väl allt annat än är inställt. ”Send mail” kan också skriva till avsändaren, som nästa åtgärd visar.

”Send mail” skickar ett extra meddelande: antingen till avsändaren av det inkommande meddelandet eller till utvalda teammedlemmar och fasta adresser. Den har egna ”Send conditions” — lämnar du dem tomma går den ut vid varje körning av det här arbetsflödet.

”Move to folder” arkiverar det behandlade meddelandet i en mapp. Lämnar du fältet tomt gäller den allmänna ”Processed folder” från IMAP-inställningarna ovanför.

Åtgärden ”Auto-reply” i detalj: du bygger ämnesraden av byggstenar. ”Original subject {originalSubject}” tar över ämnesraden från det inkommande meddelandet, ”Ticket reference {ticketTag}” infogar fallets referens — tillsammans ger de något i stil med ”Printer problem [TICKET-99-a1b2c3]”.

Referensen läggs inte till av sig själv. Den visas bara där du sätter {ticketTag}. {ticketId} infogar bara det nakna numret, och på det känner systemet inte igen ett svar. Utan referensen i ämnesraden matchas ett svar ändå om det bär bekräftelsens svarshuvuden. Bara ett meddelande med varken eller blir ett nytt ärende.

Texten under det är ditt bekräftelsemeddelande. Skriv det på engelska: det går genom samma export och import som varje annan text, och bara så kan det översättas till de andra språken. Lämnar du det tomt skickar systemet sitt eget standardmeddelande. Samma platshållare är tillåtna även här.

”Reply language” bestämmer vilket språk ämnesraden och texten går ut på: ”Standard English” använder engelska, ”Fixed language” ett språk du väljer, ”Assigned agent's language” språket hos den tilldelade agenten, och ”Team default language” teamets standardspråk. Översättningarna själva underhålls på språksidan.

Ett råd som systemet också skriver ut ovanför kortet: allt som hör till ett fall hör hemma i ETT arbetsflöde. Bara åtgärder inom samma arbetsflöde känner ärendet som just skapades — det är därför bekräftelsen kan nämna sitt nummer och en åtgärd ur ett andra arbetsflöde inte kan det.

Hela e-postkanalen — in och ut — ingår i utgåvan Professional. I Basic varken skickar eller tar systemet emot e-post. Ärenden skapas där via portalen, telefonen och agenten.

Tidsredovisningen är av som fabriksinställning. Så länge den är av finns inget fält och ingen kolumn. Kortet ”Time spent” i rapporten visas då bara om tid har registrerats under den valda perioden.

Ett dött fält vore sämre än inget alls, så funktionen försvinner helt i stället för att stå där gråtonad.

Reglaget sitter under ”Settings → General” på kortet ”Time tracking per ticket” och heter ”Enable time tracking”.

Varje team deltar då. För att lämna ett utanför stänger du av det på själva teamet, under ”Settings → Teams” i rutan ”Team details”.

Ett företag med ett internt IT-team och ett kundvänt team behöver det ofta bara för det andra.

Stänger du av tidsredovisningen igen senare förblir posterna som finns läsbara och exporterbara — de är ett underlag för fakturering, ingen bekvämlighet. Något nytt går inte att registrera. Befintliga poster kan då inte heller ändras eller raderas.

Ärendet bär ett kort som heter ”Time spent”. ”Log time” öppnar inmatningen.

Snabbknappar sitter bredvid fältet: ett klick på ”30m” registrerar trettio minuter. Vilka knappar som visas ställs in i inställningarna.

Fältet ”Duration” tar också emot fri inmatning: ”90” är nittio minuter, ”1.5h” är en och en halv timme, och det är ”1h 30m” också. Ett tal utan enhet är alltid minuter.

Inmatning som systemet inte förstår helt avvisas. ”1h in the evening” blir ingen post på en timme — det blir ett felmeddelande.

I ”What for (optional)” skriver du vad tiden gick till. Texten följer med in i exporten och visas inte i ärendets historik.

Flera agenter registrerar tid på samma ärende. Varje post bär sin dag, sin anteckning och namnet på personen som gjorde arbetet.

Tid registreras på en dag, inte på ett klockslag. Inmatningen har för detta ett datumfält som börjar med i dag; för att fylla i gårdagen väljer du dagen innan där. En dag i framtiden godtas inte. Ett klockslag skulle hävda en precision som inmatningen inte har.

För långa arbetspass finns ett stoppur på ärendet: ”Start timer” startar det, ”Pause” håller det.

Stoppuret skapar aldrig en post av sig självt. Det föreslår den förflutna tiden, och ingenting sparas förrän du trycker på knappen ”Log …” som anger tiden. Det som registreras är den tid som faktiskt har gått.

Det ersätter huvudräkning, inte kunskap. Utan det är funktionen komplett, eftersom att skriva in värdet är den egentliga vägen.

Att öppna ett annat ärende pausar det löpande stoppuret, och det nya ärendet talar om vilket ärende det hör till. Väntar tid som inte har registrerats fortfarande på ett annat ärende och du startar stoppuret här, frågar applikationen först. Frågan ”Start timer” erbjuder ”Log …” för tiden på det andra ärendet, ”Discard” och ”Cancel”. Den visas från en minuts förfluten tid.

Ett dolt fönster är ingen rast. Stoppuret fortsätter gå om du bara klickar bort det.

Mot ett stoppur som lämnats igång över natten finns en maximal löptid. Värdet kapas, det kastas aldrig, och agenten får veta det.

Stoppuret är av som fabriksinställning. Du hittar det i inställningarna under ”Stopwatch on the ticket”.

Varje post bär ett reglage ”Billable”. Tiden registreras en gång, och reglaget avgör om den hamnar på fakturan.

Därför kan ärendet visa två summor: allt registrerat till vänster, den debiterbara summan till höger. Den andra summan visas bara när den skiljer sig från den första.

Det finns ingen egen typ för goodwill. Goodwill, garantiarbete och internt omarbete heter olika saker i varje företag, och systemet känner bara den enda skillnad som pengar hänger på.

Så här registrerar du goodwill: mata in tiden som vanligt, slå av ”Billable” och skriv skälet i anteckningen.

Posten bär då synligt ”not billable”. Minuterna stannar i den registrerade summan, eftersom arbetet faktiskt utfördes.

Den som inte registrerar tiden alls förlorar just det tal som senare förklarar varför en kund fakturerades så lite.

Är det mesta av ditt arbete inte debiterbart vänder du på standardvärdet med reglaget ”New entries are billable by default”.

Som fabriksinställning faktureras allt på minuten. Den som fakturerar i kvartar sätter två värden.

”Rounding increment (minutes)” är steget. Varje post avrundas uppåt till nästa multipel.

”Minimum per entry (minutes)” är golvet. Varje post faktureras med minst det värdet.

De två verkar efter varandra: först golvet, sedan steget. Med ett golv på 20 och ett steg på 15 blir fem minuter trettio, eftersom resultatet måste uppfylla båda.

Under de två fälten står en exempelmening med dina egna värden. Den är beräknad, inte påstådd.

Bara det fakturerade värdet avrundas någonsin, och bara per post — aldrig summan. Två små poster avrundas därför uppåt två gånger.

Den registrerade tiden förblir orörd. Att ändra avrundningen senare förfalskar inga gamla data, eftersom värdet räknas ut när det visas.

Du ser båda på posten: där avrundningen ändrar värdet står resultatet bredvid inom parentes.

En tjänsteleverantör vill ofta inte ha något ärende stängt utan registrerad tid. Det finns ett reglage för det.

Det heter ”Require a time entry before resolving or closing” och är av som fabriksinställning.

Det gäller bara när en person ändrar statusen, och bara för personer som får registrera tid. Det gäller också när en svarsmall sätter statusen på ett enskilt ärende. En agent utan post får ett meddelande och ärendet förblir öppet.

Automatisk stängning, sammanslagning och massåtgärder blockeras aldrig. Annars skulle det finnas ärenden som ingen längre kan stänga.

Det här är hela funktionens farligaste reglage. Slå bara på det när ditt team verkligen registrerar tid varje gång.

Ärendelistan får en kolumn ”Time” som visar hur mycket som redan är registrerat på ett fall.

Du slår inte på den. Den visas så snart tidsredovisningen är på. Bara agenter och administratörer ser den. Du kan ta bort den ur din lista med ”Columns”.

På smala fönster är den en av de första som faller bort igen. Listan behåller då kolumnerna utan vilka ett ärende inte går att hitta.

Tid som bara står på ett enskilt ärende är inget underlag för en faktura. Därför bär rapportsidan ett kort ”Time spent”. Bara personer med behörigheten ”Time tracking: see the report” ser kortet.

Fyra tal står överst: registrerat, fakturerat, antalet poster och antalet ärenden som över huvud taget bär någon tid.

Det sista talet är det viktigaste efter summan. Fyrtio timmar på tre av femhundra ärenden är ingen utvärdering — det är tre agenter som är de enda som registrerar.

Under det kommer uppdelningarna: per anmälare, per team, per kategori och per dag.

Därtill kommer en tabell per anpassat fält. Det är vägen till fakturering per företag eller kostnadsställe: du skapar ett anpassat fält, fyller i det på ärendet, och rapporten grupperar efter det.

Perioden överst på sidan gäller dagen då arbetet utfördes. Juliarbete på ett juniärende står därför i julirapporten.

En notering under exportknapparna förtjänar att tas på allvar: siffrorna kommer från poster som människor har gjort och från dina avrundningsregler. De är ett arbetsunderlag, ingen reviderad faktura.

Tre knappar sitter under kortet. De levererar de enskilda posterna, inte summorna från sidan. De innehåller exakt de poster som matchar dina filter.

Det här är två mottagare, inte tre filformat. ”Export entries (CSV)” och ”Export entries (Excel)” går till ekonomiavdelningen: båda är fullständiga och kortas aldrig av.

”Export entries (PDF)” är dokumentet för en människa. Det går till kunden som en bilaga till fakturan. PDF:en har ingen kolumn för anteckningen.

PDF:en är kapad vid 20 000 poster, och dokumentet säger det självt. Ingen läser ändå en faktura med fler rader än så.

Alla tre filerna byggs ur samma källa: filter, avrundning, kolumner och siffror finns en gång, så de tre kan inte glida isär.

En post som inte är debiterbar har en tom cell i den debiterbara kolumnen, inte en nolla. En nolla skulle summeras i en pivottabell.

Är ”Per-agent evaluation” för tidsredovisningen av saknas kolumnen ”Agent” i alla tre filerna. Faller din licens tillbaka till Basic förblir de befintliga posterna läsbara och exporterbara.

En kund ser aldrig tidsposterna, inte ens på sitt eget ärende.

Det här är ingen inställning utan en spärr i servern. Det finns inget reglage som öppnar den.

Skälet sitter i posterna själva: anteckningar skrivs för teamet. De säger vad som gick fel och hur lång tid sökandet efter orsaken tog.

Andra system av det här slaget gör detsamma. Där tid når kunden når den dem som ett dokument.

Det är vad PDF-exporten är till för: den går ut med fakturan och inte till ärendet i kundportalen.

Rapporten kan dessutom visa vem som registrerat hur mycket. Som fabriksinställning gör den det inte.

Tid per person är prestationsdata, och i många företag har facket ett ord med i laget.

Reglaget heter ”Per-agent evaluation” och sitter i inställningarna.

Så länge det är av levererar servern inte ens siffrorna. Tabellen är inte dold — den finns inte.

Den skillnaden har betydelse. En spärr som bara visningen känner till är ingen spärr.