Útmutató

Új hibajegyet a bal oldali sávban lévő „New Ticket” gombbal hoz létre. Az űrlap neve „Create new ticket”. Ügyintézőként ezzel rögzíti mások megkereséseit is — erre való a „User” mező: azt mondja meg, kiért van az ügy, nem azt, ki gépeli be.

Minden csillagos mező kötelező: „Title”, „User”, „Main category” és „Description”. Van még egy, amelyet könnyű elnézni: az űrlap alkategória nélkül nem mentődik, pedig a „Subcategory” nem visel csillagot — a fő- és az alkategória összetartozik, és mindig párban állítjuk be.

Azt, hogy egyáltalán mely mezők jelennek meg, és melyikük kötelező, a „Settings → Ticket Settings” alatt állítja be — külön az ügyintézőknek és külön az ügyfeleknek. Ezért lát egy ügyfél rövidebb űrlapot, mint Ön, anélkül hogy bárkinek két űrlapot kellene karbantartania.

Utólag szinte mindent megváltoztathat: a hibajegy jobb oldalán van a „Details” kártya a bejelentővel, a telefonszámmal, az e-mail-címmel, a telephellyel, a kategóriával és a hivatkozási számmal; a mezőt magát írja át, és az alatta lévő „Save” gombbal erősíti meg. Az állapot, a prioritás, a kiosztás, a csatorna és a megfigyelők eggyel feljebb, az „Actions” kártyán ülnek, és külön mentés nélkül, azonnal érvényesek.

Ezt csak az ügyintézők és a rendszergazdák változtathatják meg. A bejelentő elolvashatja az ügyet, hozzászólhat és fájlokat csatolhat — de nem változtathatja meg azt a besorolást, amelyre a kimutatásai épülnek.

Egy mellékhatást érdemes egyszer megjegyezni: ha olyan hibajegyet szerkeszt, amely még senkié, utána az Öné lesz. A rendszer Önt írja be ügyintézőként, és az állapotot „Open” értékről „Assigned” értékre viszi — mindkettő bekerül az előzményekbe. Ha nem ezt akarta, ossza ki utólag valaki másnak.

Mindegyik ilyen változás bekerül a hibajegy előzményeibe, névvel, időponttal, régi és új értékkel. Ehhez semmit nem kell bekapcsolnia.

Marad a kérdés, hogyan szabadul meg mégis a hibajegyektől. A „Settings → Archive” alatt kiválaszt egy időszakot, a „Preview” gombbal megnézi, hány lezárt hibajegy van benne, és a „Create archive” gombbal ZIP-fájlt hoz létre: hibajegyek, hozzászólások, előzmények, egyéni mezők és mellékletek, mind egy fájlban. Ezek a hibajegyek csak ezután tűnnek el az élő adatbázisból — és ugyanabból a fájlból vissza is állíthatók.

A leírás és a hozzászólások nem puszta szövegdobozok. Mindegyik fölött eszköztár áll, és a gombok rámutatáskor megmondják, mit csinálnak: „Bold”, „Italic”, „Underline”, „Strikethrough”, „Text color”, „Highlight color”, „Bullet list”, „Numbered list”, „Quote”, „Link” és „Clear formatting”.

Így készül egy hivatkozás: jelölje ki a szöveget, kattintson a „Link” gombra, és írja be a címet a kis kérdőmezőbe. Az üres bevitel újra eltávolítja a hivatkozást. A webes és a levélcímek megengedettek (http, https, mailto) — minden más mentéskor eldobásra kerül, hogy egy hozzászólás semmit ne csempészhessen be senkinek.

A képek a vágólapon át jönnek: készítsen képernyőképet, és illessze be közvetlenül a szerkesztőbe a Ctrl+V billentyűvel. A szövegben eleinte csak egy jelölő látszik, például „[inline-image:1]”. Mentéskor a rendszer feltölti a képet, és pontosan ott jeleníti meg — és a kép az „Attachments” fülre is felkerül, ahol az ügy összes fájlja lakik.

Amit Ön lát, azt látják a többiek is: a formázás, a felsorolások és a hivatkozások megmaradnak a hibajegyben, és a bejelentőnek küldött levélben is. Az idegen formázást — mondjuk egy másolt weboldalról vagy egy beérkező e-mailből — a rendszer visszavágja erre a megengedett készletre. A szövegéből eközben semmi nem vész el, csak a csomagolás.

Egy hozzászólás az „Only for Admin/Agents” lehetőséggel belsőnek jelölhető. Ekkor az „Internal” jelölést viseli, és a bejelentő számára láthatatlan — még a keresés sem hozza elő.

A fájlok az ügyhöz tartoznak, nem egyetlen hozzászóláshoz. A hibajegyen az „Attachments” fül vezet a listához: az „Upload file” hozzáad egyet, minden sor megnevezi a fájlt, a méretét és a dátumát. Bárki csatolhat valamit, aki részt vesz a hibajegyben — a bejelentő is; így senkinek nem kell e-mailben elküldenie Önnek a képernyőképét.

