Deskhero
Nederlands
Probeer gratis

← Back to articles

Pilot met 2 tot 3 tags: routering op basis van vaardigheden voor supportteams

Pilot met 2 tot 3 tags: routering op basis van vaardigheden voor supportteams

Op vaardigheden gebaseerde routering stuurt elk binnenkomend contact door naar een User wiens vaardigheden aansluiten bij het verzoek, in plaats van alleen af te gaan op wie beschikbaar is. Het vervangt het model van de “volgende beschikbare User” door een match op basis van factoren zoals taal, productkennis of autorisatieniveau. Supportmanagers gebruiken het vaak om first-contact resolution (FCR), gemiddelde afhandeltijd (AHT) en overdrachtspercentages te verbeteren. In Deskhero kunnen automatiseringen voor nieuwe tickets een eenvoudigere versie van deze workflow bieden door tickets toe te wijzen aan een User of groep wanneer geconfigureerde voorwaarden overeenkomen.

Kort samengevat:

  • Op vaardigheden gebaseerde routering kan first-contact resolution verbeteren en het aantal overdrachten verminderen door naast beschikbaarheid ook vaardigheden mee te wegen.
  • Voor het opbouwen van een effectieve taxonomie is het nodig om te focussen op vaardigheden met grote impact, zoals taal, productkennis en autorisatieniveau, met vaardigheidsniveaus en regelmatige updates om veroudering te voorkomen.
  • Een succesvolle implementatie omvat een pilot met één wachtrij, het nauwkeurig taggen van contacten en het continu monitoren van KPI’s zoals FCR, AHT en overdrachtspercentages voor voortdurende optimalisatie.
  • AI kan helpen bij het classificeren van binnenkomende contacten, maar teams hebben nog steeds duidelijke regels, tests en menselijk toezicht nodig.
  • Kleine teams kunnen beginnen met een beperkte set routeringsvoorwaarden en deze alleen uitbreiden wanneer de resultaten meer complexiteit rechtvaardigen.

Inhoudsopgave

Wat is op vaardigheden gebaseerde routering? Een beknopte uitleg

Op vaardigheden gebaseerde routering (SBR) vergelijkt de vereisten van elk contact met een profiel van wat je Users daadwerkelijk kunnen. Een klant die in het Spaans e-mailt over een factuurgeschil, wordt doorgestuurd naar iemand die is getagd voor zowel facturering als Spaans, en niet naar de User wiens wachtrij toevallig het kortst is. Dat is het hele concept: contactvereisten aan de ene kant, geverifieerde vaardigheden van Users aan de andere kant en een regelsysteem dat beide aan elkaar koppelt.

De meeste teams houden een handvol vaardigheidscategorieën bij:

  • Taal (Spaans, Frans, Mandarijn)
  • Kennis van producten of functies (facturering, technische installatie, zakelijke accounts)
  • Vaardigheid per kanaal (telefoon, chat, e-mail, social media)
  • Autorisatieniveau (limieten voor terugbetalingen, accountwijzigingen, escalatierechten)

Traditionele routering op basis van wachtrijen of ACD (automatic call distributor) kan contacten op basis van beschikbaarheid doorsturen zonder gespecialiseerde kennis mee te wegen. Dat werkt wanneer elke User elk probleem kan afhandelen. Naarmate teams zich specialiseren, kan routering die alleen op beschikbaarheid is gebaseerd de kans vergroten dat een contact moet worden overgedragen.

Waarom op vaardigheden gebaseerde routering implementeren: meetbare voordelen en wanneer het mislukt

De meerwaarde van op vaardigheden gebaseerde routering moet worden getest in je eigen KPI-dashboard. Wanneer de routeringsregels en vaardigheidsgegevens nauwkeurig zijn, kunnen teams het volgende zien:

  • Een hogere first-contact resolution, omdat de User die het contact oppakt meestal al weet hoe het probleem moet worden opgelost
  • Een kortere gemiddelde afhandeltijd, omdat er minder gezocht, geëscaleerd of doorverbonden hoeft te worden
  • Minder overdrachten in het algemeen, een van de grootste oorzaken van klantfrustratie
  • Een hogere klanttevredenheid wanneer minder contacten opnieuw moeten worden uitgelegd of overgedragen

