Самостоятельная CRM или облачная подписка: считаем затраты на команду из 15 человек

Представьте два счёта на одну и ту же ежемесячную сумму. В первом написано «подписка на CRM», во втором — «сервер и лицензия». Выглядят они одинаково, но внутри спрятаны разные обязанности. В подписке обновления, как правило, входят в услугу, а на своём сервере их кто-то должен выполнить, проверить и при необходимости откатить. Поэтому сравнивать надо не суммы, а то, что эти суммы покупают. Ниже разберём, как это сделать для команды из 15 человек, не выдумывая тарифов и не объявляя заранее победителя.

Цифра 15 здесь служит рабочим сценарием, а не измеренным фактом о вашей компании. Актуальные цены вы подставите сами: тарифы меняются, а формула остаётся. Все денежные значения в примерах ниже условные и нужны только чтобы показать механику расчёта.

Сначала требования, потом деньги

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

Обязательные функции

Выпишите то, без чего команда не сможет работать в понедельник после переезда. Не «хотелось бы», а «без этого сделки встанут». Обычно получается короткий список: карточки клиентов и сделок, воронка с вашими этапами, задачи и напоминания, история переписки или звонков, импорт существующей базы, отчёт по менеджерам. Отдельно отметьте интеграции: почта, телефония, сайт с формами, мессенджеры. Именно интеграции чаще всего оказываются платными надстройками в облаке или отдельной работой на своём сервере.

Важный нюанс: не переносите возможности одного продукта на весь класс систем. Если у одного облачного сервиса есть встроенная телефония, это не значит, что она есть у всех; если у одной self-hosted CRM нужная интеграция делается расширением, это не значит, что она бесплатна в другой. Проверять нужно конкретную пару «продукт и редакция», а не категорию в целом.

Роли и разграничение доступа

Для 15 человек вопрос ролей почти всегда серьёзнее, чем кажется. Менеджеры не должны видеть чужие сделки целиком, руководитель отдела хочет видеть свой отдел, а бухгалтер — только счета. Посмотрите, как это устроено в самостоятельной системе на примере EspoCRM. В документации по ролям описано, что роль задаёт действия — создание, чтение, редактирование, удаление и stream — и уровень доступа: всё, команда, только своё или ничего. Если у пользователя несколько ролей, побеждает более разрешающее правило, а командные роли действуют на членов команды. Эффективные права можно посмотреть в разделе Access в карточке пользователя.

Практический вывод из этого не про EspoCRM, а про сам подход. Когда вы сравниваете варианты, спросите у каждого: можно ли выразить вашу схему «своё — командное — всё» без обходных приёмов, и как проверить, что права на деле такие, как задумано? Правило «более разрешающее выигрывает» удобно, но означает, что случайно выданная вторая роль может расширить доступ. Значит, кто-то должен периодически просматривать итоговые права. Это тоже труд, и его надо внести в расчёт, неважно, облако у вас или свой сервер.

Работа с данными

Третья часть требований — судьба данных. Откуда вы их импортируете, как часто нужны выгрузки, как долго хранится история, нужно ли держать данные в определённой стране или под своим контролем по внутренним правилам компании. Сами по себе эти ответы не решают выбор, но задают границы. Если база клиентов — главный актив бизнеса, вопрос «как мы заберём её, если уйдём» важен с первого дня, а не в момент расставания. Мы вернёмся к нему в разделе про цену выхода.

Из чего состоит подписка

Облачная CRM обычно кажется простой: цена за пользователя в месяц. На практике итоговая сумма складывается из нескольких слоёв, и полезно разложить их явно.

• Платные места. Сколько человек реально работает в системе: не только 15 сотрудников, но и подрядчики, стажёры, директор «на просмотр». Часть тарифов считает всех одинаково, часть различает полные и ограниченные места.
• Функции уровня тарифа. То, что вам нужно из списка обязательного, может оказаться только в старшем тарифе: расширенные роли, автоматизации, API, отчёты. Тогда реальная цена места — это цена нужного тарифа, а не стартового.
• Внешние услуги. Телефония, SMS, рассылки, интеграции через сторонние сервисы, дополнительное хранилище. Они бывают в составе подписки, а бывают отдельными счетами.
• Внедрение и настройка. Кто-то должен настроить воронку и поля. Это либо ваши часы, либо услуга подрядчика.

