Handleiding

Een nieuw ticket maak je aan met “New Ticket” in de linkerbalk. Het formulier heet “Create new ticket”. Als agent leg je daarmee ook de aanvragen van anderen vast — daar is het veld “User” voor: dat zegt voor wie de zaak is, niet wie haar intypt.

Alles met een sterretje is verplicht: “Title”, “User”, “Main category” en “Description”. En nog één die je makkelijk mist: zonder subcategorie slaat het formulier niet op, ook al draagt “Subcategory” geen sterretje — een hoofd- en een subcategorie horen bij elkaar en worden altijd als paar ingesteld.

Welke velden er überhaupt verschijnen en welke daarvan verplicht zijn, stel je in onder “Settings → Ticket Settings” — apart voor agenten en voor klanten. Daarom ziet een klant een korter formulier dan jij, zonder dat iemand twee formulieren hoeft te onderhouden.

Daarna kun je bijna alles wijzigen: rechts op het ticket staat de kaart “Details” met aanvrager, telefoon, e-mail, locatie, categorie en referentienummer; je wijzigt het veld zelf en bevestigt met de “Save” eronder. Status, prioriteit, toewijzing, kanaal en volgers staan een kaart hoger onder “Actions” en werken meteen, zonder apart op te slaan.

Alleen agenten en beheerders mogen dit wijzigen. De aanvrager kan de zaak lezen, erop reageren en bestanden meesturen — maar niet de indeling wijzigen waarop je rapportage is gebouwd.

Één bijeffect dat je één keer moet weten: bewerk je een ticket dat nog van niemand is, dan is het daarna van jou. Het systeem zet je als agent erin en zet de status van “Open” op “Assigned” — allebei komen ze in de historie. Wilde je dat niet, wijs het ticket dan daarna aan iemand anders toe.

Elk van deze wijzigingen komt in de historie van het ticket terecht, met naam, tijd, oude waarde en nieuwe waarde. Daar hoef je niets voor aan te zetten.

Blijft de vraag hoe je tickets weer kwijtraakt. Onder “Settings → Archive” kies je een periode, zie je met “Preview” hoeveel gesloten tickets die bevat, en maak je met “Create archive” een ZIP-bestand: tickets, opmerkingen, historie, eigen velden en bijlagen, allemaal in één bestand. Pas dan verdwijnen die tickets uit de draaiende database — en uit datzelfde bestand zijn ze weer terug te halen.

De omschrijving en de opmerkingen zijn geen kale tekstvakken. Boven elk ervan staat een werkbalk, en de knoppen zeggen wat ze doen als je erop wijst: “Bold”, “Italic”, “Underline”, “Strikethrough”, “Text color”, “Highlight color”, “Bullet list”, “Numbered list”, “Quote”, “Link” en “Clear formatting”.

Zo maak je een link: selecteer de tekst, klik op “Link”, typ het adres in het kleine venstertje. Een lege invoer haalt de link er weer af. Web- en mailadressen zijn toegestaan (http, https, mailto) — al het andere wordt bij het opslaan weggegooid, zodat een opmerking niemand iets kan binnensmokkelen.

Afbeeldingen komen via het klembord binnen: maak een schermafbeelding en plak haar met Ctrl+V rechtstreeks in de editor. In de tekst staat eerst alleen een markering als “[inline-image:1]”. Bij het opslaan uploadt het systeem de afbeelding en toont haar precies daar — en ze komt ook in het tabblad “Attachments” terecht, waar alle bestanden van de zaak staan.

Wat jij ziet, zien de anderen ook: opmaak, lijsten en links blijven behouden in het ticket, en ook in de mail aan de aanvrager. Vreemde opmaakcode — bijvoorbeeld uit een gekopieerde webpagina of een binnengekomen e-mail — wordt teruggebracht tot deze toegestane verzameling. Er gaat daarbij niets van je tekst verloren, alleen de verpakking.

Een opmerking kun je met “Only for Admin/Agents” als intern markeren. Ze draagt dan het label “Internal” en is voor de aanvrager onzichtbaar — zelfs de zoekfunctie brengt haar niet boven.

Bestanden horen bij de zaak, niet bij één opmerking. Op het ticket leidt het tabblad “Attachments” naar de lijst: “Upload file” voegt er een toe, elke regel noemt het bestand, de grootte en de datum. Iedereen die bij het ticket betrokken is, mag iets meesturen — de aanvrager inbegrepen; zo hoeft niemand je een schermafbeelding te mailen.