Waarom dit belangrijk is: Wetenschappelijk onderzoek naar callcenters beschrijft hoe complex het is om verschillende contacttypen te koppelen aan Users met verschillende vaardigheden. Met een pilot kun je testen of die complexiteit je eigen servicestatistieken verbetert voordat je de aanpak breder uitrolt.

Ook Users profiteren hiervan. Het afhandelen van contacten die aansluiten bij hun daadwerkelijke sterke punten betekent minder zoeken naar antwoorden en minder herstelwerk. Dat is vaak niet alleen zichtbaar in de cijfers, maar ook in het moreel.

SBR is niet automatisch de instelkosten waard. Een klein team van generalisten heeft mogelijk weinig aan een formele taxonomie. Hetzelfde kan gelden wanneer contacttypen onvoorspelbaar zijn of taggegevens te inconsistent zijn om te vertrouwen. In die gevallen kan een model op basis van beschikbaarheid of een eenvoudige prioriteitswachtrij hetzelfde doel bereiken met minder onderhoud.

Hoe op vaardigheden gebaseerde routering werkt: de technische workflow

De werking kan worden opgedeeld in drie fasen. Bouw een vaardigheidstaxonomie, koppel Users aan die taxonomie en configureer vervolgens de routerings- en toewijzingsregels. De implementatiedocumentatie van Microsoft geeft een concreet voorbeeld, inclusief beoordelingsmodellen, vaardigheidstypen, vaardigheidstoewijzing, classificatiemethoden en toewijzingsmethoden.

  1. Bouw de taxonomie. Definieer de beperkte lijst met vaardigheden die relevant zijn voor je bedrijf (taal, productgebied, kanaal, autorisatieniveau).
  2. Koppel Users aan vaardigheden. Afhankelijk van het platform krijgt elke User mogelijk een eenvoudige ja/nee-toewijzing of een beoordeling op een vastgestelde schaal voor vaardigheid.
  3. Configureer routeringsregels. De engine leest de tags van binnenkomende contacten en vergelijkt deze met Userprofielen. Waar nodig worden minimale vaardigheidsniveaus toegepast.

Contacten kunnen routeringsgegevens ontvangen uit IVR-menukeuzes, CRM-accountgegevens, onderwerpregels van e-mails, headers of geautomatiseerde classificatie van het bericht. Wanneer meerdere Users in aanmerking komen, heeft het platform een gedocumenteerde beslisregel nodig. Afhankelijk van het systeem kunnen opties bestaan uit vaardigheidsniveau, capaciteit, inactieve tijd of round robin.

Integratiepunt Rol in de routeringsbeslissing
ACD / IVR Legt het eerste contact vast en verzamelt routeringssignalen (menukeuze, beller-ID)
CRM Levert context over het account (niveau, geschiedenis, taalvoorkeur)
Chatbot / AI-classificatie Leest vrije tekst om de intentie en vereiste vaardigheid af te leiden
Personeelsbeheer Bevestigt welke Users met de vereiste vaardigheden zijn ingepland en beschikbaar zijn

Hier begint routering op basis van vaardigheden ook minder op één functie en meer op een klein integratieproject te lijken. Elke bron die contacttags aanlevert, moet nauwkeurig blijven; anders neemt de kwaliteit van de match af, zelfs wanneer de taxonomie zelf goed is ontworpen.

Een vaardigheidstaxonomie ontwerpen en Users toewijzen

Bouw de taxonomie rond de onderscheidingen die de service-uitkomsten beïnvloeden, en niet rond elke denkbare vaardigheid die iemand kan hebben. Onderzoek naar callcenterontwerp laat zien hoe snel routering complexer wordt wanneer contacttypen en capaciteiten van Users variëren. Een kleinere pilottaxonomie is eenvoudiger te testen en te onderhouden.

Twee ontwerpbeslissingen zijn het belangrijkst:

  • Vaardigheidsschalen. Als je platform beoordelingen ondersteunt, kunnen een vastgestelde schaal en een minimale drempel routinematig werk onderscheiden van gevallen waarvoor diepgaandere expertise nodig is.
  • Eigenaarschap. Bepaal vooraf of Users updates van hun vaardigheidsniveau zelf rapporteren, of een manager deze controleert en goedkeurt, of beide. Zelfrapportage gaat sneller; audits door managers signaleren veroudering.

Begin met een pilot. Kies één wachtrij, pas de taxonomie toe en meet de verandering in KPI’s voordat je verder uitbreidt.

