Deskhero
Latviešu
Sākt bez maksas

← Back to articles

Iekšējā zināšanu bāze komandām: izveidojiet tādu, ko visi lieto

Iekšējā zināšanu bāze komandām: izveidojiet tādu, ko visi lieto

Iekšējā zināšanu bāze ir centralizēta, meklējama vieta, kur jūsu komanda glabā procedūras, rīcības rokasgrāmatas, politikas, jauno darbinieku ievadīšanas soļus un iepriekš pieņemtos lēmumus, lai nevienam nebūtu divreiz jāuzdod viens un tas pats jautājums. Ja jūs to jau zināt un vēlaties sākt rīkoties, lūk, ar ko sākt šonedēļ.

  • Izvērtējiet pēdējā mēneša Slack un e-pasta sarakstes, lai atrastu 20 visbiežāk atkārtotos jautājumus.
  • Norīkojiet vienu konkrēti nosauktu atbildīgo par katru augstākā līmeņa kategoriju, pirms uzrakstāt kaut vienu rakstu.
  • Sāciet 20 rakstu pilotprojektu, aptverot tikai šos svarīgākos jautājumus, un pēc tam to paplašiniet.

Izdariet šīs trīs lietas, un ieguvumu redzēsiet ātri: mazāk pārtraukumu, kas izrauj cilvēkus no koncentrēta darba, un jaunie darbinieki vairs ik stundu nebakstīs kolēģim pie pleca. Pārējā šīs rokasgrāmatas daļa izskaidro, kāpēc tas darbojas un kā to pareizi izveidot.

Galvenie secinājumi

Noderīga iekšējā zināšanu bāze sākas ar konkrēti nosauktu atbildīgo katrai kategorijai, 20 rakstu pilotprojektu, kas veidots no reāliem jautājumiem, un 90 dienu pārskatīšanas ciklu, kas uztur saturu uzticamu.

Punkts Informācija
Sāciet ar reāliem jautājumiem Pirms jebkā rakstīšanas pārskatiet pēdējo 30–60 dienu Slack un e-pasta sarakstes, lai atrastu 20 visbiežāk atkārtotos jautājumus.
Norīkojiet atbildīgo katrai kategorijai Norīkojiet vienu konkrētu personu, nevis komandu, par atbildīgo katrai augstākā līmeņa kategorijai.
Uzturiet taksonomiju nelielu Izmantojiet nelielu, pēc funkcijām veidotu augstākā līmeņa kategoriju kopu, nevis kopējiet savas organizācijas struktūru.
Nosakiet pārskatīšanas regularitāti Katram rakstam iestatiet 90 dienu “pēdējoreiz pārskatīts” ciklu, bet politiku izmaiņu gadījumā veiciet tūlītēju pārskatīšanu.
Droši apvienojiet zināšanu bāzi ar AI Deskhero tērzēšanas robots un AI automātiskās atbildes atbild tikai no apstiprinātajiem publiskajiem BUJ ierakstiem. Šīs funkcijas ir izvēles, bet automātiskās darbības tiek marķētas un reģistrētas.

Satura rādītājs

Kāpēc iekšējā zināšanu bāze ir svarīgāka, nekā tai parasti tiek atzīts

Argumenti par labu uzņēmuma zināšanu bāzei nav abstrakti. Gartner aptaujā noskaidrots, ka ievērojamai daļai digitālo darbinieku ir grūtības atrast informāciju, kas nepieciešama darba veikšanai. Tas nozīmē gandrīz pusi jūsu darbaspēka, kas jau šobrīd klusi zaudē laiku, meklējot atbildi, kura kaut kur jau pastāv vecā Slack sarakstē vai kāda cilvēka iesūtnē.

Skaitļos: liela daļa digitālo darbinieku nespēj uzticami atrast informāciju, kas vajadzīga darba veikšanai. Katrs neatbildētais jautājums “kur ir dokuments par X?” ir šīs statistikas reāla izpausme jūsu komandā.