Een klik op de naam opent de voorbeeldweergave, zonder dat je het bestand hoeft te downloaden. Bij afbeeldingen kun je daarin in- en uitzoomen en draaien — handig bij een display dat schuin is gefotografeerd. Een PDF wordt in hetzelfde venster getoond, met paginaoverzicht, zoom en afdrukken. Tekstbestanden worden als tekst getoond. Met “Open in new tab” open je het bestand in een eigen venster.

Een bijlage hoort bij de zaak en reist mee: ze verschijnt in de historie (“File uploaded: …”), overleeft een overdracht aan een ander team, en belandt in het archiefbestand wanneer het ticket wordt gearchiveerd.

Het tabblad “History” op het ticket beantwoordt de vraag achter elke opvolging: wie heeft wat gewijzigd, en wanneer? Elke regel noemt de persoon, het veld, de doorgestreepte oude waarde, de nieuwe erachter en het tijdstip tot op de seconde. De nieuwste regel staat bovenaan.

Regels worden zonder jouw toedoen geschreven — bij statuswijzigingen, prioriteit, toewijzing, categorie, locatie, volgers, titel en omschrijving, en ook bij het aanmaken (“Ticket opened”), bij elke opmerking en bij elk geüpload bestand. Het getal op het tabblad zegt je vooraf hoeveel beweging er in de zaak zat.

De historie is niet te bewerken en niet uit te zetten. Precies dat maakt haar bruikbaar: ze is de reden dat een ticket niet stuk voor stuk te verwijderen is, en ze reist mee het archiefbestand in wanneer het ticket wordt gearchiveerd.

Een opmerking staat er ingekort in — de volledige tekst staat in het tabblad “Comments”. Een interne opmerking komt ook in de historie, maar alleen voor agenten en beheerders.

De status zegt waar een ticket op dit moment staat. Er worden twaalf statussen meegeleverd — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed en meer. Je vindt ze onder “Settings → General Settings” in het gedeelte “Drop-down lists” achter het tabblad “Status”; “+ Add status” maakt er een van jezelf aan, “Edit status” opent een bestaande.

Het belangrijke is het verschil tussen de naam en de betekenis. In de editor van een status staan onder “Meaning of this status” drie schakelaars: “Counts as resolved”, “Counts as closed” en “Waiting for the requester”. Alleen deze schakelaars vertellen het systeem hoe het een status moet behandelen.

Je mag elke status hernoemen, ook de meegeleverde: onderaan de editor staat onder “Translations” per taal een veld “Name” — zet daarin wat je mensen moeten lezen. De technische naam erachter blijft ongemoeid, en juist daarom breekt er niets: automatisering, rapportage en de schakelaars hierboven hangen aan die naam, niet aan jouw label. Zo kan “Resolved” “Done” worden.

Verwijderen lukt echter niet bij allemaal. Zes statussen dragen in de lijst het label “Mandatory” — Open, Assigned, In Progress, Resolved, Closed en Reopened. Ze zijn te hernoemen en te herschikken, maar niet weg te halen; wie het probeert, krijgt een duidelijke melding. Dat is er niet om je te ergeren: er hangen processen aan die anders zonder een woord zouden stoppen — bijvoorbeeld het automatisch sluiten, dat een status “opgelost” als vertrekpunt nodig heeft.

Twee statussen horen bij het systeem zelf: “Waiting for approval” en “Rejected” dragen het label “System only”. Ze komen uit een goedkeuringsproces, en niemand hoort met de hand te kunnen beweren dat iets is afgewezen wat nooit ter beslissing lag.

Wat de drie doen: een status die als opgelost telt, sluit het ticket na 24 uur vanzelf. Een status die als gesloten telt, is de eindtoestand waarin het ticket wordt gezet. En “Waiting for the requester” betekent precies dat: we wachten op de aanvrager — niet op een ander team en niet op een dienstverlener. Dat is de markering waarop de SLA-klok stilstaat, als je het zo instelt.

Daaronder staat “Allowed transitions to new status”. Hier vink je aan welke statussen vanuit deze bereikbaar zijn. Laat je alles leeg, dan is er niets beperkt; vink je iets aan, dan is elk ander pad dicht. Zo bouw je een verloop dat niet over te slaan is — bijvoorbeeld: vanuit “Open” kun je alleen naar “In Progress” of “Rejected”, maar niet meteen naar “Closed”.

De overige schakelaars in de editor zijn kleinigheden met een grote werking: de kleur voor de lijst, “Sort order” voor de volgorde, “Show status in new ticket form” (mag deze status bij het aanmaken van een ticket überhaupt te kiezen zijn?), “Requires comment in dialog” (een reden afdwingen) en “System only” voor statussen die alleen het systeem zelf mag zetten.

