Sagsstyring

Du opretter en ny sag med »New Ticket« i bjælken til venstre. Formularen hedder »Create new ticket«. Som agent registrerer du også andres henvendelser med den — det er, hvad feltet »User« er til: det siger, hvem sagen er for, ikke hvem der taster den ind.

Alt med en stjerne er påkrævet: »Title«, »User«, »Main category« og »Description«. Én mere, som er let at overse: formularen gemmer ikke uden en underkategori, selv om »Subcategory« ikke bærer nogen stjerne — en hoved- og en underkategori hører sammen og bliver altid sat parvis.

Hvilke felter der er påkrævede, sættes under »Settings → Ticket Settings«. Kortet »Admin / Agent Field Settings« har kun kontakten »Field is mandatory« til det. Kortet »Customer Field Settings« har desuden »Is hidden for Customer« og »Is not editable«. Derfor kan en kunde se en kortere formular end dig, uden at nogen skal vedligeholde to formularer. »Title« og »Description« er altid påkrævede. Det kan ikke slås fra.

Bagefter kan du ændre næsten alt: til højre for sagen sidder kortet »Details« med anmelder, telefon, e-mail, lokation, kategori og referencenummer; du ændrer selve feltet og bekræfter med »Save« nedenunder. Status, tildeling, prioritet, kanal og observatører sidder et kort højere oppe under »Actions«. Status og tildeling træder i kraft med det samme. Prioritet, kanal og observatører bliver først gemt med »Save« i kortet »Details«.

Kun agenter og administratorer må ændre det. Anmelderen kan læse sagen, kommentere på den og vedhæfte filer — men ikke ændre den klassificering, jeres rapportering er bygget på.

En sidevirkning, det er værd at kende én gang: retter du i en sag, der endnu ikke tilhører nogen, tilhører den dig bagefter. Systemet skriver dig ind som agent og flytter statussen fra »Open« til »Assigned« — begge dele ender i historikken. Ville du ikke det, så tildel den til en anden bagefter.

Hver eneste af disse ændringer lander i sagens historik, med navn, tidspunkt, gammel værdi og ny værdi. Du behøver ikke at slå noget til for det.

Så er der spørgsmålet om, hvordan man kommer af med sager igen. Under »Settings → Archive« vælger du en periode, ser med »Preview«, hvor mange lukkede sager den indeholder, og opretter en ZIP-fil med »Create archive«: sager, kommentarer, historik, brugerdefinerede felter og vedhæftede filer, alt sammen i én fil. Oprettelsen fjerner intet. Sagerne forlader først den kørende database med det særskilte trin »Delete from live DB« i listen »Existing archives« — og de kan gendannes fra netop den fil.

Beskrivelsen og kommentarerne er ikke nøgne tekstfelter. Hver har en værktøjslinje ovenover, og knapperne siger, hvad de gør, når du peger på dem: »Bold«, »Italic«, »Underline«, »Strikethrough«, »Text color«, »Highlight color«, »Bullet list«, »Numbered list«, »Quote«, »Link« og »Clear formatting«.

Sådan laves et link: markér teksten, klik på »Link«, tast adressen ind i den lille dialog. En tom indtastning fjerner linket igen. Web- og mailadresser er tilladt (http, https, mailto) — alt andet bliver smidt væk ved gemningen, så en kommentar ikke kan liste noget forbi nogen.

Billeder kommer ind gennem udklipsholderen: tag et skærmbillede, og indsæt det direkte i redigeringsfeltet med Ctrl+V. Til at begynde med viser teksten kun en markør som »[inline-image:1]«. Når du gemmer, uploader systemet billedet og viser det præcis der — og det lander også på fanebladet »Attachments«, hvor alle sagens filer bor. Indsættelse af billeder virker i beskrivelsen af en eksisterende sag og i en ny kommentar. Det virker ikke i formularen »Create new ticket« og heller ikke, mens du redigerer en kommentar.

Det, du ser, er det, de andre ser: formatering, lister og links bliver bevaret i sagen, og også i mailen til anmelderen. Fremmed opmærkning — fra en kopieret webside eller en indgående e-mail for eksempel — bliver skåret tilbage til dette tilladte sæt. Intet af din tekst går tabt undervejs, kun indpakningen.