Пример различия редакций полезен и вне CRM. В документации Plane различаются облачная версия и self-hosted редакции Community, Commercial и Airgapped, причём Community распространяется по лицензии AGPL v3. Plane — это не CRM и не кандидат в нашем сравнении, а лишь наглядный урок: слово «self-hosted» не означает «бесплатно и со всеми возможностями». Возможности и правила коммерческой редакции нельзя автоматически считать доступными в сообществе. То же верно и для любой CRM: прежде чем вписать в расчёт функцию, убедитесь, что она есть именно в той редакции и лицензии, которую вы будете ставить. Лицензионные условия одного продукта нельзя переносить на другой, включая EspoCRM.

Формула подписки для расчёта проста:

Подписка_в_месяц = N × Ц_места + Д_функции + В_услуги

Здесь N — число платных мест, Ц_места — цена места на нужном тарифе, Д_функции — доплата за недостающие функции, В_услуги — внешние услуги в месяц. Если тариф оплачивается годом вперёд, пересчитайте на месяц и отдельно запишите, что часть денег уходит единовременно.

Из чего состоит своя установка

У самостоятельной CRM картина обратная: прямых платежей меньше, но появляются обязанности. Разложим и её.

• Сервер. Виртуальная машина с достаточным процессором, памятью и диском. На VPS MAATRIX доступны линейки Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ), с NVMe, процессорами AMD EPYC и root-доступом. Ресурсы тарифа не равны обещанию ёмкости: сколько пользователей и данных выдержит конкретная система, показывают только замеры на вашей нагрузке. Для 15 человек с обычной базой сделок имеет смысл начать с небольшого размера и наблюдать за загрузкой, а не брать «с запасом на всякий случай».
• Лицензия. У одних продуктов есть бесплатная редакция, у других платные расширения или коммерческая редакция. Это нужно выяснить по документации выбранного продукта, а не по аналогии.
• Резервные копии. Их нужно настроить, хранить и проверять. Место для копий — тоже расход.
• Труд сопровождения. Обновления, мониторинг, продление сертификатов, разбор «почему не отправляется почта», выдача доступов новым сотрудникам.
• Интеграции. То, что в облаке включается переключателем, здесь иногда настраивается вручную.

Про копии стоит сказать подробнее, потому что именно здесь «своя установка» чаще всего оказывается дороже, чем выглядела. Не стоит считать, что копии появляются сами: в сведениях о тарифах MAATRIX нет подтверждения автоматических резервных копий во всех тарифах, поэтому расписание и хранение копий вы проектируете сами. Что входит в копию CRM, показывает пример EspoCRM: по документации по резервному копированию полная копия состоит из файлов приложения и дампа базы данных. Восстановление затрагивает файлы, права доступа, базу и проверку расписания cron, а инструкции различаются для контейнерной и обычной установки. Отсюда следует рабочий вывод: восстановление — это не одна кнопка, а процедура из нескольких шагов, и её нужно хотя бы раз отрепетировать на отдельной машине, чтобы знать, сколько она реально занимает. Это время и есть ваша оценка простоя при аварии.

Формула своей установки:

Своя_в_месяц = С_сервер + Л_лицензия + К_копии + Ч × Ставка + В_услуги

Здесь С_сервер — стоимость VPS в месяц, Л_лицензия — лицензия или платные модули в пересчёте на месяц (может быть нулём, если она вам не нужна), К_копии — хранение копий, Ч — часы сопровождения в месяц, Ставка — стоимость часа человека, который это делает, В_услуги — внешние услуги, как и в облаке. Вот третья строка и есть главная: Ч × Ставка. Её чаще всего не записывают, потому что она не приходит счётом. Но время админа или руководителя, потраченное на CRM, не бесплатно, даже если оно не отражено в бухгалтерии отдельной строкой.

Рабочий пример с условными числами

Возьмём вымышленные значения исключительно для демонстрации. Пусть в облаке место стоит 1 000 условных единиц в месяц, нужен тариф с ролями и API, так что доплата Д_функции составляет 3 000, внешние услуги — 2 000. Тогда для N = 15:

Подписка = 15 × 1 000 + 3 000 + 2 000 = 20 000 в месяц

