Hogyan építsünk tudásbázist 30 nap alatt: struktúra, források, felelősök — és a tudásbázis, amely abból nő ki, amit a csapat már elmond (2026)

A tudásbázis azoknak a válaszoknak a halmaza, amelyeket egy szervezet egynél többször ad meg, egyszer leírva, és ott tartva, ahol az, akinek szüksége van a válaszra, megtalálja anélkül, hogy kérdezősködnie kellene. „Hogyan számlázunk egy svájci forgalmazónak?", „mit mondunk annak a szülőnek, akinek a gyereke lekéste a határidőt?", „melyik fuvarozóval szállítsunk raklapokat Marokkóba?" — amikor ezek bármelyikét negyedszer kérdezik meg, a szervezetnek van tudásbázisa, akár építette, akár nem. Csak éppen egyetlen kolléga fejében és egy tucat csevegési szálban él.

A legtöbb útmutató a szoftver kiválasztásával kezdi. Ez korábban indul, mert a szoftver a legkisebb dolog: a tudásbázis három döntés — egy struktúra, a források egy köre és egy név minden bejegyzésen —, és egy hónap, amely alatt ezeket sorrendben meghozzuk. Az alábbi 30 napos terv egy 10–200 fős szervezetet eljuttat egy olyan tudásbázishoz, amelyet az emberek valóban megnyitnak. Hozzátartozik egy lemásolható bejegyzéssablon, egy kidolgozott példa, egy táblázat arról, hogy hol él a tudásbázis a csapat által már használt eszközökben, majd az a rész, amelyet a legtöbb útmutató kihagy: a tudásbázis nagyrészt már meg van írva, abban, amit a csapat a megbeszéléseken mond és a csevegésekben begépel, a feladat pedig az, hogy ezt egy helyen tartsuk, a csapat minden tagja számára olvashatóan.

Mi a tudásbázis — és mi nem az

Négy dolgot neveznek tudásbázisnak, és a köztük lévő összekeverés az oka annak, hogy olyan sokat építenek, és olyan keveset használnak:

A tudásbázis az első sor, és függ a másik háromtól. A wiki az, amivé struktúra nélkül válik; a dokumentumtár az, ahol a fájljai élnek; a csevegési előzmények pedig az a hely, ahol a bejegyzései többségét először megírják, véletlenül, válaszként. A mesterség abban áll, hogy egy választ a negyedik sorból az elsőbe mozgatunk — egyszer, névvel ellátva —, és az alábbi módszer erre a mozdulatra épül.

Építés előtt még két megkülönböztetés számít. A belső tudásbázis a csapatnak szól: hogyan csináljuk a dolgokat, hol vannak a dolgok, mit döntöttünk. A külső az ügyfeleknek: hogyan működik a termék, mit tegyenek, ha valami meghibásodik. Ez az útmutató a belsőről szól; a külső bázist később a belsőből írják meg, azoknak a bejegyzéseknek az átírásával, amelyeket az ügyfelek láthatnak. A tudásbázis továbbá nem folyamatleírás és nem SOP: ezek egy egész munkát írnak le az elejétől a végéig; a bejegyzés egy kérdésre válaszol, és ha a válasz az, hogy „kövesse az eljárást", akkor az eljárásra hivatkozik.

A három döntés: struktúra, források, felelősség

Struktúra: kérdések szerint, nem részlegek szerint. Aki azt kérdezi, „hogyan számlázunk Svájcba?", nem tudja, hogy a válasz a pénzügyhöz, az értékesítéshez vagy a logisztikához tartozik-e; a kérdést tudja. A részlegek szerint szervezett bázis három szekcióba küldi, hogy egy választ megtaláljon. Szervezze az embereket foglalkoztató kérdések szerint — az ő szavaikkal —, és a felső szintet tartsa hét szekcióban vagy kevesebben. Hét fölött maga a struktúra igényel keresőt, és a keresés egy olyan bázison, amelyet még senki nem töltött fel, semmit nem ad vissza. Egy kisebb szervezet tipikus felső szintjei: ügyfelek és megrendelések; pénz és számlázás; emberek és felvétel; eszközök és hozzáférés; szabályok és döntések; kit hívjunk.