En kommentar kan markeres som intern med »Internal note (not visible to the customer)«. Den bærer så mærkningen »Internal« og er usynlig for anmelderen — heller ikke søgningen får den frem.

Alle kan ændre og slette deres egne kommentarer. Det, en kunde har skrevet, kan kun den kunde eller en administrator ændre eller slette. Det gælder også hendes mails. Kommentarer fra kolleger kan ændres og slettes af hver agent, der må arbejde på sagen. Det gælder også et team, der havde sagen tidligere.

Filer hører til sagen, ikke til en enkelt kommentar. På sagen fører fanebladet »Attachments« til listen: »Upload file« lægger en til, hver række nævner filen, dens størrelse og dens dato. Alle, der er med i sagen, må vedhæfte noget — også anmelderen, så ingen behøver at maile jer sit skærmbillede. En kunde kan kun slette vedhæftede filer, hun selv har uploadet. Når en undersag bliver lukket, bliver dens vedhæftede filer kopieret til oversagen, hvor de bærer mærkningen »Internal«. Agenter ser dem; kunder hverken ser eller downloader dem.

Et klik på navnet åbner forhåndsvisningen, uden at du skal hente filen. Billeder kan du zoome ind på, zoome ud fra og dreje derinde — nyttigt ved et display, der er fotograferet skævt. En PDF bliver vist i det samme vindue, med sideoversigt, zoom og print. Tekstfiler bliver vist som tekst. Med »Open in new tab« åbner du filen i sit eget vindue.

En vedhæftet fil hører til sagen og følger med den: den står i historikken (»File uploaded: …«), overlever en overdragelse til et andet team og ender inde i arkivfilen, når sagen bliver arkiveret.

Fanebladet »History« på sagen svarer på spørgsmålet bag enhver opfølgning: hvem ændrede hvad, og hvornår? Hver række nævner personen, feltet, den gamle værdi overstreget, den nye bagefter og tidspunktet ned til sekundet. Den nyeste post står øverst.

Poster bliver skrevet uden din medvirken — ved statusskift, prioritet, tildeling, kategori, lokation, observatører, titel og beskrivelse, og ved oprettelsen (»Ticket opened«), ved hver kommentar og ved hver uploadet fil. Tallet på fanebladet fortæller dig på forhånd, hvor meget bevægelse der var i sagen.

Historikken kan ikke redigeres og ikke slås fra. Det er præcis det, der gør den nyttig: det er grunden til, at en sag ikke kan slettes enkeltvis, og den følger med ind i arkivfilen, når sagen bliver arkiveret.

For en kommentar noterer historikken kun, at den er tilføjet, redigeret eller slettet. Ordlyden bor på fanebladet »Comments«. En intern kommentar dukker også op i historikken, men kun for agenter og administratorer.

Statussen siger, hvor en sag står lige nu. Tolv statusser følger med systemet — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed og flere. Du finder dem under »Settings → General Settings« i afsnittet »Drop-down lists« bag fanebladet »Status«; »+ Add status« opretter en af dine egne, »Edit status« åbner en eksisterende.

Det vigtige er forskellen på navnet og betydningen. I redigeringen af en status, under »Meaning of this status«, er der tre kontakter: »Counts as resolved«, »Counts as closed« og »Waiting for the requester«. Kun disse kontakter fortæller systemet, hvordan en status skal behandles.

Du må omdøbe hver status, også dem der følger med systemet: nederst i redigeringen, under »Translations«, er der et »Name«-felt per sprog — skriv det derind, som dine folk skal læse. Det tekniske navn bagved bliver ikke rørt, og netop derfor går intet i stykker: automatisering, rapportering og kontakterne ovenover hænger på det navn, ikke på din etiket. Så »Resolved« kan blive til »Done«.

At slette virker derimod ikke for dem alle. Otte statusser bærer mærkningen »Mandatory« i listen — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval og Rejected. De kan omdøbes og flyttes i rækkefølgen, men ikke fjernes; forsøger man det, ender det med en tydelig besked. Det er ikke der for at genere dig: der hænger processer på dem, som ellers ville stoppe uden et ord — for eksempel den automatiske lukning, der har brug for en »løst«-status som udgangspunkt.

