Цена одного документа: Notion против своей вики за три года

MAATRIX

Сравнивать Notion и самостоятельно поднятую вики через «сколько стоит тариф в месяц» — почти бессмысленно: у команды из пяти человек и команды из пятидесяти совершенно разная интенсивность работы с документами, а месячный счёт растёт линейно от числа мест, а не от того, сколько реальной пользы из этих документов извлекается. Более честный вопрос — сколько стоит один документ, который команда реально создала, отредактировала и к которому кто-то потом возвращался. Эта метрика непривычная, но именно она показывает, где Notion становится дорогим удовольствием, а где своя вики на сервере попросту не окупает возню с её администрированием.

Почему цена подписки — плохая метрика, а цена документа — рабочая

Цена подписки в чистом виде — это про поставщика, а не про вас. Notion продаёт места, а не документы: команда из десяти человек, которая ведёт активную базу знаний с сотнями страниц, и команда из десяти человек, у которой в workspace десяток случайных заметок, платят одинаково. Сравнивать такие суммы напрямую с расходами на свой сервер — сравнивать разные единицы измерения.

Цена одного документа — это нормировка на реальное использование. Формула предельно простая:

Цена документа = Совокупная стоимость владения за период / Число документов, созданных и поддерживаемых за этот период

У метрики есть здоровая аналогия — «стоимость владения на пользователя в месяц», которую SaaS-компании считают внутри себя, чтобы понять, окупается ли клиент. Здесь мы делаем то же самое, но с точки зрения покупателя: не «сколько мы платим за место», а «сколько нам обходится единица реальной ценности» — документ, к которому кто-то обращается за информацией.

Важная оговорка сразу: если число документов у обеих платформ одинаковое (а оно и должно быть одинаковым, если команда одна и та же и просто выбирает, где хранить знания), то сравнение цены за документ математически сводится к сравнению совокупных расходов. Смысл метрики не в том, что она открывает какую-то скрытую арифметику — а в том, что она переводит абстрактную сумму в интуитивно понятную единицу, на которую проще опереться при принятии решения и объяснить его коллегам, которые не хотят разбираться в тарифных планах.

Как оценить число документов, которые команда создаёт за три года

Это самая уязвимая часть расчёта — переоценка или недооценка объёма документооборота сразу искажает итоговую цену за штуку. Есть два пути.

Путь первый — если команда уже пользуется Notion. Тогда число документов не нужно оценивать, его можно посчитать. Экспортируйте workspace (Settings → Export content, формат Markdown & CSV) и посчитайте файлы:

unzip notion_export.zip -d notion_export
find notion_export -name "*.md" | wc -l

Это даст верхнюю границу — экспорт включает и мёртвые страницы, которые никто не открывал два года. Дальше можно грубо отфильтровать по дате последнего изменения в CSV-таблице метаданных, если она приложена к экспорту, чтобы отделить «живые» документы от архивных.

Путь второй — если считаете на будущее, до миграции. Тогда придётся оценивать по косвенным признакам: сколько встреч в неделю фиксируется протоколами, сколько задач заводится и требует технического описания, сколько онбординг-документов на нового сотрудника, сколько ревью процессов в квартал. Практичный ориентир: активная команда разработки или продукта обычно создаёт от одного до трёх новых документов на человека в месяц (заметки со встреч, спеки, ретро, решения) плюс правки существующих. Это именно ориентир, а не измеренная величина — у конкретной команды может быть кратно больше или меньше, и перед тем как опираться на расчёт, стоит прикинуть свою цифру, а не брать чужую.

Для самостоятельной вики, если она уже развёрнута (например, на Outline), число документов считается напрямую из базы:

psql -d outline -c "select count(*) from documents where \"deletedAt\" is null;"

