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 verplicht zijn, stel je in onder “Settings → Ticket Settings”. De kaart “Admin / Agent Field Settings” heeft daarvoor alleen de schakelaar “Field is mandatory”. De kaart “Customer Field Settings” heeft daarnaast “Is hidden for Customer” en “Is not editable”. Daarom kan een klant een korter formulier zien dan jij, zonder dat iemand twee formulieren hoeft te onderhouden. “Title” en “Description” zijn altijd verplicht. Dat is niet uit te zetten.

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, toewijzing, prioriteit, kanaal en volgers staan een kaart hoger onder “Actions”. Status en toewijzing werken meteen. Prioriteit, kanaal en volgers worden pas opgeslagen met de “Save” in de kaart “Details”.

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. Het aanmaken verwijdert niets. De tickets verlaten de draaiende database pas met de aparte stap “Delete from live DB” in de lijst “Existing archives” — 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. Afbeeldingen plakken werkt in de omschrijving van een bestaand ticket en in een nieuwe opmerking. Het werkt niet in het formulier “Create new ticket” en ook niet terwijl je een opmerking bewerkt.

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 “Internal note (not visible to the customer)” als intern markeren. Ze draagt dan het label “Internal” en is voor de aanvrager onzichtbaar — zelfs de zoekfunctie brengt haar niet boven.

Iedereen kan zijn eigen opmerkingen wijzigen en verwijderen. Wat een klant heeft geschreven, kan alleen die klant of een beheerder wijzigen of verwijderen. Dat geldt ook voor zijn mails. Opmerkingen van collega's kan elke agent wijzigen en verwijderen die aan het ticket mag werken. Dat geldt ook voor een team dat het ticket eerder had.

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 klant kan alleen bijlagen verwijderen die hij zelf heeft geüpload. Wordt een subticket gesloten, dan worden de bijlagen ervan naar het hoofdticket gekopieerd, waar ze het label “Internal” dragen. Agenten zien ze; klanten zien ze niet en kunnen ze niet downloaden.

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.

Bij een opmerking legt de historie alleen vast dat die is toegevoegd, bewerkt of verwijderd. De tekst zelf 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. Acht statussen dragen in de lijst het label “Mandatory” — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval en Rejected. 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 “Assigned”, 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.

Maximaal vier statussen staan op het ticket als knoppen onder “Change Status to:”. Je kiest ze in de editor met de schakelaar “Set as primary status (max. 4)”. In de fabrieksinstelling zijn dat In Progress, Waiting for User Response, Waiting for Service Provider Response en Resolved. Alle andere statussen staan onder “More statuses”.

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”, “Location”, “Role”, “Status” en “Priority”. De bediening verschilt van lijst tot lijst.

Éé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 location”, “+ Add department” enzovoort. De regels eronder zijn de bestaande waarden. Bij “Department”, “Position” en “Location” wijzig je daar een naam en bevestig je met de “Save” ernaast.

Voor veel waarden tegelijk bieden “Department”, “Position” en “Location” ook “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”, acht van de meegeleverde statussen, en in de lijsten Location, Position en Department telkens één tijdelijke waarde (“None selected or available”). Geen ervan is te verwijderen: er hangen rechten en processen aan die anders zonder een woord zouden stoppen. De statussen zijn in hun editor wel te hernoemen. De rollen en de tijdelijke waarden zijn niet te hernoemen. Wat mag, hangt van de lijst af. “Role” is vergrendeld: een rol kan niet worden toegevoegd en ook niet worden hernoemd. In “Priority” voeg je waarden toe en verwijder je ze, maar er is geen bestand en geen hernoemen. “Status” heeft een eigen editor en ook geen bestand.

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. Verwijder je een koppeling, dan zijn tickets die dat paar gebruiken nog steeds op te slaan. Alleen een nieuw gekozen categorie wordt aan de koppelingen getoetst.

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 “E-mail” wanneer het uit een binnengekomen mail is ontstaan. Maakt een agent een ticket aan, dan begint het formulier met “Entered by an agent”.

Een kanaal dat het systeem heeft gezet, kan later door niemand worden gewijzigd. Het veld zegt dan “Recorded by the system. It cannot be changed.” Anders zou het veld 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.

“E-mail” 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. De lijst onthoudt je filters, apart voor elke teamlijst. Ze staan er weer als je terugkomt uit een ticket, de pagina opnieuw laadt of je op een andere computer aanmeldt. De zoektekst onthoudt hij niet. 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. Ook eigen velden die voor klanten verborgen zijn, doorzoeken ze niet.

Iedereen stelt zijn eigen ticketlijst samen. Daarvoor staat de knop “Columns” naast “Filter”. Die opent het dialoogvenster “Choose columns”.

In het dialoogvenster vink je elke kolom aan die je wilt zien. De pijlen ernaast bepalen de volgorde. “#” en “Title” zijn altijd inbegrepen. De breedte van een kolom verander je in de lijst zelf, door de rand van de kolomkop te verslepen.

“Save” slaat je keuze op bij je gebruikersaccount. Daardoor geldt ze op elke computer en blijft ze staan nadat je je afmeldt. “Default columns” zet de lijst terug naar de fabrieksinstelling.