To statusser hører til systemet selv: »Waiting for approval« og »Rejected« bærer mærkningen »System only«. De kommer ud af en godkendelsesproces, og ingen skal kunne påstå i hånden, at noget blev afvist, som aldrig var oppe til beslutning.

Hvad de tre gør: en status, der tæller som løst, lukker sagen af sig selv efter 24 timer. En status, der tæller som lukket, er den endelige tilstand, sagen bliver flyttet ind i. Og »Waiting for the requester« betyder præcis det: vi venter på anmelderen — ikke på et andet team og ikke på en leverandør. Det er den markering, SLA-uret stopper på, hvis du sætter det op sådan.

Nedenunder sidder »Allowed transitions to new status«. Her sætter du flueben ved, hvilke statusser der kan nås fra denne. Lad alt stå tomt, og intet er begrænset; sæt flueben ved noget, og hver anden vej er lukket. Sådan bygger du et forløb, der ikke kan springes over — for eksempel: fra »Open« kan man kun komme til »In Progress« eller »Assigned«, men ikke direkte til »Closed«.

De øvrige kontakter i redigeringen er små ting med stor virkning: farven til listen, »Sort order« til rækkefølgen, »Show status in new ticket form« (skal denne status overhovedet kunne vælges, når man opretter en sag?), »Requires comment in dialog« (fremtving en begrundelse) og »System only« til statusser, som kun systemet selv må sætte.

Op til fire statusser vises på sagen som knapper under »Change Status to:«. Du vælger dem i redigeringen med kontakten »Set as primary status (max. 4)«. I fabriksindstillingen er det In Progress, Waiting for User Response, Waiting for Service Provider Response og Resolved. Alle andre statusser ligger under »More statuses«.

Alt, der dukker op som en rulleliste i en sag, tilhører dig. Under »Settings → General Settings« sidder kortet »Drop-down lists« med seks faneblade: »Department«, »Position«, »Location«, »Role«, »Status« og »Priority«. Håndteringen er forskellig fra liste til liste.

Én ad gangen: tast det engelske navn ind i det tomme felt, og klik på knappen ved siden af — den er opkaldt efter listen, altså »+ Add location«, »+ Add department« og så videre. Rækkerne nedenunder er de eksisterende poster. I »Department«, »Position« og »Location« er det der, du ændrer et navn og bekræfter med det »Save«, der står ved siden af.

Til mange poster på én gang tilbyder »Department«, »Position« og »Location« også »Export JSON« og »Import JSON«. På et frisk installeret system henter du den tomme struktur med »Export JSON«, udfylder den og importerer den igen. Det er ikke en måde at omdøbe på — det siger kortet selv.

Nogle poster bærer mærkningen »Mandatory«. De tre roller »Admin«, »Agent« og »Customer« er blandt dem, otte af de statusser der følger med systemet, og én pladsholder i hver af listerne Location, Position og Department (»None selected or available«). Ingen af dem kan slettes: der hænger rettigheder og processer på dem, som ellers ville stoppe uden et ord. Statusserne kan dog omdøbes i deres egen editor. Rollerne og pladsholderne kan ikke omdøbes. Hvad der er tilladt, afhænger af listen. »Role« er låst: en rolle kan hverken tilføjes eller omdøbes. I »Priority« tilføjer og sletter du poster, men der er ingen fil og ingen omdøbning. »Status« har sin egen editor og heller ingen fil.

Du oversætter ikke til de andre sprog her, men i ét hug på oversættelsessiden. Det engelske navn er nok her — det er det anker, oversættelserne senere hænger på.

Statussen er den eneste post med sin egen redigering, fordi der hænger mere på den end et navn; den har sit eget kort længere nede.

Kategorier er det, anmelderen eller agenten vælger, når en sag bliver oprettet — og det, du senere grupperer dine rapporter efter. Hvert team har sine egne: en helpdesk sorterer efter andre ting end en netværksafdeling, og ingen af dem ser det andet teams lister.

Du finder dem under »Settings« som posten »<teamnavn> Categories«. I eksemplet hedder teamet »Helpdesk«, så posten hedder »Helpdesk Categories«.

Siden har tre kort: »Main categories«, »Subcategories« og »Links«. Den hurtigste start: tast det engelske navn ind i feltet »EN (required)«, og klik på »+ New main category« eller »+ New subcategory«. Alt andet oversætter du senere i ét hug på oversættelsessiden — der er intet at forberede til det her.