Darbojoša iekšējās dokumentācijas sistēma šo problēmu risina tieši. Tā samazina laiku līdz atbildei, jo cilvēki meklē, nevis jautā. Tā samazina konteksta pārslēgšanu, jo nozares eksperts netiek izrauts no sava darba, lai atkārtotu kaut ko, ko jau piecas reizes ir izskaidrojis. Tā saīsina ievadīšanu darbā, jo jaunais darbinieks var atrast ieviešanas kontrolsarakstu, negaidot vecākā inženiera kalendārā brīvu laiku.

Ieguvumi parādās vairākās paredzamās jomās:

  • Ātrāka jauno darbinieku ievadīšana, jo pirmās nedēļas jautājumiem ir rakstiskas atbildes, nevis tikai kāda cilvēka galvā glabātas nerakstītas zināšanas.
  • Fewer repeat tickets or Slack pings, jo atbilde atrodas meklējamā vietā, nevis slēgtā sarakstē.
  • Mazāka konteksta pārslēgšana vadošajiem darbiniekiem, kuri pārstāj darboties kā cilvēku meklētājprogrammas.
  • Konsekventākas atbildes, jo visi izmanto vienu un to pašu avotu, nevis piecus nedaudz atšķirīgus mutiskus skaidrojumus.

Veiciet aptuvenu aprēķinu savai komandai: ja pieci cilvēki katrs dienā pavada 20 minūtes, atbildot uz jautājumiem, kurus tā vietā varētu atrisināt komandu zināšanu bāze, tas nozīmē vairāk nekā astoņas stundas nedēļā atgūta senioru darba laika. Sareiziniet to ar ceturksni, un ieguvums kļūst acīmredzams — nav nepieciešams pieņemt darbā nevienu jaunu darbinieku.

Kam vispirms jābūt jūsu zināšanu bāzē

Ne katram iekšējās dokumentācijas rīkam pirmajā dienā jāietver pilnīgi viss. Mēģinājums uzreiz dokumentēt visu uzņēmumu ir iemesls, kāpēc lielākā daļa zināšanu bāzes projektu apstājas vēl pirms palaišanas. Sāciet ar satura veidiem, kas patiešām neļauj cilvēkiem pārtraukt citam citu.

Nosakiet prioritātes šādā secībā:

  1. Rīcības rokasgrāmatas un problēmu novēršanas ceļveži atkārtotiem steidzamiem gadījumiem (servera pārstartēšanas procedūra, atmaksas process, bieži sastopamas kļūdas labojums).
  2. Ievadīšanas darbā kontrolsaraksti pirmajai nedēļai un pirmajam mēnesim.
  3. Politikas, par kurām pastāvīgi tiek uzdoti jautājumi (apmaksāts brīvais laiks, izdevumu apstiprināšana, attālinātā darba noteikumi).
  4. Instrukciju raksti atkārtojamiem uzdevumiem (kā pieprasīt piekļuvi, kā iesniegt pirkuma pasūtījumu).
  5. Lēmumu ieraksti, kas izskaidro, kāpēc tika izvēlēts konkrēts risinājums, lai pēc sešiem mēnešiem neviens to atkal neapstrīdētu.
  6. Glosāriji iekšējam žargonam un akronīmiem, kas mulsina jaunos darbiniekus.
  7. BUJ, kas veidoti tieši no visbiežāk uzdotajiem klientu atbalsta un iekšējiem jautājumiem.
  8. Veidnes dokumentiem, kurus jūsu komanda raksta atkārtoti.

Daži piemēri lapu struktūrām, ko vērts izmantot:

  • Standarta darbības procedūras vai rīcības rokasgrāmatas veidne: aktivizējošais nosacījums, darbības pa soļiem, pie kā eskalēt problēmu, paredzamais atrisināšanas laiks.
  • Pirmās nedēļas ievadīšanas darbā kontrolsaraksts: izveidojamie konti, satiktie cilvēki, pirmais nodevums, kam jautāt, ja rodas grūtības.
  • Īsa politikas lapa: augšdaļā vienas rindkopas kopsavilkums, kam seko pilns izklāsts un pēc tam izņēmumu sadaļa.