Pro-tip: Voer je eerste vaardigheidstaxonomie gedurende een korte pilotperiode uit in één wachtrij en vergelijk FCR en AHT met je nulmeting voordat je de aanpak ergens anders uitrolt. Als de cijfers niet veranderen, moet de taxonomie worden herzien, niet het aantal wachtrijen worden uitgebreid.

Beschouw de taxonomie als een levend onderdeel van je operationele strategie en niet als een eenmalige insteltaak. De categorieën die je kiest, moeten aansluiten op de factoren die CSAT en oplossingspercentages daadwerkelijk beïnvloeden. Die lijst verandert naarmate je product en klantenbestand veranderen.

Implementatiechecklist: installatie, tests en lanceringsplan

De uitrol van op vaardigheden gebaseerde routering werkt het best als een gefaseerd project en niet als een verandering waarbij je simpelweg een schakelaar omzet.

  1. Stel eerst doelen. Bepaal welke KPI’s je wilt verbeteren (FCR, AHT, overdrachtspercentage) voordat je iets opbouwt.
  2. Kies een pilotwachtrij. Kies één contacttype met duidelijke vaardigheidsvereisten, en niet je meest chaotische wachtrij.
  3. Betrek belanghebbenden. Zorg dat een manager, enkele ervaren Users en de verantwoordelijke voor je CRM- of helpdeskgegevens samen aan tafel zitten.
  4. Maak de vaardighedenlijst. Houd deze compact en stem hem af op de doelen uit stap één.
  5. Tag contacten. Configureer IVR-, CRM- en e-mailregels voor tagging, zodat contacten met de juiste metadata binnenkomen.
  6. Wijs Users en drempelwaarden toe. Koppel Users aan vaardigheden met vaardigheidsniveaus en stel per vaardigheid minimale drempelwaarden in.
  7. Stel beslisregels voor gelijke uitkomsten in. Bepaal de volgorde van terugvalopties wanneer meerdere Users in aanmerking komen.
  8. Test met synthetisch verkeer. Stuur voorbeeldcontacten door de regels voordat je live gaat en controleer of terugvalroutering werkt wanneer geen gekwalificeerde User beschikbaar is.
  9. Rol gefaseerd uit. Breid de aanpak wachtrij voor wachtrij uit, train Users in de nieuwe werkwijze en houd dashboards tijdens de eerste week nauwlettend in de gaten.

Op vaardigheden gebaseerde routering meten, auditen en onderhouden

Op vaardigheden gebaseerde routering verslechtert stilletjes als niemand erop let. De KPI’s die je doorlopend moet volgen zijn FCR, CSAT, AHT, overdrachtspercentage, bezettingsgraad van Users en het behalen van SLA’s. Een daling in een van deze cijfers, vooral FCR of het overdrachtspercentage, is meestal het eerste teken dat Userprofielen niet langer met de werkelijkheid overeenkomen.

Een routeringsmodel is slechts zo actueel als de profielen en regels erachter. Wijs een eigenaar aan, bepaal hoe wijzigingen in vaardigheidsniveaus worden goedgekeurd en controleer het model volgens een vast schema.

Een werkbare frequentie ziet er als volgt uit:

  • Dagelijks: controleer dashboards op afwijkingen (plotselinge pieken in AHT, ongebruikelijke overdrachtspatronen)
  • Wekelijks: controleer steekproefsgewijs of gerouteerde contacten overeenkomen met de daadwerkelijke prestaties van Users
  • Per kwartaal: beoordeel de volledige taxonomie aan de hand van de huidige bedrijfsprioriteiten

Iemand moet eigenaar zijn van dit proces, of dat nu een teamleider of operationsmanager is. Ook moeten Userprikkels nauwkeurige zelfgerapporteerde vaardigheden belonen in plaats van overdreven hoge niveaus. Overdreven vaardigheidsniveaus brengen de nauwkeurigheid van routering sneller in gevaar dan bijna al het andere.

AI en op vaardigheden gebaseerde routering: wat AI toevoegt en waar menselijk toezicht essentieel blijft

Op vaardigheden gebaseerde routering bestaat al langer dan de huidige generatieve AI-systemen en de op regels gebaseerde kern ervan blijft nuttig. AI kan een classificatielaag toevoegen die op basis van een bericht in vrije tekst inschat wat een contact nodig heeft.

