Ask Us Anything: Kennisbeheer, met Stefan en Camilo

Hoi ​@Jaap, 

Bedankt voor deze scherpe en goed onderbouwde vraag. Dit is precies het soort feedback waar we wat mee kunnen, dus ik neem graag de tijd om het uit te leggen.

Om meteen met de conclusie te beginnen: er komt geen strategische verschuiving weg van Diensten. Wat je wel ziet gebeuren is een ontkoppeling. Kennisbeheer krijgt steeds meer eigen, zelfstandige bouwstenen, zodat het niet meer volledig afhankelijk hoeft te zijn van de dienstenstructuur. Diensten blijven bestaan en krijgen op sommige vlakken zelfs een grotere rol. Een service desk levert natuurlijk diensten. Jullie structuur inrichting van kennisitems op basis van diensten is dan ook één van de best practices!

Hieronder loop ik jullie vier punten langs.

Rechten en autorisaties
Hier zit de duidelijkste verandering. We werken aan een eigen rechtenmodel voor de kennisbank, los van diensten: behandelaarsgroepen kunnen straks direct gekoppeld worden aan groepen kennisitems. Dit hangt samen met de nieuwe folder-gebaseerde structuur van de kennisbank, die inmiddels is opgeleverd. De oude opzet, waarin kennisitems werden misbruikt als mapjes, was namelijk niet goed te combineren met een modern rechtensysteem of met de nieuwe dienstenarchitectuur. Kortom: rechten op kennis worden geleidelijk minder afhankelijk van hoe diensten zijn ingericht, maar we gaan er wel van uit dat de gekoppelde behandelaargroepen verantwoordelijk zijn voor bepaalde diensten die geleverd worden, en de daarbij horende kennis.

Bundelen en structureren van kennis en dienstverlening
De kennisbank krijgt een eigen, moderne structuur die los staat van diensten. Tegelijkertijd blijft de koppeling tussen kennisitems en diensten bestaan en wordt die zelfs in de toekomst verder uitgewerkt, maar dan als een keuze die je kunt maken, niet als een verplichte hiërarchie. Een structuur gebaseerd op diensten is zoals eerder beschreven wel de best practice.

Routeren van vragen naar de juiste afdeling
Hier komt AI in beeld. We werken aan een triage-functionaliteit die meldingen automatisch categoriseert en routeert op basis van intentie en context, niet alleen op basis van de dienst die is gekozen. Een belangrijke aanleiding hiervoor: op dit moment is minder dan 3 procent van de incidenten gekoppeld aan een kennisitem, waardoor veel kennis onbenut blijft bij het oplossen of doorzetten van tickets. Dit is dus geen vervanging van routing via diensten, maar een aanvullende laag die zowel kennis als diensten als bron gebruikt.

Flows in combinatie met kennisitems
Hier is het beeld het meest geruststellend voor jullie. Diensten en service flows blijven de eenheid waarin een formulier, de beschikbaarheid en rechten, en gekoppelde kennisitems samenkomen. We investeren hier momenteel juist actief in, onder andere om onze nieuwe AI-ondersteuning (de Virtual Support Agent) op basis van diensten en flows te laten navigeren naar de juiste plek in de Self Service Portal. Diensten blijven hier dus het fundament.

Over de zoekresultaten
We herkennen dat dienstweergave in zoekresultaten is veranderd. Zoeken binnen diensten en zoeken binnen de kennisbank hebben nu nog gedeeltelijk gescheiden trajecten, en we zijn ons bewust dat dit tot een minder consistente ervaring kan leiden. Dit is een van de punten waar we nog verder onderzoek naar doen; nog geen concreet antwoord, maar wel op de radar.

Samengevat: geen afbouw van diensten, wel een gerichte ontkoppeling zodat kennisbeheer flexibeler en zelfstandiger wordt. Voor rechten, structuur en zoeken wordt kennis steeds minder afhankelijk van diensten. Voor routing komt er een aanvullende AI-laag naast diensten. En voor flows blijven diensten het fundament, met nieuwe ontwikkelingen die daar juist op voortbouwen.

Een deel van bovenstaande zit nog in een vroege fase van onderzoek en verkenning, dus beschouw dit als richting, niet als toezegging met een vaste planning. Zodra er concretere stappen zijn, delen we die uiteraard hier in de community.