Katram rakstam neatkarīgi no tā veida augšpusē nepieciešami vienādi metadati: atbildīgais, pēdējās pārskatīšanas datums, statusa atzīme (aktuāls, jāpārskata, arhivēts) un vairākas alternatīvās frāzes, lai meklēšana uztvertu veidu, kā cilvēki patiešām formulē jautājumu, nevis tikai oficiālo terminu.

Kā izveidot un strukturēt iekšējo zināšanu bāzi

Darbinieku zināšanu datubāzes izveide, kas pastāv arī pēc trešā mēneša, galvenokārt ir atkarīga no pareizas secības. Izlaidiet auditu un uzreiz ķerieties pie rakstīšanas — jūs piepildīsiet sistēmu ar rakstiem, kurus neviens nemeklē. Lūk, plāns pa posmiem, ko varat īstenot aptuveni četrās nedēļās.

Četru posmu iekšējās zināšanu bāzes izveides laika grafiks

1. posms: audits (1.–5. diena)

Apkopojiet faktiskos jautājumus, ko cilvēki uzdod. Pārmeklējiet pēdējo 30–60 dienu Slack, e-pasta un atbalsta pieteikumus, lai atrastu atkārtotas tēmas. Visdrošākais sākumpunkts ir 20 svarīgākie jautājumi, ko darbinieki patiešām uzdod, nevis hipotētisks saraksts ar visu, ko jūsu nodaļa teorētiski varētu dokumentēt.

  • Kas: projekta atbildīgais, apkopojot informāciju no trim vai četriem nodaļu vadītājiem.
  • Kas jādara: sarindot 20–30 visbiežāk atkārtotos jautājumus.
  • Rezultāts: izklājlapa ar jautājumu, aptuveno biežumu un ierosināto atbildīgo.
  • Pieņemšanas kritēriji: katrs sarakstā iekļautais jautājums audita periodā ir uzdots vismaz divas reizes.

2. posms: taksonomija un atbildība (6.–10. diena)

Pretojieties vēlmei veidot sarežģītu kategoriju koku. Praktiski izmantojama taksonomija balstās uz nelielu skaitu pēc funkcijām organizētu augstākā līmeņa kategoriju. Izmantojiet, piemēram, “Darba sākšana”, “IT un piekļuve”, “Personālvadība un politikas” un “Klientu atbalsta procedūras”, nevis kopējiet savas organizācijas struktūru. Norīkojiet vienu konkrēti nosauktu atbildīgo katrai augstākā līmeņa kategorijai. Nevis komandu. Vienu personu. Ja atbildībai nav konkrēta vārda, raksti sāk novecot.

  • Kas: kategoriju atbildīgie, kas rakstiski apstiprināti.
  • Kas jādara: kodolīga, pēc funkcijām veidota augstākā līmeņa kategoriju taksonomija.
  • Rezultāts: taksonomijas karte, kur blakus katram atzaram norādīts atbildīgā vārds.
  • Pieņemšanas kritēriji: katrai kategorijai ir tieši viens par to atbildīgais, kurš ir piekritis šai lomai.

3. posms: pilotprojekta izveide (11.–20. diena)