A névre kattintva megnyílik az előnézet, anélkül hogy le kellene töltenie a fájlt. Képeknél ott nagyíthat, kicsinyíthet és forgathat — ez akkor jön jól, ha egy kijelzőt ferdén fényképeztek le. A PDF ugyanabban az ablakban jelenik meg, oldalak áttekintésével, nagyítással és nyomtatással. A szövegfájlok szövegként látszanak. Az „Open in new tab” lehetőséggel külön ablakban nyitja meg a fájlt.

A melléklet az ügyhöz tartozik, és vele utazik: megjelenik az előzményekben („File uploaded: …”), túléli a másik csapatnak való átadást, és a hibajegy archiválásakor bekerül az archívumfájlba.

A hibajegy „History” füle minden utókérdés mögötti kérdésre válaszol: ki mit változtatott, és mikor? Minden sor megnevezi a személyt, a mezőt, az áthúzott régi értéket, mögötte az újat, és az időpontot másodpercre pontosan. A legújabb bejegyzés van felül.

A bejegyzések az Ön közreműködése nélkül keletkeznek — állapotváltásnál, prioritásnál, kiosztásnál, kategóriánál, telephelynél, megfigyelőknél, címnél és leírásnál, valamint a létrehozáskor („Ticket opened”), minden hozzászólásnál és minden feltöltött fájlnál. A fülön lévő szám előre megmondja, mennyi mozgás volt az ügyben.

Az előzményeket nem lehet szerkeszteni és nem lehet kikapcsolni. Pontosan ettől hasznosak: ezért nem lehet egy hibajegyet egyesével törölni, és ezért utaznak be az archívumfájlba a hibajegy archiválásakor.

Egy hozzászólás ott lerövidítve jelenik meg — a teljes szöveg a „Comments” fülön lakik. A belső hozzászólás is megjelenik az előzményekben, de csak az ügyintézők és a rendszergazdák számára.

Az állapot azt mondja meg, hol tart éppen egy hibajegy. Tizenkét állapot érkezik a rendszerrel — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed és még több. A „Settings → General Settings” alatt, a „Drop-down lists” részben, a „Status” fül mögött találja őket; a „+ Add status” sajátot hoz létre, az „Edit status” egy meglévőt nyit meg.

A lényeges rész a név és a jelentés közötti különbség. Egy állapot szerkesztőjében, a „Meaning of this status” alatt három kapcsoló van: „Counts as resolved”, „Counts as closed” és „Waiting for the requester”. Csak ezek a kapcsolók mondják meg a rendszernek, hogyan kezeljen egy állapotot.

Minden állapotot átnevezhet, azokat is, amelyek a rendszerrel érkeznek: a szerkesztő alján, a „Translations” alatt nyelvenként van egy „Name” mező — írja bele, amit az emberei olvassanak. A mögötte lévő technikai név érintetlen marad, és pontosan ezért nem törik el semmi: az automatizálás, a kimutatások és a fenti kapcsolók azon a néven függenek, nem az Ön feliratán. A „Resolved” állapotból tehát lehet „Kész”.

A törlés viszont nem mindegyiknél működik. Hat állapot viseli a listában a „Mandatory” jelölést — Open, Assigned, In Progress, Resolved, Closed és Reopened. Ezeket át lehet nevezni és át lehet rendezni, de eltávolítani nem; a próbálkozás egyértelmű üzenettel zárul. Ez nem bosszantásból van így: olyan folyamatok függenek rajtuk, amelyek különben szó nélkül leállnának — például az automatikus lezárás, amelynek kiindulópontként egy „megoldott” állapotra van szüksége.

Két állapot magához a rendszerhez tartozik: a „Waiting for approval” és a „Rejected” a „System only” jelölést viseli. Ezek egy jóváhagyási folyamatból származnak, és senki ne állíthassa kézzel, hogy elutasítottak valamit, ami soha nem került döntésre.

Mit csinál a három: az az állapot, amely megoldottnak számít, 24 óra után magától lezárja a hibajegyet. Az az állapot, amely lezártnak számít, az a végállapot, amelybe a hibajegy kerül. A „Waiting for the requester” pedig pontosan azt jelenti: a bejelentőre várunk — nem egy másik csapatra és nem egy szolgáltatóra. Ez az a jelölő, amelyen az SLA órája megáll, ha így állítja be.

Alatta áll az „Allowed transitions to new status”. Itt jelöli be, mely állapotok érhetők el ebből. Hagyjon mindent üresen, és semmi nincs korlátozva; jelöljön be valamit, és minden más út zárva van. Így épít olyan folyamatot, amelyet nem lehet átugrani — például: az „Open” állapotból csak az „In Progress” vagy a „Rejected” érhető el, a „Closed” közvetlenül nem.