Források: ami már létezik, mielőtt bármi új készülne. Senkinek nincs ideje tudásbázist írni üres lapról, és nincs is rá szükség. A válaszok léteznek — abban a válaszban, amelyet egy kolléga múlt kedden adott, annak a megbeszélésnek az összefoglalójában, ahol a szabályt megalkották, abban az árlistában, amelyet valaki márciusban csatolt egy üzenethez, az utolsó új munkatárs bevezetési jegyzeteiben. A legtöbb bejegyzés első változatát másolják, nem írják. Hogy hol élnek a források, és mennyi érhető el belőlük később, az lejjebb a táblázat tárgya; a rövid változat az, hogy a legtöbb csomagban a csevegés, a fájlok és a megbeszélési jegyzetek három külön hely, a megbeszélés maga pedig az, amelyik a legkevesebbet hagyja maga után.

Felelősség: név és dátum minden bejegyzésen. Az az egyetlen dolog, ami a megbízható tudásbázist elválasztja attól, amelyet az emberek már nem nyitnak meg, az, hogy a bejegyzés megmondja, ki a felelőse, és mikor ellenőrizték utoljára. Egy névvel és „felülvizsgálva 2026. október 14." megjegyzéssel ellátott bejegyzésnek hisznek; ugyanaz a szöveg ezek nélkül „valószínűleg elavult". A felelős dolga kicsi: negyedévente megválaszolni, hogy „ez még mindig helyes?", és átírni a dátumot. Nem a bázis újraírása. Ha egy bejegyzéshez senkit sem lehet megnevezni, a bejegyzés nem tudás, hanem találgatás, és kikerül.

Hogyan építsünk tudásbázist 30 nap alatt

A terv azt feltételezi, hogy egy ember viszi — a csapatvezető, vagy aki a legtöbb kérdést kapja —, heti körülbelül két órát fordítva rá, a csapat többi tagja pedig perceket.

1. hét — a kérdéseket gyűjtsük, ne a válaszokat. Nyisson egy csatornát, vagy egy jegyzetet egy meglévőben, és hét napon át mindenki dobja be minden kérdését, amelyet egy kollégától kérdezett, vagy amelyet neki tettek fel, a használt szavakkal. Válaszok még nincsenek. Péntekre negyven-nyolcvan kérdés lesz; egyharmada ismétlődés. Számolja meg az ismétlődéseket: az ötször feltett kérdés az első bejegyzés. Az előző napon eldől, hogy hol él a lista, ott fog élni a bázis is; a helyet itt döntik el azzal, amit a csapat naponta amúgy is megnyit, nem szoftverösszehasonlítással.

2. hét — a struktúra és a felelősök. Csoportosítsa a kérdéseket; a csoportok a szekciók, és legfeljebb hét van belőlük. Nevezzen meg egy felelőst szekciónként — azt, aki az 1. héten a kérdései többségére válaszolt. Aztán nevezzen meg egy felelőst bejegyzésenként a húsz leggyakoribb kérdéshez. Még semmit ne írjon, csak a listát: szekció, kérdés, felelős. Küldje el a csapatnak, és kérdezzen egyet: „mely kérdések hiányoznak?" A lista tíz újabbal jön vissza.

3. hét — az első húsz bejegyzés, forrásokból. Minden felelős megírja a bejegyzéseit az alábbi sablonnal, abból kiindulva, ami már létezik: a csevegésbeli válaszból, az összefoglalóból, a fájlból. A 3. hét szabálya: „a rövid és igaz többet ér a hosszú és teljes válasznál": a kétmondatos válasz, a fájlra mutató linkkel, keltezve és aláírva, bejegyzés. Az az oldal, amely a szabály történetét magyarázza, dokumentum, és ráér később. Azok a bejegyzések, amelyek olyan döntéstől függenek, amelyet senki sem talál, előbb a döntési naplóba kerülnek, aztán linkkel a bázisba.

4. hét — publikálás, majd a ciklus futtatása. Tűzze ki a bázist oda, ahol a csapat olvas. Aztán alakítsa ki a két szokást, amely életben tartja: a kérdéscsatornában ezentúl minden feltett kérdés kap egy bejegyzést vagy egy linket egyhez, amelyet az ír meg, aki válaszolt; és minden bejegyzés felelőse megkapja a felülvizsgálat dátumát a naptárába. A 30. nap nem kész bázis. Húsz-harminc bejegyzés, mindegyiknek van felelőse és dátuma, és egy ciklus, amely hozzátesz egyet, valahányszor megválaszolnak egy kérdést. Hat hónap múlva kétszáz van belőle, és senki sem írta projektként.