Alles wat in een ticket als keuzelijst verschijnt, is van jou. Onder “Settings → General Settings” staat de kaart “Drop-down lists” met zes tabbladen: “Department”, “Position”, “Site”, “Role”, “Status” en “Priority”. Achter elk daarvan zit dezelfde bediening, dus je hoeft het maar één keer te leren.

Één voor één: typ de Engelse naam in het lege veld en klik op de knop ernaast — die is naar de lijst genoemd, dus “+ Add site”, “+ Add department” enzovoort. De regels eronder zijn de bestaande waarden: daar wijzig je een naam en bevestig je met de “Save” ernaast.

Voor veel waarden tegelijk zijn er “Export JSON” en “Import JSON”. Op een net geïnstalleerd systeem download je met “Export JSON” de lege structuur, vul je haar in en importeer je haar weer. Het is geen manier om te hernoemen — de kaart zegt dat zelf.

Sommige waarden dragen het label “Mandatory”. Daartoe horen de drie rollen “Admin”, “Agent” en “Customer”, zes van de meegeleverde statussen, en in de lijsten Site, Position en Department telkens één tijdelijke waarde (“None selected or available”). Ze zijn te hernoemen maar niet te verwijderen: er hangen rechten en processen aan die anders zonder een woord zouden stoppen.

In de andere talen vertaal je hier niet, maar in één keer op de vertaalpagina. De Engelse naam is hier genoeg — die is het anker waaraan de vertalingen later worden gehangen.

De status is de enige waarde met een eigen editor, omdat er meer aan hangt dan een naam; die heeft verderop een eigen kaart.

Categorieën zijn wat de aanvrager of de agent kiest bij het aanmaken van een ticket — en waarop je later je rapporten groepeert. Elk team heeft die van zichzelf: een helpdesk sorteert op andere dingen dan een netwerkafdeling, en geen van beide ziet de lijsten van het andere team.

Je vindt ze onder “Settings” als de regel “<teamnaam> Categories”. In het voorbeeld heet het team “Helpdesk”, dus staat er “Helpdesk Categories”.

De pagina heeft drie kaarten: “Main categories”, “Subcategories” en “Links”. Het snelste begin: typ de Engelse naam in het veld “EN (required)” en klik op “+ New main category” of “+ New subcategory”. Alles vertaal je later in één keer op de vertaalpagina — daar hoef je hier niets voor voor te bereiden.

Heb je veel categorieën voor de boeg, neem dan de weg via het bestand: “Export JSON” downloadt de structuur — op een net geïnstalleerd systeem is het bestand leeg en toont het je alleen de indeling. Je vult het in (met de hand of met hulp van een AI), slaat het op en uploadt het weer via “Import JSON”. Het is geen manier om te hernoemen: een naam wijzig je in het veld van die categorie en bevestig je met de “Save” ernaast — de pagina zegt dat ook.

De derde kaart, “Links”, is waar het eigenlijke werk gebeurt. Kies bovenaan een hoofdcategorie, vink eronder de subcategorieën aan die erbij horen, en sla op met “Save links”. De truc: één subcategorie mag aan meerdere hoofdcategorieën hangen. Zo heb je “Malfunction” maar één keer nodig en hergebruik je haar voor Printer, Network, Meeting-Room en Notebook.

Vanaf dat moment zijn de categorieën in het ticket beschikbaar. Verwijderen kan mislukken zolang er nog tickets een categorie gebruiken — dat is met opzet, anders zouden oude tickets hun indeling kwijtraken.

Draag je een ticket over aan een ander team, dan blijft de indeling staan — ook wanneer het nieuwe team die categorieën helemaal niet heeft. Ze staat dan samen met haar herkomst in het veld, bijvoorbeeld “Meeting-Room · from Helpdesk”, en is grijs: het nieuwe team kan zien waaronder de zaak tot nu toe liep, maar kan die waarde zelf niet toekennen. Om opnieuw in te delen kies je uit je eigen lijst — en dan wil het systeem een hoofd- en een subcategorie samen.

Elk ticket draagt een kanaal. Het staat in het formulier en later op de kaart “Actions” onder “How the request came in”, en het beantwoordt een vraag die in de rapportage snel belangrijk wordt: komt het werk via het portaal binnen of via de telefoon?

