Плата за места в подписке, которыми никто не пользуется

MAATRIX

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

Откуда берутся мёртвые места в подписке

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

Основные источники «мёртвых» мест:

• Увольнения и переходы. Сотрудник уходит из компании или переходит в другой отдел, доступ к отдельным сервисам закрывают не сразу, а иногда не закрывают вовсе — особенно если сервис не входит в стандартный чек-лист офбординга. Похожая история разбирается в статье про SSH-ключ уволенного сотрудника: доступ отзывают на бумаге, а по факту он продолжает работать месяцами. С местами в SaaS-подписках то же самое, только счётчик тикает не в рисках безопасности, а в деньгах.
• Закупка «с запасом». Планировали нанять трёх человек в квартале — купили пять мест сразу, чтобы не возиться с апгрейдом тарифа посреди месяца. Найм задержался, отменился или пошёл через подрядчика с доступом в другой сервис — а места остались оплаченными.
• Тестовые и временные аккаунты. Кто-то завёл аккаунт, чтобы проверить фичу, показать демо клиенту или временно подключить подрядчика на две недели. Задача закрыта, аккаунт — нет.
• Дублирующиеся или устаревшие роли. После реорганизации у одного человека остаётся два аккаунта в одном сервисе — старый и новый, потому что миграцию делали быстро и не подчистили за собой.
• Автопродление на вырост. Часть тарифных планов продаётся блоками — «от 10 мест», «от 25 мест». Компания выросла до 12 человек, но платит за 25, потому что переход на блок поменьше требует ручного даунгрейда, а руки до него не доходят.

Ни один из этих сценариев не выглядит критично сам по себе. Проблема в масштабе: если в компании 15-20 активных SaaS-подписок по местам, а в каждой скапливается 2-4 неиспользуемых места, суммарная переплата легко достигает 15-25% от всего SaaS-бюджета — и это без единого явного признака проблемы, кроме самого счёта.

Почему это трудно заметить без целенаправленной проверки

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

Есть три причины, почему проблема остаётся невидимой месяцами:

1. Ответственность размыта. Обычно нет одного человека, который бы одновременно видел HR-события (кто уволился, кто перешёл в другой отдел), список активных подписок и биллинг по каждой. HR знает про увольнения, IT — про доступы, финансы — про счета, и эти три картины редко сверяются друг с другом.
2. Счёт приходит агрегированной суммой. В большинстве биллингов видно «12 мест × тариф», а не «8 активных + 4 без единого входа за последние 60 дней». Чтобы увидеть разницу, нужно зайти в раздел пользователей каждого сервиса отдельно и посмотреть дату последнего входа — это не то действие, которое кто-то делает по умолчанию.
3. Стоимость одного места кажется незначительной. Одно неиспользуемое место в подписке стоит в месяц заметно меньше, чем время, которое кажется нужным, чтобы разобраться и отключить его. На уровне одного места экономика действительно не бьётся. На уровне 20-30 накопленных мест по всей компании — бьётся всегда, потому что действие одно и то же (снять галочку и подтвердить), просто повторённое системно.

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

Как посчитать реальную стоимость неиспользуемого места

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

Порядок расчёта:

1. Возьмите список всех подписок, тарифицируемых по местам (таск-трекеры, CRM, дизайн-инструменты, аналитика, коммуникационные платформы, сервисы для разработки).
2. В каждой зайдите в раздел управления пользователями и найдите колонку «последний вход» или «последняя активность» — она есть почти в любой административной панели.
3. Отметьте все аккаунты без входа за последние 30-45 дней (порог можно скорректировать под специфику инструмента — для сервиса, которым пользуются раз в квартал, 45 дней слишком жёстко).
4. Умножьте количество таких мест на стоимость одного места по вашему тарифу и просуммируйте по всем подпискам.

Условный пример для ориентира (реальные цифры у вас будут другими — это иллюстрация метода, а не норматив):

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

Отдельно стоит смотреть на годовые контракты: там неиспользуемое место оплачено на 12 месяцев вперёд одним платежом, и обнаружить его в середине срока — уже поздно возвращать деньги, но не поздно освободить место до продления. Про похожую логику накопленных мелких трат — в материале об аудите подписок и платежах-призраках.