Ami a 30 nap alatt nem történik meg: a dokumentumtár átköltöztetése, új eszköz választása, vagy oldal írása minden folyamathoz. A bázis a fájlokra mutat, ahol azok vannak, és az eljárásokra, ahol azok élnek. Az áthelyezésük külön projekt, és gyakran felesleges.

Tudásbázis-cikk sablon

Egy bejegyzés, egy kérdés, egy oldalnál rövidebb. Másolja át jegyzetként, és töltse ki; a leggyakrabban kihagyott sorok az utolsó három, és ezek tartják igazan a bejegyzést.

[Kérdés, azokkal a szavakkal, amelyekkel az emberek felteszik]
Felelős: [név] · Szekció: [a hét egyike] · Utoljára felülvizsgálva: [dátum] · Következő felülvizsgálat: [dátum]
Rövid válasz: [két mondat — mit kell tenni]
Érvényes: [csapat, iroda, ügyféltípus] · Nem érvényes: [az az eset, amellyel az emberek összekeverik]
Hogyan: [számozott lépések, mindegyik megnevezi az érintett rendszert, személyt vagy fájlt]
A mögötte álló szabály: [a döntés, amely megalkotta, a dátumával, és hogy miért]
Kivételek: [a megszokott úttól eltérő esetek, és hogy ki dönt mindegyikről]
Hol vannak a fájlok: [link az aktuális sablonra, árlistára, szerződésre]
Kapcsolódó bejegyzések: [az SOP, a folyamat, az előző verzió]

A sablon egyszerű szöveg félkövér címkékkel, így átformázás nélkül beilleszthető Word-fájlba, Google Docba, wikioldalra, Slack canvasba vagy csevegési jegyzetbe.

Kidolgozott példa: egy exportőr tudásbázisa 30 nap után

Egy olasz gépgyártó exportőr, 38 fő, értékesítési iroda Milánóban, forgalmazók Spanyolországban, Romániában és Marokkóban. Az 1. hét 61 kérdést hozott; az ismétlődések után 44-et. A belőlük kialakult struktúra, a 30. napi bejegyzésszámokkal szekciónként:

1. Forgalmazók és megrendelések (7) — hogyan állítanak be egy új forgalmazót; ki hagyja jóvá a hitelkeretet; mire van szüksége egy megrendelésnek, mielőtt a gyártásba kerül
2. Számlázás és fizetés (5) — számlázás egy svájci forgalmazónak; mikor használnak díjbekérőt; mit kell tenni, ha egy fizetés 30 napot késik
3. Szállítás és vám (6) — fuvarozók célország szerint; a Marokkóba tartó raklaphoz szükséges dokumentumok; ki írja alá az exportvámnyilatkozatot
4. Szerviz és garancia (4) — mire terjed ki a garancia; hogyan foglalnak szervizlátogatást; mely alkatrészeket tartják raktáron
5. Eszközök és hozzáférés (3) — ki ad hozzáférést a CRM-hez; hol van az árlista; hogyan érhető el a közös postafiók
6. Szabályok és döntések (3) — a kétaláírásos szabály 10 000 felett; a kedvezményplafon; a döntési napló
7. Kit hívjunk (2) — a vámügynök; a fuvarozók elérhetőségei országonként

Harminc bejegyzés. Az 1. hét leggyakoribb kérdésére — „milyen dokumentumok kellenek egy Marokkóba tartó raklaphoz?" — egy év alatt tizenegyszer válaszolt a csatornában ugyanaz a logisztikai vezető; a bejegyzés húsz percébe került, mert a tizenegyedik válasz már meg volt írva, és csak a felelős sorra és a dátumra volt szüksége.

Egy kitöltött bejegyzés a 3. szekcióból:

Milyen dokumentumok kellenek egy Marokkóba tartó raklaphoz?
Felelős: Logisztikai vezető · Szekció: Szállítás és vám · Utoljára felülvizsgálva: 2026. november 3. · Következő felülvizsgálat: 2027. február 3.
Rövid válasz: Kereskedelmi számla három példányban, csomagolási lista, EUR.1 igazolás, és a forgalmazó importengedélyének száma a számlán.
Érvényes: minden szállítmányra a marokkói forgalmazóknak · Nem érvényes: 1 000 EUR alatti, futárral küldött alkatrészekre, amelyek a futár saját űrlapjával mennek.
Hogyan: 1. Exportálja a számlát a rendszerből a marokkói sablonnal. 2. Adja hozzá az engedély számát a forgalmazó aktájából. 3. Kérje az EUR.1-et a kereskedelmi kamarától, három munkanap. 4. Csatolja a csomagolási listát. 5. Küldje el a készletet a vámügynöknek, és másolatot a forgalmazónak.
A mögötte álló szabály: Az engedély számát a 2026. márciusi casablancai feltartóztatás után adták hozzá (döntési naplóbejegyzés: 2026-03-19).
Kivételek: A bemutatógépek ideiglenes behozatal alatt mennek; a logisztikai vezető dönt.
Hol vannak a fájlok: Marokkói számlasablon; EUR.1 igénylőlap; forgalmazói aktákat.
Kapcsolódó bejegyzések: Fuvarozók célország szerint; ki írja alá az exportvámnyilatkozatot.

Hol él a tudásbázis a már használt eszközökben

Egy 10–200 fős szervezet a bázisát abban a csomagban építi, amelyért már fizet, és minden csomagban van hely a bejegyzésnek, hely a fájloknak, és út ahhoz, amit egy megbeszélés maga után hagy. Mindegyik más ponton áll meg, és mindegyikben a rögzített anyag azon a nyelven van, amelyen beírták. Csak dokumentált működés, a gyártók saját oldalairól, az egyes oldalak ellenőrzésének hónapjával:

Mind a négyben három dolog azonos. A bejegyzés egy dokumentum vagy üzenet azon az egy nyelven, amelyen beírták, és az a tag, aki más nyelven olvas, ezt olvassa, vagy egy másolatot, amelyet valaki készített. A fájlok egy második helyen vannak, egy második kereséssel találhatók meg. És a megbeszélés — ahol a szabályt megvitatták és megalkották — csak akkor kerül a bázisba, ha valaki utólag begépeli: hogy a Teams és a Meet hol őriz egyáltalán átiratot és összefoglalót, és hogyan tarthatók meg a hívás után, azt a hol tárolja a Microsoft Teams és a Google Meet az átiratot, a felvételt és az összefoglalót cikk mutatja; az AI-jegyzetelőket, amelyeket sok csapat ugyanezért ad hozzá, az Otter.ai alternatívák hasonlítja össze, és mindegyikük egy nyelven írja az összefoglalóját.

A fordítás, amelyet ezek a csomagok dokumentálnak, a híváshoz vagy az olvasó képernyőjéhez tartozik, nem a rögzített anyaghoz: a Microsoft dokumentálja a lefordított élő feliratokat a Teams-megbeszéléseken, ha a szervező Teams Premium vagy Microsoft 365 Copilot licenccel rendelkezik, a Google dokumentálja a lefordított feliratokat a Meetben a jogosult Workspace-csomagokon (mindkettő ellenőrizve: 2026. augusztus), a WhatsApp pedig a kapott üzenet fordítását az olvasó telefonján (ellenőrizve: 2026. augusztus) — hogy mindegyik mit fed le, és hol áll meg, azt a Microsoft Teams élő fordítás, a Google Meet élő fordítás és a WhatsApp fordítás mutatja. A bejegyzés, amelyet a casablancai forgalmazó ügyintézője hétfőn megnyit, külön tárgy ezektől a feliratoktól, és azon a nyelven olvassa, amelyen beírták.

A tudásbázis, amely abból nő ki, amit a csapat már elmond

Az InterMIND egy kommunikációs tér, ahol a csapat munkája egy csatornában él, így a tudásbázisnak kézenfekvő otthona van: az azt használó csapat csatornája — az exportcsapaté, a klinika recepciójáé, az ügynökség ügyfélcsoportjáé —, és ez a csatorna egyben a kérdéscsatorna és az a hely is, ahonnan a megbeszélések indulnak. A fenti három döntés közvetlenül rávetíthető.