Je kunt alleen kiezen wat een mens weet en het systeem niet: “Phone” en “Entered by an agent”. De andere twee waarden zet het systeem zelf — “Self-service” wanneer de aanvrager het ticket in het portaal heeft aangemaakt, en “Email” wanneer het uit een binnengekomen mail is ontstaan.

Daarom kun je een door het systeem gezet kanaal ook niet achteraf op “Phone” zetten: het veld zou juist de uitspraak kwijtraken waarvoor het bestaat. Andersom mag je op een telefonisch vastgelegd ticket al het andere nog gewoon wijzigen.

Alleen een agent of een beheerder mag het kanaal zetten. Voor de aanvrager zou het een uitspraak over de eigen zaak zijn — en de rapportage zou ervan afhangen dat iedereen eerlijk is.

“Email” vraagt om een gekoppeld postvak, en dat hoort bij de editie Professional. De andere drie kanalen bestaan in beide edities.

Boven elke ticketlijst staat het veld “Search tickets…”. Het doorzoekt niet alleen titels maar de hele zaak: titel, omschrijving, de naam van de aanvrager, het e-mailadres en telefoonnummer, de locatie, het referentienummer, alle opmerkingen en de tekstwaarden van je eigen velden.

Het voorbeeld laat het zien: “coffee” staat in geen enkele titel, alleen in de omschrijving van één ticket — en het wordt toch gevonden. Je hoeft dus niet te onthouden hoe een ticket heette; één woord uit de zaak is genoeg.

Hoofdletters en kleine letters maken niet uit. Het zoeken geldt altijd voor de lijst waarin je op dat moment staat en is te combineren met “Filter” ernaast; “Reset” wist zoekopdracht en filters weer. Voor klanten geldt een grens die je niet ziet maar wel moet kennen: zij doorzoeken geen interne opmerkingen — anders zouden ze uit de resultatenlijst kunnen afleiden wat er intern is besproken.

Het ticket biedt daarvoor twee knoppen naast elkaar, en het verschil staat er in kleine letters onder. “Involve another team”: jij blijft verantwoordelijk, het andere team werkt naast je in een gekoppeld ticket. “Escalate to another team”: het andere team neemt het over.

Bij een overdracht verschuift de verantwoordelijkheid zonder dat er een tweede ticket ontstaat. Je team houdt leestoegang en mag nog opmerkingen plaatsen, maar kan niets meer wijzigen — en precies dat zegt het dialoogvenster je voordat je bevestigt. Daar kies je het doelteam en kun je een reden toevoegen.

Betrek je een team, dan blijft je ticket in jouw handen en krijgt het een subticket in het andere team. Dat van jou gaat naar de status “Waiting for other team”; zodra het andere team het zijne sluit, komt het jouwe terug als “Back from other team”. Je hoeft dus niet te vragen of er daar iets is gebeurd.

Wat de indeling betreft: de categorieën van het overdragende team blijven op het ticket staan, ook wanneer het nieuwe team ze helemaal niet heeft — ze staan daar met hun herkomst, grijs. Zo kan het nieuwe team zien waaronder de zaak tot nu toe liep, en haar zo nodig in de eigen lijst herindelen.

Alleen wie op dit moment verantwoordelijk is, mag een ticket doorgeven. Een eerdere halte ziet de zaak nog wel, maar kan haar geen tweede keer doorgeven.

Ontbreekt er in je tickets een gegeven — het inventarisnummer, het einde van de garantie, de kostenplaats — dan voeg je het zelf toe. Onder “Settings → Ticket Settings” staat onderaan de kaart “Custom fields”; de knop heet “Add custom field”.

In het dialoogvenster geef je een naam en een veldtype: “Text”, “Multiline text”, “Integer”, “Decimal”, “Date” of “Yes / No”. Het type bepaalt wat er ingevuld kan worden — een datumveld neemt geen “volgende week” aan, en juist daarom kun je er later op rapporteren.

Onder “Scope” bepaal je waar het veld geldt: “All teams (including new ones)” of “Selected teams only”. De eerste keuze dekt ook teams die nog niet bestaan — het soort verschil dat je pas een half jaar later merkt.

De drie schakelaars onder “Defaults” gelden voor nieuwe tickets: “Mandatory by default”, “Hidden for customer by default” en “Not editable by customer by default”. Het zijn standaardwaarden — de veldinstellingen op dezelfde pagina blijven de plek waar je het per rol precies instelt.

Op het ticket staan de eigen velden in een eigen kaart, “Additional information”, tussen de omschrijving en de opmerkingen. Zonder sjabloon toont het formulier alle eigen velden van het team. Kies je bij het aanmaken een sjabloon, dan toont het precies de velden die dat sjabloon noemt, in zijn volgorde — “alleen de velden die deze zaak nodig heeft”.