Регулярный аудит активности: что и как проверять

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

Рабочая схема аудита раз в месяц или раз в квартал (частота зависит от размера команды — при штате до 15-20 человек хватает квартального цикла, при более активной ротации кадров лучше ежемесячно):

• Единый список подписок. Заведите таблицу или страницу со всеми SaaS-подписками по местам: название, ответственный, дата продления, цена за место, ссылка на панель управления пользователями. Без этого списка аудит каждый раз начинается с вопроса «а что у нас вообще есть» — и часто на этом же вопросе и заканчивается.
• Дата последнего входа по каждому пользователю. Большинство сервисов показывают её в интерфейсе администратора без дополнительной настройки. Там, где есть API, имеет смысл выгружать список одним запросом вместо ручного просмотра — особенно если подписок много.
• Сверка со списком уволенных и переведённых сотрудников за период. Это единственный пункт, который требует данных не из самого SaaS, а из HR. Если HR-процесс офбординга уже включает пункт «отозвать доступы», аудит подписок — это подстраховка на случай, если какой-то сервис выпал из чек-листа.
• Отдельная проверка тестовых и демо-аккаунтов. Их проще всего пропустить, потому что они формально не привязаны к штатному сотруднику. Стоит завести правило: любой тестовый доступ создаётся с пометкой в названии и дедлайном в календаре на отключение.

Пример простого скрипта-напоминания, если у сервиса есть API со списком пользователей и датой последней активности (псевдокод, структура API у каждого сервиса своя — проверяйте актуальную документацию конкретного инструмента):

#!/usr/bin/env bash
# audit-seats.sh — раз в месяц по cron, выводит места без входа 30+ дней
THRESHOLD_DAYS=30
NOW=$(date +%s)

curl -s -H "Authorization: Bearer $API_TOKEN" \
  "https://api.example-saas.com/v1/users" \
  | jq -r '.[] | [.email, .last_login] | @tsv' \
  | while IFS=$'\t' read -r email last_login; do
      last_ts=$(date -d "$last_login" +%s 2>/dev/null || echo 0)
      diff_days=$(( (NOW - last_ts) / 86400 ))
      if [ "$diff_days" -ge "$THRESHOLD_DAYS" ] || [ "$last_ts" -eq 0 ]; then
        echo "Проверить: $email — без входа $diff_days дней"
      fi
    done

Такой скрипт не отключает места автоматически — он только формирует список кандидатов на проверку, потому что финальное решение («это реально не нужно» или «человек в отпуске») всегда должен принимать человек, а не cron-задача.

Как построить процесс, чтобы места освобождались сами, а не по напоминанию

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

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

Триггер 2: закупка мест «с запасом». Если планируете нанять людей в течение квартала, разумнее держать в календаре дату ревизии — например, через 6-8 недель после покупки мест проверить, закрыт ли найм. Если нет — либо подождать ещё, либо временно вернуть тариф на меньшее число мест и докупить их точечно, когда человек выйдет. Не во всех тарифных планах это возможно без потери скидки за объём — это стоит уточнить до покупки, а не постфактум.

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

Особенности по типам SaaS: где места копятся быстрее всего

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

• Инструменты разработки и таск-трекеры. Высокий риск: подрядчики и стажёры подключаются на проект и отключаются часто, а место в трекере обычно живёт дольше, чем сам проект.
• CRM и продажи. Средний-высокий риск, особенно в компаниях с текучкой в отделе продаж — доступ к CRM обычно выдают быстро в первый день, а закрывают не всегда так же быстро.
• Аналитика и BI. Средний риск: часто покупают места «на весь менеджерский состав», но реально смотрят дашборды 2-3 человека, остальные заходили один раз при внедрении.
• Коммуникационные платформы. Низкий-средний риск для основного рабочего пространства (там активность видна сразу), но высокий для гостевых и внешних воркспейсов, которые заводят под конкретного клиента или партнёра и забывают закрыть после завершения работы.
• Дизайн и совместная работа над контентом. Средний риск: часто на проект временно подключают фрилансера с местом в подписке, а не через гостевой доступ, потому что так быстрее — и это место остаётся оплаченным дольше самого проекта.

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

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