Gebruik deze sjabloon
Goede support begint met een goede ticketdocumentatie. Met Trupeer kun je uren besparen op supportdocumentatie door te starten met een gratis klantticket en resolutiesjabloon, dit aan te passen met je brand guidelines en opgeloste tickets om te zetten in video-cases voor de supportkennisbank.
De meeste supportteams hebben een ticketsysteem vol tickets en geen idee wat er eigenlijk misgaat. Alles wordt gecategoriseerd als Overig, resolutienotities zeggen "opgelost" en het maandrapport toont volume en niets anders.
Dat is een probleem met de veldopzet, niet met rapportage. Dit sjabloon dekt beide helften van een ticket: het record dat je vastlegt en bepaalt wat je later kunt leren, en de reacties die je verstuurt en bepalen wat de klant ervaart.
Download het ticket- en resolutiesjabloon
Formaat | Beste voor |
|---|---|
Excel (.xlsx) | Het ticketlogboek, met categorieën, resolutiecoden en rapportagetabs |
Word (.docx) | Het ticketformulier, het resolutieoverzicht en de responssjablonen |
Printbare en invulbare ticketformulieren voor aan de balie of veldservice | |
Google Sheets | Een gedeeld logboek voor kleine teams zonder helpdesktool |
Google Docs | De responssjablonen, om te kopiëren naar je helpdesk-standaardantwoorden |
Gratis, bewerkbaar, geen watermerk. Als je al een helpdesktool hebt, gebruik dan de veldlijst en de formulering van de reacties en negeer het logboek.
Zo pas je dit sjabloon aan in Trupeer
Stap 1: Open het gedeelte Templates
Ga naar het gedeelte Templates in de hoofd navigatie.
Stap 2: Selecteer en open een sjabloon
Klik op een willekeurig sjabloon waarmee je wilt werken om het te openen.
Stap 3: Vouw de sjabloonweergave uit
Als dat nodig is, vouw je de sjabloonweergave uit om de volledige indeling en details duidelijk te zien.
Stap 4: Bewerk het sjabloon
Klik op Bewerken om te beginnen met het aanpassen van het geselecteerde sjabloon.
In de editor kun je:
Nieuwe secties toevoegen
Opmaakregels definiëren of bijwerken
Een logo toevoegen en de positie en bijbehorende instellingen aanpassen
Stap 5: Sla je aangepaste sjabloon op
Nadat je alle noodzakelijke wijzigingen hebt gedaan, klik je op Opslaan om het bijgewerkte sjabloon als je eigen sjabloon op te slaan.
Stap 6: Bekijk en verfijn het sjabloon
Als je wilt zien hoe je aangepaste sjabloon eruitziet, open je de Voorvertoning.
Vanaf het scherm met de voorvertoning kun je, indien nodig, direct doorgaan met het maken van aanpassingen, zodat het sjabloon precies verschijnt zoals jij het wilt.
Met een klantticket en resolutiesjabloon kun je:
Uren besparen op schrijven: Sla de lege pagina over met een structuur die is gebouwd voor ticketdocumentatie.
Supportkwaliteit standaardiseren: Ingebouwde velden zorgen ervoor dat elk ticket de kerninformatie vastlegt.
In lijn blijven met je merk: Pas je logo, lettertypen en kleuren toe met Trupeer's brand kit.
Bouw een sterkere KB: Opgeloste tickets worden toekomstige helpartikelen en runbooks.
Trends spotten: Gestandaardiseerde tickets maken het eenvoudig om terugkerende problemen te identificeren.
Bereik globale teams: Vertaal ticket-sjablonen naar 65+ talen met één klik.
De twee helften van een ticketsjabloon
Het record. Wat er wordt vastgelegd: wie, wat, wanneer, hoe urgent, welke categorie, wat is opgelost. Deze helft is onzichtbaar voor de klant en bepaalt alles wat je later kunt leren.
De reacties. Wat de klant ontvangt in elke fase: bevestiging, updates, escalatiebericht, oplossing, follow-up. Deze helft is waar ze jou op beoordelen.
Teams investeren meestal in het tweede deel en verwaarlozen het eerste, daarom levert supportrapportage zo vaak volume-grafieken op en geen inzicht. Beide delen zitten in dit sjabloon.
De velden van het ticketformulier
Elk veld moet zijn plek verdienen. Elk veld dat je toevoegt vertraagt de intake en velden die niemand gebruikt worden gevuld met rommel.
Vastgelegd bij intake
Veld | Waarom het bestaat |
|---|---|
Ticket-ID | Referentie voor alles wat daarna komt |
Datum en tijd van aanmelding | Start de SLA-klok |
Kanaal | E-mail, telefoon, chat, portal, aan de balie. Zegt je waar de vraag echt binnenkomt |
Naam en contactgegevens van de aanvrager | Aan wie je moet antwoorden |
Account of organisatie | Groepering van tickets per klant, waar patronen zichtbaar worden |
Product, service of systeem | Het ding dat niet werkt |
Categorie | Zie hieronder. Het belangrijkste veld |
Beschrijving | In de woorden van de klant, niet geparafraseerd |
Prioriteit | Afgeleid van impact en urgentie, niet vrij gekozen |
Toegewezen aan | Eén naam, nooit een team |
Status | Open, in behandeling, wachten op klant, opgelost, gesloten |
Vastgelegd bij afsluiting
Veld | Waarom het bestaat |
|---|---|
Resolutiecoden | Wat het echt heeft opgelost. Zie hieronder |
Resolutienotities | Genoeg zodat de volgende persoon het kan herhalen |
Root cause | Waar bekend. Optioneel per ticket, essentieel in totaal |
Tijd tot eerste reactie | Gemeten, niet ingeschat |
Tijd tot oplossing | Exclusief tijd wachten op de klant |
Opnieuw geopend | Ja of nee. Een opnieuw geopend ticket is niet opgelost |
Kennisartikel aangemaakt of bijgewerkt | Het veld dat het geheel versterkt |
Bevestiging door klant | Hebben ze ermee ingestemd dat het is opgelost |
Dat laatste intakeveld en het kennisartikelveld zijn de twee meest ontbrekende, en beide zijn degene die het verschil maken tussen een wachtrij en een systeem dat verbetert.
Categorisering die echt werkt
Categorie is het veld dat bepaalt of je ticketdata iets waard is, en het is bijna altijd kapot.
Twee niveaus, niet vier. Categorie en subcategorie. Diepere hiërarchieën zorgen voor inconsistente tagging, omdat agents stoppen met lezen na de tweede dropdown.
Tussen acht en vijftien topcategorieën. Minder en alles is Overig. Meer en niemand kan de juiste vinden.
Noem categorieën naar wat de klant heeft ervaren, niet naar de interne structuur van je team. "Kan niet inloggen" in plaats van "Identity platform".
Geen Overig. Of als je er echt één moet hebben: bekijk het maandelijks en zet terugkerende items om in echte categorieën. Een Overig-bucket boven vijf procent betekent dat je taxonomie niet klopt.
Catagoriseer bij het eerste contact, en laat de agent het bij afsluiting aanpassen als blijkt dat het iets anders is. Categorisering achteraf gebeurt altijd gehaast en is altijd fout.
Bekijk de taxonomie elk kwartaal. Categorieën worden verouderd als het product verandert.
Een werkbare startset voor de meeste supportteams: toegang en inloggen, facturering en betalingen, setup en configuratie, hoe doe ik, niet zoals verwacht, dataprobleem, integratie, performance, feature request, bug, wijziging account, annulering.
Resolutiecoden
Het equivalent aan de afsluitkant, en nog vaker verwaarloosd. Resolutienotities die als vrije tekst zijn geschreven, kun je niet tellen.
Code | Betekent | Wat het je vertelt |
|---|---|---|
Opgelost door support | Agent heeft het direct opgelost | Normale oplossing |
Opgelost door engineering | Vereiste een code- of configuratiewijziging | Volume van productdefecten |
Gebruikersfout of misverstand | Product werkte, verwachting kwam niet overeen | Gat in documentatie of UX |
Documentatie verstrekt | Antwoord bestond al | Vindbaarheidsprobleem, geen kennisprobleem |
Workaround verstrekt | Onderliggend probleem blijft bestaan | Verborgen backlog. Let op deze |
Duplicaat | Zelfde probleem als een ander ticket | Vergroot volume als het niet wordt bijgehouden |
Geen fout gevonden | Kon niet reproduceren | Heeft een drempel nodig voordat het een patroon wordt |
Ingetrokken door klant | Loste zichzelf op of was niet langer nodig | Betekent vaak trage reactie |
Buiten scope | Niet iets waar je support voor biedt | Controleer of het zo zou moeten zijn |
Twee van deze zijn diagnostisch goud. Een hoog percentage documentatie verstrekt betekent dat je helpcontent bestaat en niet gevonden kan worden. Een hoog percentage workaround verstrekt betekent dat je onopgeloste problemen opbouwt die terug zullen komen.
Prioriteit en hoe je die instelt
Prioriteit moet worden afgeleid, niet gekozen. Agents die vrij mogen kiezen, markeren alles als hoog, omdat elke klant het voor zichzelf urgent vindt.
Lage urgentie | Gemiddelde urgentie | Hoge urgentie | |
|---|---|---|---|
Lage impact | P4 | P4 | P3 |
Gemiddelde impact | P4 | P3 | P2 |
Hoge impact | P3 | P2 | P1 |
Impact is hoeveel mensen er last van hebben en hoe erg. Eén gebruiker die ongemak ervaart is laag. Een heel team dat geblokkeerd is, is hoog.
Urgentie is hoe snel het opgelost moet worden. Een cosmetisch probleem is laag, ongeacht hoeveel mensen het zien. Een geblokkeerde deadline is hoog.
Publiceer de matrix en de responstargets voor elk niveau, zodat prioriteit een berekening is en geen onderhandeling.
De levenscyclus van een ticket
Fase | Wat er gebeurt | Wat de klant ontvangt |
|---|---|---|
Aangemaakt | Ticket aangemaakt, gecategoriseerd, geprioriteerd | Bevestiging met referentie en verwachte timing |
Toegewezen | Eigenaar benoemd | Niets, tenzij de eigenaar wijzigt |
In behandeling | Wordt gewerkt | Update als het de beloofde termijn overschrijdt |
Wachten op klant | Geblokkeerd totdat informatie binnen is | Duidelijk verzoek, plus een aangegeven auto-close-venster |
Gëscaleerd | Doorgestuurd volgens de matrix | Bericht over wie het nu beheert en wanneer ze reageren |
Opgelost | Fix toegepast, wacht op bevestiging | Resolutiebericht met beschrijving van wat er is gedaan |
Gesloten | Klant bevestigt of auto-close is verstreken | Optionele tevredenheidsenquête |
Opnieuw geopend | Probleem kwam terug of is niet opgelost | Bevestiging dat het niet is opgelost |
De status "wachten op klant" heeft een gedefinieerd auto-close-venster nodig, meestal vijf tot tien werkdagen met een herinnering vooraf. Zonder dit blijven tickets voor altijd openstaan en worden je metrics voor oplostijd betekenisloos.
Responssjablonen per fase
De formulering die klanten echt zien. Houd elk bericht kort en vervang placeholders door echte waarden in plaats van ze generiek te laten.
Bevestiging
Bedankt dat je contact hebt opgenomen. Je referentie is [ID] en ik kijk er nu naar. Ik kom bij je terug met een update tegen [time], ook als ik tegen die tijd nog geen volledig antwoord heb.
Het laatste deel is belangrijk. Een belofte om een update te geven in plaats van een oplossing is een belofte die je kunt nakomen.
Statusupdate
Een korte update over [ID]. Ik heb [wat je hebt gedaan] en ik ben nu [wat is de volgende stap]. Ik verwacht dat dit is opgelost tegen [time]. In dit stadium is er niets van jou nodig.
Verstuur dit voordat de klant achter je aan gaat. Een update zonder dat je erom gevraagd wordt, is meer waard dan een snel antwoord op een achtervolging.
Verzoek om informatie
Om dit verder te brengen heb ik [specifiek ding] nodig. Zodra ik dat heb, moet ik in staat zijn om [resultaat]. Als ik vóór [date] niets van je hoor, sluit ik het ticket en kun je op elk moment antwoorden om het opnieuw te openen.
Vraag om één ding. Drie verzoeken in één bericht leveren betrouwbaar één antwoord op.
Escalatiebericht
Ik heb dit geëscaleerd naar [naam of team] omdat [reden]. Ze nemen contact op tegen [time]. Je referentie is ongewijzigd op [ID] en ik blijf in de cc.
Zeg waarom. Escalatie zonder reden klinkt alsof het rond wordt gestuurd.
Resolutie
Dit is nu opgelost. De oorzaak was [cause] en ik heb [wat je hebt gedaan]. Je zou nu [verwacht resultaat] moeten zien. Als het opnieuw gebeurt, antwoord dan op dit bericht en het komt meteen weer bij mij terug.
Noem de oorzaak. "Het is nu opgelost" laat klanten zonder vertrouwen dat het zo blijft.
Resolutie follow-up
Ik check [ID] van [date]. Werkt alles nog steeds zoals verwacht? Als dat niet zo is, antwoord dan hier gewoon op.
Twee tot drie dagen later, en alleen voor alles wat significant of terugkerend was.
Storing of wijdverspreid probleem
We zijn op de hoogte van [issue] dat van invloed is op [scope] en we werken er nu aan. Ik geef je hoe dan ook een update tegen [time], ongeacht de voortgang. Je hoeft niets te doen.
Proactief, voor iedereen die erdoor wordt getroffen, voordat ze contact met je opnemen.
Excuses na een servicefout
Je had gelijk om dit aan te kaarten en het spijt me. [Wat er misging], en dat ligt bij ons. Ik heb [actie ondernomen] en [wat herhaling voorkomt]. Als er nog iets openstaat, zeg het me dan en ik regel het.
Specifiek, zonder defensiviteit, en vermeldt wat het voorkomt dat het terugkomt.
Het resolutieoverzicht
Voor alles wat significant is, heeft het afsluitrecord meer nodig dan een notitie. Het sjabloon bevat een resolutieoverzicht met:
Ticketreferentie en datums. Wat de klant heeft gemeld, in hun eigen woorden. Wat er echt gebeurde, wat vaak anders is. Root cause. Wat er is gedaan om het op te lossen. Of er een workaround is gebruikt en of het onderliggende probleem nog steeds bestaat. Tijd tot eerste reactie en tot oplossing. Of het is teruggekomen. Wat er is gewijzigd om herhaling te voorkomen, of een notitie dat er niets is. Kennisartikel aangemaakt of bijgewerkt.
Dat laatste duo is wat een opgelost ticket omzet in een verbetering. De meeste afsluitnotities stoppen bij wat er is gedaan, wat de volgende persoon alleen helpt als die het ticket vindt.
Wat je met ticketdata kunt doen
Als de velden goed zijn ingevuld:
Vind de top vijf categorieën op volume en los de grootste op. Meestal is de grootste een documentatie- of productprobleem, niet een supportprobleem.
Vergelijk volume met resolutiecoden. Hoog volume met een code die door documentatie is geleverd, is vindbaarheid van content, niet supportcapaciteit.
Let op het percentage workarounds, dat is je verborgen backlog.
Controleer het percentage opnieuw openen per agent en per categorie. Veel opnieuw geopende tickets betekenen dat tickets worden afgesloten in plaats van opgelost.
Kijk naar de kanaalmix in de tijd. Groei in telefoon betekent vaak dat selfservice ergens is stukgelopen.
Cross-reference op account. Eén klant die herhaaldelijk tickets aanmaakt in dezelfde categorie is een trainings- of configuratieprobleem, geen pech.
Volg eerste reactie versus oplossing apart. Ze hebben verschillende oorzaken en verschillende oplossingen.
Dit alles is niet mogelijk zonder gedisciplineerde categorisering bij intake, daarom krijgt dat veld de meeste aandacht in dit sjabloon.
Helpdesk, servicedesk en ticketsjablonen
Helpdesk | Servicedesk | Klantensupport | |
|---|---|---|---|
Doel | Interne medewerkers, meestal IT | Interne medewerkers, breder servicecatalogus | Externe klanten |
Focus | Break-fix | Aanvragen, incidenten, wijzigingen, problemen | Productvragen en -problemen |
Framework | Informeel | Vaak ITIL-gericht | Verschilt |
Extra velden | Asset, device | Service, wijzigingsreferentie, CI | Account, abonnement, order |
De veldlijst en de formulering van de reacties op deze pagina werken voor alle drie. Servicedesks die ITIL draaien, moeten wijzigings- en probleemreferenties toevoegen, en het onderscheid tussen incident en aanvraag is daar relevant op een manier die niet geldt voor klantensupport.
Zo stel je dit in
Ontwerp eerst de categorieën, met de mensen die ze gaan gebruiken. Acht tot vijftien, twee niveaus, genoemd naar wat de klant heeft ervaren.
Bepaal de vereiste velden bij intake, en houd de lijst kort. Elk veld vertraagt de eerste reactie.
Bouw de prioriteitsmatrix en publiceer die met responstargets.
Definieer resolutiecoden vóór go-live, niet na zes maanden vrije tekst.
Stel het auto-close-venster in voor wachten op klant.
Laad de responssjablonen als standaardantwoorden en bewerk de formulering zodat het klinkt als jullie team.
Train specifiek op categorisering. Dit is het veld dat het vaakst slecht wordt gedaan en dat het meest belangrijk is.
Bekijk de Overig-bucket maandelijks voor het eerste kwartaal.
Rapporteer over categorieën en resolutiecoden, niet alleen over volume.
Herzie de taxonomie elk kwartaal.
Best practices
Catagoriseer bij het eerste contact, corrigeer bij afsluiting.
Houd de vereiste intakevelden tot het minimum dat het ticket werkbaar maakt.
Leid prioriteit af van impact en urgentie in plaats van agents te laten kiezen.
Gebruik resolutiecoden, niet vrije tekst, voor alles wat je wilt kunnen tellen.
Beloof een update in plaats van een oplossing.
Verstuur updates voordat de klant achter je aan gaat.
Noem de oorzaak in het resolutiebericht.
Stel een auto-close-venster in voor wachten op klant.
Leg vast of er een kennisartikel is aangemaakt.
Rapporteer per categorie en resolutiecoden.
Veelgemaakte fouten
Een Overig-categorie die een derde van de tickets opslokt.
Hiërarchieën met vier niveaus waar agents niet meer doorlezen.
Categorieën die zijn genoemd naar interne teams in plaats van naar symptomen bij klanten.
Prioriteit vrij gekozen, dus alles is hoog.
Resolutienotities met vrije tekst zonder iets dat je kunt tellen.
Geen tracking van workarounds, waardoor onopgeloste problemen verdwijnen.
Wachten op klant zonder auto-close, waardoor het aantal open tickets eindeloos wordt opgeblazen.
Resolutieberichten die zeggen opgelost zonder te zeggen wat er mis was.
Geen follow-up op significante issues.
Alleen rapportage over volume, wat laat zien hoe druk je bent en niets over waarom.
Categorisering achteraf aan het einde van de maand.
Zet opgeloste tickets om in dingen die klanten zelf kunnen oplossen
Open het sjabloon in Trupeer AI, pas je brand kit toe zodat alles wat klantgericht is overeenkomt, en bewerk elke sectie direct. De setup staat in de template guide.
Bekijk de tabel met resolutiecoden nog eens. Documentatie verstrekt betekent dat het antwoord bestond en niet gevonden kon worden. Opgelost door support, herhaaldelijk, in dezelfde categorie betekent dat het antwoord nog niet bestaat. Beide zijn contentproblemen die zich voordoen als supportvolume, en beide worden op dezelfde manier opgelost.
Wanneer een agent iets voor de vierde keer oplost, leg het dan één keer vast. Trupeer AI genereert het geschreven artikel en een ingesproken video walkthrough op basis van dezelfde sessie, zodat de volgende klant de fix kan bekijken in plaats van een ticket aan te maken. Vertaal het naar 65+ talen en houd de set bij in je knowledge base, zodat het vindbaar is op het moment dat iemand vastloopt. Gebruik dezelfde opnames voor agent training.
Leg het vast. Branded het. Vertaal het. Trupeer it.
Veelgestelde vragen
Is er een gratis ticketsysteem-sjabloon?
Ja. De Excel-versie werkt als een compleet ticketlogboek voor kleine teams zonder helpdesktool, met categorieën, prioriteit, resolutiecoden en rapportagetabs. Als je al een helpdesk-systeem hebt, neem dan de veldlijst en responssjablonen en negeer het logboek.
Is er een helpdesk-ticket-sjabloon in Word?
Ja. Het Word-bestand bevat het ticket-intakeformulier, het resolutieoverzicht en alle responssjablonen, zodat je het formulier kunt printen of de tekst kunt kopiëren naar je helpdesk-standaardantwoorden.
Is er een servicedesk-ticket-sjabloon in Excel?
Ja, en Excel is de versie die de meeste teams nuttig vinden. Eén rij per ticket met intake- en afsluitvelden, dropdowns voor categorie, prioriteit en resolutiecoden, plus tabs die volume samenvatten per categorie en resolutietype.
Is er een servicedesk-ticket-sjabloon in Word?
Ja. De Word-versie bevat een printbaar servicedesk-ticket dat geschikt is voor veldservice of support aan de balie, met handtekeningregels voor afgerond werk en klantacceptatie.
Is er een IT-servicedesk-ticketformulier-sjabloon?
Ja. De IT-versie van het intakeformulier voegt een asset- of device-referentie toe, systeem dat is beïnvloed, en een wijzigingsreferentieveld voor servicedesks die een formeel wijzigingsproces volgen.
Is er een gratis support-ticket-systeem HTML- of Bootstrap-sjabloon?
Nee, en het is de moeite waard om daar direct over te zijn. Die verzoeken zijn voor front-end code om een ticketsysteeminterface te bouwen, wat een web development asset is en geen document. Zoek naar een Bootstrap admin dashboard theme, of gebruik een bestaande helpdeskplatform, aangezien het bouwen van een ticketsysteem vanuit een sjabloon meestal duurder is dan het lijkt zodra je rekening houdt met authenticatie, e-mailrouting en SLA-logica. Wat deze pagina je geeft, is het veldontwerp en de formulering van de reacties, die je hoe dan ook nodig hebt, ongeacht in welke interface het wordt gebouwd.
Wat is een ticket-resolutiesjabloon?
Twee dingen, afhankelijk van de context. Het resolutiebericht dat naar de klant wordt gestuurd om uit te leggen wat er mis was en wat er is gedaan, en het resolutie-record dat intern wordt vastgelegd met de resolutecode, root cause en tijd tot oplossing. Beide zijn hier inbegrepen en het tweede is wat je ticketdata bruikbaar maakt.
Welke velden moet een supportticket hebben?
Bij intake: ticket-ID, datum, kanaal, aanvrager, account, product of service, categorie, beschrijving in de woorden van de klant, prioriteit, eigenaar en status. Bij afsluiting: resolutecode, resolutienotities, root cause waar bekend, responstijden en oplostijden, of het opnieuw is geopend, en of er een kennisartikel is aangemaakt.
Hoe moeten supporttickets worden gecategoriseerd?
Twee niveaus, acht tot vijftien topcategorieën, genoemd naar wat de klant heeft ervaren in plaats van naar de interne structuur van je team. Categoriseer bij het eerste contact en sta correctie toe bij afsluiting. Vermijd een Overig-bucket, of bekijk die maandelijks en promoot de terugkerende items naar echte categorieën.
Wat zijn resolutiecoden en waarom doen ze ertoe?
Een vaste set waarden die beschrijft hoe een ticket is opgelost: opgelost door support, opgelost door engineering, documentatie verstrekt, workaround verstrekt, gebruikersfout, duplicaat, geen fout gevonden. Ze doen ertoe omdat resolutienotities met vrije tekst niet te tellen zijn en twee van die codes in het bijzonder aangeven waar je echte problemen zitten.
Hoe stel je ticketprioriteit in?
Leid die af van impact en urgentie met behulp van een gepubliceerde matrix in plaats van agents vrij te laten kiezen. Impact is hoeveel mensen er worden beïnvloed en hoe erg. Urgentie is hoe snel het opgelost moet worden. Publiceer de matrix met responstargets zodat prioriteit een berekening is en geen onderhandeling.
Wat moet een ticket-resolutiebericht zeggen?
Wat de oorzaak was, wat je hebt gedaan, wat de klant nu zou moeten zien en hoe je weer contact kunt opnemen als het opnieuw gebeurt. De oorzaak benoemen is het onderdeel dat het vaakst wordt gemist en het is wat de klant vertrouwen geeft dat de fix blijft werken.
Hoe lang moet je wachten voordat je een ticket sluit?
Vijf tot tien werkdagen voor wachten op klant, met een herinnering voordat je sluit en een duidelijke verklaring dat antwoorden het opnieuw opent. Zonder een auto-close-venster worden aantallen open tickets eindeloos opgeblazen en stoppen metrics voor oplostijd met betekenis.
Kan ik dit ticket- en resolutiesjabloon aanpassen?
Ja, alle versies zijn volledig bewerkbaar. De categorieën en resolutiecoden zijn de onderdelen die van jou moeten zijn en ze worden geleverd als een startset om te bewerken in plaats van volledig over te nemen. In Trupeer AI kun je ook je brand kit toepassen zodat klantgerichte berichten en artikelen overeenkomen.