A struktúra és a felelősség maguk a bejegyzések. Jegyzetként közzétéve — egy formázott szövegű üzenet címsorokkal és számozott listákkal, amelyet később a saját menüjéből szerkesztenek — a bejegyzést minden tag a saját nyelvén olvassa, az eredeti egy kapcsolóval elérhető, és kitűzve áll, így az aktuális változat az első, amit egy új kolléga megtalál; bekapcsolt szerkesztési előzmények mellett egy megváltozott szabály korábbi szövege az aktuális szöveg fölött jelenik meg szószintű különbségként, időbélyeggel, és ez az a felülvizsgálati nyom, amelyre a felelős „utoljára felülvizsgálva" sora mutat. A fájlok, amelyekre a bejegyzés mutat — az árlista, a marokkói sablon, a forgalmazói szerződés —, ugyanabba a csatornába kerülnek feltöltésre, és minden csomagon AI-összefoglalót kapnak az olvasó nyelvén, minden pont a bekezdéshez linkelve, ahonnan származik; a fizetős csomagokon maga a fájl az olvasó nyelvére lefordítva nyílik meg (30 nyelv dokumentumokhoz). Ha a mesterpéldány egy dokumentumeszközben marad, a frissítései e-mailben érkeznek a csatornába: a csatorna házigazdája saját címet ad neki, és az oda küldött üzenet szabályos üzenetként jelenik meg, a feladó megnevezésével és a csatolmányok megtartásával. A Slackből érkező csapat magával hozza a csatornáit: a Slack szabványos munkaterület-exportja Slack-csatornánként egy csatornaként áll vissza, az üzenetek sorrendben, eredeti időbélyegekkel, a kitűzések és reakciók megtartva, minden üzenetet minden tag a saját nyelvén olvas.

A források ott vannak, ahol a csatorna elvégzi azt a munkát, amelyet a fenti táblázat egy emberre hagy. A megbeszélés, ahol a szabályt megalkotják, a csatornából indul; a hívás alatt a bejegyzéstervezet mindenki képernyőjére kerül a videócsempék mellé a Share to conference funkcióval — egy jegyzet, vagy egy Google Docs- vagy OneDrive-dokumentum, amelyet a csevegésben linkeltek —, és minden résztvevő egymástól függetlenül görgeti, és a saját nyelvén olvassa, miközben a megosztó élőben szerkeszti. Amikor a hívás véget ér, az összefoglaló magából a megbeszélésből készül — egy összegzés, az egyezettnek, nyitottnak vagy vitatottnak jelölt pontok, a feladatok felelősökkel, minden sor megtartva az időbélyegét —, és az ülés alatt megosztott dokumentumok összefoglalói a elhangzottak mellett szerepelnek. E-mailben érkezik, üzenetként a csatornában és linkként a naptáresemény­ben, és minden bejelentkezett tag a saját nyelvén olvassa: a rögzített anyagot olvasónként fordítják, nem egyszer írják meg azon a nyelven, amelyet a terem történetesen használt. Bármelyik tag szerkesztheti, minden szerkesztés megtartja a szerzőt és a változatelőzményeket, és a csatorna megőrzi minden korábbi ülés összefoglalóját — így a megbeszélés, amely a marokkói szabályt megalkotta, egy kattintásra van a bejegyzéstől, amely kimondja. Ez az, amikor a bázis abból nő ki, amit a csapat már elmond: a tizenegyedik válasz a csatornában, a hívás összefoglalója, ahol a szabályt megvitatták, a márciusban csatolt fájl, mind egy helyen, a bejegyzéssel a tetejükön.

A kérdéscsatorna a másik irányból kapja ugyanezt a kezelést. A tag saját asszisztense — Claude, ChatGPT, Copilot vagy Gemini, az MCP-összekötőn keresztül csatlakoztatva — egyetlen kérdéssel keres az összefoglalókban, átiratokban, csevegésekben és a megosztott fájlok szövegében, „milyen dokumentumok kellenek egy Marokkóba tartó raklaphoz?", és visszaadja a részleteket, megjelölve a megbeszélést, a dátumot és a fájlt, amelyből mindegyik származik; ez a bekapcsolt AI-funkciókkal rendelkező szervezeteknél működik, és az asszisztensen keresztüli olvasás azokra a megbeszélésekre és csatornákra korlátozódik, amelyekben a tag részt vesz. Magának a csevegésnek van keresője, és a bázis egészben kivihető: minden csomagon a Beállításokból készített biztonsági mentés ZIP-fájlként exportálja a csatornákat az üzeneteikkel, átirataikkal és fájljaikkal, ami a tulajdonlás kérdésének megválaszolása a szervezet szintjén, nem a bejegyzés szintjén. A fenti táblázat mellé téve a különbség egyszerű ténymegállapítás: a feliratok, amelyeket ezek a csomagok dokumentálnak, a hívást fordítják, amíg az zajlik; itt a bejegyzés, a megbeszélések, amelyek létrehozták, a fájljai és az előzményei egyetlen rögzített anyag, amelyet minden tag a saját nyelvén olvas.