Als er niet genoeg ruimte is voor alle kolommen, vallen de kolommen helemaal rechts als eerste weg. “#”, “Title” en “Status” blijven altijd staan. Wat voor jou het belangrijkst is, zet je dus vooraan.

Met Professional worden ook je eigen velden aangeboden. Ze verschijnen in het dialoogvenster onder hun eigen naam, hier bijvoorbeeld “Asset tag”.

Klanten kunnen hun lijst op dezelfde manier inrichten, maar krijgen minder kolommen aangeboden. “Team”, “Created by”, “Last activity”, “Status changed at”, “Deadline”, “Follow-up” en “Time” zijn voor hen niet beschikbaar. Velden die je voor klanten hebt verborgen, verschijnen ook niet als kolom.

Op een telefoon wordt de knop niet getoond. Daar toont de lijst de kolommen die passen.

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. De bijlagen van het subticket worden met het label “Internal” naar jouw ticket gekopieerd, en de klant ziet ze niet.

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. Ze kan opmerkingen plaatsen, maar het ticket niet naar zichzelf terughalen.

In de lijst van je team toont het ticket dan “Waiting for other team”, zolang het andere team eraan werkt. Het vinkje “Also show tickets this team handed over” staat als fabrieksinstelling aan, en de eigen keuze van elke gebruiker blijft bewaard. Voor het andere team begint het ticket als “Open”.

Wie overdraagt, wordt volger van het ticket. Het dialoogvenster zegt dat voordat je bevestigt. Als volger krijg je een e-mail wanneer de status verandert, het ticket wordt gesloten of iemand een opmerking plaatst. Zoals elke volger verwijder je jezelf met “Stop observing”.

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” zijn “Mandatory by default”, “Hidden for customer by default” en “Not editable by customer by default”. Ze gelden voor een veld alleen zolang er in de veldinstellingen op dezelfde pagina nog niets voor dat veld is opgeslagen. Zodra je het daar instelt, beslissen de veldinstellingen.

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. Wat de beheerder voor klanten heeft verborgen, blijft verborgen, ook als een sjabloon het opneemt. Een verplicht veld dat een sjabloon niet opneemt, wordt niet gevraagd; die verplichting geldt dus niet voor tickets die met dit sjabloon worden aangemaakt.

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. Op het ticket wordt een wijziging daar opgeslagen met de “Save” in de kaart “Details”.

Alleen agenten en beheerders van het team waartoe het ticket behoort, 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. Komen er in die tijd meerdere opmerkingen binnen, dan staan ze allemaal in de mail.

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

Volgers invullen hoort bij Basic. De mail aan volgers hoort bij Professional, omdat die uitgaande post nodig heeft. Zonder dat kun je wel volgers invullen, maar er gaat niets uit. Een volger kan zichzelf verwijderen met de knop “Stop observing”. Daarvoor is geen recht nodig om het ticket te wijzigen.

Een volger wordt ook vanzelf toegevoegd: wie een ticket met “Escalate to another team” doorgeeft, wordt volger. Zo hoort die wat het andere team ermee doet.

Werken twee mensen tegelijk aan hetzelfde ticket, dan kan het latere opslaan het eerdere overschrijven, en niemand zou het merken. Daarom laat het ticket zien wie het nog meer open heeft. Daarnaast weigert het ticket het opslaan op een verouderde stand.

De melding staat in de kop van het ticket. “Marco Rossi is viewing this ticket” betekent dat Marco het ticket open heeft. “Marco Rossi is actively editing this ticket” betekent dat Marco er niet-opgeslagen invoer in heeft. Dat kan een begonnen antwoord zijn, een opmerking die gewijzigd wordt, de titel of de beschrijving in bewerkmodus, een opvolging, een aangepast veld of een tijdregistratie. Gewijzigde velden in de kaarten “Actions” en “Details” tellen ook mee, zolang ze niet met “Save” zijn opgeslagen. Ook een open venster op het ticket telt mee. Dat zijn de vensters “Involve another team?”, “Escalate to another team?”, “Close ticket”, “Resolve incident” en “Start a workflow”, plus het venster voor de opmerking bij een statuswijziging. Na twee minuten zonder invoer toont de melding weer “viewing”, ook als het concept er nog staat.

Hebben meerdere collega's het ticket open, dan vat de melding ze samen, bijvoorbeeld “Marco Rossi and 2 more are viewing this ticket”. Wijs de melding aan om alle namen te zien. Zodra iemand actief bewerkt, telt de regel alleen nog de mensen die bewerken. Jezelf zie je nooit. Heb je het ticket in twee tabbladen open, dan tel je één keer. Is het ticket alleen in een verborgen tabblad open, dan verdwijn je na ongeveer een minuut uit de melding van de anderen.

Slaat een collega een wijziging op, dan staat er “Marco Rossi changed this ticket”, met de knop “Refresh” ernaast. Een nieuwe opmerking van iemand anders toont “Marco Rossi added a comment”. Komt de wijziging niet van een persoon, bijvoorbeeld van een automatiseringsregel of een binnengekomen e-mail, dan staat er “This ticket was changed”. De melding blijft staan tot je opnieuw laadt.

