Antwoord- en ticketsjablonen

Sjablonen staan onder “Settings → Templates”. De regel onder de kop zegt wat ze doen en wat niet: “Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.” Een sjabloon is een voorbereide zet, geen machine — versturen doe je altijd zelf.

Er zijn twee soorten en je kiest er een bij het aanmaken: “Add reply template” voor het antwoord op een openstaand ticket, “Add ticket template” voor het formulier voor een nieuw ticket. De soort is later niet te wijzigen, omdat ze bepaalt welke velden het formulier überhaupt toont. Het label boven elk sjabloon zegt naar welke je kijkt: blauw “Reply template”, groen “Ticket template”.

Een antwoordsjabloon bestaat uit de antwoordtekst (“Reply text”), het vinkje “Internal note” en een willekeurig aantal acties. Er zijn zes acties: “Set the status”, “Set the priority”, “Assign to a user”, “Remove the assignee”, “Hand over to another team” en “Set a follow-up”.

De lijst “Assign to a user” begint met de regel “The agent who applies it”. Neem die wanneer meerdere mensen het sjabloon delen: het ticket hoort dan bij wie het heeft toegepast, niet bij één vaste persoon uit de lijst. “Set a follow-up” vraagt om een hoeveelheid en een eenheid (minuten, uren, dagen, werkminuten, werkuren, werkdagen) plus de notitie die je later vertelt waarom het ticket terug is.

Het blauwe vak aan het eind van elk sjabloon schrijft in één zin op wat het gaat doen — bijvoorbeeld “Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.” De zin bouwt zichzelf opnieuw op terwijl je bewerkt. Het is je tegenproef: staat er iets anders dan je bedoelde, dan is er één instelling fout.

Tekst is niet verplicht. “Draag dit over aan het netwerkteam zonder een woord te schrijven” is een geldig sjabloon — de zin luidt dan “Suggests actions without a reply text”. De actie “Set the status” volgt dezelfde regels als een statuswijziging met de hand. Toegepast op meerdere tickets tegelijk slaat het sjabloon vergrendelde tickets over en noemt het de reden.

Ook het venster “Close ticket” biedt antwoordsjablonen aan, in het veld “Template”. Het toont alleen sjablonen waarvan de actieve actie “Set the status” een status zet die als opgelost of gesloten telt. Interne sjablonen worden daar niet aangeboden. Kies je er een, dan neemt het venster de tekst ervan over als opmerking. Verstuurt het sjabloon een mail en biedt het venster verzenden per mail aan, dan neemt het de ontvanger alleen over als die “Requester” of een vast adres is. De andere acties en de bijlagen van het sjabloon worden daar niet uitgevoerd. Het ticket wordt zoals gewoonlijk gesloten.

Op een openstaand ticket staat de knop “Template” boven de opmerkingeneditor. Een klik opent het zoekveld met suggesties (“Search templates…”), en een keuze vult de opmerkingeneditor. Verder gebeurt er niets, en de regel eronder zegt dat: “Nothing happens until you add the comment.”

Elke actie van het sjabloon wordt een chip naast de knop — in gewone woorden, niet in jargon: “sets status to Waiting for Service Provider Response”, “assigns to the applying agent”, “sets a follow-up in 3 days”. Een klik op een chip streept hem door: hij is uitgevinkt en loopt niet. Nog een klik brengt hem terug.

Uitgevinkte acties worden doorgestreept, niet verwijderd. Zo blijft zichtbaar wat het sjabloon had voorgesteld — en blijft de beslissing omkeerbaar zolang je niet hebt verstuurd.

Welke chips actief beginnen, bepaalt het sjabloon: in de instellingen draagt elke actie een schakelaar “Suggested”. Die schakelaar is het voorstel voor elk geval; de chip op het ticket is de beslissing voor dit ene.

De “×” achter de chips haalt het sjabloon er weer af. De tekst blijft in de editor staan — je hebt hem misschien al herschreven; alleen de werking verdwijnt, dus acties, mail en bijlagen.