Uzrakstiet 20 rakstu pilotprojektu tieši no audita saraksta. Izmantojiet iepriekšējā sadaļā minētās veidnes, lai visiem rakstiem būtu vienāda struktūra. Šeit nemigrējiet visu veco wiki saturu. Pārnesiet tikai tādu saturu, kas nesen patiešām izmantots vai uz kuru ir atsauces, pārrakstiet visu, kas izskatās novecojis vai nepabeigts, bet pārējo arhivējiet, nevis ieraduma dēļ pārnesiet uz priekšu.

  • Kas: kategoriju atbildīgie, kuri katrs raksta vai norīko savus rakstus.
  • Kas jādara: 20 pabeigti raksti, kas atbilst pilotprojekta svarīgākajiem jautājumiem.
  • Rezultāts: publicēta pilotprojekta sadaļa, ko pārskatījusi vismaz viena persona ārpus autora komandas.
  • Pieņemšanas kritēriji: testa lasītājs var atrast un saprast katru rakstu mazāk nekā divu minūšu laikā, neuzdodot papildu jautājumu.

4. posms: meklēšanas integrēšana un izmēģinājuma palaišana (21.–28. diena)

Integrējiet zināšanu bāzi vietās, kur jūsu komanda jau pavada darba dienu — Slack, Microsoft Teams vai pieteikumu pārvaldības rīkā. Zināšanu bāze, kuras lietošanai jāatver atsevišķa cilne, ir zināšanu bāze, par kuras esamību cilvēki aizmirst. Vispirms veiciet izmēģinājuma palaišanu vienā nodaļā, apkopojiet atsauksmes, novērsiet acīmredzamās nepilnības un tikai pēc tam atveriet to visam uzņēmumam.

  • Kas: projekta atbildīgais un viens vai divi izmēģinājuma nodaļas brīvprātīgie.
  • Kas jādara: meklēšanas integrācija un īss iekšējs paziņojums.
  • Rezultāts: lietošanas dati par pirmajām divām nedēļām un atsauksmju vienumu saraksts.
  • Pieņemšanas kritēriji: vismaz puse izmēģinājuma grupas pirmajās desmit dienās ir izmantojusi zināšanu bāzi bez pamudinājuma.

Profesionāļa padoms: Uzsāciet ar šaurāku tvērumu, nekā sākotnēji šķiet ērti. Kompakts 20 rakstu pilotprojekts, ko cilvēki patiešām izmanto, rada daudz lielāku iekšējo uzticēšanos nekā plašs 200 rakstu krājums, ko neviens nelasa.

Pirms uzskatāt darbu par pabeigtu, pārbaudiet, cik viegli saturs ir atrodams. Uzdodiet piecus reālus jautājumus cilvēkam, kurš nav piedalījies satura rakstīšanā, un izmēriet, cik ilgs laiks viņam nepieciešams atbildes atrašanai. Ja tas aizņem vairāk nekā minūti, jāuzlabo taksonomija vai marķējums, nevis jāraksta vēl vairāk rakstu.

Kā izvēlēties īsto zināšanu bāzes rīku, nepārlieku sarežģījot izvēli

Īstā zināšanu bāzes rīka izvēle, nepārlieku sarežģījot izvēli, pārskata diagramma

Rīka izvēle paralizē daudzas komandas. Risinājums ir īss kontrolsaraksts un skaidra izpratne par to, kas jūsu komandas izmēram ir obligāti nepieciešams un kas būtu tikai patīkams papildinājums.

Izvērtējiet katru kandidātu zināšanu pārvaldības platformu, izmantojot šo kontrolsarakstu:

  • Meklēšanas kvalitāte, tostarp drukas kļūdu tolerance un sinonīmu atpazīšana, ne tikai precīza atslēgvārdu sakritība.
  • SSO un detalizētas atļaujas, lai sensitīvas personālvadības vai finanšu lapas nebūtu redzamas visiem.
  • Integrācija ar Slack vai Microsoft Teams, lai atbildes parādītos vietā, kur cilvēki jau sarunājas.
  • API vai kvalitatīva eksporta iespēja, īpaši, ja vēlāk plānojat pieslēgt AI asistentus.
  • Analītika, kas parāda, kuri raksti tiek skatīti, kuri meklējumi nedod rezultātu un kur cilvēki pārtrauc meklēt.
  • Ērta redaktora pieredze, jo neērts rakstīšanas rīks garantē mazāku ieguldījumu.
  • Satura atbildības funkcijas, piemēram, piešķirami pārskatītāji un redzami pēdējās atjaunināšanas datumi.