Har du mange kategorier foran dig, så tag vejen gennem filen: »Export JSON« henter strukturen — på et frisk installeret system er filen tom og viser dig kun opbygningen. Du udfylder den (i hånden eller med hjælp fra en AI), gemmer den og lægger den op igen via »Import JSON«. Det er ikke en måde at omdøbe på: et navn ændrer du i den kategoris felt og bekræfter med det »Save«, der står ved siden af — det siger siden også selv.

Det tredje kort, »Links«, er der, det egentlige arbejde sker. Vælg en hovedkategori øverst, sæt flueben ved de underkategorier, der hører til den, nedenunder, og gem med »Save links«. Fidusen: én underkategori må hænge på flere hovedkategorier. Så du skal kun bruge »Malfunction« én gang og genbruger den til Printer, Network, Meeting-Room og Notebook.

Fra da af er kategorierne til rådighed i sagen. At slette kan mislykkes, så længe der stadig er sager, der bruger en kategori — det er med vilje, ellers ville gamle sager miste deres klassificering. Fjerner du en kobling, kan sager, der bruger det par, stadig gemmes. Kun en nyvalgt kategori bliver kontrolleret mod koblingerne.

Giver du en sag videre til et andet team, bliver dens klassificering stående — også når det nye team slet ikke har de kategorier. Den står så i feltet sammen med sin oprindelse, for eksempel »Meeting-Room · from Helpdesk«, og er gråtonet: det nye team kan se, hvad sagen hidtil kørte som, men kan ikke selv tildele den post. For at sortere den om vælger du fra din egen liste — og systemet vil så have en hoved- og en underkategori sammen.

Hver sag bærer en kanal. Den står i formularen og senere på kortet »Actions« under »How the request came in«, og den svarer på et spørgsmål, der hurtigt bliver vigtigt i rapporteringen: kommer arbejdet ind gennem portalen eller over telefonen?

Du kan kun vælge det, et menneske ved, og systemet ikke ved: »Phone« og »Entered by an agent«. De to andre værdier sætter systemet selv — »Self-service«, når anmelderen oprettede sagen i portalen, og »E-mail«, når den voksede ud af en indgående mail. Når en agent opretter en sag, starter formularen med »Entered by an agent«.

En kanal, som systemet har sat, kan ingen ændre bagefter. Feltet siger så »Recorded by the system. It cannot be changed.« Ellers ville feltet miste præcis den oplysning, det findes for. Den anden vej rundt må du stadig ændre alt andet på en sag, der er registreret over telefonen.

Kun en agent eller en administrator må sætte kanalen. For anmelderen ville det være en udtalelse om hendes egen sag — og rapporteringen ville afhænge af, at alle er ærlige.

»E-mail« kræver en tilsluttet postkasse, og den er en del af Professional-udgaven. De tre andre kanaler findes i begge udgaver.

Over hver sagsliste er feltet »Search tickets…«. Det søger ikke kun i titler, men i hele sagen: titel, beskrivelse, anmelderens navn, e-mailadresse og telefonnummer, lokation, referencesagsnummer, alle kommentarer og tekstværdierne i dine egne brugerdefinerede felter.

Eksemplet viser det: »coffee« står i ingen titel, kun i beskrivelsen på én sag — og den bliver alligevel fundet. Så du behøver ikke at huske, hvad en sag blev kaldt; ét ord fra sagen er nok.

Store og små bogstaver er ligegyldige. Søgningen gælder altid den liste, du står i lige nu, og kan kombineres med »Filter« ved siden af; »Reset« rydder søgning og filtre igen. Listen husker dine filtre, separat for hver teamliste. De står der igen, når du kommer tilbage fra en sag, genindlæser siden eller logger ind på en anden computer. Søgeteksten husker den ikke. For kunder er der en grænse, du ikke kan se, men bør kende: de søger ikke i interne kommentarer — ellers kunne de af resultatlisten slutte sig til, hvad der blev drøftet internt. De søger heller ikke i brugerdefinerede felter, der er skjult for kunder.

Alle sammensætter deres egen sagsliste. Til det sidder knappen »Columns« ved siden af »Filter«. Den åbner dialogen »Choose columns«.