A szerkesztő többi kapcsolója apróság nagy hatással: a lista színe, a „Sort order” a sorrendhez, a „Show status in new ticket form” (egyáltalán választható legyen-e ez az állapot hibajegy létrehozásakor?), a „Requires comment in dialog” (indoklás kikényszerítése) és a „System only” azoknak az állapotoknak, amelyeket csak maga a rendszer állíthat be.

Minden, ami egy hibajegyen legördülő listaként jelenik meg, az Öné. A „Settings → General Settings” alatt van a „Drop-down lists” kártya hat füllel: „Department”, „Position”, „Site”, „Role”, „Status” és „Priority”. Mindegyik mögött ugyanaz a kezelés áll, tehát csak egyszer kell megtanulnia.

Egyesével: írja be az angol nevet az üres mezőbe, és kattintson a mellette lévő gombra — az a lista nevét viseli, tehát „+ Add site”, „+ Add department” és így tovább. Az alatta lévő sorok a meglévő bejegyzések: ott változtat meg egy nevet, és a mellette lévő „Save” gombbal erősíti meg.

Ha egyszerre sok bejegyzésről van szó, ott van az „Export JSON” és az „Import JSON”. Frissen telepített rendszeren az „Export JSON” gombbal tölti le az üres szerkezetet, kitölti, és újra importálja. Átnevezésre nem való — a kártya ezt maga is kiírja.

Némelyik bejegyzés a „Mandatory” jelölést viseli. Ilyen a három szerepkör, az „Admin”, az „Agent” és a „Customer”, a rendszerrel érkező állapotok közül hat, valamint egy-egy helyőrző a Site, a Position és a Department listában („None selected or available”). Ezeket át lehet nevezni, de törölni nem: olyan jogosultságok és folyamatok függenek rajtuk, amelyek különben szó nélkül leállnának.

A többi nyelvre nem itt fordít, hanem egyben a fordítási oldalon. Itt elég az angol név — ez az a horgony, amelyre a fordítások később felakadnak.

Az állapot az egyetlen bejegyzés, amelynek saját szerkesztője van, mert több függ tőle, mint egy név; erről lejjebb külön kártya szól.

A kategóriák azok, amelyeket a bejelentő vagy az ügyintéző választ ki hibajegy létrehozásakor — és amelyek szerint később a kimutatásait csoportosítja. Minden csapatnak sajátjai vannak: egy helpdesk más szempontok szerint rendez, mint egy hálózati részleg, és egyik sem látja a másik csapat listáit.

A „Settings” alatt találja őket „<csapatnév> Categories” bejegyzésként. A példában a csapat neve „Helpdesk”, tehát a bejegyzés így szól: „Helpdesk Categories”.

Az oldalon három kártya van: „Main categories”, „Subcategories” és „Links”. A leggyorsabb kezdés: írja be az angol nevet az „EN (required)” mezőbe, és kattintson a „+ New main category” vagy a „+ New subcategory” gombra. Mindent később, egyben fordít le a fordítási oldalon — ehhez itt semmit nem kell előkészíteni.

Ha sok kategória áll Ön előtt, válassza a fájlon át vezető utat: az „Export JSON” letölti a szerkezetet — frissen telepített rendszeren a fájl üres, és csak a felépítést mutatja meg. Kitölti (kézzel vagy mesterséges intelligencia segítségével), elmenti, és az „Import JSON” gombbal újra feltölti. Átnevezésre nem való: a nevet az adott kategória mezőjében változtatja meg, és a mellette lévő „Save” gombbal erősíti meg — az oldal ezt maga is kiírja.

A harmadik kártyán, a „Links” kártyán történik a tényleges munka. Válasszon fent egy főkategóriát, jelölje be alatta a hozzá tartozó alkategóriákat, és mentsen a „Save links” gombbal. A trükk: egy alkategória több főkategórián is lóghat. Így a „Malfunction” alkategóriára csak egyszer van szüksége, és újra felhasználja a nyomtatóhoz, a hálózathoz, a tárgyalóhoz és a noteszgéphez.

Ettől kezdve a kategóriák elérhetők a hibajegyen. A törlés meghiúsulhat, amíg hibajegyek használnak egy kategóriát — ez szándékos, különben a régi hibajegyek elveszítenék a besorolásukat.

Ha átad egy hibajegyet egy másik csapatnak, a besorolása megmarad — akkor is, ha az új csapatnak ilyen kategóriái egyáltalán nincsenek. Ilyenkor a mezőben áll az eredetével együtt, például „Meeting-Room · from Helpdesk”, és halványan jelenik meg: az új csapat látja, mi alatt futott eddig az ügy, de ezt a bejegyzést maga nem tudja kiosztani. Az átsoroláshoz a saját listájából választ — és a rendszer ilyenkor fő- és alkategóriát együtt kér.

Minden hibajegy visel egy csatornát. Az űrlapon áll, később pedig az „Actions” kártyán a „How the request came in” alatt, és egy olyan kérdésre válaszol, amely a kimutatásokban gyorsan fontossá válik: a munka a portálon át érkezik, vagy telefonon?