Azok, akik egy csapat tudását őrzik, nem mindig alkalmazottak. A forgalmazó megrendelés-ügyintézője, a vámügynök, a szabadúszó könyvelő, aki ismeri a svájci szabályt: a csatorna külső tagja e-mailben csatlakozik egy ingyenes fiókkal, és úgy olvassa a bejegyzéseket és azok előzményeit, mint mindenki más; a fiók nélküli személy egy megbeszélés vendége — linkkel csatlakozik a híváshoz, telefonról, költség nélkül, élőben hallja a saját nyelvén, és utána nem kap rögzített anyagot. A házigazda biztosítja a teret, és fizetős csomagon csak a az előző 28 napban aktív tagokért fizet — aki csatlakozott egy megbeszéléshez, írt egy csevegésben vagy kérdezett az asszisztenstől; azok a tagok, akik elcsendesednek, költség nélkül megtartják a hozzáférésüket, és erre van szüksége egy tudásbázisnak: aki két éve megírta a bejegyzést, még mindig a csatornában lehet.

• Nyisson meg egy teljes összefoglalót — valódi rögzített anyag, ugyanazzal a kóddal megjelenítve, amely a sajátját írja.
• Próbálja ki az élő demót — regisztráció nélkül; beszéljen, és hallja, ahogy a termet hallgatónként lefordítják.

A tudásbázis-építés mint mesterség minden eszközt túlél: valakinek még mindig össze kell gyűjtenie a kérdéseket, a struktúrát hét szekcióra kell korlátoznia, nevet és dátumot kell tennie minden bejegyzésre, és a csatornában kell válaszolnia a közvetlen üzenet helyett. Amit nem kell túlélnie, az a második munka — annak újragépelése a bázisba, amit a megbeszélés eldöntött, és minden bejegyzés lefordított másolatának kézi vezetése, egyszerre egy nyelven, annak az irodának, amelyik a másikat olvassa.

GYIK

Mi az a tudásbázis?

A tudásbázis olyan válaszok gyűjteménye, amelyek azokra a kérdésekre szólnak, amelyeket egy szervezetnek egynél többször feltesznek, egyszer leírva, mindegyik felelőssel és dátummal, és ott tartva, ahol az, akinek szüksége van a válaszra, megtalálja anélkül, hogy egy kollégát kellene kérdeznie. A belső tudásbázis a csapat saját kérdéseire válaszol — hogyan számlázunk, hol vannak a fájlok, mit döntöttünk; a külső az ügyfelek termékkel kapcsolatos kérdéseire. A wikitől abban különbözik, hogy van struktúrája és felelősei, a dokumentumtártól pedig abban, hogy válaszokat tartalmaz, nem fájlokat.

Hogyan hozzunk létre tudásbázist?

Gyűjtse egy héten át azokat a kérdéseket, amelyeket a csapat ténylegesen feltesz, a használt szavakkal; csoportosítsa őket legfeljebb hét szekcióba; nevezzen meg egy felelőst minden szekcióhoz és a húsz leggyakoribb kérdés mindegyikéhez; a felelősök írják meg ezeket a bejegyzéseket abból, ami már létezik — csevegésbeli válaszok, megbeszélési összefoglalók, fájlok —, egy egyoldalas sablonnal, amelyben rövid válasz, lépések, kivételek és felülvizsgálati dátum szerepel; publikáljon ott, ahol a csapat amúgy is olvas; majd tartsa futva a ciklust, amelyben minden megválaszolt kérdésből bejegyzés lesz, és minden bejegyzés felelőse a dátumán felülvizsgálja.

Mit tartalmazzon egy tudásbázis?