Ключевое допущение методики: если команда одна и та же и просто выбирает платформу, число документов N в знаменателе примерно одинаковое для Notion и для своей вики — люди не станут писать вдвое больше заметок только потому, что сменился инструмент. Это упрощение, и в реальности интерфейс всё-таки немного влияет на частоту записи (см. раздел про нематериальные факторы), но для расчёта единицы экономики удобно зафиксировать N как константу и менять только числитель — совокупную стоимость.

Notion: считаем цену документа по формуле

Стоимость Notion за три года раскладывается на простую формулу:

Совокупная стоимость (Notion) = Число платных мест × Цена места в месяц × 36 месяцев

Точный тариф здесь сознательно не указываю числом — Notion меняет цены и состав планов регулярно, и любая цифра, зафиксированная в тексте статьи, устареет быстрее, чем вы её прочитаете. На конец августа 2026 года актуальную цену стоит смотреть напрямую на сайте Notion в разделе тарифов для нужного плана (обычно команды берут план уровня Business или выше ради истории версий и прав доступа). Обозначим её переменной P — цена одного платного места в месяц.

Для иллюстрации подставим условные значения — не текущие тарифы, а числа для демонстрации самого расчёта:

• Число платных мест: S = 12
• Условная цена места: P = $10/мес (подставьте актуальную цену со своего тарифа)
• Период: T = 36 месяцев

Совокупная стоимость = 12 × $10 × 36 = $4 320

Дальше берём число документов из раздела выше. Возьмём условный ориентир: команда из 12 человек создаёт около 1,5 документа на человека в месяц — это N = 12 × 1,5 × 36 = 648 документов за три года (с учётом того, что часть из них — правки, а не новые страницы, реальное число уникальных документов обычно меньше; для расчёта берём именно уникальные записи).

Цена документа (Notion) = $4 320 / 648 ≈ $6,7 за документ

Это число не имеет смысла само по себе — оно нужно только в сравнении со второй частью расчёта. Обратите внимание: если команда создаёт документов заметно меньше (скажем, 300 за три года вместо 648), цена документа для Notion вырастает вдвое при той же подписке — и это ровно тот случай, когда метрика показывает то, что скрыто за месячным счётом: вы платите за места, а не за использование.

Своя вики на VPS: считаем цену документа

Формула для самостоятельной вики симметричная, но числитель устроен иначе — вместо цены за место есть фиксированная стоимость сервера плюс изредка возникающие затраты на администрирование:

Совокупная стоимость (своя вики) = Стоимость VPS в месяц × 36 месяцев + Резервное копирование + Время администратора

Для базы знаний на 10-20 человек обычно достаточно небольшого VPS — 2 vCPU, 4 ГБ RAM хватает с запасом для Outline, BookStack, Wiki.js или DokuWiki вместе с PostgreSQL и обратным прокси; при росте команды и объёма вложений (картинки, файлы) стоит закладывать больше диска, но не обязательно больше CPU. Возьмём для примера конфигурацию с условной ценой C = $15/мес (цены на серверы у разных провайдеров и в разных локациях отличаются — уточняйте актуальную на момент аренды).

Стоимость сервера за 3 года = $15 × 36 = $540

К этому стоит честно добавить резервное копирование (снапшоты или выгрузка дампа на отдельное хранилище — обычно $2-5/мес) и время администратора. Второе — самая недооценённая статья расхода в подобных расчётах: даже стабильно работающая вики требует обновлений, разбора редких инцидентов и настройки при первом запуске. Если оценить это в 2-3 часа в месяц по ставке специалиста, получится ощутимая сумма за три года, но по факту для многих команд это время IT-сотрудника, который и так на зарплате и всё равно решал бы другие задачи — включать или не включать эту статью в расчёт зависит от того, есть ли у вас выделенный человек под инфраструктуру или это довесок к другим обязанностям.

Резервное копирование: $3 × 36 = $108
Совокупная стоимость (консервативно, без учёта времени админа) ≈ $540 + $108 = $648

При том же N = 648 документов:

Цена документа (своя вики) = $648 / 648 ≈ $1 за документ