Для своей установки пусть сервер стоит 2 500, лицензии нет (0), копии на отдельном хранилище — 500, внешние услуги те же 2 000, сопровождение — 6 часов в месяц по условной ставке 1 500 за час:

Своя = 2 500 + 0 + 500 + 6 × 1 500 + 2 000 = 14 000 в месяц

Выглядит как победа своей установки. Но проверим, насколько вывод хрупок. Если сопровождение съедает не 6, а 14 часов, получим 2 500 + 500 + 21 000 + 2 000 = 26 000, и картина разворачивается. Если же вы вообще не считаете часы, своя установка кажется почти в десять раз дешевле. Поэтому полезно найти точку безубыточности по часам:

Ч_порог = (Подписка − С_сервер − Л_лицензия − К_копии − В_услуги) / Ставка

В нашем условном примере это (20 000 − 2 500 − 0 − 500 − 2 000) / 1 500 = 10 часов в месяц. Если ваша команда способна удержать сопровождение ниже этого порога, своя установка выгоднее в обычный месяц; если нет, выгоднее подписка. Вместо вопроса «что дешевле» вы получаете вопрос, на который можно честно ответить: сколько часов в месяц мы готовы тратить?

Первый год и обычный месяц — разные задачи

Одна ошибка в сравнении повторяется особенно часто: смешивают расходы запуска и расходы эксплуатации. Они ведут себя по-разному и должны считаться раздельно.

В первый год у обоих вариантов есть единовременная часть. В облаке это настройка воронки, импорт базы, обучение сотрудников, возможно оплата года вперёд. На своём сервере к этому добавляются установка и настройка окружения, настройка почты и сертификатов, написание процедуры копирования и её проверка, а также тестовое восстановление. Если нужная интеграция не готова, добавляются часы на её настройку.

Год_1 = Запуск + 12 × Месяц + Резерв_на_инциденты

Слагаемое «Резерв_на_инциденты» не выдумка ради осторожности. В самостоятельной установке один неприятный день в году — это нормальная статистическая ожидаемость: не обновилось, не запустился cron, закончилось место. Заложите на него несколько часов с той же ставкой. В облаке такой резерв тоже нужен, но он обычно меньше: на вашей стороне остаются ошибки настройки и права, а работа платформы — на поставщике.

Обычный месяц после запуска — другая картина. Единовременные расходы ушли, остаются регулярные: сервер или подписка, копии, обновления, выдача доступов. Здесь выигрывает тот вариант, у которого рутинная нагрузка ниже. Для команды из 15 человек типичная рутина — пара сотрудников приходят и уходят, кто-то просит изменить поле, кто-то не видит чужую карточку. Часть этих задач одинакова в обоих вариантах, и их можно из сравнения исключить. Сравнивайте только разницу.

Хорошая практика — сделать таблицу с двумя столбцами, «первый год» и «обычный месяц», и честно записать в каждую ячейку три числа: деньги платежом, часы людей и риск, оцененный как часы на инцидент.

Цена выхода: о чём вспоминают поздно

Любое решение стоит сравнивать и по тому, во что обойдётся передумать. Для CRM это особенно важно, потому что в ней накапливается история, которую жалко терять: переписка, комментарии, этапы сделок, вложения.

В облаке вопрос звучит так: в каком виде можно выгрузить всё, включая историю и файлы, а не только таблицу контактов? Ответ нужно найти до подписки, потому что у разных сервисов он разный, а некоторые данные могут выгружаться только частично. Это проверяется практически: возьмите пробный период, внесите тестовые данные и выгрузите их.

На своём сервере данные в вашем распоряжении, но выход всё равно не бесплатен. Нужно уметь снять полную копию, как в описанном выше случае файлов и дампа базы, и понимать, в какую систему вы это потом загрузите. Формат хранения понятен только самой CRM, поэтому перенос в другую систему тоже потребует маппинга полей и часов работы. Условно:

Цена_выхода = Ч_выгрузки × Ставка + Ч_переноса × Ставка + Простой × Потери_в_час

Слагаемое «Простой × Потери_в_час» чаще всего самое неприятное, и его нельзя оценить по книжке: нужно спросить отдел продаж, во что обходится час без доступа к клиентской базе. Эта величина полезна ещё и для другого расчёта, о котором дальше.

Что сломается дороже: простой и ответственный