Een sjabloon kan een veld daarbovenop verplicht maken, maar het kan geen regel opheffen: wat de beheerder voor klanten heeft verborgen of verplicht heeft verklaard, blijft dat, ook als een sjabloon iets anders zegt. Anders zou een sjabloon een manier zijn om onder een huisregel uit te komen.

Hoeveel eigen velden een team mag hebben, stel je in onder “Settings → General Settings” in de kaart “Custom fields limit”. Een veld raak je kwijt met “Deactivate”: het verdwijnt uit het formulier, maar de waarden ervan blijven op de oude tickets staan — de schakelaar “Show deactivated” haalt het weer in de lijst.

Soms moet iemand een zaak volgen zonder eraan te werken: de teamleider bij een gevoelige kwestie, de collega die volgende week overneemt. Daar zijn volgers voor. Op het ticket staat het veld “Observers” op de kaart “Actions”, de knop heet “Add observer”; het formulier “Create new ticket” heeft hetzelfde veld.

Alleen agenten en beheerders van een betrokken team zijn te kiezen. Een klant kan geen volger zijn — die zou anders mail over intern werk ontvangen.

Een volger krijgt een e-mail wanneer er iets op het ticket gebeurt: een nieuwe opmerking, een gewijzigde status, een nieuwe toewijzing, gewijzigde velden. Die wordt niet meteen verstuurd maar gebundeld: na de laatste wijziging wacht het systeem een minuut en stuurt dan ÉÉN mail over alles wat er in die tijd is gebeurd. Een ticket in één keer afwerken levert dus geen zeven mails op.

Wie er volgt, hoort bij de historie: een wijziging wordt net als elke andere vastgelegd, met de oude en de nieuwe toestand.

De melding is een e-mail — er moet dus uitgaande post zijn ingericht (Professional). Zonder dat kun je wel volgers invullen, maar er gaat niets uit.

Het mailkanaal is één weg met twee richtingen, en die horen bij elkaar: een binnenkomende mail wordt een ticket, jouw antwoord gaat als mail uit, en het antwoord van de aanvrager komt als opmerking op hetzelfde ticket terecht — niet op een tweede.

Het koppelen gaat niet op gevoel: een antwoord komt alleen op het bestaande ticket terecht wanneer de mail de referentie van de zaak in het onderwerp draagt of de antwoordkoppen van het mailprogramma meebrengt. Een mail met geen van beide begint een nieuwe zaak — liever één ticket te veel dan twee zaken die niets met elkaar te maken hebben samengevoegd omdat het onderwerp toevallig overeenkwam.

Alles daarvoor staat onder “Settings → E-Mail Settings”. De bovenste kaart, “SMTP settings”, is de weg naar buiten: host, poort, “Use SSL”, gebruiker en wachtwoord, plus het afzenderadres en de afzendernaam. Met “Send test e-mail” stuur je jezelf een proef — eerst opslaan, dan testen, zoals de kaart zelf zegt.

De kaart “IMAP settings” is de weg naar binnen: host, poort, het ophaalinterval en de twee mappen. Je hoeft de mapnaam niet te raden: “Read from server” haalt de mappen op die echt in je postvak bestaan, “Create on server” maakt er een nieuwe aan. Het veld neemt dan het pad over dat je mailserver ervoor gebruikt — de ene server schrijft “INBOX/Processed”, de volgende “INBOX.Processed”, en allebei bedoelen ze hetzelfde.

Verwerkte mails verhuizen naar de “Processed folder”; laat je die leeg, dan blijven ze in het postvak staan. Daaronder stel je in wanneer het opruimen loopt (“Hour”, “Minute”) en hoe oud een bericht mag worden (“Retention (days)”) — anders groeit het postvak stilletjes door.

Postvakken horen bij het team, niet bij het systeem: onder “Team mailboxes” vult elk team zijn eigen adres met een wachtwoord in. Dat adres is tegelijk de afzender van de mails van dat team — zo antwoordt de aanvrager op dezelfde plek waar de post wordt opgehaald.

En nu het deel zonder welk dit alles niet gebeurt: de workflow. Een ingesteld postvak op zich doet helemaal niets. Heeft een team geen ingeschakelde workflow, dan wordt het postvak niet eens opgehaald — geen ticket, geen bevestiging, de mails blijven gewoon staan. Het automatische antwoord aan je klanten bestaat alleen hier, en dat stel je zelf in. Dat is met opzet: een systeem dat ongevraagd naar elk afzenderadres schrijft, zou erger zijn dan een systeem dat stil blijft.

