Tickets vallen niet meer tussen wal en schip wanneer drie dingen samenwerken in Odoo Helpdesk: een team dat eigenaar is van elke wachtrij, een SLA-beleid dat elk ticket een klok geeft, en automatische toewijzing die elk ticket bij binnenkomst een naam geeft.
Een klant mailt op maandagochtend over een kapotte bestelling. De mail belandt in een gedeelde inbox die vier mensen half in de gaten houden. Iedereen gaat ervan uit dat een ander hem wel oppakt. Op donderdag belt de klant, boos, en nu ontdek je dat de e-mail er al drie dagen ligt zonder dat iemands naam eraan hangt. Ondertussen werd een vraag met lage prioriteit binnen tien minuten beantwoord omdat die toevallig bij de juiste persoon terechtkwam. Het werk is niet het probleem. Het probleem is dat niets bepaalt wie eigenaar is van een ticket en tegen wanneer, dus de urgente glippen weg en de makkelijke krijgen aandacht.
Zo ziet een supportproces zonder routering en SLA's eruit. Tickets komen binnen via verschillende kanalen, stapelen zich op één plek op, en wachten erop dat een mens ze opmerkt. Odoo Helpdesk lost dit op met drie dingen die samenwerken: teams die eigenaar zijn van een wachtrij, een SLA-beleid dat de klok instelt, en toewijzingsregels die elk ticket een naam geven op het moment dat het binnenkomt. Zo stel je alle drie in, waar mensen op vastlopen, en wanneer de routering zo ingewikkeld wordt dat je er een partner bij moet halen.
Waarom tickets tussen wal en schip vallen
Niemand bepaalt wie eigenaar is van een ticket, dus niemand is het. Een gedeelde inbox of één ongefilterde wachtrij spreidt de verantwoordelijkheid over iedereen, wat betekent dat die bij niemand terechtkomt. Het ticket dat een specialist nodig heeft, ligt naast het ticket dat een antwoord van één regel nodig heeft, en beide wachten erop dat dezelfde persoon ze handmatig triageert.
Er is geen klok, dus niets is te laat. Zonder SLA heeft "we komen er nog op terug" geen deadline. Een ticket kan een dag of een week blijven liggen en niets in het systeem zegt dat het achterstallig is, omdat er om te beginnen niets is beloofd. Het enige signaal dat je krijgt is een boze klant, en tegen die tijd is de schade al aangericht.
Het diepere probleem is dat triage, toewijzing en prioriteren allemaal handmatig zijn. Iemand moet elk ticket lezen, bepalen bij welk team het hoort, bepalen wie het afhandelt, en bepalen hoe urgent het is. Als die iemand het druk heeft of afwezig is, loopt de hele wachtrij vast. De oplossing is om Odoo de routering en de timing automatisch te laten doen, zodat de mens tijd besteedt aan het oplossen van tickets, niet aan het sorteren ervan.
De oplossing, in stappen
Stel de wachtrij, de kanalen, de klok en de routering in die volgorde in. Elke stap bouwt voort op de vorige.
Maak een team voor elke wachtrij die je daadwerkelijk draait
In Helpdesk is een team een wachtrij met eigen leden, kanalen en regels. Ga naar Helpdesk > Configuratie > Helpdesk-teams en maak één team per aparte supportstroom: bijvoorbeeld "Klantenservice", "Technisch", "Retouren". Maak niet één team per persoon, en maak niet op dag één twintig teams. Een team moet overeenkomen met een echte groep mensen die een echte categorie werk afhandelt. Het team is waar je kanalen aanzet, SLA-beleid koppelt en de toewijzingsmethode instelt, dus eerst de teams goed krijgen maakt alles daarna eenvoudiger.
Zet de kanalen aan die klanten daadwerkelijk gebruiken
Elk team kan tickets ontvangen uit meerdere kanalen, en je zet die per team aan. Open het team en schakel in wat past:
- E-mailalias. Berichten die naar het adres van het team worden gestuurd (bijvoorbeeld support@jouwbedrijf.com) worden automatisch tickets. Dit is het werkpaardkanaal voor de meeste bedrijven.
- Websiteformulier. Voegt een inzendpagina toe zodat klanten een ticket kunnen aanmaken met de velden die jij kiest. Goed voor gestructureerde intake waarbij je vooraf een categorie of een ordernummer wilt.
- Live Chat. Laat een bezoeker met een agent praten, en een agent kan dat gesprek ter plekke omzetten in een ticket met het commando
/ticketin het chatvenster.
Zet alleen de kanalen aan die je daadwerkelijk gaat bemannen. Een e-mailalias die niemand leest, is dezelfde gedeelde inbox waarmee je begon, alleen dan binnen Odoo.
Stel SLA-beleid in zodat elk ticket een klok heeft
Een SLA-beleid zegt: tickets die aan deze criteria voldoen, moeten binnen deze tijd deze fase bereiken. Open een team en gebruik de knop SLA-beleid om er een aan te maken. Een beleid heeft twee helften.
De criteria bepalen op welke tickets het beleid van toepassing is: het team (verplicht), en optioneel de prioriteit, de tags, de klant of het type. Zo kun je zeggen dat "tickets met hoge prioriteit voor dit team" een strakker doel krijgen dan normale.
Het doel is de fase die het ticket moet bereiken en de tijd die het mag duren om die te bereiken. Bijvoorbeeld: een ticket met hoge prioriteit moet binnen 2 werkuren "In behandeling" bereiken en binnen 8 "Opgelost". De klok telt in de werkuren van het team, niet in kloktijd, dus een SLA tikt niet 's nachts door als je team 's nachts niet werkt. Maak een paar niveaus: een snel doel voor urgente tickets, een ruimer doel voor normale vragen. Wanneer een ticket zijn doel mist, wordt de SLA-tag rood en blijft rood, zodat een achterstallig ticket onmogelijk te missen is in de lijst.
Routeer tickets automatisch zodat elk een naam krijgt
Een ticket zonder toegewezen persoon is een ticket dat erop wacht vergeten te worden. Zet op het team Automatische toewijzing aan en kies hoe Odoo het werk verdeelt:
- Elke gebruiker krijgt een gelijk aantal tickets toegewezen, op basis van het totale aantal. Simpele round-robin: iedereen krijgt na verloop van tijd ongeveer hetzelfde aantal.
- Elke gebruiker heeft een gelijk aantal openstaande tickets, op basis van de huidige werklast. Odoo geeft het volgende ticket aan degene die op dit moment de minste openstaande tickets heeft, wat de belasting verdeelt wanneer sommige tickets veel langer duren dan andere.
Kies de optie met werklastverdeling als je tickets sterk variëren in inspanning, en de optie met gelijk aantal als ze ongeveer vergelijkbaar zijn. Je kiest ook welke teamleden in de toewijzingspool zitten, zodat je een senior persoon uit de rotatie kunt houden en die handmatig kunt inschakelen. Voor de rest krijgt een ticket op het moment dat het binnenkomt een naam, een SLA-klok en een plek in iemands wachtrij, zonder menselijke triage ertussen.
Bewaak de wachtrij en de SLA-prestaties in rapportages
Routering en SLA's helpen alleen als je ernaar kijkt. Helpdesk-rapportage laat je het SLA-slagingspercentage zien, de gemiddelde tijd tot afsluiten, en tickets per team en per agent. Controleer het wekelijks: een dalend SLA-slagingspercentage betekent dat de doelen te strak zijn of dat het team onderbezet is, en een wachtrij die voor één team blijft groeien betekent dat de routering of de bezetting niet klopt. Het rapport verandert "het voelt druk" in "dit team miste vorige week 18% van zijn SLA's", en daar kun je iets mee.
Het stuk waar mensen over struikelen
Een paar dingen overkomen vrijwel iedereen
Een paar dingen overkomen vrijwel iedereen.
De SLA-klok gebruikt werkuren, en die moet je instellen. Een SLA-doel van "4 uur" betekent vier werkuren, geteld tegen het werkrooster van het team. Als je de werkuren nooit instelt, of verkeerd instelt, komen de deadlines niet overeen met wat klanten ervaren. Controleer het rooster voordat je op de doelen vertrouwt.
Prioriteit stuurt de SLA aan, maar prioriteit wordt vaak nooit ingesteld. Een beleid dat alleen geldt voor tickets met hoge prioriteit doet niets als geen enkel ticket ooit als hoge prioriteit wordt gemarkeerd. Bepaal wie prioriteit instelt en wanneer. Train agents om het in te stellen, of stel het automatisch in op basis van het kanaal of de klant, anders blijft je strakke SLA-niveau ongebruikt terwijl alles als normaal telt.
Automatische toewijzing negeert wie er daadwerkelijk beschikbaar is. Round-robin en werklastverdeling spreiden tickets over de pool, maar ze weten niet wie er op vakantie of ziek is, tenzij je die persoon uit de toewijzingspool haalt. Een ticket dat is toegewezen aan iemand die afwezig is, valt weer tussen wal en schip. Houd de pool actueel.
Een gefaalde SLA-tag blijft voor altijd rood. Zodra een ticket zijn doel mist, blijft de rode tag staan, zelfs nadat je het ticket hebt opgelost. Dat is met opzet, zodat de gemiste deadline zichtbaar is in rapportages, maar het betekent dat een rode tag niet altijd "nu actie" betekent. Lees het als "deze was te laat", en gebruik de live-deadline, niet de kleur van de tag, om te bepalen wat nu echt urgent is.
Eén team per persoon is een valkuil. Het voelt georganiseerd, maar het betekent dat elke routeringsbeslissing nog steeds een mens is die bepaalt welke persoon, en dat is precies de handmatige triage die je probeerde weg te halen. Teams horen wachtrijen met werk te zijn, met mensen erin, zodat de toewijzingsregels iets hebben om over te verdelen.
Snelle checklist
- Je hebt één Helpdesk-team per echte supportwachtrij, niet één per persoon.
- Elk team heeft de kanalen aangezet die je daadwerkelijk bemant (e-mailalias, websiteformulier, livechat).
- Elk team heeft minstens één SLA-beleid met een duidelijk fasedoel en een duidelijke tijd.
- De SLA-doelen tellen tegen werkuren die correct zijn ingesteld voor het team.
- Prioriteit wordt op tickets ingesteld, zodat de prioriteitsgebaseerde SLA-niveaus ook echt gelden.
- Automatische toewijzing staat aan, met de juiste methode en een actuele pool van beschikbare agents.
- Je controleert het SLA-slagingspercentage en de wachtrijgrootte in rapportages minstens wekelijks.
FAQ
Hoe werken SLA's in Odoo Helpdesk?
Een SLA-beleid in Odoo Helpdesk stelt een doel: tickets die aan bepaalde criteria voldoen (team, prioriteit, tags, klant) moeten binnen een vastgestelde tijd een gekozen fase bereiken. De tijd telt in de werkuren van het team, niet rond de klok. Als een ticket zijn doel mist, wordt de SLA-tag rood en blijft rood, zodat achterstallige tickets makkelijk te herkennen zijn in de lijst en in rapportages. Je maakt beleidsregels per team aan met de knop SLA-beleid op het team.
Hoe wijst Odoo helpdesktickets automatisch toe?
Zet Automatische toewijzing aan op een Helpdesk-team en kies een methode. Odoo kan zo toewijzen dat elk lid na verloop van tijd een gelijk aantal tickets krijgt (round-robin op totaalaantal), of zo dat elk lid op dit moment een gelijk aantal openstaande tickets heeft (gebalanceerd op de huidige werklast). Je kiest welke teamleden in de toewijzingspool zitten, en elk nieuw ticket wordt toegewezen op het moment dat het binnenkomt, zodat niets wacht om handmatig getriageerd te worden.
Uit welke kanalen kan Odoo Helpdesk tickets ontvangen?
Per team kun je een e-mailalias aanzetten (berichten naar een teamadres worden automatisch tickets), een websiteformulier (een inzendpagina met de velden die jij kiest), en Live Chat (een agent zet een chat om in een ticket met het commando /ticket). Je zet alleen de kanalen aan die je daadwerkelijk bemant, op elk team, zodat tickets uit elke bron in één wachtrij belanden met dezelfde routerings- en SLA-regels.
Waarom worden supporttickets gemist in Odoo?
Meestal omdat geen team eigenaar is van de wachtrij, geen SLA een deadline stelt, en toewijzing handmatig is. Een gedeelde inbox spreidt de verantwoordelijkheid over iedereen, dus die komt bij niemand terecht, en zonder SLA is niets ooit "te laat". De oplossing is een team per wachtrij, een SLA-beleid dat elk ticket een klok geeft, en Automatische toewijzing die elk ticket een naam geeft op het moment dat het binnenkomt, zodat triage niet langer afhangt van een mens die het opmerkt.