I dialogen sætter du flueben ved hver kolonne, du vil se. Pilene ved siden af bestemmer rækkefølgen. »#« og »Title« er altid med. Bredden på en kolonne ændrer du i selve listen ved at trække i kanten af dens overskrift.

»Save« gemmer dit valg på din brugerkonto. Derfor gælder det på hver computer og bliver ved, når du logger ud. »Default columns« sætter listen tilbage til fabriksindstillingen.

Når der ikke er plads til alle kolonner, falder dem længst til højre væk først. »#«, »Title« og »Status« bliver altid. Så du flytter det, der betyder mest for dig, frem.

Med Professional bliver dine brugerdefinerede felter også tilbudt. De står i dialogen under deres eget navn, her for eksempel »Asset tag«.

Kunder kan indrette deres liste på samme måde, men får tilbudt færre kolonner. »Team«, »Created by«, »Last activity«, »Status changed at«, »Deadline«, »Follow-up« og »Time« er ikke tilgængelige for dem. Felter, du har skjult for kunder, vises heller ikke som kolonne.

På en smartphone vises knappen ikke. Der viser listen de kolonner, der er plads til.

Sagen tilbyder to knapper ved siden af hinanden til det, og forskellen står med småt nedenunder. »Involve another team«: du er stadig ansvarlig, det andet team arbejder ved siden af dig i en tilknyttet sag. »Escalate to another team«: det andet team overtager.

Når du giver videre, flytter ansvaret, uden at der opstår en sag nummer to. Dit team beholder læseadgang og må stadig kommentere, men kan ikke længere ændre noget — og præcis det fortæller dialogen dig, før du bekræfter. Der vælger du modtagerteamet og kan tilføje en begrundelse.

Når du inddrager et team, bliver din sag i dine hænder og får en undersag i det andet team. Din flytter til statussen »Waiting for other team«; når det andet team lukker sin, kommer din tilbage som »Back from other team«. Så du behøver ikke at spørge, om der er sket noget derovre. Undersagens vedhæftede filer bliver kopieret til din sag med mærkningen »Internal«, og kunden ser dem ikke.

Med hensyn til klassificeringen: det afgivende teams kategorier bliver stående på sagen, også når det nye team slet ikke har dem — de dukker op der med deres oprindelse, gråtonede. På den måde kan det nye team se, hvad sagen hidtil kørte som, og sortere den om til sin egen liste, hvis der er brug for det.

Kun den, der er ansvarlig lige nu, må give en sag videre. En tidligere station ser stadig sagen, men kan ikke sende den videre en gang til. Den kan kommentere, men den kan ikke tage sagen tilbage til sig selv.

I dit teams liste viser sagen derefter »Waiting for other team«, så længe det andet team arbejder på den. Fluebenet ved »Also show tickets this team handed over« er sat som fabriksindstilling, og hver brugers eget valg bliver gemt. For det andet team starter sagen som »Open«.

Den, der giver sagen videre, bliver observatør på den. Dialogen siger det, før du bekræfter. Som observatør får du en e-mail, når status ændres, sagen lukkes, eller nogen kommenterer. Som enhver observatør fjerner du dig selv med »Stop observing«.

Når en oplysning mangler i jeres sager — aktivnummeret, garantiens udløb, omkostningsstedet — tilføjer du den selv. Under »Settings → Ticket Settings« sidder nederst kortet »Custom fields«; knappen hedder »Add custom field«.

I dialogen giver du et navn og en felttype: »Text«, »Multiline text«, »Integer«, »Decimal«, »Date« eller »Yes / No«. Typen bestemmer, hvad der kan tastes ind — et datofelt tager ikke imod »i næste uge«, og netop derfor kan du rapportere på det senere.

Under »Scope« bestemmer du, hvor feltet gælder: »All teams (including new ones)« eller »Selected teams only«. Det første valg dækker også teams, der endnu ikke findes — den slags forskel, man først opdager et halvt år senere.

De tre kontakter under »Defaults« er »Mandatory by default«, »Hidden for customer by default« og »Not editable by customer by default«. De gælder kun for et felt, så længe der ikke er gemt noget for det felt i feltindstillingerne på den samme side. Så snart du sætter det der, bestemmer feltindstillingerne.