Novērtējiet katru kandidātu atbilstoši savai komandai, nevis vispārīgam funkciju sarakstam:

  1. Mazas komandas (mazāk nekā 30 cilvēku): meklēšana, atļaujas un redaktora lietošanas ērtums ir obligāti nepieciešami. Padziļināta analītika un API piekļuve ir patīkams papildinājums.
  2. Vidēja lieluma uzņēmumu komandas: obligāti nepieciešamo funkciju sarakstam pievienojiet Slack vai Teams integrāciju un pamata analītiku.
  3. Lielu uzņēmumu komandas: API piekļuve, SSO un detalizētas atļaujas no patīkamiem papildinājumiem kļūst par obligātām funkcijām, jo atbilstība prasībām un mērogošana tās pieprasa.

Salīdzinot produktus, pārbaudiet meklēšanas kvalitāti un administratora vadīklas ar savu saturu un atļauju modeli, nevis paļaujieties uz pārdošanas lapas funkciju saraksta garumu. Ja nākotnē plānojat pievienot AI, dodiet priekšroku rīkiem, kas piedāvā markdown vai kvalitatīvu API, jo strukturētu saturu izguves sistēmām ir vieglāk konsekventi izmantot nekā nekonsekventi formatētu materiālu kaudzi.

Kā panākt, lai atbildes patiešām būtu atrodamas

Zināšanu bāze, kuru neviens nevar atrast, ir tikai dokumentu skapis ar labāku zīmolu. Atrodamība ir joma, kurā lielākā daļa iekšējās dokumentācijas rīku nemanāmi cieš neveiksmi, taču to var novērst ar dažiem konkrētiem paradumiem.

Veidojiet atzīmes atbilstoši tam, kā cilvēki patiešām meklē, nevis tam, kā jūs rakstītu formālu virsrakstu. Ja jūsu norēķinu politikas raksta nosaukums ir “Debitoru parādu procedūras”, bet visi meklē “kā saņemt atmaksu”, pievienojiet šo frāzi kā alternatīvu nosaukumu. Iekļaujiet arī biežākās drukas kļūdas un saīsinājumus. Pēc tam nogādājiet saturu ārpus pašas zināšanu bāzes meklēšanas joslas un tajos rīkos, ko cilvēki ikdienā izmanto, piemēram, Slack robotā, kas atbild tieši no zināšanu bāzes rakstiem, vai logrīkā jūsu pieteikumu pārvaldības sistēmā.

Uzturiet augstākā līmeņa taksonomiju organizētu pēc funkcijām, katrā kategorijā konsekventi izmantojiet vienu un to pašu raksta veidu un izdzēsiet dublētās lapas, tiklīdz tās pamanāt; divas vienas politikas versijas, kas sniedz nedaudz atšķirīgas atbildes, ir sliktāk nekā vispār neesoša lapa.

Trīs rādītāji parāda, vai meklēšana patiešām darbojas:

  • Nulles rezultātu īpatsvars: cik bieži meklēšana nedod nevienu rezultātu, signalizējot par trūkstošu saturu vai sliktu marķējumu.
  • Pāreju no meklēšanas uz rakstu īpatsvars: vai cilvēki noklikšķina uz rezultāta vai padodas un tā vietā jautā citam cilvēkam.
  • Laiks līdz pirmajai atbildei Slack vai tērzēšanas rīkā, nosakot, vai automatizēta vai no zināšanu bāzes iegūta atbilde pārspēj cilvēka atbildi.

Ja nulles rezultātu īpatsvars pieaug, vispirms tā ir taksonomijas un marķējuma, nevis satura problēma. Tas saistīts ar iepriekš minēto par atrodamību: gandrīz puse darbinieku jau ziņo par grūtībām atrast informāciju, tāpēc augsts nulles rezultātu īpatsvars jūsu zināšanu bāzes meklēšanā nozīmē, ka tā pati kļūme notiek rīkā, kas paredzēts tās novēršanai.