Csak azt választhatja, amit egy ember tud, és a rendszer nem: „Phone” és „Entered by an agent”. A másik két értéket a rendszer maga állítja be — a „Self-service” értéket, ha a bejelentő a portálon hozta létre a hibajegyet, és az „Email” értéket, ha egy beérkező levélből nőtt ki.

Ezért nem lehet egy rendszer által beállított csatornát utólag „Phone” értékre váltani: a mező pontosan azt az állítást veszítené el, amiért létezik. Fordítva viszont: egy telefonon rögzített hibajegyen minden mást megváltoztathat.

A csatornát csak ügyintéző vagy rendszergazda állíthatja be. A bejelentő számára ez a saját ügyéről szóló állítás lenne — és a kimutatás azon múlna, hogy mindenki őszinte-e.

Az „Email” értékhez bekötött postafiók kell, ami a Professional kiadás része. A másik három csatorna mindkét kiadásban létezik.

Minden hibajegylista fölött ott van a „Search tickets…” mező. Nem csak a címekben keres, hanem a teljes ügyben: cím, leírás, a bejelentő neve, e-mail-címe és telefonszáma, telephely, hivatkozott hibajegyszám, minden hozzászólás és a saját egyéni mezőinek szöveges értékei.

A példa megmutatja: a „coffee” egyetlen címben sem szerepel, csak az egyik hibajegy leírásában — és mégis megtalálja. Tehát nem kell emlékeznie, hogyan címezték a hibajegyet; egy szó az ügyből elég.

A kis- és nagybetűk nem számítanak. A keresés mindig arra a listára vonatkozik, amelyikben éppen van, és a mellette lévő „Filter” lehetőséggel kombinálható; a „Reset” újra törli a keresést és a szűrőket. Az ügyfeleknél van egy korlát, amelyet nem lát, de érdemes tudnia: ők nem keresnek a belső hozzászólásokban — különben a találati listából következtethetnének arra, miről esett szó belül.

A hibajegy ehhez két gombot kínál egymás mellett, és a különbség apró betűvel alattuk áll. „Involve another team”: Ön marad a felelős, a másik csapat Ön mellett dolgozik egy kapcsolt hibajegyben. „Escalate to another team”: a másik csapat átveszi.

Átadáskor a felelősség úgy költözik, hogy nem keletkezik második hibajegy. Az Ön csapata megtartja az olvasási hozzáférést, és továbbra is hozzászólhat, de már semmit nem változtathat — pontosan ezt mondja meg a párbeszédablak, mielőtt megerősítené. Ott választja ki a célcsapatot, és indoklást is hozzáadhat.

Ha bevon egy csapatot, az Ön hibajegye az Ön kezében marad, és a másik csapatban alhibajegyet kap. Az Öné a „Waiting for other team” állapotba kerül; ha a másik csapat lezárja a sajátját, az Öné „Back from other team” állapotban tér vissza. Így nem kell rákérdeznie, történt-e ott valami.

Ami a besorolást illeti: az átadó csapat kategóriái a hibajegyen maradnak, akkor is, ha az új csapatnak ilyenek egyáltalán nincsenek — ott az eredetükkel együtt, halványan jelennek meg. Így az új csapat látja, mi alatt futott eddig az ügy, és szükség esetén átsorolhatja a saját listájába.

Hibajegyet csak az adhat tovább, aki éppen felelős érte. Egy korábbi állomás továbbra is látja az ügyet, de másodszor nem adhatja tovább.

Ha a hibajegyeiből hiányzik egy adat — az eszközazonosító, a garancia vége, a költséghely —, akkor felveszi maga. A „Settings → Ticket Settings” alatt, legalul van a „Custom fields” kártya; a gomb neve „Add custom field”.

A párbeszédablakban nevet és mezőtípust ad meg: „Text”, „Multiline text”, „Integer”, „Decimal”, „Date” vagy „Yes / No”. A típus dönti el, mit lehet bevinni — egy dátummező nem fogadja el a „jövő héten” értéket, és pontosan ezért lehet rá később kimutatást készíteni.

A „Scope” alatt dönti el, hol érvényes a mező: „All teams (including new ones)” vagy „Selected teams only”. Az első választás azokra a csapatokra is kiterjed, amelyek még nem léteznek — ez az a különbség, amelyet csak fél évvel később vesz észre.

A „Defaults” alatti három kapcsoló az új hibajegyekre vonatkozik: „Mandatory by default”, „Hidden for customer by default” és „Not editable by customer by default”. Ezek alapbeállítások — a mezőbeállítások ugyanezen az oldalon továbbra is az a hely, ahol szerepkörönként pontosan beállítja.

A hibajegyen az egyéni mezők saját kártyán ülnek, „Additional information” néven, a leírás és a hozzászólások között. Sablon nélkül az űrlap a csapat összes egyéni mezőjét mutatja. Ha hibajegy létrehozásakor sablont választ, pontosan azokat a mezőket mutatja, amelyeket az a sablon felsorol, annak sorrendjében — „csak azok a mezők, amelyekre ennek az ügynek szüksége van”.