Mocht je nog vervolgvragen hebben, denk graag met ons mee.

Hoi ​@Patricia Keijer,

Bedankt voor je vraag en dat is vervelend om te horen, maar ik kan je verzekeren dat dit niet komt door de gearchiveerde kennisitems of doordat ze gekoppeld zijn aan meldingen. Dit heeft te maken met de "synchronisatiestatus" van deze kennisitems.

Om het kennissysteem te verbeteren, te innoveren en toekomstbestendig te maken, worden alle nieuwe functionaliteiten op een nieuwe architectuur gebouwd. De data van het kennissysteem staat daardoor deels nog in de oude module en deels al in de nieuwe architectuur. Omdat we die nieuwe architectuur up-to-date willen houden, synchroniseren we de informatie tussen beide.

Het komt af en toe voor dat de data hierdoor corrupt raakt of niet volledig is. Dit kan verschillende oorzaken hebben, maar is meestal op te lossen met een hersynchronisatie. Onze support kan je hier graag mee helpen.

Lang verhaal kort, deze kennisitems kunnen gewoon blijven bestaan, inclusief hun link. Ik zag dat je hiervoor nog geen ticket hebt aangemaakt bij onze support afdeling, neem vooral even contact met ze op. Zij kunnen dit probleem verhelpen zodat je ook deze kennisitems kan migreren. 

Hoi ​@Ronald Visscher,

Bedankt voor je vraag.
Om heel eerlijk te zijn, zijn het ook twee verschillende oplossingen. Deze functionaliteit hoort natuurlijk bij incidentbeheer. Toen deze ooit gebouwd was, was er nog geen koppeling met kennisitems Als je een nieuwe standaardoplossing aanmaakte moest je zelf in de tekstvelden het antwoord vermelden. Later bedacht ik dat het antwoord ook gewoon vanuit het kennissysteem kon komen. (Eigenlijk vindt ik dat ze daar ten alle tijde moeten staan 😅, maar dat terzijde). Om wat tijd te winnen hebben we beide aan elkaar gekoppeld. De kracht van de standaardoplossing is vooral het vullen van de "procesinformatie" aan de linkerkant van het incident (hoe is het incident geclassificeerd) en die van het kennisitem het serveren van het antwoord. Dit was een stukje geschiedenis, maar niet de toekomstige situatie.

In de toekomst willen we dat dit soort dingen gedaan kunnen worden middels AI. De eerste stap wordt gezet met de triage-functionaliteit, die het classificeren en routeren makkelijker maakt. De volgende stap waarover we nog aan het nadenken zijn is of deze "agent" ook het incident ook niet alvast kan voorzien met het antwoord. De behandelaar hoeft dan alleen nog maar de laatste check te doen en het te bevestigen. Hiermee zouden we de standaard oplossingen functionaliteit kunnen vervangen. 

Wat betreft de andere bronnen. Dit is inderdaad iets dat we aan het onderzoeken zijn. We snappen dat niet alle kennis alleen uit het kennissysteem komt, maar ook vanuit Sharepoint of een pdf handleiding van een leverancier bijvoorbeeld. We willen dat dit soort bronnen gebruikt kunnen worden om incidenten op te lossen. Dit is dus nog wel in de onderzoeken fase!  

Hoi ​@Ruben Vermeulen,

Goede vraag, en eentje die steeds relevanter wordt naarmate er meer AI-functionaliteit op kennisitems draait.

Er is op dit moment geen verplicht format vanuit TOPdesk, maar op basis van hoe onze eigen AI-features kennisitems gebruiken, en hoe AI-gedreven kennisbanken in de bredere sector het beste presteren, kunnen we wel een onderbouwd advies geven.

Waarom dit uitmaakt
De AI Answer assistant, die operators een concept-antwoord voorstelt op basis van een kennisitem, matcht op semantische gelijkenis tussen de melding en de inhoud van het KI, en citeert vervolgens letterlijk uit dat KI. Als er geen goede match is, laat het systeem bewust niets zien in plaats van iets te verzinnen. De kwaliteit en indeling van je kennisitems bepalen dus rechtstreeks hoe goed deze en andere AI-features voor jou werken.