Kā ilgtermiņā uzturēt zināšanu bāzes uzticamību

Zināšanu bāze sāk novecot tajā brīdī, kad vairs nav neviena, kas par to rūpētos. Pārvaldība atšķir zināšanu bāzi, kas ir noderīga arī otrajā gadā, no tādas, kas klusi pārvēršas par novecojušu ekrānuzņēmumu kapsētu.

Skaidri definējiet trīs lomas:

  • Par katru kategoriju tieši atbildīga persona (DRI) — tas pats konkrēti nosauktais atbildīgais no taksonomijas posma, kurš atbild par precizitāti.
  • Redaktori, kuri var atjaunināt saturu, neprasot DRI apstiprinājumu nelieliem labojumiem.
  • Pārskatītāji, kuri pārbauda precizitāti pēc noteikta grafika, nevis gaida, kad kāds pamanīs problēmu.

Dažas komandas, zināšanu bāzei pārsniedzot dažus simtus rakstu, izveido zināšanu darbības komiteju, taču lielākajai daļai organizāciju skaidri noteikts DRI katrai kategorijai ir pietiekama struktūra, lai sāktu.

Nosakiet pārskatīšanas regularitāti katram rakstam, ne tikai palaišanas datumu. Lielākajai daļai operatīvā satura labi darbojas 90 dienu pārskatīšanas cikls: katram rakstam ir lauks “pēdējoreiz pārskatīts”, un viss, kas 90 dienas nav pārskatīts, tiek atzīmēts tā DRI. Saturam, kas saistīts ar politikas izmaiņām, veiciet tūlītēju pārskatīšanu ārpus cikla, nevis gaidiet paredzēto datumu.

  1. Sekojiet to rakstu procentuālajam īpatsvaram, kuriem beidzies pārskatīšanas termiņš, lai pamanītu nolaidību, pirms to pamana lasītāji.
  2. Sekojiet to meklējumu procentuālajam īpatsvaram, kas dod nulles rezultātu, lai pamanītu satura nepilnības.
  3. Sekojiet ieviešanai, proti, unikālo apmeklētāju un skatījumu skaitam uz rakstu, lai redzētu, kas patiešām tiek izmantots.
  4. Sekojiet laika līdz atbildei uzlabojumiem, salīdzinot, cik ilgs laiks bija nepieciešams jautājuma atrisināšanai pirms un pēc zināšanu bāzes izveides.

Profesionāļa padoms: Norādiet “pēdējoreiz pārskatīts” datumu tieši pašā rakstā, lai tas būtu redzams lasītājiem, nevis paslēpts administratora panelī. Redzams datums veido uzticēšanos; tā neesamība to klusi grauj.

Kā izmantot AI, neļaujot tam minēt

AI var būtiski paātrināt veidu, kā komanda izmanto savu zināšanu bāzi, taču tikai tad, ja to ierobežo atbilstoši drošības mehānismi. Ja to nekontrolē, AI asistents labprāt izdomās pārliecinoši skanošu atbildi, nevis atzīs, ka nezina.

Noderīgi lietojuma scenāriji ir konkrēti: tērzēšanas robots, kas atbild no kontrolēta apstiprinātu rakstu kopuma, ar AI sagatavotas atbildes, ko pirms nosūtīšanas pārskata cilvēks, saistītie raksti, kas lietotājam tiek parādīti pieteikuma izskatīšanas laikā, un BUJ ieteikumi, kas veidoti no pieteikumiem, kurus jūsu komanda jau ir atrisinājusi.