Onder “E-Mail workflows” kies je bovenaan het team en maak je met “+ Add workflow” een workflow aan. Die krijgt een naam (alleen voor jou), een schakelaar “Enabled” en twee uitspraken over wanneer hij geldt: “Match” bepaalt of alle voorwaarden waar moeten zijn (“All conditions”) of dat er één genoeg is, en “Stop after match” beëindigt de doorloop zodra deze workflow heeft gepast — een workflow verderop komt dan nooit aan de beurt. De volgorde wijzig je met de pijltjes ernaast.

Onder “When?” staat de voorwaarde zelf. “Every e-mail in this mailbox” neemt elke mail; “Only when subject or text contains” vraagt om een woord in het onderwerp of in de tekst. “Advanced” maakt het precies: daar kies je waarnaar wordt gekeken — “Subject or body”, “Subject”, “Body”, “Sender (From)” of “Recipient (To/Cc)” — en hoe er wordt vergeleken: “Contains”, “Equals” of “Regex”. Zo scheid je bijvoorbeeld meldingen aan een gedeeld adres van al het andere.

Daaronder staan vijf acties als schakelaars. Zij zijn de eigenlijke inhoud van de workflow — wat niet aanstaat, gebeurt niet:

“Create or append ticket” maakt van de mail een ticket — of hangt haar als opmerking aan een bestaand ticket wanneer de referentie in het onderwerp staat. Zonder deze actie wordt een mail nooit een zaak.

“Set fields” zet prioriteit, status, hoofd- en subcategorie, verantwoordelijk team en behandelaar meteen bij het aanmaken van het ticket. Alles wat op “— Keep default —” blijft staan, blijft zoals het zonder workflow zou zijn.

“Auto-reply” is de bevestiging aan de afzender — de enige plek waar het systeem uit zichzelf antwoordt. Staat deze schakelaar uit, dan krijgt je klant nooit een automatisch antwoord, hoe goed al het andere ook is ingesteld.

“Send mail” stuurt een extra mail: ofwel naar de afzender van de binnenkomende mail, ofwel naar geselecteerde teamleden en vaste adressen. Die heeft eigen “Send conditions” — laat je die leeg, dan gaat hij bij elke doorloop van deze workflow uit.

“Move to folder” bergt de verwerkte mail in een map op. Laat je het veld leeg, dan geldt de algemene “Processed folder” uit de IMAP-instellingen hierboven.

De actie “Auto-reply” in detail: het onderwerp stel je samen uit bouwstenen. “Original subject {originalSubject}” neemt het onderwerp van de binnenkomende mail over, “Ticket reference {ticketTag}” voegt de referentie van de zaak in — samen leveren ze zoiets als “Printer problem [TICKET-99]”.

De referentie komt er niet vanzelf bij. Ze verschijnt alleen waar jij {ticketTag} of {ticketId} neerzet — en juist daaraan herkent het systeem later het antwoord van je klant. Staat ze niet in het onderwerp, dan begint elk vervolgbericht een nieuw ticket in plaats van een opmerking op het oude te worden.

De tekst eronder is je bevestigingsbericht. Schrijf het in het Engels: het loopt door dezelfde export en import als elke andere tekst, en alleen zo is het in de andere talen te vertalen. Laat je het leeg, dan stuurt het systeem zijn eigen standaardbericht. Dezelfde variabelen zijn hier ook toegestaan.

“Reply language” bepaalt in welke taal het onderwerp en de tekst uitgaan: “Standard English” gebruikt Engels, “Fixed language” een taal die jij kiest, “Assigned agent's language” de taal van de toegewezen agent, en “Team default language” de standaardtaal van het team. De vertalingen zelf onderhoud je op de taalpagina.

Één advies dat het systeem ook boven de kaart afdrukt: alles wat bij één zaak hoort, hoort in ÉÉN workflow. Alleen acties binnen dezelfde workflow kennen het ticket dat zojuist is aangemaakt — daarom kan de bevestiging het nummer ervan noemen en een actie uit een tweede workflow niet.

Het hele mailkanaal — in en uit — hoort bij de editie Professional. In Basic verstuurt en ontvangt het systeem geen e-mail; tickets ontstaan daar via het portaal, de telefoon en de agent.

Tijdregistratie staat als fabrieksinstelling uit. Zolang ze uit staat, is er geen veld, geen kolom en geen tegel in het rapport.