Hoe beter de content is opgeknipt in behapbare, op zichzelf staande stukken, hoe betrouwbaarder de AI-resultaten zijn. Een kennisbank die voor mensen prettig leest, bevat vaak juist ruis die een AI in de war brengt.

Waar we op dit moment op zouden aansturen

1. Een kennisitem per probleem of onderwerp, geen verzamelartikelen. Kleinere, eenduidige stukken zijn beter terug te vinden dan grote documenten met meerdere onderwerpen door elkaar.
2. Schrijf en titel in de taal en bewoording van de eindgebruiker, niet alleen in interne terminologie. AI matcht het beste wanneer de structuur van je kennisitem lijkt op hoe iemand de vraag daadwerkelijk zou stellen, bijvoorbeeld in vraag-en-antwoordvorm in plaats van lopende tekst.
3. Een volledige, zelfstandige oplossing in de tekst zelf, dus niet alleen een verwijzing naar een bijlage of extern document. AI kan alleen citeren wat er daadwerkelijk in het kennisitem staat.
4. Duidelijk herkenbare, losse oplossingsstappen in plaats van dichte alinea's. Kort en concreet werkt beter dan uitgebreid en verhalend.
5. Regelmatig onderhoud. Houd je kennisitems actueel zodat er geen oude informatie gedeeld wordt met de eindgebruiker.

Dit is dus richting, geen verplichting. Zodra TOPdesk hier concretere richtlijnen of tooling voor uitbrengt, laten we dat hier in de community weten.

​@Esther Bennis  wellicht dat ​ ​@Stefan van Opstal  hier nog op terug komt, maar mag ik je ook vragen dit idee in te schieten via de officiële weg, namelijk https://tip.topdesk.com/ 
Dan komt alles namelijk direct ook bij de juiste mensen binnen. 

Bedankt voor deze feature request ​@Esther Bennis.
Dit is inderdaad op dit moment niet mogelijk. Als Product manager wil ik natuurlijk graag de vraag achter de wens weten. Wat is de reden dat je een item zou willen verplaatsen in plaats van laten waar hij is en hem daar gewoon te archiveren?

Hoi ​@Juno,

Dit is een bekende wens en inderdaad iets dat we hopelijk in de toekomst ook beschikbaar kunnen maken voor het SSP.

Op dit moment wordt er voor het SSP een virtual support agent gemaakt die het zoeken naar kennis makkelijker moet maken. Deze agent kan "delen" van het kennisitem voorschotelen aan een eindgebruiker. Dit alles dankzij de koppen die je gemaakt hebt. Hopelijk wordt het zo makkelijker voor een eindgebruiker om het juiste deel van een lang kennisitem te krijgen.

2e antwoord:

We willen het feedback systeem verbeteren in de toekomst, maar omdat er nog genoeg andere verbeteringen zijn en we de architectuur van het kennissysteem verder willen updaten, prioriteren we nu andere functionaliteiten (zoals drafts kunnen schrijven 🤗). Daarom hebben we gekozen voor nu het huidige systeem één op één over te nemen. Ik neem je wens mee!

 

Hoi ​@Giovanni Bakker,

De makkelijkste manier is het om dit te doen via een selectie op basis van tijd. Dit geeft je een selectie overzicht waarbij je dan de aanmaker van de kaart kan opnemen als kolom. 

In de toekomst willen we je een dashboard geven waar je dit makkelijker kan zien. 

Oké, antwoord zelf al gevonden 😄

Het is inderdaad mogelijk om via een URL naar een kennisitem-map te verwijzen, alleen is er een kleine omweg nodig om de juiste gegevens te achterhalen.

Het pad is:

/tas/public/ssp/ssp/knowledge/[unid]

Deze URL kun je vervolgens als snelkoppeling aan een dienst toevoegen.

De UNID van de map achterhaal je als volgt:

1. Ga vanuit de startpagina naar het kennissysteem.
2. Klik met de rechtermuisknop op de betreffende map.
3. Kies ‘Linkadres kopiëren’.
4. Plak de link bijvoorbeeld even in Kladblok.
5. Achter folder staat de UNID die je nodig hebt.