Nekas no tā nav drošs bez aizsargmehānismiem:

  • Atbildes, kas ierobežotas ar avotiem, lai AI izmantotu tikai apstiprinātu saturu, nevis atvērto internetu vai savus apmācības datus.
  • Cilvēka pārskatīšana un skaidras vadīklas, lai uzmetumi tiktu pārbaudīti pirms nosūtīšanas un automātiska nosūtīšana tiktu apzināti aktivizēta.
  • Žurnālfaili un audita izsekojamība, lai katru automātisko darbību varētu izsekot un vēlāk pārskatīt.
  • Pārliecības sliekšņi, lai atbildes ar zemu pārliecību tiktu nodotas cilvēkam, nevis izdomātas.

Profesionāļa padoms: Uztveriet sava AI asistenta precizitātes rādītāju tāpat kā jebkuru citu KPI. Katru nedēļu izlases veidā pārbaudiet tā atbildes, un, ja sāk parādīties nepatiesas atbildes, uztveriet to kā signālu atkārtoti indeksēt avota saturu, nevis turpināt virzīties uz priekšu.

Deskhero pieeja dzīvi uzturošai zināšanu bāzei

Noderīgs jebkura iekšējā zināšanu centra pārbaudes kritērijs ir tas, vai tas ir savienots ar darbu, kas notiek pieteikumos, nevis atrodas malā kā statiska wiki. Deskhero atrisinātie pieteikumi var palīdzēt izveidot ieteiktus publiskos BUJ ierakstus. Lietotājs pārskata un apstiprina katru ieteikumu, pirms to var izmantot klientiem paredzētais tērzēšanas robots vai AI automātiskās atbildes.

Pamata drošības mehānisms ir vienkāršs: Deskhero klientiem paredzētais tērzēšanas robots un AI automātiskās atbildes izmanto tikai apstiprinātos publiskos BUJ. Ja tērzēšanas robots nevar pārliecinoši atbildēt, tas pārslēdzas uz saziņas veidlapu.

Šo apstiprināšanas procesu atbalsta konkrēts vadīklu kopums, ko vērts meklēt jebkurā rīkā:

  • Cilvēka apstiprinājums nepieciešams, pirms ieteiktais BUJ ieraksts kļūst publisks.
  • Katras automātiskās darbības reģistrēšana, pievienojot marķējumu, lai nekas nenotiktu slepeni.
  • Klientu atbildes, kas ierobežotas ar avotiem, proti, tērzēšanas robots un AI automātiskās atbildes izmanto tikai apstiprinātos publiskos BUJ.
  • Izvēles vadīklas AI automātiskajām atbildēm katrai grupai un tērzēšanas robotam katram logrīkam.
  • Skaidrs aktivizēšanas slieksnis, jo tērzēšanas robotam nepieciešami vismaz 100 apstiprināti publisko BUJ ieraksti.

Deskhero šo procesu apvieno ar divvirzienu Gmail, Google Workspace un Microsoft 365 sinhronizāciju, visaptverošu REST API, Google un Microsoft SSO, kā arī 14 lietotāja saskarnes valodu atbalstu. Iekšējā zināšanu bāze un citas darbvietas zināšanas veido ieteikumu uzmetumus lietotājiem, savukārt apstiprinātie publiskie BUJ nodrošina klientiem paredzētā tērzēšanas robota un AI automātisko atbilžu darbību.

Slazdi, par kuriem neviens jūs nebrīdina

Daudzas zināšanu bāzes neveiksmes ir atbildības, nevis satura neveiksmes. Komandas var pavadīt nedēļas, rakstot rūpīgi izstrādātus rakstus, bet pēc tam ļaut bibliotēkai novecot, jo neviens vairs nav atbildīgs par atjauninājumiem.

Lielākais drauds ir konkrēti nosaukta atbildīgā trūkums. “Komanda” par neko neatbild; par lietām atbild konkrēta persona. Otrajā vietā ir pārmērīga migrācija: visu veco dokumentu pārnešana uz jauno sistēmu pirmajā dienā garantē, ka puse no tiem būs nepareiza, un lasītāji pārstās uzticēties visai zināšanu bāzei, tiklīdz sastaps novecojušu lapu. Trešais drauds ir pārmērīga kategorizēšana — sarežģītas taksonomijas izveide, pirms jums ir pietiekami daudz satura, lai to pamatotu.