Versturen doe je met de gewone opmerkingenknop. Pas dan wordt de opmerking aangemaakt, en pas daarna lopen de acties die nog actief zijn.

In de antwoordtekst mag je vijf variabelen gebruiken; de lijst staat onder het veld: “{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}”. Schrijf ze met accolades, precies zoals ze daar staan.

“{ticketRef}” is de ticketreferentie in de vorm “[TICKET-8-…]”. Daaraan herkent het systeem het antwoord van een klant wanneer dat per e-mail terugkomt. “{ticketId}” is daarentegen alleen het kale nummer.

Ze worden ingevuld op het moment dat het sjabloon wordt TOEGEPAST, niet bij het opslaan: op de instellingenpagina blijft “{requesterName}” staan, in de opmerkingeneditor op het ticket staat de echte naam. De reden is praktisch — invullen bij het opslaan zou de waarden van ÉÉN ticket voorgoed in het sjabloon branden.

Zo lees je de afgeronde tekst voordat er iets het bedrijf verlaat. Past de aanhef niet, dan wijzig je hem in de editor zoals elke andere tekst.

Wie er als “aanvrager” geldt, bepaalt het ticket en niet het account: de aanvrager die op het ticket staat, gaat voor het account dat het heeft ingediend. Dient een agent na een telefoongesprek een ticket in voor een collega, dan groet het antwoord toch die collega en niet de agent.

Een verkeerd getypte variabele wordt bij het opslaan geweigerd, en ze wordt genoemd: “Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.” Zo merk je het terwijl je het sjabloon schrijft, en niet bij een klant.

Het e-mailonderwerp heeft zijn EIGEN, kortere lijst (“{originalSubject}, {ticketTag}, {ticketId}”) — daarom staat die daar een tweede keer afgedrukt. “{ticketRef}” werkt daar ook en betekent hetzelfde als “{ticketTag}”. “{requesterName}”, “{ticketTitle}” en “{agentName}” werken niet in het onderwerp en worden net zo geweigerd.

De schakelaar “Send the comment as e-mail” maakt van de opmerking ook de mail. Er is bewust geen tweede tekstveld voor: wat in het ticket staat, is wat de klant leest — twee teksten zouden vroeg of laat uit elkaar lopen.

Onder “Recipient” kies je tussen “Requester”, “Assignee”, “Observers” en “Fixed address”. Wie de aanvrager is, zoekt de server uit wanneer het sjabloon wordt toegepast — een sjabloon kent het ticket nog niet. Naar het postvakaccount zelf wordt nooit geschreven; dat zou een bericht aan onszelf zijn. Staat in het veld “User” een naam zonder adres, dan gaat er geen mail naar de aanvrager. Hij gaat in plaats daarvan ook niet naar wie het ticket heeft vastgelegd.

Het onderwerp mag “{originalSubject}”, “{ticketTag}” en “{ticketId}” bevatten. Houd “{ticketTag}” erin: aan die referentie herkent het systeem het antwoord van de klant en hangt het aan hetzelfde ticket. Zonder haar wordt elk antwoord een nieuw ticket.

De mail gaat als platte tekst uit. Vet, lijsten en links worden er vóór het versturen af gehaald, anders zou de klant de ruwe opmaakcode lezen. In het ticket houdt de opmerking haar opmaak.

Op het ticket is de mail nog een chip naast de acties (“E-mail to Requester”) en net zo uit te vinken als die. Zo verstuurt een sjabloon nooit iets zonder dat jij het hebt gezien. De chip verschijnt alleen wanneer het postvak van het team mails bij ticketacties verstuurt.

De bijlagen van een sjabloon (“Attachments”) zijn eigen kopieën van de bestanden. Het toepassen van het sjabloon voegt ze aan het TICKET toe, met een eigen regel in de historie — ze horen niet bij de mail. Bijlagen op een sjabloon vragen geen Professional-licentie; alleen het versturen wel. Een sjabloon met het vinkje “Internal note” voegt geen bestanden toe.

