Как посчитать цену простоя для B2B-сервиса: формула без маркетинга

MAATRIX

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

Зачем вообще считать цену простоя в деньгах

Цена простоя — это не абстрактная метрика для отчёта, а конкретное число, с которым сравнивается стоимость защиты от простоя: второй сервер в резерве, geo-репликация базы, платный SLA поддержки хостинга, дежурство инженера ночью. Если резервирование стоит дороже, чем математическое ожидание потерь от простоя, оно экономически не оправдано — и наоборот. Без числа этот разговор превращается в спор ощущений: один считает «мы не можем себе позволить час простоя», другой — «за пять лет ничего серьёзного не падало, зачем платить вдвое».

Здесь важно сразу разделить два вопроса, которые часто путают: сколько стоит один конкретный инцидент (фактические данные по этому часу и этим клиентам) и сколько простой стоит в среднем (усреднённая величина для расчёта окупаемости резервирования). Формула ниже подходит для обоих случаев, но использовать в них нужно разные исходные данные — не среднегодовые вместо фактических и наоборот.

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

Прямые потери выручки: считаем среднечасовую ставку сервиса

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

Каркас расчёта:

Среднечасовая выручка = Выручка за расчётный период / Количество рабочих часов сервиса за этот период

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

• Клиент, оплативший месячную или годовую подписку, обычно не получает возврат денег за час недоступности — если это прямо не прописано в договоре (см. раздел про SLA ниже). Прямой потери выручки за этот конкретный час может не быть вовсе — деньги уже получены.
• Реальные потери в подписочной модели — это не «выручка за час», а риск оттока: часть клиентов, столкнувшихся с простоем, не продлит подписку или уйдёт к конкуренту. Это отдельная, куда более тяжёлая для расчёта величина, и она не равна среднечасовой ставке.
• Для транзакционных B2B-сервисов (платёжный шлюз, API с оплатой за вызов, маркетплейс с комиссией за сделку) прямая потеря ближе к истине: если сделки не произошли, комиссия не начислена, и её можно посчитать по фактическому трафику за аналогичные часы.

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

Стоимость команды: не только простой, но и реакция плюс разбор

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

Сюда входят минимум три фазы:

1. Реакция на инцидент — время от алерта до восстановления сервиса: дежурный инженер, а часто и второй-третий человек, подключённые для диагностики. Считается как количество вовлечённых человеко-часов, умноженное на их часовую стоимость для компании (не голая зарплата, а полная стоимость часа с учётом налогов и накладных — обычно это множитель 1.3–1.5 к окладу, но точный коэффициент нужно брать из вашей бухгалтерии, а не из общих ориентиров).
2. Пост-инцидентный разбор — время на восстановление хронологии, написание постмортема, встречу с командой, обсуждение исправлений. Это часто занимает больше времени, чем сам инцидент, особенно если причина не очевидна с первого взгляда. Как структурировать этот этап — отдельная тема, разобранная в статье про то, как писать разбор инцидента.
3. Коммуникация с клиентами — если у вас есть служба поддержки или аккаунт-менеджеры, которые в момент инцидента отвечают на тикеты и звонки, их время тоже часть стоимости, просто более рассеянная во времени (не в момент простоя, а в течение нескольких дней после).

Каркас:

Стоимость команды = Σ (человеко-часы каждого вовлечённого сотрудника × его часовая стоимость для компании)
                     по всем трём фазам: реакция + разбор + коммуникация

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

Репутационные издержки: не выдумываем цифру, но не игнорируем

Здесь маркетинговые калькуляторы обычно либо вообще не упоминают этот пункт, либо выдают псевдоточную цифру вида «репутационный ущерб составляет X% от годовой выручки» — и это число, как правило, ничем не обосновано и кочует из одной презентации в другую без источника.

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

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

Если вы всё же хотите включить репутационную составляющую в модель принятия решений, честнее сделать это через сценарный анализ («что если мы потеряем X% крупных клиентов в течение года после публичного простоя») с явно обозначенным диапазоном неопределённости, чем через одну ложно-точную цифру.

Договорные обязательства: штрафы и компенсации по SLA

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

Порядок действий:

1. Поднимите все действующие договоры с клиентами, где прописан SLA с финансовыми последствиями за его нарушение.
2. Для каждого договора выпишите формулу компенсации: обычно это процент от ежемесячного платежа за превышение допустимого простоя, иногда — ступенчатая шкала (чем ниже фактический аптайм, тем выше процент возврата).
3. Сопоставьте фактическую длительность простоя с уровнем SLA по каждому договору и посчитайте, попадает ли инцидент под компенсацию вообще — короткие сбои часто укладываются в допустимый месячный бюджет простоя и не требуют выплат.

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

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

Итоговая формула-каркас

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

Цена простоя (за конкретный инцидент) =

  Прямые потери выручки
    (для транзакционной модели: фактический объём операций за час × ставка;
     для подписочной модели: обычно ≈ 0, если нет прямого возврата денег)

+ Стоимость команды
    (человеко-часы реакции + разбор инцидента + коммуникация с клиентами)
    × полная часовая стоимость сотрудника для компании

+ Договорные выплаты по SLA
    (сумма компенсаций по всем договорам, где инцидент превысил допустимый простой)

+ [качественная оценка репутационного риска — не суммируется как число,
   учитывается отдельно при принятии решений о резервировании]

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

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

Как не дать себя обмануть маркетинговым калькулятором

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

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

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

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

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