Egy sablon ezen felül kötelezővé tehet egy mezőt, de szabályt nem oldhat fel: amit a rendszergazda elrejtett az ügyfelek elől vagy kötelezőnek nyilvánított, az az is marad, akkor is, ha egy sablon mást mond. Különben a sablon a házirend megkerülésének útja lenne.

Azt, hogy egy csapatnak hány egyéni mezője lehet, a „Settings → General Settings” alatt, a „Custom fields limit” kártyán állítja be. Egy mezőtől a „Deactivate” gombbal szabadul meg: eltűnik az űrlapról, de az értékei a régi hibajegyeken megmaradnak — a „Show deactivated” kapcsoló visszahozza a listába.

Néha valakinek követnie kell egy ügyet anélkül, hogy dolgozna rajta: a csapatvezetőnek egy kényes ügyben, vagy annak a kollégának, aki jövő héten átveszi. Erre valók a megfigyelők. A hibajegyen az „Observers” mező az „Actions” kártyán ül, a gomb neve „Add observer”; a „Create new ticket” űrlapon ugyanez a mező megvan.

Csak egy résztvevő csapat ügyintézői és rendszergazdái választhatók. Egy ügyfél nem lehet megfigyelő — különben belső munkáról kapna levelet.

A megfigyelő e-mailt kap, ha történik valami a hibajegyen: új hozzászólás, megváltozott állapot, új kiosztás, megváltozott mezők. Ez nem azonnal megy ki, hanem összefogva: az utolsó változás után a rendszer vár egy percet, és EGY levelet küld mindarról, ami ezalatt történt. Így egy hibajegy egyben való feldolgozása nem vált ki hét levelet.

Az, hogy ki figyel meg, része az előzményeknek: a változás ugyanúgy rögzítésre kerül, mint bármi más, a régi és az új állapottal.

Az értesítés e-mail — tehát be kell állítani a kimenő levelezést (Professional). Enélkül fel tud venni megfigyelőket, de semmi nem megy ki.

A levélcsatorna egy út két iránnyal, és a kettő összetartozik: egy beérkező levélből hibajegy lesz, az Ön válasza levélként megy ki, a bejelentő válasza pedig hozzászólásként ugyanarra a hibajegyre kerül — nem egy másodikra.

A hozzárendelés nem érzésre megy: egy válasz csak akkor kerül a meglévő hibajegyre, ha a levél a tárgyában viseli az ügy hivatkozási számát, vagy magával hozza a levelezőprogram válaszfejléceit. Az a levél, amelyben egyik sincs, új ügyet indít — jobb eggyel több hibajegy, mint két össze nem tartozó ügy összevonva csak azért, mert a tárgy véletlenül egyezett.

Minden ehhez tartozó beállítás a „Settings → E-Mail Settings” alatt van. A felső kártya, az „SMTP settings”, a kifelé vezető út: gazdagép, port, „Use SSL”, felhasználó és jelszó, valamint a feladó címe és neve. A „Send test e-mail” gombbal mintát küld magának — előbb mentsen, aztán teszteljen, ahogy a kártya maga is írja.

Az „IMAP settings” kártya a befelé vezető út: gazdagép, port, a lekérdezési időköz és a két mappa. A mappa nevét nem kell kitalálnia: a „Read from server” lehívja azokat a mappákat, amelyek valóban léteznek a postafiókjában, a „Create on server” pedig újat hoz létre. A mező ezután azt az útvonalat veszi át, amelyet a levelezőkiszolgálója használ hozzá — az egyik kiszolgáló „INBOX/Processed” alakot ír, a másik „INBOX.Processed” alakot, és mindkettő ugyanazt jelenti.

A feldolgozott levelek a „Processed folder” mappába költöznek; ha üresen hagyja, a beérkező mappában maradnak. Alatta állítja be, mikor fusson a takarítás („Hour”, „Minute”), és mennyire lehet régi egy üzenet („Retention (days)”) — különben a postafiók csendben nő tovább.

A postafiókok a csapathoz tartoznak, nem a rendszerhez: a „Team mailboxes” alatt minden csapat megadja a saját címét egy jelszóval. Ez a cím egyben az adott csapat leveleinek a feladója is — így a bejelentő ugyanoda válaszol, ahonnan a leveleket begyűjtik.

És most az a rész, amely nélkül mindebből semmi nem történik: a folyamat. Egy beállított postafiók önmagában semmit nem csinál. Ha egy csapatnak nincs bekapcsolt folyamata, a postafiókot a rendszer le sem kérdezi — nincs hibajegy, nincs visszaigazolás, a levelek egyszerűen ott állnak. Az ügyfeleinek szóló automatikus válasz csak itt létezik, és Ön állítja be. Ez szándékos: az a rendszer, amely kérés nélkül ír minden feladócímre, rosszabb lenne annál, amelyik hallgat.

