Як створити базу знань за 30 днів: структура, джерела, відповідальні — і база, що виростає з того, що команда вже говорить (2026)

База знань — це набір відповідей, які організація дає не раз, записаних один раз і збережених там, де той, кому потрібна відповідь, може знайти її, нікого не питаючи. «Як виставити рахунок дистриб'ютору у Швейцарії?», «що сказати батькам, чия дитина пропустила дедлайн?», «який перевізник для палет до Марокко?» — коли будь-яке з цих питань звучить вчетверте, у організації вже є база знань, чи будувала вона її, чи ні. Просто вона живе в голові одного колеги й у десятках гілок чатів.

Більшість посібників із створення бази починаються з вибору програмного забезпечення. Цей починається раніше, бо софт тут — найменше: база знань — це три рішення (структура, набір джерел і ім'я на кожному записі) та місяць, щоб ухвалити їх по черзі. План на 30 днів нижче веде організацію на 10–200 людей до бази, яку люди справді відкривають: із шаблоном запису, який можна скопіювати, прикладом, таблицею того, де база живе в інструментах, якими команда вже користується, і з частиною, яку більшість посібників пропускає: база здебільшого вже написана — у тому, що команда каже на своїх зустрічах і набирає у своїх чатах, а завдання в тому, щоб зібрати це в одному місці, зрозумілому всій команді.

Що таке база знань — і чим вона не є

Базою знань називають чотири різні речі, і плутанина між ними — причина, чому так багато баз створено і так мало використовується:

База знань — це перший рядок, і вона залежить від решти трьох. Вікі — це те, чим вона стає без структури; бібліотека документів — це місце, де лежать її файли; історія чатів — це місце, де більшість її записів уперше з'являються, випадково, як відповіді. Майстерність полягає в тому, щоб перенести відповідь із четвертого рядка в перший — один раз, з іменем на ній, — і метод нижче побудований навколо цього переносу.

Перед створенням важливі ще два розрізнення. Внутрішня база знань призначена для команди: як ми робимо речі, де що лежить, що ми вирішили. Зовнішня — для клієнтів: як працює продукт, що робити, коли щось ламається. Цей посібник про внутрішню; зовнішню пізніше пишуть із внутрішньої, переписуючи записи, які клієнтам дозволено бачити. Крім того, база знань — не документ процесу і не SOP: вони описують усю роботу від початку до кінця, а запис відповідає на одне питання і веде до процедури, коли відповідь — «виконайте її».

Три рішення: структура, джерела, відповідальність

Структура: за питаннями, а не за відділами. Той, хто питає «як нам виставити рахунок у Швейцарію?», не знає, чи належить відповідь фінансам, продажам чи логістиці; він знає питання. База, організована за відділами, відправляє його у три розділи заради однієї відповіді. Організуйте за питаннями, які ставлять люди, — їхніми словами — і тримайте верхній рівень не більше ніж сімома розділами. Понад сім сама структура потребує пошуку, а пошук по базі, яку ще ніхто не наповнив, нічого не повертає. Типові верхні рівні для невеликої організації: клієнти й замовлення; гроші та рахунки; люди й найм; інструменти й доступи; правила й рішення; кому телефонувати.

Джерела: те, що вже існує, перш ніж писати щось нове. Ні в кого немає часу писати базу знань із чистого аркуша, і ніхто не мусить. Відповіді вже існують: у відповіді, яку колега дав минулого вівторка, в підсумку зустрічі, де встановили правило, у прайс-листі, який хтось прикріпив до повідомлення в березні, в онбординг-нотатках, які вів останній новачок. Перша версія більшості записів копіюється, а не пишеться. Де живуть джерела і скільки з кожного буде доступно пізніше — тема таблиці далі; коротко кажучи, в більшості пакетів чат, файли й нотатки зустрічей — три окремі місця, а сама зустріч залишає по собі найменше.

Відповідальність: ім'я й дата на кожному записі. Єдине, що відрізняє базу знань, якій довіряють, від тієї, яку перестали відкривати, — чи вказано в записі, хто ним володіє і коли його востаннє перевіряли. Запис з іменем і «переглянуто 14 жовтня 2026» вважають вірним; той самий текст без них — «імовірно, застарілий». Робота власника невелика: раз на квартал відповісти на питання «чи це досі так?» і змінити дату. Це не переписування бази. Якщо для запису не можна назвати власника, це не знання, а припущення, і його прибирають.

Як створити базу знань за 30 днів

План передбачає одну людину, яка веде процес, — керівника команди або того, кого питають найчастіше, — що витрачає близько двох годин на тиждень, тоді як решта команди витрачає хвилини.

Тиждень 1 — збираємо питання, а не відповіді. Відкрийте канал або нотатку в наявному каналі й протягом семи днів нехай усі кидають туди кожне питання, яке вони ставили колезі або яке поставили їм, — тими словами, які були використані. Відповідей поки немає. До п'ятниці набереться від сорока до вісімдесяти питань, третина з них — дублі. Порахуйте повтори: питання, яке ставили п'ять разів, — це запис номер один. Заздалегідь: там, де живе список, житиме й база; місце обирають тут за тим, що команда вже відкриває щодня, а не за порівнянням софту.

Тиждень 2 — структура й власники. Розсортуйте питання на групи; групи — це розділи, і їх не більше семи. Призначте власника на кожен розділ — того, хто відповів на більшість його питань у тижні 1. Потім призначте власника на кожен запис для двадцяти найчастіших питань. Поки нічого не пишіть, крім списку: розділ, питання, власник. Надішліть його команді й попросіть про одне: «яких питань бракує?» Список повернеться з ще десятьма.

Тиждень 3 — перші двадцять записів, із джерел. Кожен власник пише свої записи за шаблоном нижче, виходячи з того, що вже існує: відповіді в чаті, підсумку, файлу. Правило тижня 3: «коротке й правдиве краще за довге й повне»: відповідь у два речення з посиланням на файл, датована й підписана, — це запис. Сторінка, що пояснює історію правила, — це документ, і вона може з'явитися пізніше. Записи, які залежать від рішення, що його ніхто не може знайти, спочатку потрапляють у журнал рішень, а потім у базу — з посиланням.

Тиждень 4 — публікуємо, потім запускаємо цикл. Закріпіть базу там, де команда читає. Потім заведіть дві звички, які підтримують її живою: на кожне питання, поставлене в каналі питань, відтепер з'являється запис або посилання на нього, написане тим, хто відповів; а власник кожного запису отримує дату перегляду у свій календар. День 30 — це не готова база. Це двадцять–тридцять записів, кожен із власником і датою, і цикл, що додає ще один щоразу, коли на питання відповідають. Через півроку їх уже двісті, і ніхто не писав їх як проєкт.

Чого не відбувається за ці 30 днів: міграції бібліотеки документів, вибору нового інструмента чи написання сторінки для кожного процесу. База вказує на файли там, де вони лежать, і на процедури там, де вони живуть. Переміщення — це окремий проєкт, і часто непотрібний.

Шаблон статті бази знань

Один запис, одне питання, менше однієї сторінки. Скопіюйте його як нотатку й заповніть; найчастіше пропускають три останні рядки, а саме вони підтримують запис правдивим.

[Питання тими словами, якими люди його ставлять]
Власник: [ім'я] · Розділ: [один із семи] · Востаннє переглянуто: [дата] · Наступний перегляд: [дата]
Коротка відповідь: [два речення — що робити]
Стосується: [команда, офіс, тип клієнта] · Не стосується: [випадок, з яким це плутають]
Як: [пронумеровані кроки, у кожному названо систему, людину чи файл]
Правило, що за цим стоїть: [рішення, яке його встановило, з датою та причиною]
Винятки: [випадки поза звичайним шляхом і хто вирішує кожен]
Де файли: [посилання на поточний шаблон, прайс-лист, договір]
Пов'язані записи: [SOP, процес, попередня версія]

Шаблон — це простий текст із жирними мітками, тож його можна вставити у файл Word, Google Doc, сторінку вікі, Slack canvas або нотатку в чаті без переформатування.

Приклад: база експортера через 30 днів

Італійський експортер машинобудівного обладнання, 38 людей, відділ продажів у Мілані та дистриб'ютори в Іспанії, Румунії та Марокко. Тиждень 1 дав 61 питання; після видалення дублів — 44. Структура, що з них постала, з кількістю записів у кожному розділі на 30-й день:

1. Дистриб'ютори та замовлення (7) — як налаштовують нового дистриб'ютора; хто затверджує кредитний ліміт; що потрібно замовленню, перш ніж воно піде у виробництво
2. Рахунки та оплата (5) — виставлення рахунку дистриб'ютору у Швейцарії; коли використовують проформу; що робити, коли оплата затримується на 30 днів
3. Доставка та митниця (6) — перевізники за напрямками; документи, потрібні для палети до Марокко; хто підписує експортну декларацію
4. Сервіс і гарантія (4) — що покриває гарантія; як бронюють сервісний візит; які запчастини тримають на складі
5. Інструменти та доступи (3) — хто надає доступ до CRM; де лежить прайс-лист; як отримати доступ до спільної поштової скриньки
6. Правила та рішення (3) — правило двох підписів понад 10 000; стеля знижок; журнал рішень
7. Кому телефонувати (2) — митний брокер; контакти перевізників за країнами

Тридцять записів. Найчастіше питання тижня 1 — «які документи потрібні для палети до Марокко?» — протягом року одинадцять разів отримувало відповідь у каналі від однієї й тієї самої керівниці логістики; запис забрав у неї двадцять хвилин, бо одинадцята відповідь була вже написана й потребувала лише рядка з власником і дати.

Заповнений запис із розділу 3:

Які документи потрібні для палети до Марокко?
Власник: керівниця логістики · Розділ: Доставка та митниця · Востаннє переглянуто: 3 листопада 2026 · Наступний перегляд: 3 лютого 2027
Коротка відповідь: Комерційний інвойс у трьох примірниках, пакувальний лист, сертифікат EUR.1 і номер імпортної ліцензії дистриб'ютора в інвойсі.
Стосується: усіх відправлень марокканським дистриб'юторам · Не стосується: запчастин до 1 000 EUR кур'єром, які йдуть за власною формою кур'єра.
Як: 1. Експортуйте інвойс із системи за марокканським шаблоном. 2. Додайте номер ліцензії з файлу дистриб'ютора. 3. Замовте EUR.1 у торговій палаті, три робочі дні. 4. Додайте пакувальний лист. 5. Надішліть комплект митному брокеру й поставте в копію дистриб'ютора.
Правило, що за цим стоїть: Номер ліцензії додали після затримки в Касабланці в березні 2026 (запис журналу рішень 2026-03-19).
Винятки: Демонстраційні машини йдуть за тимчасовим допуском; вирішує керівниця логістики.
Де файли: Марокканський шаблон інвойсу; форма запиту EUR.1; файли дистриб'юторів.
Пов'язані записи: Перевізники за напрямками; хто підписує експортну декларацію.

Де живе база знань в інструментах, якими ви вже користуєтеся

Організація на 10–200 людей будує свою базу в пакеті, за який уже платить, і в кожному пакеті є місце для запису, місце для файлів і шлях для того, що залишає по собі зустріч. Кожен зупиняється в різній точці, і в кожному запис зберігається тією мовою, якою його набрали. Лише задокументована поведінка, зі сторінок самих вендорів, із зазначенням місяця, коли сторінку перевірено:

У всіх чотирьох однакові три речі. Запис — це документ або повідомлення тією єдиною мовою, якою його набрали, і учасник, що читає іншою мовою, читає саме це або копію, яку хтось зробив. Файли лежать у другому місці, яке знаходять другим пошуком. А зустріч, де правило обговорювали й ухвалили, потрапляє в базу лише тоді, коли людина потім вручну вносить його туди: де Teams і Meet взагалі зберігають транскрипт і підсумок та як зберегти їх після дзвінка — у де Microsoft Teams і Google Meet зберігають ваш транскрипт, запис і підсумок; AI-нотатники, які багато команд додають із тієї самої причини, порівняно в альтернативах Otter.ai, і кожен із них пише свій підсумок однією мовою.

Переклад, який ці пакети документують, належить дзвінку або екрану читача, а не запису: Microsoft документує живі перекладені субтитри на зустрічах Teams, коли організатор має ліцензію Teams Premium або Microsoft 365 Copilot, Google документує перекладені субтитри в Meet у відповідних планах Workspace (обидва перевірено в серпні 2026), а WhatsApp документує переклад отриманого повідомлення на телефоні читача (перевірено в серпні 2026) — що саме охоплює кожен і де кожен зупиняється, описано в живому перекладі Microsoft Teams, живому перекладі Google Meet і перекладі в WhatsApp. Запис, який у понеділок відкриває клерк дистриб'ютора в Касабланці, — це окремий об'єкт щодо цих субтитрів, і його читають тією мовою, якою його набрали.

База, що виростає з того, що команда вже говорить

InterMIND — це простір спілкування, де робота команди живе в каналі, тож у бази знань є очевидний дім: канал команди, яка нею користується, — експортного відділу, рецепції клініки, акаунт-групи агенції, — і цей канал водночас є каналом питань і місцем, звідки починаються зустрічі. Три рішення вище накладаються на нього безпосередньо.

Структура та відповідальність — це самі записи. Запис публікується як нотатка — повідомлення з розширеним форматуванням, із заголовками та нумерованими списками, яке потім редагують із його власного меню — і кожен учасник читає його своєю мовою, а оригінал лишається за одним перемикачем; його закріплюють, щоб поточна версія була першим, що знаходить новий колега; а коли ввімкнено історію редагувань, попередня редакція зміненого правила з'являється над поточним текстом як порівняння на рівні слів з відміткою часу — це і є слід перегляду, на який вказує рядок власника «востаннє переглянуто». Файли, на які вказує запис — прайс-лист, марокканський шаблон, договір з дистриб'ютором, — завантажуються в той самий канал і на кожному плані мають AI-підсумок мовою читача, де кожен пункт пов'язаний з абзацом, звідки він узятий; на платних планах сам файл відкривається перекладеним мовою читача (30 мов для документів). Якщо головна копія лишається в інструменті для документів, її оновлення потрапляють у канал електронною поштою: господар каналу дає йому окрему адресу, і надіслане туди повідомлення з'являється як звичайне повідомлення з названим відправником і збереженими вкладеннями. Команда, що приходить зі Slack, приносить свої канали з собою: стандартний експорт робочого простору Slack відновлюється як один канал на кожен канал Slack, повідомлення в порядку, з початковими відмітками часу, із закріпленими повідомленнями й реакціями, і кожен учасник читає кожне повідомлення своєю мовою.

Джерела — це те, де канал робить роботу, яку таблиця вище залишає людині. Зустріч, на якій ухвалюють правило, починається з каналу; під час дзвінка чернетка запису з'являється на екрані в усіх поруч із плитками відео через Share to conference — нотатка, або документ Google Docs чи OneDrive, на який є посилання в чаті, — і кожен учасник прокручує його незалежно та читає своєю мовою, поки той, хто показує, редагує його наживо. Коли дзвінок закінчується, підсумок складається з самої зустрічі — стислий виклад, пункти, позначені як погоджені, відкриті чи спірні, action items із власниками, і кожен рядок зберігає свою відмітку часу, — а документи, які показували під час сесії, додають свої підсумки до сказаного. Він приходить електронною поштою, як повідомлення в каналі та як посилання в події календаря, і кожен авторизований учасник читає його своєю мовою: запис перекладається для кожного читача, а не пишеться один раз мовою, якою випадково говорила кімната. Будь-який учасник може його редагувати, кожна правка зберігає автора й історію ревізій, а канал зберігає підсумок кожної минулої сесії — тож зустріч, що встановила марокканське правило, за один клік від запису, який його формулює. Ось так база виростає з того, що команда вже говорить: одинадцята відповідь у каналі, підсумок дзвінка, на якому обговорювали правило, файл, прикріплений у березні — усе в одному місці, а запис — над ними.

Канал питань отримує те саме з іншого боку. Власний асистент учасника — Claude, ChatGPT, Copilot або Gemini, підключений через конектор MCP, — шукає в підсумках, транскриптах, чатах і тексті спільних файлів одним питанням: «які документи потрібні для палети до Марокко?» — і повертає уривки із зазначенням зустрічі, дати та файлу, звідки кожен узято; це працює для організацій із увімкненими функціями AI, а читання через асистента обмежене зустрічами й каналами, в яких учасник перебуває. Сам чат має пошук, а базу можна забрати цілою: на кожному плані резервна копія з Settings експортує канали як ZIP із повідомленнями, транскрипціями та файлами, і це відповідь на питання власності на рівні організації, а не запису. Поряд із таблицею вище різниця проста: субтитри, які документують ці пакети, перекладають дзвінок, поки він триває; тут запис, зустрічі, що його породили, його файли та його історія — це єдиний запис, який кожен учасник читає своєю мовою.

Люди, що тримають знання команди, не завжди є співробітниками. Менеджер із замовлень дистриб'ютора, митний брокер, позаштатний бухгалтер, який знає швейцарське правило: зовнішній учасник каналу приєднується за електронною поштою з безкоштовним обліковим записом і читає записи та їхню історію, як усі інші; людина без облікового запису — гість однієї зустрічі: вона приєднується до дзвінка за посиланням, з телефона, безкоштовно, чує його наживо своєю мовою і не отримує жодного запису потім. Господар надає простір і, на платному плані, платить лише за учасників, активних протягом попередніх 28 днів — тих, хто долучився до зустрічі, писав у чаті або питав асистента; учасники, які притихли, зберігають доступ безкоштовно, а саме це й потрібно базі знань: людина, що написала запис два роки тому, може й далі бути в каналі.

• Відкрити повний підсумок — справжній запис, створений тим самим кодом, що пише ваш.
• Спробуйте живе демо — без реєстрації; говоріть і чуйте, як зал перекладається для кожного слухача.

Створення бази знань як ремесло переживає будь-який інструмент: хтось усе одно має збирати питання, тримати структуру в межах семи розділів, ставити ім'я й дату на кожен запис і відповідати в каналі, а не в особистих повідомленнях. Те, що не мусить пережити, — це друга робота: передруковувати в базу те, що вирішила зустріч, і вручну вести перекладену копію кожного запису, по одній мові за раз, для офісу, який читає іншою.

FAQ

Що таке база знань?

База знань — це збірка відповідей на питання, які організації ставлять не раз, записаних один раз, кожна з власником і датою, і збережених там, де той, кому потрібна відповідь, може знайти її, не питаючи колегу. Внутрішня база знань відповідає на власні питання команди: як ми виставляємо рахунки, де лежать файли, що ми вирішили; зовнішня відповідає на питання клієнтів про продукт. Від вікі вона відрізняється наявністю структури й власників, а від бібліотеки документів — тим, що містить відповіді, а не файли.

Як створити базу знань?

Протягом тижня збирайте питання, які команда справді ставить, — тими словами, що були вжиті; згрупуйте їх не більше ніж у сім розділів; призначте власника для кожного розділу та для кожного з двадцяти найчастіших питань; нехай власники напишуть ці записи з того, що вже існує — відповідей у чатах, підсумків зустрічей, файлів, — за одно-сторінковим шаблоном із короткою відповіддю, кроками, винятками та датою перегляду; опублікуйте в місці, яке команда вже читає; потім підтримуйте цикл: кожне питання, на яке відповіли, стає записом, а власник кожного запису переглядає його у призначену дату.

Що має містити база знань?

Один запис на питання, і в кожному: питання тими словами, якими люди його ставлять, власник, дата останнього перегляду та наступного, коротка відповідь, випадки, до яких це стосується й не стосується, кроки з назвою системи чи людини, рішення, що стоїть за правилом, із датою, винятки й хто їх вирішує, посилання на поточні файли та посилання на пов'язані записи. База загалом потребує структури не більше ніж із семи розділів, організованої за питаннями, які ставлять, а не за відділами.

Чим база знань відрізняється від вікі?

Вікі — це набір сторінок, які будь-хто може писати в будь-якій структурі; база знань організована за питаннями, які ставлять люди, з одним записом на питання та іменованим власником і датою перегляду на кожному. Вікі можна перетворити на базу знань, додавши структуру й власників; без них вікі розростається до сотень сторінок, у яких ніхто не може зорієнтуватися і які ніхто не перевіряв. Програмне забезпечення часто те саме; різниця — у цих двох рішеннях.

Як структурувати базу знань?

За питаннями, а не за відділами: той, хто питає, не знає, якому відділу належить відповідь, але знає, про що питає. Згрупуйте питання, зібрані в перший тиждень, не більше ніж у сім розділів верхнього рівня — для невеликої організації це зазвичай клієнти й замовлення, гроші та рахунки, люди й найм, інструменти й доступи, правила й рішення, кому телефонувати, — і тримайте кожен запис в межах одного питання. Якщо розділ виростає понад тридцять записів, розділіть його за питаннями, які ставлять люди, а не за тим, хто відповідає.

Скільки часу потрібно, щоб створити базу знань?

Тридцять днів до бази, яку люди відкривають: тиждень збору питань, тиждень на структуру й власників, тиждень на написання перших двадцяти записів із наявних джерел, тиждень на публікацію й запуск циклу перегляду. Той, хто веде процес, витрачає близько двох годин на тиждень; кожен власник — двадцять хвилин на запис, бо більшість записів копіюються з уже даної відповіді, а не пишуться заново. База не завершена на 30-й день; вона росте на один запис щоразу, коли відповідають на питання.

Чи можна створити базу знань безкоштовно?

Так — шаблон у цьому посібнику є простим текстом, і база може жити в нотатці, документі або каналі в інструментах, якими команда вже користується: canvas у Slack, Google Doc, вкладка Files каналу Teams, закріплена нотатка в чаті. Те, що нічого не коштує в софті, усе одно коштує часу власників на перегляд, а обмеження — це обмеження самого пакета: план Free у Slack зберігає 90 днів історії повідомлень, а в кожному пакеті запис зберігається тією мовою, якою його набрали. В InterMIND план Basic безкоштовний, а ціни платних планів — на сторінці цін.

Джерела: 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. Сторінку Microsoft Learn про Teams і SharePoint перевірено в листопаді 2026; сторінки про зберігання даних Teams і нотатки зустрічей, сторінку шаблону canvas у Slack та сторінку Google «Take notes for me» перевірено в жовтні 2026; сторінки про переклад повідомлень і субтитри в Teams, сторінки Slack про ціни, зберігання й експорт, сторінки Google Chat про переклад і Meet про субтитри та сторінки WhatsApp перевірено в серпні 2026. Вендори з часом змінюють плани, функції та списки мов; актуальний стан дивіться на їхніх сторінках.