De meeste sjablonen ontstaan niet aan een tekentafel maar op het moment dat je hetzelfde antwoord voor de tweede keer schrijft. Daarom draagt elke opmerking op een ticket rechts een klein bladpictogram met het opschrift “Make template”. Dat neemt precies die opmerking als begintekst — ook de opmerking van een collega. Alleen wie sjablonen mag beheren, ziet het pictogram.

Heeft het ticket bijlagen, dan vraagt een dialoogvenster eerst welke mee moeten: “Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default.” Er staat niets vooraf aangevinkt, en dat is met opzet.

Daarna kom je op de sjablonenpagina terecht met een concept dat nog NIET is opgeslagen. Bovenaan staat de oranje banner “Draft from ticket #… — name it and review the text (it may contain customer details), then save.” De naam is leeg: die moet je geven, anders wordt er niet opgeslagen.

Wat er wordt overgenomen: de tekst, het vinkje “Internal note”, het team van het ticket, en de toestand van het ticket als voorstel — de status en de prioriteit staan er al als twee acties. Wat er niet wordt overgenomen: aanvrager, adres en titel. Die horen bij dit ene geval.

Lees de tekst voordat je opslaat. Hij komt uit een echte zaak en kan een naam, een ordernummer of een ruimte bevatten. Er wordt niets voor je geanonimiseerd — de banner zegt dat, maar het doen is jouw werk.

Pas “Save” maakt het sjabloon aan; de aangevinkte bijlagen worden dan mee gekopieerd en met een melding bevestigd.

“Applies to” bepaalt wie het sjabloon aangeboden krijgt: één bepaald team of “All teams”. Een nieuw sjabloon begint bij een concreet team — “All teams” is een keuze die iemand moet maken, geen stille standaard.

Op een ticket krijg je de sjablonen van het verantwoordelijke team plus de algemene aangeboden. Verhuist het ticket na een overdracht naar een ander team, dan verhuist de lijst mee — je kiest dan uit de sjablonen van het nieuwe team.

De schakelaar “Draft” maakt van het sjabloon je werkplaats: “Only you can see this template until you publish it.” Het concept van iemand anders staat in geen enkele lijst en is ook via zijn adres niet te bereiken — ook niet voor beheerders. Een nieuw sjabloon begint als concept; pas als je dat uitzet en opslaat, zien de anderen het.

Twee sjablonen mogen niet dezelfde naam dragen als ze elkaar kunnen tegenkomen: een algemeen sjabloon botst met elk sjabloon van dezelfde naam, in welk team dan ook. Een antwoordsjabloon en een ticketsjabloon mogen wél dezelfde naam dragen — die staan nooit samen in dezelfde lijst.

“Duplicate” maakt een kopie, en die kopie is altijd een concept: “Duplicated. The copy is a draft only you can see.” Dat is de comfortabele weg naar een variant zonder dat iemand anders de halfafgemaakte versie aangeboden krijgt.

Een ticketsjabloon vult het formulier “Create new ticket”. Het heeft geen antwoordtekst, geen acties en geen mail — op dat moment is er nog geen ticket om iets op te doen. Het formulier toont daarom andere velden dan bij een antwoordsjabloon, en het groene kader zegt je dat je naar een ticketsjabloon kijkt.

Je kunt “Ticket title”, “Owning team of the new ticket”, “Main category”, “Subcategory”, “Priority” en de “Ticket description” vooraf invullen. Elk veld mag op “Not prefilled” blijven staan — wat leeg blijft, vult degene in die het formulier later gebruikt.

Let op het verschil tussen de twee teamvelden: “Applies to” bovenaan zegt WIE het sjabloon ziet. “Owning team of the new ticket” zegt WAAR het nieuwe ticket naartoe gaat. Dat zijn twee verschillende vragen, en ze mogen verschillende antwoorden hebben.

De categorieën staan per team gegroepeerd, omdat een categorie bij een team hoort. Kies je er een van een ander team, dan meldt het formulier dat en wordt het opslaan geweigerd: op het formulier van het doelteam zou die categorie helemaal niet worden aangeboden, dus zou de voorinvulling nergens toe leiden.