Een dood veld zou erger zijn dan helemaal geen veld, dus verdwijnt de functie volledig in plaats van er grijs bij te staan.

De schakelaar staat onder “Settings → General” op de kaart “Time tracking per ticket” en heet “Enable time tracking”.

Daarna doet elk team mee. Om er een buiten te laten, zet je het op het team zelf uit, onder “Settings → Teams” in het vak “Team details”.

Een bedrijf met een intern IT-team en een klantgericht team heeft het vaak alleen voor het tweede nodig.

Zet je de tijdregistratie later weer uit, dan blijven de bestaande boekingen leesbaar en te exporteren — ze zijn een basis voor facturatie, geen gemak. Nieuwe boekingen zijn niet meer mogelijk.

Het ticket draagt een kaart “Time spent”. “Log time” opent de invoer.

Naast het veld staan sneltoetsen: één klik op “30m” boekt dertig minuten. Welke knoppen verschijnen, stel je in de instellingen in.

Het veld “Duration” neemt ook vrije invoer aan: “90” is negentig minuten, “1.5h” is anderhalf uur, en “1h 30m” ook. Een getal zonder eenheid is altijd minuten.

Invoer die het systeem niet volledig begrijpt, wordt geweigerd. “1h in the evening” wordt geen boeking van een uur — het wordt een foutmelding.

In “What for (optional)” schrijf je waar de tijd voor was. Die tekst gaat mee de export in en verschijnt niet in de tickethistorie.

Meerdere agenten boeken tijd op hetzelfde ticket. Elke boeking draagt haar dag, haar notitie en de naam van de persoon die het werk heeft gedaan.

Tijd wordt op een dag geboekt, niet op een tijdstip. Gisteren invullen is het normale geval, en een tijdstip zou een nauwkeurigheid claimen die de invoer niet heeft.

Voor lange sessies staat er een stopwatch op het ticket: “Start timer” start hem, “Pause” houdt hem stil.

De stopwatch maakt nooit uit zichzelf een boeking. Hij stelt de verstreken tijd voor, en er wordt niets opgeslagen tot je op “Log” drukt.

Hij vervangt hoofdrekenen, geen kennis. Zonder hem is de functie compleet, want het getal typen is de eigenlijke weg.

Open je een ander ticket, dan pauzeert de lopende stopwatch, en het nieuwe ticket zegt je bij welk ticket hij hoort.

Een verborgen venster is geen pauze. De stopwatch loopt door als je alleen maar wegklikt.

Tegen een stopwatch die de hele nacht doorloopt, staat er een maximale looptijd. De waarde wordt afgetopt, nooit weggegooid, en de agent krijgt het te horen.

De stopwatch staat als fabrieksinstelling uit. Je vindt hem in de instellingen onder “Stopwatch on the ticket”.

Elke boeking draagt een vinkje “Billable”. De tijd wordt één keer geboekt, en het vinkje bepaalt of ze op de factuur komt.

Daarom toont het ticket twee totalen: links alles wat is geboekt, rechts de factureerbare som.

Er is geen apart type voor coulance. Coulance, garantiewerk en intern herstelwerk heten in elk bedrijf anders, en het systeem kent alleen het ene onderscheid waar geld aan hangt.

Zo boek je coulance: voer de tijd gewoon in, haal het vinkje weg en schrijf de reden in de notitie.

De boeking draagt dan zichtbaar “not billable”. De minuten blijven in het geboekte totaal staan, want het werk is wel degelijk gedaan.

Wie de tijd helemaal niet boekt, raakt juist het getal kwijt dat later verklaart waarom een klant zo weinig in rekening is gebracht.

Is het grootste deel van je werk niet factureerbaar, draai de standaard dan om met de schakelaar “New entries are billable by default”.

Als fabrieksinstelling wordt alles op de minuut gefactureerd. Wie in kwartieren factureert, stelt twee waarden in.

“Rounding increment (minutes)” is de stap. Elke boeking wordt naar het volgende veelvoud naar boven afgerond.

“Minimum per entry (minutes)” is de bodem. Elke boeking wordt met minstens deze waarde gefactureerd.

De twee werken na elkaar: eerst de bodem, dan de stap. Bij een bodem van 20 en een stap van 15 wordt vijf minuten dertig, omdat de uitkomst aan allebei moet voldoen.

Onder de twee velden staat een voorbeeldzin met je eigen waarden. Die is berekend, niet beweerd.