Az „E-Mail workflows” alatt fent kiválasztja a csapatot, és a „+ Add workflow” gombbal folyamatot hoz létre. Kap egy nevet (csak Önnek), egy „Enabled” kapcsolót és két állítást arról, mikor érvényes: a „Match” dönti el, hogy minden feltételnek teljesülnie kell-e („All conditions”), vagy elég egy, a „Stop after match” pedig befejezi a futást, amint ez a folyamat illeszkedett — egy lejjebb álló folyamat ilyenkor soha nem kerül sorra. A sorrendet a mellette lévő nyilakkal változtatja meg.

A „When?” alatt áll maga a feltétel. Az „Every e-mail in this mailbox” minden levelet átvesz; az „Only when subject or text contains” egy szót követel meg a tárgyban vagy a törzsszövegben. Az „Advanced” pontosít: ott választja ki, mit néz a rendszer — „Subject or body”, „Subject”, „Body”, „Sender (From)” vagy „Recipient (To/Cc)” —, és hogyan hasonlítja össze: „Contains”, „Equals” vagy „Regex”. Így választja szét például egy közös címre érkező bejelentéseket minden mástól.

Alatta öt művelet áll kapcsolóként. Ezek a folyamat tényleges tartalma — ami nincs bekapcsolva, az nem történik meg:

A „Create or append ticket” hibajeggyé alakítja a levelet — vagy hozzászólásként fűzi egy meglévőhöz, ha a hivatkozási szám a tárgyban van. E művelet nélkül egy levélből soha nem lesz ügy.

A „Set fields” már a hibajegy létrehozásakor beállítja a prioritást, az állapotot, a fő- és alkategóriát, a tulajdonos csapatot és a felelőst. Minden, ami a „— Keep default —” értéken marad, úgy marad, ahogy folyamat nélkül lenne.

Az „Auto-reply” a feladónak szóló visszaigazolás — az egyetlen hely, ahol a rendszer magától válaszol. Ha ez a kapcsoló ki van kapcsolva, az ügyfele soha nem kap automatikus választ, bármilyen jól van beállítva minden más.

A „Send mail” további levelet küld: vagy a beérkező levél feladójának, vagy kiválasztott csapattagoknak és rögzített címekre. Saját „Send conditions” feltételei vannak — ha üresen hagyja őket, a levél ennek a folyamatnak minden futásakor kimegy.

A „Move to folder” a feldolgozott levelet egy mappába iktatja. Ha üresen hagyja a mezőt, a fenti IMAP-beállítások általános „Processed folder” értéke érvényes.

Az „Auto-reply” művelet részletesen: a tárgyat építőelemekből rakja össze. Az „Original subject {originalSubject}” átveszi a beérkező levél tárgyát, a „Ticket reference {ticketTag}” beszúrja az ügy hivatkozási számát — együtt valami ilyesmi lesz belőlük: „Printer problem [TICKET-99]”.

A hivatkozási szám nem kerül oda magától. Csak ott jelenik meg, ahová a {ticketTag} vagy a {ticketId} elemet teszi — és később pontosan erről ismeri fel a rendszer az ügyfele válaszát. Ha ez nincs a tárgyban, minden utólagos üzenet új hibajegyet indít, ahelyett hogy hozzászólás lenne a régin.

Az alatta lévő szöveg az Ön visszaigazoló üzenete. Írja angolul: ugyanazon az exportáláson és importáláson megy át, mint minden más szöveg, és csak így fordítható le a többi nyelvre. Ha üresen hagyja, a rendszer a saját alapértelmezett üzenetét küldi. Itt is ugyanazok a helyőrzők megengedettek.

A „Reply language” dönti el, milyen nyelven megy ki a tárgy és a szöveg: a „Standard English” angolul, a „Fixed language” egy Ön által választott nyelven, az „Assigned agent's language” a kiosztott ügyintéző nyelvén, a „Team default language” pedig a csapat alapértelmezett nyelvén. Magukat a fordításokat a nyelvi oldalon tartja karban.

Egy tanács, amelyet a rendszer a kártya fölött is kiír: minden, ami egy ügyhöz tartozik, EGY folyamatba tartozik. Csak az azonos folyamaton belüli műveletek ismerik az éppen létrehozott hibajegyet — ezért tudja a visszaigazolás megnevezni a számát, és ezért nem tudja egy második folyamat művelete.

A teljes levélcsatorna — befelé és kifelé — a Professional kiadás része. A Basicben a rendszer nem küld és nem fogad e-mailt; a hibajegyek ott a portálon, telefonon és az ügyintézőn keresztül keletkeznek.

Az időnyilvántartás gyári beállításként ki van kapcsolva. Amíg ki van kapcsolva, nincs mező, nincs oszlop, és nincs csempe a kimutatásban.

A halott mező rosszabb lenne, mint a semmi, ezért a funkció teljesen eltűnik, ahelyett hogy halványan ott ülne.