Разница с Notion в этом иллюстративном примере — почти семикратная. Но важно понимать источник разницы: стоимость сервера почти не зависит от числа мест и слабо зависит от числа документов, пока вы не упираетесь в реальные лимиты железа. Экономика своей вики становится тем выгоднее, чем больше людей и документов приходится на один и тот же сервер — а экономика Notion остаётся линейной, потому что каждое новое место стоит ровно столько же, сколько предыдущее.

Где именно ломается экономика: сравнение и точка перелома

Ключевое наблюдение метрики — не абсолютные цифры, а то, как они масштабируются с ростом команды. У Notion цена документа примерно постоянна на человека (растёт число мест — растёт числитель почти пропорционально росту знаменателя, если документооборот на человека стабилен). У своей вики цена документа падает по мере роста команды, пока сервера хватает по ресурсам.

*Цифры условные, для иллюстрации логики расчёта — не текущие тарифы Notion и не гарантированная цена сервера.

Точка перелома, где разница в цене документа становится ощутимой, а не теоретической, обычно приходится на команды от 15-20 человек — до этого размера абсолютные суммы у Notion не настолько велики, чтобы оправдывать возню с миграцией и администрированием. После этого порога кривые расходятся всё сильнее, потому что стоимость своей инфраструктуры растёт ступенчато (апгрейд сервера раз в год-два), а не линейно на каждого нового сотрудника.

Похожая логика разбирается и для других SaaS-инструментов — почитайте, например, про окупаемость перехода на свой почтовый сервер: там точка перелома считается по числу почтовых ящиков, но методика та же самая — фиксированная инфраструктура против линейно растущей подписки.

Что эта метрика не учитывает: честные оговорки

Цена документа — полезный ориентир для бюджета, но она ничего не говорит о качестве работы с этим документом, а именно оно определяет, будет ли команда вообще пользоваться базой знаний.

В пользу Notion:

• Интерфейс, к которому не нужно приучать сотрудников — большинство уже знакомы с блочным редактором, базами данных, шаблонами.
• Поиск работает из коробки и не требует настройки индексации.
• Готовые интеграции (Slack, Google Drive, календари, десятки сторонних сервисов через API и маркетплейс) — на своей вики то же самое придётся собирать вручную или обходиться без этого.
• Совместное редактирование в реальном времени отполировано годами — на self-hosted решениях это часто работает менее гладко или отсутствует вовсе.
• Мобильные приложения и оффлайн-режим не требуют отдельной настройки.

В пользу своей вики:

• Полный контроль над данными — критично, если документы содержат чувствительную информацию (финансы, персональные данные, коммерческая тайна) и нужно соответствовать требованиям к месту хранения данных.
• Никакой зависимости от смены политики поставщика, повышения цен «задним числом» или блокировки аккаунта.
• Возможность встроить вики в собственную инфраструктуру — единый SSO, свои бэкапы, свой мониторинг рядом с остальными сервисами.
• Экспорт и миграция данных полностью под вашим контролем, без ограничений формата экспорта чужого сервиса.

Если поиск и удобство интерфейса для команды критичны (например, поддержка часто ищет ответы в базе знаний под давлением времени), а грубый self-hosted поиск без дополнительной настройки полнотекстового индекса будет всех раздражать — экономия в цене документа может не окупить потерю продуктивности. Честная рекомендация: считать деньги важно, но решение стоит принимать вместе с коротким пилотом — разверните Outline на VPS на пробной подписке, перенесите часть реальных документов и дайте команде пару недель поработать до финального решения, а не только до расчёта в таблице.

Стоит также заранее прикинуть, сколько RAM закладывать под Outline при ожидаемом росте команды — если экономия на бумаге упирается в постоянные апгрейды сервера, часть выгоды съедается. А если не уверены, какая именно система вики подходит лучше — сравнение BookStack и Wiki.js поможет выбрать между более простой структурированной вики и более гибкой markdown-ориентированной.

Частые вопросы