På sagen sidder de brugerdefinerede felter på deres eget kort, »Additional information«, mellem beskrivelsen og kommentarerne. Uden en skabelon viser formularen alle teamets brugerdefinerede felter. Vælger du en skabelon, når du opretter en sag, viser den præcis de felter, skabelonen nævner, i dens rækkefølge — »kun de felter, denne sag har brug for«.

En skabelon kan desuden gøre et felt påkrævet. Det, administratoren har skjult for kunder, forbliver skjult, også når en skabelon opfører det. Et påkrævet felt, som en skabelon ikke opfører, bliver ikke efterspurgt, så det krav gælder ikke for sager, der bliver oprettet med denne skabelon.

Hvor mange brugerdefinerede felter et team må have, bliver sat under »Settings → General Settings« i kortet »Custom fields limit«. Du kommer af med et felt med »Deactivate«: det forsvinder fra formularen, men dets værdier bliver stående på de gamle sager — kontakten »Show deactivated« henter det tilbage i listen.

Nogle gange skal nogen følge en sag uden at arbejde på den: teamlederen i en delikat sag, kollegaen der overtager i næste uge. Det er, hvad observatører er til. På sagen sidder feltet »Observers« på kortet »Actions«, knappen hedder »Add observer«; formularen »Create new ticket« har det samme felt. På sagen bliver en ændring der gemt med »Save« i kortet »Details«.

Kun agenter og administratorer fra det team, sagen hører til, kan vælges. En kunde kan ikke være observatør — hun ville ellers få mail om internt arbejde.

En observatør får en e-mail, når der sker noget på sagen: en ny kommentar, en ændret status, en ny tildeling, ændrede felter. Den bliver ikke sendt med det samme, men samlet: efter den sidste ændring venter systemet et minut og sender så ÉN mail, der dækker alt, hvad der skete i den tid. Så at arbejde en sag igennem i ét stræk udløser ikke syv mails. Kommer der flere kommentarer i den tid, står de alle i mailen.

Hvem der observerer, er en del af historikken: en ændring bliver noteret som enhver anden, med den gamle og den nye tilstand.

At indtaste observatører er en del af Basic. Mailen til observatører er en del af Professional, fordi den kræver udgående post. Uden det kan du indtaste observatører, men der går intet ud. En observatør kan fjerne sig selv med knappen »Stop observing«. Det kræver ingen ret til at ændre sagen.

En observatør bliver også tilføjet automatisk: den, der giver en sag videre med »Escalate to another team«, bliver observatør. Sådan får vedkommende at vide, hvad det andet team gør med den.

Når to personer arbejder på den samme sag på samme tid, kan den senere gemning overskrive den tidligere, og ingen ville opdage det. Derfor viser sagen, hvem der ellers har den åben. Derudover afviser den en gemning, der bygger på en forældet tilstand.

Meddelelsen står øverst på sagen. »Marco Rossi is viewing this ticket« betyder, at Marco har sagen åben. »Marco Rossi is actively editing this ticket« betyder, at Marco har ikke-gemte indtastninger i den. Det kan være et påbegyndt svar, en kommentar, der er ved at blive ændret, titlen eller beskrivelsen i redigeringstilstand, en påmindelse, et brugerdefineret felt eller en tidspost. Ændrede felter på kortene »Actions« og »Details« tæller også med, så længe de ikke er gemt med »Save«. Et åbent vindue på sagen tæller også. Det er vinduerne »Involve another team?«, »Escalate to another team?«, »Close ticket«, »Resolve incident« og »Start a workflow«, plus vinduet til kommentaren ved et statusskift. Efter to minutter uden indtastning viser meddelelsen igen »viewing«, også selv om udkastet stadig står der.

Har flere kolleger sagen åben, samler meddelelsen dem, for eksempel »Marco Rossi and 2 more are viewing this ticket«. Peg på meddelelsen for at se alle navne. Så snart nogen redigerer aktivt, tæller linjen kun de personer, der redigerer. Dig selv ser du aldrig. Har du sagen åben i to faneblade, tæller du én gang. Er sagen kun åben i et skjult faneblad, forsvinder du fra de andres meddelelse efter cirka et minut.