Сравнение двух сумм скрывает вопрос, кто отвечает за работоспособность. В облаке вы покупаете часть этой ответственности. В самостоятельной установке она целиком на вас. Её можно выразить числом, если постараться.

Риск_в_месяц = Вероятность_инцидента × (Время_восстановления × (Потери_в_час + Люди × Ставка))

Вероятность вы оцениваете сами по опыту команды, время восстановления измеряете на учебной аварии, потери в час берёте у отдела продаж. Если восстановление занимает полдня, а команда из 15 человек простаивает, то даже редкий инцидент не пренебрежимо мал на фоне разницы в подписке. Именно поэтому тестовое восстановление из копии — не формальность, а получение недостающей переменной для формулы.

Здесь стоит помнить и о границах самой инфраструктуры. Один VPS остаётся одним сервером: наличие нескольких тарифов и локаций в каталоге не делает одно приложение отказоустойчивым. Если для вашей CRM простой в несколько часов недопустим, это требование к архитектуре и копиям, а не побочная опция тарифа, и в расчёте оно должно появиться отдельной строкой.

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

Теперь самый честный поворот. Все формулы выше предполагают, что у слагаемого Ч есть владелец. Ч — это часы конкретного человека с конкретными навыками, который готов отвечать за обновления, копии и права. В компании из 15 человек такого человека часто нет. Есть руководитель, который «немного разбирается», или разработчик, у которого основная работа в другом месте. Тогда расчёт меняется принципиально.

Спросите себя прямо:

• Кто в конкретную среду получит уведомление, что копия не создалась?
• Кто примет решение обновить или отложить обновление?
• Кто заменит этого человека на время отпуска?
• Кто проверит права после ухода сотрудника?

Если на эти вопросы нет имён, то слагаемое Ч × Ставка в формуле — это иллюзия, а реальная стоимость — риск неподготовленной аварии. В такой ситуации подписка перестаёт быть «дорогой»: вы покупаете не программу, а исчезновение целого пласта обязанностей. Её разумно выбирать, даже если на бумаге своя установка дешевле.

Возможен и промежуточный вариант: свой сервер, но сопровождение отдано подрядчику по договору с оговорённым объёмом часов. Тогда Ч × Ставка заменяется месячной ценой договора, а в договоре нужно зафиксировать, кто делает копии, кто проверяет восстановление и в какое время реагирует на сбой. Если в каталоге MAATRIX есть образ с установкой нужного вам приложения, это сокращает часть работы на старте: в публичном предложении упомянуты n8n и Nextcloud с установкой, а точное наличие и операционная система проверяются в форме заказа. Но это сокращение этапа запуска, а не снятие обязанности по сопровождению.

Если же человек есть и ему интересно, свой сервер даёт реальные плюсы, которые не всегда видны в цене: полный контроль над данными и над сроками обновлений, свобода интеграций, отсутствие привязки к решению поставщика о повышении цен. Для таких команд VPS с root-доступом — естественная площадка, а оплата картой РФ или через СБП и создание сервера в течение нескольких минут после оплаты упрощают старт. Но это условие удобства, а не аргумент в пользу самого подхода.

Тот же ход мысли применим и к другим сервисам команды. Например, разбор по аналогичной схеме для мессенджера есть в статье об окупаемости перехода со Slack на свой сервер: там тоже сравниваются подписка и обязанности, только на другом масштабе команды.

Как принять решение за один вечер

Порядок действий можно уложить в несколько шагов, не требующих особых ресурсов.

1. Запишите обязательные функции, роли и требования к данным. Если пункт нельзя проверить, он не обязательный.
2. Для каждого кандидата в облаке найдите тариф, который действительно покрывает ваш список, и посчитайте формулу подписки с реальными ценами.
3. Для каждой self-hosted CRM выясните лицензионные условия именно выбранной редакции и подставьте их в формулу своей установки.
4. Оцените Ч в часах, не оптимистично, а по сценарию «обновление не прошло с первого раза». Умножьте на ставку.
5. Найдите Ч_порог. Если ваша честная оценка выше порога, выбирайте подписку; если ниже — своя установка достойна пробы.
6. Проверьте цену выхода: выгрузите тестовые данные и, для своей установки, восстановитесь из копии на отдельной машине.

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

Обязательство, которое вы выбираете

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