“Refresh” laadt de actuele stand van het ticket, zoals status, toewijzing, velden en geschiedenis. De hele pagina wordt daarbij niet opnieuw geladen. Je niet-opgeslagen invoer blijft staan. Een begonnen antwoord blijft in het antwoordveld staan, en een geopende titel of beschrijving houdt je tekst. Is de opgeslagen tekst intussen veranderd, dan verschijnt onder het veld “The saved text has changed in the meantime.”. Sla je dan op, dan vervangt jouw tekst de opgeslagen tekst. De knop “Refresh” in de kop van het ticket doet hetzelfde.

Sla je toch op een verouderde stand op, dan wordt het opslaan geweigerd. Het venster “Ticket changed in the meantime” gaat open. Heeft een persoon de wijziging gedaan, dan noemt het venster die persoon. Je wijziging is niet opgeslagen. Klik op “Refresh”, controleer je wijziging tegen de actuele stand en sla opnieuw op. Dat geldt voor elke wijziging aan het ticket zelf, bijvoorbeeld status, toewijzing, prioriteit, de kaart “Details” en aangepaste velden.

Opmerkingen worden nooit geweigerd. Twee antwoorden overschrijven elkaar niet. Allebei komen ze op het ticket terecht. Hetzelfde geldt voor bijlagen en tijdregistraties. Ook massa-acties op de ticketlijst en automatiseringsregels worden niet tegen de stand gecontroleerd. Ze wijzigen het ticket direct. Wie het open heeft, ziet daarna de melding.

Klanten zien hier niets van. Ze verschijnen niet in de melding. Ze zien ook niet wie aan hun ticket werkt.

Wie een ticket open heeft, staat alleen in het werkgeheugen van de server. Ongeveer een minuut nadat de persoon het ticket heeft verlaten, is de vermelding weg. Niets daarvan wordt in een logboek geschreven. Het ticket slaat op wie het als laatste heeft gewijzigd. Die vermelding hoort bij de gegevensexport voor die persoon. Wordt de persoon geanonimiseerd, dan wordt ze verwijderd.

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.

De “Processed folder” neemt de mails op die het systeem apart legt: mails van geblokkeerde afzenders, automatisch gegenereerde mails en mails die een workflow met “Move to folder” verplaatst zonder eigen map. Laat je hem 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. Staat deze schakelaar uit, dan krijgt je klant geen bevestiging, hoe goed al het andere ook is ingesteld. Ook “Send mail” kan de afzender schrijven, zoals de volgende actie laat zien.

“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-a1b2c3]”.

De referentie komt er niet vanzelf bij. Ze verschijnt alleen waar jij {ticketTag} neerzet. {ticketId} voegt alleen het kale nummer in, en daaraan herkent het systeem geen antwoord. Staat de referentie niet in het onderwerp, dan komt een antwoord toch op het juiste ticket terecht als het de antwoordkoppen van de bevestiging meebrengt. Alleen een mail zonder beide wordt een nieuw ticket.

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 en geen kolom. De kaart “Time spent” in het rapport verschijnt dan alleen als er in de gekozen periode tijd is geboekt.

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. Bestaande boekingen kunnen dan ook niet meer worden gewijzigd of verwijderd.

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. De invoer heeft daarvoor een datumveld dat met vandaag begint; om gisteren in te vullen kies je daar de dag ervoor. Een dag in de toekomst wordt niet aangenomen. 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 de knop “Log …” drukt die de tijd noemt. Geboekt wordt de tijd die werkelijk is gelopen.

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. Wacht er op een ander ticket nog tijd die niet is geboekt en start je hier de stopwatch, dan vraagt de toepassing het eerst. De vraag “Start timer” biedt “Log …” voor de tijd op het andere ticket, “Discard” en “Cancel”. Ze verschijnt vanaf één minuut verstreken tijd.

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 schakelaar “Billable”. De tijd wordt één keer geboekt, en de schakelaar bepaalt of ze op de factuur komt.

Daarom kan het ticket twee totalen tonen: links alles wat is geboekt, rechts de factureerbare som. Het tweede totaal verschijnt alleen als het van het eerste afwijkt.

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, zet “Billable” uit 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, en alleen voor mensen die tijd mogen boeken. Hij geldt ook wanneer een antwoordsjabloon de status op een los ticket zet. 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 de tijdregistratie aanstaat. Alleen agenten en beheerders zien haar. Met “Columns” kun je haar uit je lijst halen.

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”. Alleen mensen met het recht “Time tracking: see the report” zien de kaart.

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 onder de exportknoppen verdient het serieus genomen te worden: de cijfers 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. Ze bevatten precies de boekingen die bij je filters passen.

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 heeft geen kolom voor de notitie.

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.

Staat “Per-agent evaluation” van de tijdregistratie uit, dan ontbreekt de kolom “Agent” in alle drie de bestanden. Valt je licentie terug naar Basic, dan blijven de bestaande boekingen leesbaar en te exporteren.

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.