Når en kollega gemmer en ændring, står der »Marco Rossi changed this ticket« med knappen »Refresh« ved siden af. En ny kommentar fra en anden viser »Marco Rossi added a comment«. Kom ændringen ikke fra en person, for eksempel fra en automatiseringsregel eller en indgående e-mail, står der »This ticket was changed«. Meddelelsen bliver stående, indtil du genindlæser.

»Refresh« indlæser sagens aktuelle tilstand, for eksempel status, tildeling, felter og historik. Hele siden bliver ikke genindlæst. Dine ikke-gemte indtastninger bliver. Et påbegyndt svar bliver stående i svarfeltet, og en åben titel eller beskrivelse beholder din tekst. Har den gemte tekst ændret sig i mellemtiden, vises »The saved text has changed in the meantime.« under feltet. Gemmer du så, erstatter din tekst den gemte. Knappen »Refresh« øverst på sagen gør det samme.

Gemmer du alligevel på en forældet tilstand, bliver gemningen afvist. Vinduet »Ticket changed in the meantime« åbner. Har en person lavet ændringen, nævner vinduet personens navn. Din ændring er ikke gemt. Klik på »Refresh«, hold din ændring op mod den aktuelle tilstand, og gem igen. Det gælder enhver ændring af selve sagen, for eksempel status, tildeling, prioritet, kortet »Details« og brugerdefinerede felter.

Kommentarer bliver aldrig afvist. To svar overskriver ikke hinanden. Begge havner på sagen. Det samme gælder vedhæftede filer og tidsposter. Heller ikke massehandlinger på sagslisten og automatiseringsregler bliver kontrolleret mod tilstanden. De ændrer sagen direkte. Den, der har den åben, ser meddelelsen bagefter.

Kunder ser intet af dette. De vises ikke i meddelelsen. De ser heller ikke, hvem der arbejder på deres sag.

Hvem der har en sag åben, ligger kun i serverens arbejdshukommelse. Cirka et minut efter at personen har forladt sagen, er posten væk. Intet af det bliver skrevet i en log. Sagen gemmer, hvem der sidst ændrede den. Den oplysning er en del af dataeksporten for den person. Når personen bliver anonymiseret, bliver den fjernet.

Mailkanalen er én vej med to retninger, og de hører sammen: en indgående mail bliver til en sag, dit svar går ud som mail, og anmelderens svar lander som kommentar på den samme sag — ikke på en nummer to.

Sammenkoblingen sker ikke på fornemmelsen: et svar lander kun på den eksisterende sag, når mailen bærer sagens henvisning i emnefeltet eller har mailprogrammets svarhoveder med sig. En mail med ingen af delene starter en ny sag — hellere én sag for meget end to sager, der intet har med hinanden at gøre, slået sammen bare fordi emnet tilfældigvis passede.

Alt til det sidder under »Settings → E-Mail Settings«. Det øverste kort, »SMTP settings«, er vejen ud: vært, port, »Use SSL«, bruger og adgangskode, dertil afsenderadressen og afsendernavnet. Med »Send test e-mail« sender du dig selv en prøve — gem først, test så, som kortet selv siger.

Kortet »IMAP settings« er vejen ind: vært, port, hentningsintervallet og de to mapper. Du behøver ikke at gætte mappenavnet: »Read from server« henter de mapper, der virkelig findes i din postkasse, »Create on server« opretter en ny. Feltet tager så den sti, din mailserver bruger til den — én server skriver »INBOX/Processed«, den næste »INBOX.Processed«, og begge dele betyder det samme.

»Processed folder« modtager de mails, som systemet lægger til side: mails fra blokerede afsendere, automatisk genererede mails og mails, som et workflow flytter med »Move to folder« uden sin egen mappe. Lader du feltet stå tomt, bliver de i indbakken. Nedenunder sætter du, hvornår oprydningen kører (»Hour«, »Minute«), og hvor gammel en besked må blive (»Retention (days)«) — ellers vokser postkassen stille og roligt.

Postkasser hører til teamet, ikke til systemet: under »Team mailboxes« indtaster hvert team sin egen adresse med en adgangskode. Den adresse er samtidig afsenderen på det teams mails — så anmelderen svarer det samme sted hen, som posten bliver hentet fra.