Variabelen bestaan hier niet, en de aanwijzing onder de tekst zegt dat: “No placeholders here: the template only prefills the form, nothing is resolved or sent.” Een “{requesterName}” zou letterlijk in het nieuwe ticket belanden — daarom wordt hij bij het opslaan geweigerd.

Het blauwe vak vat ook hier samen wat het sjabloon doet: “Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.”

Op het formulier zelf kies je het sjabloon met de knop “Template”; daarnaast staat “Prefills the form - nothing is created until you submit.” Alles wat is voorgevuld, is nog te wijzigen, en er wordt niets aangemaakt tot je verstuurt.

Er wordt één voorbeeldsjabloon meegeleverd: “Example: create accounts for a new colleague”. Het laat de vorm van het geheel zien en doet uit zichzelf niets — bouw het na of verwijder het.

De schakelaar “Offer this template to customers” staat standaard uit. De aanwijzing ernaast zegt allebei de dingen die je moet weten: “Customers can pick this template when they create a ticket. A draft stays hidden either way.”

Waarom hij standaard uit staat: een sjabloon is vaak in intern jargon benoemd en voor collega's geschreven. Het zichtbaar maken voor klanten is een uitspraak naar buiten — dat hoort iemand bewust te doen, niet per ongeluk.

De klant ziet dezelfde knop “Template” boven het formulier voor een nieuw ticket, maar alleen de vrijgegeven sjablonen. Een concept blijft ook met de schakelaar aan verborgen — de twee regels staan achter elkaar, niet naast elkaar.

Het gaat niet om gemak maar om het eerste contact: een aanvraag die compleet binnenkomt, bespaart de vragenronde die anders twee dagen kost. Zet die vragen in de omschrijving van het sjabloon — de klant beantwoordt ze terwijl hij het ticket aanmaakt.

Met “Fields to ask for” kun je verder gaan. Het sjabloon bepaalt dan welke eigen velden het formulier vraagt, in welke volgorde, en welke daarvan verplicht zijn. Die keuze VERVANGT de gebruikelijke velden van het team, ze komt er niet bij. Dat is precies de bedoeling. Eigen velden zelf horen bij Professional; hun kaart heet “Custom fields”. Een sjabloon voor klanten vrijgeven werkt in elke editie.

Een veld dat voor klanten verborgen is, blijft verborgen, ook als een sjabloon het noemt. De veldkeuze is een middel voor ordening en voor de snit, geen omweg om de veldinstellingen heen.

Elk gebruik dat meer doet dan tekst invoegen, schrijft ÉÉN regel in de historie, onder de veldnaam “Template”. Die noemt het sjabloon. De acties die zijn gelopen, schrijven eigen regels. Zonder haar zou er later geen manier zijn om uit te leggen waarom een ticket ineens naar “In Progress” sprong: de afzonderlijke acties schrijven wel hun eigen regels, maar geen daarvan noemt het sjabloon.

Op de afbeelding staat: “Template ‘First reply: we have your ticket’ applied”. Wat het sjabloon deed, staat in de regels van zijn eigen acties, zoals de statuswijziging.

Uitgevinkte acties staan er niet in: die zijn niet gebeurd. Een mislukking staat er wel in, en wordt als zodanig benoemd, achter het woord “failed”. Een puur tekstsjabloon zonder acties, mail of bijlagen laat op een los ticket geen regel “Template” achter. Het heeft alleen tekst ingevoegd. Toegepast op meerdere tickets tegelijk wordt de regel altijd geschreven, samen met de interne regel “Bulk”.

De regel is INTERN — de aanvrager ziet haar niet. De naam van een sjabloon is intern jargon (“standaardafwijzing”), en de historie staat ook open voor wie het ticket heeft aangemaakt. De veldwijzigingen zelf blijven voor die persoon zichtbaar; alleen hun herkomst in een sjabloon niet.

De auteur is de agent, niet “system” en niet het sjabloon. Dat is bewust zo: het toepassen was zijn beslissing. Anders dan bij een automatiseringsregel staat hier een mens op het ticket.