Alleen de gefactureerde waarde wordt ooit afgerond, en alleen per boeking — nooit het totaal. Twee kleine boekingen worden dus twee keer naar boven afgerond.

De geboekte tijd blijft onaangeroerd. De afronding later wijzigen vervalst geen oude gegevens, omdat de waarde bij het tonen wordt uitgerekend.

Je ziet allebei op de boeking: waar de afronding de waarde verandert, staat de uitkomst er tussen haakjes naast.

Een dienstverlener wil vaak geen enkel ticket gesloten zien zonder geboekte tijd. Daar is een schakelaar voor.

Hij heet “Require a time entry before resolving or closing” en staat als fabrieksinstelling uit.

Hij geldt alleen wanneer een mens de status wijzigt. Een agent zonder boeking krijgt een melding en het ticket blijft openstaan.

Automatisch sluiten, samenvoegen en massa-acties worden nooit geblokkeerd. Anders zouden er tickets zijn die niemand nog kan sluiten.

Dit is de gevaarlijkste schakelaar van de hele functie. Zet hem pas aan wanneer je team werkelijk elke keer tijd boekt.

De ticketlijst krijgt een kolom “Time” die toont hoeveel er al op een zaak is geboekt.

Je zet haar niet aan. Ze verschijnt zodra een ticket in de lijst tijd draagt.

Bij smalle vensters valt ze als een van de eerste weer weg. De lijst houdt dan de kolommen over waarzonder een ticket niet te vinden is.

Tijd die alleen op een los ticket staat, is geen basis voor een factuur. Daarom draagt de rapportpagina een kaart “Time spent”.

Bovenaan staan vier getallen: geboekt, gefactureerd, het aantal boekingen en het aantal tickets dat überhaupt tijd draagt.

Dat laatste getal is na het totaal het belangrijkste. Veertig uur op drie van de vijfhonderd tickets is geen analyse — het zijn drie agenten die als enigen boeken.

Daaronder komen de uitsplitsingen: per aanvrager, per team, per categorie en per dag.

Daar komt per eigen veld één tabel bij. Dat is de weg naar factureren per bedrijf of kostenplaats: je maakt een eigen veld aan, vult het op het ticket in, en het rapport groepeert erop.

De periode bovenaan de pagina geldt voor de dag waarop het werk is gedaan. Werk in juli aan een ticket uit juni staat dus in het rapport van juli.

Een opmerking boven de cijfers verdient het serieus genomen te worden: ze komen uit boekingen die mensen hebben gedaan en uit je afrondingsregels. Ze zijn een werkbasis, geen gecontroleerde factuur.

Onder de kaart staan drie knoppen. Ze leveren de afzonderlijke boekingen, niet de totalen van de pagina.

Dat zijn twee ontvangers, geen drie bestandsvormen. “Export entries (CSV)” en “Export entries (Excel)” gaan naar de boekhouding: allebei zijn ze volledig en worden ze nooit ingekort.

“Export entries (PDF)” is het document voor een mens. Dat gaat als bijlage bij de factuur naar de klant.

De PDF is afgetopt op 20.000 boekingen, en het document zegt dat zelf. Een factuur met meer regels leest toch niemand.

Alle drie de bestanden komen uit dezelfde bron: filters, afronding, kolommen en cijfers bestaan één keer, dus kunnen de drie niet uit elkaar lopen.

Een boeking die niet factureerbaar is, heeft een lege cel in de factureerbare kolom, geen nul. Een nul zou in een draaitabel worden opgeteld.

Een klant ziet de tijdboekingen nooit, ook niet op zijn eigen ticket.

Dit is geen instelling maar een grendel in de server. Er is geen schakelaar die hem opent.

De reden zit in de boekingen zelf: notities zijn voor het team geschreven. Ze zeggen wat er misging en hoe lang het zoeken naar de oorzaak duurde.

Andere systemen van dit soort doen hetzelfde. Waar tijd de klant bereikt, bereikt ze hem als document.

Daar is de PDF-export voor: die gaat met de factuur mee en niet naar het ticket in het klantportaal.

Het rapport kan daarnaast tonen wie hoeveel heeft geboekt. Als fabrieksinstelling doet het dat niet.

Tijd per persoon is een prestatiegegeven, en in veel bedrijven heeft de ondernemingsraad daar zeggenschap over.

De schakelaar heet “Per-agent evaluation” en staat in de instellingen.

Zolang hij uit staat, levert de server de cijfers niet eens. De tabel is niet verborgen — ze bestaat niet.

Dat verschil telt. Een grendel waar alleen de weergave van weet, is geen grendel.