Kérdésenként egy bejegyzést, mindegyikben a kérdést az emberek által használt szavakkal, a felelőst, az utolsó felülvizsgálat dátumát és a következő felülvizsgálat dátumát, egy rövid választ, azokat az eseteket, amelyekre érvényes és amelyekre nem, a rendszert vagy személyt megnevező lépéseket, a szabály mögötti döntést a dátumával, a kivételeket és azt, hogy ki dönt róluk, linkeket az aktuális fájlokra, és linkeket a kapcsolódó bejegyzésekre. A bázis egészének hét vagy kevesebb szekcióból álló struktúrára van szüksége, a feltett kérdések szerint szervezve, nem részlegek szerint.

Mi a különbség a tudásbázis és a wiki között?

A wiki olyan oldalak halmaza, amelyeket bárki bármilyen struktúrában írhat; a tudásbázist az emberek által feltett kérdések szerint szervezik, kérdésenként egy bejegyzéssel, és mindegyiken megnevezett felelőssel és felülvizsgálati dátummal. A wikiből tudásbázist lehet csinálni a struktúra és a felelősök hozzáadásával; ezek nélkül a wiki több száz oldalra nő, amelyben senki sem tud eligazodni, és amelyet senki sem ellenőrzött. A szoftver gyakran ugyanaz; a különbség a két döntés.

Hogyan strukturáljunk egy tudásbázist?

Kérdések szerint, nem részlegek szerint: aki kérdez, nem tudja, melyik részleghez tartozik a válasz, de tudja, mit kérdez. Csoportosítsa az első héten összegyűjtött kérdéseket legfeljebb hét felső szintű szekcióba — egy kisebb szervezetnél tipikusan ügyfelek és megrendelések, pénz és számlázás, emberek és felvétel, eszközök és hozzáférés, szabályok és döntések, és kit hívjunk —, és minden bejegyzést tartson egy kérdésnél. Ha egy szekció körülbelül harminc bejegyzés fölé nő, ossza fel az emberek által feltett kérdések szerint, nem aszerint, hogy ki válaszol.

Mennyi ideig tart egy tudásbázis felépítése?

Harminc nap egy olyan bázishoz, amelyet az emberek megnyitnak: egy hét a kérdések gyűjtésével, egy hét a struktúrával és a felelősökkel, egy hét az első húsz bejegyzés megírásával meglévő forrásokból, egy hét a publikálással és a felülvizsgálati ciklus beállításával. A vezető heti körülbelül két órát fordít rá; minden felelős bejegyzésenként húsz percet, mert a legtöbb bejegyzés egy már megadott válasz másolata, nem újonnan írt. A bázis a 30. napon nem kész; minden alkalommal egy bejegyzéssel nő, amikor megválaszolnak egy kérdést.

Építhető tudásbázis ingyen?

Igen — az útmutatóban szereplő sablon egyszerű szöveg, és a bázis élhet egy jegyzetben, egy dokumentumban vagy egy csatornában a csapat által már használt eszközökben: egy Slack canvasban, egy Google Dokumentumban, egy Teams-csatorna Fájlok lapján, egy csevegésben kitűzött jegyzetben. Ami szoftverben nem kerül semmibe, az is kerül a felelősök felülvizsgálati idejébe, és a korlátok a csomag saját korlátai: a Slack Free csomagja 90 napnyi üzenetelőzményt őriz, és minden csomagban a bejegyzés azon a nyelven van, amelyen beírták. Az InterMINDban a Basic csomag ingyenes, a fizetős csomagok árai pedig az árazási oldalon találhatók.

Források: Microsoft Learn — Teams and SharePoint integration; Microsoft Learn — Learn about retention for Teams; Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Translate a message in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Slack — Pricing; Slack — Customize data retention in Slack; Slack — Export your workspace data; Slack — Meeting agenda template (canvas); Google Chat — Use Automatic Translation in Chat; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; WhatsApp — How to export your chat history; WhatsApp — Privacy policy; WhatsApp blog — Introducing message translations. A Microsoft Learn Teams–SharePoint oldalt 2026 novemberében ellenőriztük; a Teams-megőrzési és megbeszélési jegyzet oldalakat, a Slack canvas-sablon oldalt és a Google „Take notes for me" oldalt 2026 októberében; a Teams üzenetfordítási és feliratok oldalait, a Slack árazási, megőrzési és exportoldalait, a Google Chat fordítási és a Meet feliratok oldalait és a WhatsApp-oldalakat 2026 augusztusában. A gyártók idővel változtatják a csomagokat, a funkciókat és a nyelvlistákat; az aktuális állapotért nézze meg az oldalaikat.