A kapcsoló a „Settings → General” alatt, a „Time tracking per ticket” kártyán ül, és a neve „Enable time tracking”.

Ezután minden csapat részt vesz benne. Ha egyet ki szeretne hagyni, magán a csapaton kapcsolja ki, a „Settings → Teams” alatt, a „Team details” dobozban.

Az a cég, amelynek van belső IT-csapata és egy ügyfelekkel dolgozó csapata, gyakran csak a másodikhoz igényli.

Ha az időnyilvántartást később újra kikapcsolja, a meglévő bejegyzések olvashatók és exportálhatók maradnak — ezek számlázási alapok, nem kényelmi funkció. Újat nem lehet rögzíteni.

A hibajegy visel egy „Time spent” nevű kártyát. A „Log time” nyitja meg a bevitelt.

A mező mellett gyorsgombok ülnek: egy kattintás a „30m” gombra harminc percet rögzít. Hogy mely gombok jelenjenek meg, azt a beállításokban állítja be.

A „Duration” mező szabad bevitelt is elfogad: a „90” kilencven perc, az „1.5h” másfél óra, és ugyanígy az „1h 30m” is. Az egység nélküli szám mindig percet jelent.

Azt a bevitelt, amelyet a rendszer nem ért meg teljesen, visszautasítja. Az „1h in the evening” nem lesz egyórás bejegyzés — hibaüzenet lesz belőle.

A „What for (optional)” mezőbe azt írja, mire ment az idő. A szöveg bekerül az exportba, és nem jelenik meg a hibajegy előzményeiben.

Több ügyintéző is rögzíthet időt ugyanazon a hibajegyen. Minden bejegyzés viseli a napját, a feljegyzését és annak a személynek a nevét, aki a munkát végezte.

Az időt egy napra rögzítjük, nem egy óraidőpontra. A tegnapi utólagos kitöltése a szokásos eset, és az óraidőpont olyan pontosságot állítana, amellyel a bevitel nem rendelkezik.

Hosszú munkamenetekhez van egy stopper a hibajegyen: a „Start timer” elindítja, a „Pause” megállítja.

A stopper soha nem hoz létre magától bejegyzést. Javasolja az eltelt időt, és semmi nem mentődik, amíg meg nem nyomja a „Log” gombot.

A fejszámolást váltja ki, nem a tudást. Nélküle is teljes a funkció, mert az érték begépelése a tulajdonképpeni út.

Egy másik hibajegy megnyitása megállítja a futó stoppert, az új hibajegy pedig megmondja, melyik hibajegyhez tartozik.

Az elrejtett ablak nem szünet. A stopper tovább fut, ha csak elkattint.

Az éjszakára futni hagyott stopper ellen van egy maximális futásidő. Az értéket a rendszer levágja, soha nem dobja el, és az ügyintézőt tájékoztatja.

A stopper gyári beállításként ki van kapcsolva. A beállításokban találja, a „Stopwatch on the ticket” alatt.

Minden bejegyzés visel egy „Billable” pipát. Az időt egyszer rögzíti, a pipa pedig eldönti, rákerül-e a számlára.

Ezért mutat a hibajegy két összeget: bal oldalt a rögzített egészet, jobb oldalt az elszámolható összeget.

A méltányosságnak nincs külön típusa. A méltányosság, a garanciális munka és a belső utómunka minden cégnél mást jelent, a rendszer pedig csak azt az egy különbséget ismeri, amelyen pénz múlik.

Így rögzít méltányosságot: vigye be az időt a szokott módon, vegye ki a pipát, és írja az indoklást a feljegyzésbe.

A bejegyzés ezután láthatóan viseli a „not billable” jelölést. A percek benne maradnak a rögzített összegben, mert a munka megtörtént.

Aki az időt egyáltalán nem rögzíti, épp azt a számot veszíti el, amely később megmagyarázza, miért került az ügyfélnek ilyen keveset.

Ha a munkája nagyobb része nem elszámolható, fordítsa meg az alapbeállítást a „New entries are billable by default” kapcsolóval.

Gyári beállításként minden percre pontosan kerül elszámolásra. Aki negyedórákban számláz, két értéket állít be.

A „Rounding increment (minutes)” a lépésköz. A rendszer minden bejegyzést a következő többszörösre kerekít felfelé.

A „Minimum per entry (minutes)” az alsó határ. Minden bejegyzés legalább ezzel az értékkel kerül elszámolásra.

A kettő egymás után dolgozik: előbb az alsó határ, aztán a lépésköz. 20-as alsó határnál és 15-ös lépésköznél az öt percből harminc lesz, mert az eredménynek mindkettőnek meg kell felelnie.

A két mező alatt egy mintamondat áll a saját értékeivel. Kiszámolva, nem állítva.

A kerekítés mindig csak az elszámolt értéket érinti, és mindig csak bejegyzésenként — soha nem az összeget. Két kis bejegyzés tehát kétszer kerekedik felfelé.