Uztveriet zināšanu bāzi kā infrastruktūru, kas jāuztur vienmēr, nevis projektu, kuru var pabeigt. Sāciet ar mazāku tvērumu, nekā šķiet ērti, pirmajā mēnesī izmēriet, vai cilvēki to patiešām izmanto, un pēc tam pielāgojiet to.

Izmēģiniet integrētu palīdzības dienestu ar iebūvētu zināšanu bāzi

Ja apsverat, vai pievienot AI savai esošajai wiki vai jau no pirmās dienas sākt ar rīku, kas paredzēts abu elementu savienošanai, Deskhero ļauj izlaist papildu savienošanas posmu. Tas pārvērš jūsu esošo Gmail, Google Workspace vai Microsoft 365 pastkasti par palīdzības dienestu ar pieteikumiem, kurā ir iekšējā zināšanu bāze lietotājiem paredzētiem ieteikumu uzmetumiem un AI tērzēšanas robots, kas atbild tikai no apstiprinātajiem publiskajiem BUJ.

Deskhero

Nav nepieciešama e-pasta migrācija vai jaunas adreses pārvaldība. Klientu jautājumi kā pieteikumi nonāk koplietotā iesūtnē, un atrisinātās sarunas var palīdzēt izveidot ieteiktus publiskos BUJ ierakstus. Pēc tam, kad lietotājs tos apstiprina, šie BUJ ieraksti var nodrošināt tīmekļa vietnes tērzēšanas robota un AI automātisko atbilžu darbību. Iekšējā zināšanu bāze un citas darbvietas zināšanas palīdz sagatavot atbilžu uzmetumus lietotāju pārskatīšanai. Automātiskās darbības tiek reģistrētas un marķētas, savukārt pilnībā automātiskām klientu atbildēm nepieciešama skaidra izvēles aktivizēšana. Ja izvērtējat zināšanu bāzes programmatūru mazai vai vidēja lieluma atbalsta komandai, sāciet 30 dienu bezmaksas izmēģinājumu vietnē Deskhero — kredītkarte nav nepieciešama.

Avoti

BUJ

Kas ir iekšējā zināšanu bāze?

Tā ir centralizēta, meklējama uzņēmuma informācijas krātuve, kurā ietvertas procedūras, politikas, ievadīšanas darbā soļi un iepriekš pieņemtie lēmumi, lai darbinieki varētu paši atrast atbildes, nevis jautāt kolēģim.

Kādi ir daži iekšējo zināšanu bāzu piemēri?

Parasti piemēri ir IT palīdzības centrs paroļu atiestatīšanai un piekļuves pieprasījumiem, personālvadības politiku centrs pabalstiem un apmaksātam brīvajam laikam, inženierijas rīcības rokasgrāmatu bibliotēka incidentu novēršanai un pārdošanas atbalsta wiki prezentācijām un iebildumu apstrādei.

Kāds ir zināšanu pārvaldības sistēmas piemērs?

Platforma, kas apvieno meklējamu satura bibliotēku ar kategorizēšanu, analītiku un lietotāju atsauksmēm, ir uzskatāma par zināšanu pārvaldības sistēmu. Deskhero paplašina šo modeli, savienojot iekšējo zināšanu bāzi un apstiprinātos publiskos BUJ ierakstus ar palīdzības dienestu, kurā tiek pārvaldīti pieteikumi. Tā tērzēšanas robots atbild tikai no apstiprinātajiem publiskajiem BUJ.

Kā vēl sauc zināšanu bāzi?

Atkarībā no piegādātāja vai komandas, kas to izmanto, to mēdz dēvēt arī par uzņēmuma wiki, iekšējās dokumentācijas sistēmu, darbinieku zināšanu datubāzi vai zināšanu pārvaldības platformu.