AI draagt doorgaans op drie manieren bij:

  • Intentieclassificatie: vrije tekst lezen (een e-mail, een chatbericht) om het werkelijke probleem af te leiden, en niet alleen de categorie die de klant heeft gekozen
  • Vaardigheidsvoorspelling: aangeven welke vaardigheidstags van toepassing zijn wanneer een contact niet netjes in een IVR-menu past
  • Ondersteuning bij routering: een categorie of betrouwbaarheidsindicator leveren die geconfigureerde toewijzingsregels kunnen gebruiken

Harde vereisten zoals licenties, taal of autorisatie moeten expliciete regels blijven. Een voorzichtige workflow is om het contact te classificeren, de vereiste vaardigheidsregels toe te passen, een gedocumenteerde beslisregel te gebruiken voor gekwalificeerde Users en onduidelijke gevallen ter beoordeling naar een mens te sturen.

Uitdagingen en veelvoorkomende valkuilen bij de implementatie van op vaardigheden gebaseerde routering

Een veelvoorkomend probleem is de data die de routeringslogica voedt. Als Userprofielen tijdens de onboarding worden aangemaakt en daarna nooit meer worden gecontroleerd, raakt de taxonomie steeds verder verwijderd van de huidige capaciteiten. Contacten kunnen ook verkeerd worden geclassificeerd wanneer menuopties of geautomatiseerde categorieën niet goed aansluiten op de vaardigheden die je hebt gedefinieerd. Deze fouten kunnen werk naar de verkeerde wachtrij sturen of vermijdbare overdrachten veroorzaken.

Te veel engineering kan net zo schadelijk zijn als verwaarlozing. Een grote set zeer specifieke vaardigheden kan ertoe leiden dat voor veel contacten geen volledig gekwalificeerde User beschikbaar is, waardoor voortdurend moet worden teruggevallen op alternatieve routering. Gearchiveerd callcenteronderzoek laat zien waarom routering over verschillende contacttypen en capaciteiten van Users een optimalisatieprobleem met echte afwegingen is.

Kleine teams hebben met een ander probleem te maken: er zijn te weinig Users per combinatie van vaardigheden, waardoor de “best gekwalificeerde” User vaak niet beschikbaar is en elke terugval in feite weer neerkomt op routering naar de volgende beschikbare User. Cross-training helpt hier meer dan extra regels toevoegen.

Tot slot lanceren veel teams SBR zonder er ooit opnieuw naar te kijken. Geen auditfrequentie, geen updates van vaardigheidsniveaus, geen beoordeling van de taxonomie. Het systeem dat bij de lancering goed werkte, raakt langzaam uit de pas met het team dat het daadwerkelijk bemant. Niemand merkt dit op totdat FCR een kwartaal lang ongemerkt daalt.

Uitdagingen en veelvoorkomende valkuilen bij de implementatie van op vaardigheden gebaseerde routering: overzichtsdiagram

Vergelijking van op vaardigheden gebaseerde routering met andere routeringsstrategieën

Round-robin-routering verdeelt contacten cyclisch over beschikbare Users zonder expertise te proberen matchen. De configuratie is eenvoudig en het doel is het werk gelijkmatig te verdelen. Dit kan geschikt zijn voor teams waarin elke User elk contacttype kan afhandelen.

Prioriteitsroutering rangschikt contacten op urgentie of klantniveau (een VIP-account springt voor in de wachtrij), maar houdt nog steeds geen rekening met welke User het best is toegerust om te helpen. Je kunt prioriteitsregels combineren met SBR, en de meeste volwassen implementaties doen dat ook: prioriteit bepaalt wie als eerste wordt geholpen binnen de groep Users die op vaardigheden zijn gematcht.

Routering op basis van langste inactiviteit of volgende beschikbaarheid, de standaardinstelling van ACD, optimaliseert uitsluitend voor eerlijkheid in de werkbelasting van Users. Het is snel en vereist geen configuratie, maar behandelt een factuurvraag en een technische storing identiek en stuurt beide naar degene die het langst inactief is.

Op vaardigheden gebaseerde routering ruilt die eenvoud in voor precisie. Er zijn een taxonomie, Usertoewijzing en doorlopend onderhoud voor nodig, terwijl round-robin- en volgende-beschikbaarheidsmodellen dat helemaal niet nodig hebben. De beloning bestaat uit minder overdrachten en snellere oplossingen, maar alleen als de onderliggende vaardigheidsgegevens nauwkeurig blijven. Een team dat niet de capaciteit heeft om die gegevens te onderhouden, is vaak beter af met een eenvoudiger model met prioriteitsregels, totdat het volume en de complexiteit van contacten de investering rechtvaardigen.