A rögzített idő érintetlen marad. A kerekítés utólagos megváltoztatása semmilyen régi adatot nem hamisít meg, mert az érték a megjelenítéskor számolódik ki.

Mindkettőt látja a bejegyzésen: ahol a kerekítés megváltoztatja az értéket, ott az eredmény zárójelben áll mellette.

Egy szolgáltató gyakran azt szeretné, hogy egyetlen hibajegy se záruljon le rögzített idő nélkül. Erre van egy kapcsoló.

A neve „Require a time entry before resolving or closing”, és gyári beállításként ki van kapcsolva.

Csak akkor érvényes, ha egy ember változtatja meg az állapotot. A bejegyzés nélküli ügyintéző üzenetet kap, és a hibajegy nyitva marad.

Az automatikus lezárást, az összevonást és a sorozatműveleteket a rendszer soha nem blokkolja. Különben lennének olyan hibajegyek, amelyeket senki nem tud többé lezárni.

Ez az egész funkció legveszélyesebb kapcsolója. Csak akkor kapcsolja be, ha a csapata valóban minden alkalommal rögzíti az időt.

A hibajegylista kap egy „Time” oszlopot, amely megmutatja, mennyit rögzítettek már egy ügyön.

Ezt nem kell bekapcsolnia. Megjelenik, amint a listában lévő valamelyik hibajegy időt visel.

Keskeny ablakoknál ez az egyik első, amely újra kiesik. A lista ilyenkor azokat az oszlopokat tartja meg, amelyek nélkül egy hibajegy nem található meg.

Az az idő, amely csak egyetlen hibajegyen áll, nem alap egy számlához. Ezért visel a kimutatások oldala egy „Time spent” kártyát.

Felül négy szám áll: rögzített, elszámolt, a bejegyzések száma és azoknak a hibajegyeknek a száma, amelyek egyáltalán viselnek időt.

Ez az utolsó szám az összeg után a legfontosabb. Negyven óra ötszázból három hibajegyen nem kiértékelés — az három ügyintéző, akik egyedüliként rögzítenek.

Alatta jönnek a bontások: bejelentő, csapat, kategória és nap szerint.

Ezen felül jön egy táblázat minden egyéni mezőhöz. Ez az út a cég vagy a költséghely szerinti számlázáshoz: létrehoz egy egyéni mezőt, kitölti a hibajegyen, és a kimutatás aszerint csoportosít.

Az oldal tetején lévő időszak arra a napra vonatkozik, amelyen a munka történt. Egy júniusi hibajegyen végzett júliusi munka tehát a júliusi kimutatásban áll.

A számok fölötti megjegyzést érdemes komolyan venni: emberek által készített bejegyzésekből és az Ön kerekítési szabályaiból származnak. Munkaalapok, nem auditált számla.

A kártya alatt három gomb ül. Ezek az egyes bejegyzéseket adják, nem az oldal összegeit.

Ez két címzett, nem három fájlformátum. Az „Export entries (CSV)” és az „Export entries (Excel)” a könyvelésnek megy: mindkettő teljes, és soha nem rövidül.

Az „Export entries (PDF)” az ember számára készült dokumentum. Az ügyfélhez megy, a számla mellékleteként.

A PDF 20 000 bejegyzésnél van korlátozva, és a dokumentum ezt maga is kiírja. Ennél több sorból álló számlát úgysem olvas el senki.

Mind a három fájl ugyanabból a forrásból épül: a szűrők, a kerekítés, az oszlopok és a számok egyszer léteznek, így a három nem tud szétcsúszni.

Az a bejegyzés, amely nem elszámolható, üres cellát kap az elszámolható oszlopban, nem nullát. A nullát egy kimutatástábla összeadná.

Az ügyfél soha nem látja az időbejegyzéseket, még a saját hibajegyén sem.

Ez nem beállítás, hanem zár a kiszolgálóban. Nincs olyan kapcsoló, amely kinyitná.

Az ok magukban a bejegyzésekben van: a feljegyzések a csapatnak íródnak. Azt mondják el, mi romlott el, és mennyi ideig tartott az ok keresése.

Az ilyen rendszerek másutt is így csinálják. Ahol az idő eljut az ügyfélhez, ott dokumentumként jut el hozzá.

Erre való a PDF-export: a számlával megy ki, és nem az ügyfélportálon lévő hibajegyre.

A kimutatás ezen felül megmutathatja, ki mennyit rögzített. Gyári beállításként nem mutatja.

A személyenkénti idő teljesítményadat, és sok cégnél az üzemi tanácsnak beleszólása van.

A kapcsoló neve „Per-agent evaluation”, és a beállításokban ül.

Amíg ki van kapcsolva, a kiszolgáló a számokat sem adja ki. A táblázat nincs elrejtve — nem létezik.

Ez a különbség számít. Az a zár, amelyről csak a megjelenítés tud, nem zár.