Og nu den del, uden hvilken intet af det sker: workflowet. En opsat postkasse gør slet ingenting i sig selv. Har et team intet slået workflow til, bliver postkassen ikke engang hentet — ingen sag, ingen kvittering, mailene bliver bare liggende. Det automatiske svar til jeres kunder findes kun her, og du sætter det selv op. Det er med vilje: et system, der uopfordret skriver til hver afsenderadresse, ville være værre end et, der tier stille.

Under »E-Mail workflows« vælger du teamet øverst og opretter et workflow med »+ Add workflow«. Det får et navn (kun til dig), en »Enabled«-kontakt og to udsagn om, hvornår det gælder: »Match« bestemmer, om alle betingelser skal være opfyldt (»All conditions«), eller om én er nok, og »Stop after match« afslutter kørslen, så snart dette workflow har passet — et workflow længere nede kommer så aldrig til. Rækkefølgen ændrer du med pilene ved siden af.

Under »When?« sidder selve betingelsen. »Every e-mail in this mailbox« tager hver mail; »Only when subject or text contains« kræver et ord i emnet eller teksten. »Advanced« gør det præcist: der vælger du, hvad der bliver kigget på — »Subject or body«, »Subject«, »Body«, »Sender (From)« eller »Recipient (To/Cc)« — og hvordan der bliver sammenlignet: »Contains«, »Equals« eller »Regex«. Sådan skiller du for eksempel anmeldelser til en fælles adresse fra alt det andet.

Nedenunder sidder fem handlinger som kontakter. De er workflowets egentlige indhold — det, der ikke er slået til, sker ikke:

»Create or append ticket« gør mailen til en sag — eller føjer den som kommentar til en eksisterende, når henvisningen står i emnet. Uden denne handling bliver en mail aldrig til en sag.

»Set fields« sætter prioritet, status, hoved- og underkategori, ejerteam og sagsbehandler allerede når sagen bliver oprettet. Alt, der står på »— Keep default —«, bliver, som det ville være uden et workflow.

»Auto-reply« er kvitteringen til afsenderen. Med denne kontakt slået fra får din kunde ingen kvittering, uanset hvor godt alt andet er sat op. »Send mail« kan også skrive til afsenderen, som den næste handling viser.

»Send mail« sender en ekstra mail: enten til afsenderen af den indgående mail eller til udvalgte teammedlemmer og faste adresser. Den har sine egne »Send conditions« — lader du dem stå tomme, går den ud ved hver kørsel af dette workflow.

»Move to folder« lægger den behandlede mail i en mappe. Lad feltet stå tomt, og den generelle »Processed folder« fra IMAP-indstillingerne ovenover gælder.

Handlingen »Auto-reply« i detaljer: emnet bygger du af klodser. »Original subject {originalSubject}« overtager emnet fra den indgående mail, »Ticket reference {ticketTag}« indsætter sagens henvisning — sammen giver de noget i retning af »Printer problem [TICKET-99-a1b2c3]«.

Henvisningen bliver ikke tilføjet af sig selv. Den dukker kun op, hvor du sætter {ticketTag}. {ticketId} indsætter kun det nøgne nummer, og på det genkender systemet ikke et svar. Står henvisningen ikke i emnet, bliver et svar alligevel koblet til sagen, hvis det har kvitteringens svarhoveder med sig. Kun en mail med ingen af delene bliver til en ny sag.

Teksten nedenunder er din kvitteringsbesked. Skriv den på engelsk: den løber gennem den samme eksport og import som hver anden tekst, og kun på den måde kan den oversættes til de andre sprog. Lad den stå tom, og systemet sender sin egen standardbesked. De samme pladsholdere er tilladt her også.

»Reply language« bestemmer, hvilket sprog emnet og teksten går ud på: »Standard English« bruger engelsk, »Fixed language« et sprog, du vælger, »Assigned agent's language« den tildelte agents sprog, og »Team default language« teamets standard. Selve oversættelserne bliver vedligeholdt på sprogsiden.

Ét råd, som systemet også skriver over kortet: alt, der hører til én sag, hører til i ÉT workflow. Kun handlinger inden for det samme workflow kender den sag, der lige er oprettet — derfor kan kvitteringen nævne sit nummer, og en handling fra et andet workflow kan ikke.

Hele mailkanalen — ind og ud — er en del af Professional-udgaven. I Basic sender og modtager systemet ingen e-mail; sager bliver der oprettet gennem portalen, telefonen og agenten.