Vergelijking van vier routeringsstrategieën voor support

Branchespecifieke toepassingen en voorbeelden van op vaardigheden gebaseerde routering

E-commercesupportteams kunnen routeren op productlijn en probleemtype. Een vertraagde verzending kan naar een User gaan die vertrouwd is met logistiek, terwijl een betalingsgeschil naar iemand kan gaan met de juiste autorisatie voor terugbetalingen.

SaaS-bedrijven kunnen werk verdelen op productgebied en technische diepgang. Een factuurvraag en een probleem met een API-integratie vereisen vaak verschillende kennis, dus door ze naar verschillende groepen te routeren kunnen vermijdbare escalaties worden verminderd.

Supportteams in aan de gezondheidszorg verwante organisaties kunnen vragen over planning, verzekeringen en facturering routeren op basis van rol, training en toegangsrechten. Het routeringsontwerp moet aansluiten op de eigen privacy- en compliancevereisten van de organisatie.

Meertalige retail- en reismerken gebruiken taal als hun belangrijkste vaardigheidscategorie, vaak gecombineerd met regiospecifieke productkennis. Zo komt een Franstalige klant met een boekingsprobleem terecht bij iemand die de lokale algemene voorwaarden daadwerkelijk kan lezen, in plaats van alleen de woorden te vertalen.

Teams in de financiële dienstverlening kunnen autorisatieniveau combineren met productkennis. De relevante trainings-, toestemmings- en licentievereisten zijn afhankelijk van het product en de jurisdictie.

Impact van op vaardigheden gebaseerde routering op medewerkerstevredenheid en training

Werk koppelen aan de sterke punten van een User kan vermijdbare overdrachten en de frustratie van het herhaaldelijk afhandelen van onbekende problemen verminderen. Meet het effect via feedback van Users en kwaliteitsbeoordelingen in plaats van ervan uit te gaan dat het personeelsbehoud zal verbeteren.

Ook de invulling van training verandert. In plaats van elke User in alles even bekwaam te proberen maken, kunnen teams nieuwe medewerkers eerst trainen in een kleiner aantal vaardigheidsgebieden, hun niveau controleren en hun inzetbaarheid geleidelijk uitbreiden.

De keerzijde is dat specialisatie silo’s kan creëren als deze niet zorgvuldig wordt beheerd. Users die uitsluitend één vaardigheidsgebied behandelen, kunnen stagneren. Cross-training moet daarom doelgericht blijven, zodat het team niet eindigt met single points of failure waarbij de vakantie van één User een dekkingsprobleem voor een volledige vaardigheidscategorie veroorzaakt. Door Users roulerend ook secundaire vaardigheden te laten uitvoeren, zelfs met een lagere vaardigheidsdrempel, blijft het systeem veerkrachtig en krijgen Users een ontwikkelpad in plaats van een permanente rol.

AI-ondersteunde classificatie kan het handmatige werk van het labelen van contacten met vrije tekst verminderen. De bruikbaarheid ervan blijft afhankelijk van nauwkeurigheidscontroles, betrouwbaarheidsdrempels en een terugvaloptie voor berichten die niet binnen de taxonomie passen.

Sommige routeringsplatforms ondersteunen ook machinelearningclassificatie of configureerbare rangschikking binnen een gekwalificeerde groep. Beschouw deze functies als invoer die je moet testen, en niet als reden om harde geschiktheidsvereisten te verwijderen.

Prestatiegegevens kunnen managers helpen verouderde vaardigheidsbeoordelingen te identificeren, maar het automatisch wijzigen van geschiktheid op basis van resultaatgegevens brengt eigen risico’s met zich mee. Zorg dat wijzigingen controleerbaar blijven en leg vast wie ze mag goedkeuren.

Integratie met een kennisbank kan routering aanvullen door relevante informatie te tonen nadat een ticket de juiste User heeft bereikt. Routering en de kwaliteit van antwoorden moeten nog steeds afzonderlijk worden gemeten.

De aanpak van Deskhero voor kleine en middelgrote supportteams

Deskhero biedt geen volledige engine voor vaardigheidsprofielen met vaardigheidsscores of rangschikking op basis van capaciteit. Het biedt wel automatiseringen voor nieuwe tickets waarmee je de User, groep, prioriteit, status, tags of aangepaste dropdownvelden kunt instellen. Voorwaarden kunnen gebruikmaken van de automatisch gedetecteerde taal, onderwerp- of berichttekst, gegevens van de aanvrager of een voorwaarde in gewone taal: “Any (AI evaluated)”. Hierdoor is het mogelijk om een kleine set toewijzingsregels te testen zonder het resultaat te presenteren als enterprise-routering op basis van vaardigheden.

Routering met aandacht voor vaardigheden testen zonder een volledig platformoverhaul

Met Deskhero kunnen kleine en middelgrote teams eenvoudige toewijzingsregels testen terwijl ze hun bestaande e-mailadres behouden. Het maakt verbinding met Gmail of Microsoft 365 via tweezijdige synchronisatie, zodat antwoorden afkomstig blijven van het eigen bedrijfsadres.

Deskhero

Voor een routeringspilot kan Deskhero de taal van een ticket detecteren en geconfigureerde automatiseringsvoorwaarden toepassen om de groep, toegewezen User of tags in te stellen. De meertalige ondersteuning voor 14 talen kan Users helpen om in ondersteunde talen te lezen en te antwoorden. Opgeloste tickets kunnen bijdragen aan voorgestelde openbare FAQ-vermeldingen, maar een User moet een vermelding goedkeuren voordat deze openbaar wordt. De AI-chatbot beantwoordt vragen uitsluitend op basis van de goedgekeurde openbare FAQ en vereist ten minste 100 goedgekeurde FAQ-items voordat deze kan worden ingeschakeld.

Voor de gratis proefperiode van 30 dagen is geen creditcard nodig. Gebruik deze om een kleine set automatiseringen voor nieuwe tickets te configureren, ze met representatieve berichten te testen en de nauwkeurigheid van toewijzingen, het overdrachtspercentage en de oplossingsresultaten te vergelijken met je nulmeting.

Bronnen

Voor de technische werking van routering op basis van vaardigheden legt de documentatie van Microsoft vaardigheidsbeoordelingen, classificatie, matching en toewijzing in Dynamics 365 uit. Wikipedia biedt historische context. Raadpleeg voor een beknopte definitie uit de sector de NICE-woordenlijst.

Veelgestelde vragen

Wat is skill-based routing in Salesforce?

Salesforce Omni-Channel kan toegewezen vaardigheden gebruiken bij het routeren van ondersteunde werkitems. Het precieze gedrag hangt af van de manier waarop een organisatie vaardigheden, servicekanalen, wachtrijen en routeringsregels configureert.

Wat is het verschil tussen routering op basis van wachtrijen en op vaardigheden gebaseerde routering?

Routering op basis van wachtrijen stuurt elk contact in een wachtrij naar de volgende beschikbare User, ongeacht expertise. Op vaardigheden gebaseerde routering filtert die groep eerst op een geverifieerde vaardigheidsmatch en gebruikt beschikbaarheid pas daarna als beslisregel.

Kun je een voorbeeld geven van leren op basis van vaardigheden?

In een supportcontext betekent leren op basis van vaardigheden dat Users worden getraind op specifieke, getagde competenties (zoals autorisatie voor terugbetalingen of een bepaalde productlijn) in plaats van op een algemeen onboardingcurriculum. Zo weerspiegelen vaardigheidsscores in het routeringssysteem daadwerkelijke, geverifieerde capaciteiten.

Hoe lang duurt het om op vaardigheden gebaseerde routering in te stellen?

Er bestaat geen universele insteltijd. Een pilot hangt af van het aantal vaardigheden, de kwaliteit van bestaande gegevens, het routeringsplatform, het testvolume en de tijd die het team nodig heeft om een zinvolle KPI-vergelijking te verzamelen.

Werkt op vaardigheden gebaseerde routering voor kleine supportteams?

Ja, als de contacttypen voldoende van elkaar verschillen om routeringsregels te rechtvaardigen. In Deskhero kan een klein team automatiseringen voor nieuwe tickets gebruiken met gedetecteerde taal, berichtinhoud, gegevens van de aanvrager of een door AI geëvalueerde voorwaarde om een User of groep toe te wijzen. Deskhero biedt geen volledige engine voor op vaardigheidsniveau gebaseerde routering.