B2B и enterprise: покупатель — не пользователь

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

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

1. Четыре роли вместо одной

1.1. Разделение, которое ломает привычные модели

Следствия для продуктовой работы, каждое из которых нарушается регулярно:

1. Ценность нужно формулировать дважды — на языке пользователя («не собираю отчёт руками каждое утро») и на языке покупателя («12 человеко-часов в неделю, 1,7 млн ₽ в год»).
2. Продуктовые метрики раздваиваются: активация пользователя не равна успеху аккаунта. Аккаунт может платить год, пока в нём активны 3 человека из 200 — и не продлиться.
3. Отказ приходит не от того, кто не любит продукт. Сделка чаще умирает у блокера, чем у пользователя; значит, часть роадмапа — это ответы блокерам (раздел 6).
4. Обратная связь искажена ролью. Просьбы, которые приносят продажи, — это почти всегда голос покупателя и чемпиона, а не пользователя. Их нужно взвешивать отдельно.

1.2. Как выглядит путь сделки

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

1.3. Чемпион — это ваш продукт-менеджер внутри клиента

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

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

2. Пилот: как не превратить его в бесплатную разработку

2.1. Анатомия пилота

2.2. Правила, без которых пилот тянется вечно

• Критерий успеха записан до старта и сформулирован в терминах клиента, а не вашей телеметрии («время подготовки отчёта сократилось с 4 часов до 30 минут на выборке из 10 отчётов»).
• Ограничен по времени и объёму. Бессрочный пилот — это бесплатная эксплуатация; 4–8 недель достаточно почти всегда.
• Есть явное «что будет после». Цена и условия обсуждены до начала, а не после успеха — иначе пилот превращается в рычаг для скидки.
• Доработки только под критерий. Любая просьба «а ещё бы нам…» записывается, но делается только если блокирует согласованный сценарий.
• Считается использование. Пилот без телеметрии бесполезен: вы не сможете отличить «не понравилось» от «не попробовали».

Отдельно про бесплатные пилоты: они снижают барьер, но и снижают приоритет у клиента. Платный пилот (даже символически) на порядок повышает шанс, что на стороне клиента выделят людей и время.

3. Sales-led, PLG и гибрид

3.1. Три модели

• Sales-led: сначала разговор, потом продукт. Подходит, когда чек большой, внедрение сложное, а решение принимает не пользователь.
• Product-led (PLG): сначала продукт, потом разговор. Работает, когда пользователь может получить ценность сам за минуты, а покупка малого объёма не требует бюджетного комитета.
• Гибрид (сегодня — дефолт в B2B-SaaS): самостоятельный вход снизу, продажа сверху, когда использование внутри аккаунта переходит порог.

Выбор определяется не модой, а тремя параметрами: время до первой ценности, размер чека и кто может начать без разрешения. Если пользователю нужно подключить корпоративную БД и получить согласование ИБ, чтобы просто попробовать, — PLG не заработает, сколько ни улучшай онбординг.

3.2. PQL: продуктовый сигнал вместо холодного звонка

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

from dataclasses import dataclass


@dataclass(frozen=True)
class AccountUsage:
    account: str
    active_users_14d: int
    seats_paid: int
    departments: int          # сколько разных отделов затронуто
    core_action_30d: int      # ключевое действие, определяющее ценность
    limit_usage: float        # доля от лимита тарифа, 0..1


def pql_score(u: AccountUsage) -> dict:
    """Простой аддитивный скоринг PQL с понятными правилами.

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

    Время: O(1), память: O(1).
    """
    seat_pressure = u.active_users_14d / max(u.seats_paid, 1)
    score = 0
    reasons = []

    if seat_pressure >= 1.2:
        score += 35
        reasons.append("активных больше, чем оплачено")
    if u.departments >= 2:
        score += 25
        reasons.append("вышли за пределы одного отдела")
    if u.limit_usage >= 0.8:
        score += 20
        reasons.append("упираются в лимит тарифа")
    if u.core_action_30d >= 50:
        score += 20
        reasons.append("сценарий стал регулярным")

    tier = "hot" if score >= 60 else "warm" if score >= 35 else "cold"
    return {"account": u.account, "score": score, "tier": tier, "reasons": reasons}


print(pql_score(AccountUsage("ООО Ромашка", 31, 20, 3, 140, 0.86)))
# {'account': 'ООО Ромашка', 'score': 100, 'tier': 'hot',
#  'reasons': ['активных больше, чем оплачено', 'вышли за пределы одного отдела',
#              'упираются в лимит тарифа', 'сценарий стал регулярным']}

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

3.3. Land and expand

Стратегия «зайти малым и вырасти внутри» опирается на конкретную продуктовую работу:

1. Land: минимальный полезный кусок, который один отдел внедряет без согласований.
2. Adopt: пользователи возвращаются сами (не потому, что велели).
3. Expand: появляются соседние отделы, сценарии, интеграции.
4. Standardize: продукт становится частью процесса компании, замена дорога.

Продуктовые рычаги на каждом шаге разные: для land — время до первой ценности и отсутствие требований к ИТ; для expand — совместная работа, роли и права, шаринг результатов внутрь компании; для standardize — интеграции, аудит, администрирование. Механика расширения выручки и NRR разобрана в https://courses.digitable.life/post/product-management/07-pricing-and-growth/.

4. Роадмап под давлением сделок

4.1. Проблема

Каждая крупная сделка приходит со списком «сделаете — купим». Если соглашаться, роадмап превращается в очередь заказной разработки: команда строит функции, которыми пользуется один клиент, поддерживает их вечно, а стратегия (https://courses.digitable.life/post/product-management/04-strategy-and-roadmap/) существует только на слайде. Если отказывать всем — компания теряет выручку, а продакт теряет доверие продаж.

Работающая позиция посередине и состоит из трёх частей: классификация запроса, расчёт окупаемости и правила обещаний.

4.2. Классификация: конфигурация, платформа, кастом

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

4.3. Считаем, стоит ли делать под одного клиента

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

def custom_feature_case(
    contract_year: float,      # годовая выручка, которую разблокирует фича, ₽
    gross_margin: float,       # валовая маржа, 0..1
    build_weeks: float,        # разработка, человеко-недели
    week_cost: float,          # стоимость человеко-недели, ₽
    yearly_maintenance: float, # доля стоимости постройки, уходящая на поддержку ежегодно
    years: int = 3,
    discount: float = 0.15,
    renewal_prob: float = 0.85,
    focus_penalty: float = 0.25,  # надбавка за расфокус команды
) -> dict:
    """NPV кастомной функции под одного клиента.

    Учитывает три вещи, которые обычно забывают:
      1) поддержка платится каждый год, а не один раз;
      2) контракт может не продлиться (renewal_prob в степени года);
      3) команда теряет темп на переключении (focus_penalty).

    Время: O(years), память: O(1).
    """
    build = build_weeks * week_cost * (1 + focus_penalty)
    npv = -build
    alive = 1.0
    for year in range(years):
        alive = alive * (renewal_prob if year else 1.0)
        revenue = contract_year * gross_margin * alive
        upkeep = build * yearly_maintenance
        npv += (revenue - upkeep) / (1 + discount) ** year
    return {
        "build_cost": round(build),
        "npv": round(npv),
        "verdict": "делать" if npv > 0 else "отказать или продать дороже",
    }


print(custom_feature_case(contract_year=3_000_000, gross_margin=0.75,
                          build_weeks=10, week_cost=250_000,
                          yearly_maintenance=0.20))
# {'build_cost': 3125000, 'npv': 1953426, 'verdict': 'делать'}

print(custom_feature_case(contract_year=900_000, gross_margin=0.75,
                          build_weeks=10, week_cost=250_000,
                          yearly_maintenance=0.20))
# {'build_cost': 3125000, 'npv': -1288581, 'verdict': 'отказать или продать дороже'}

Второй пример — типичная ситуация, в которой сделка выглядит привлекательно («три четверти миллиона в год!»), а решение отрицательное. Из этого расчёта рождаются рабочие альтернативы: поднять цену за кастом, разделить стоимость разработки с клиентом, сделать урезанную версию, предложить платформенное расширение или честно отказаться. Обратите внимание: даже положительный NPV не означает автоматическое «да» — фича всё ещё конкурирует за ту же ёмкость с остальным бэклогом по правилам https://courses.digitable.life/post/product-management/03-prioritization/.

4.4. Правила обещаний

1. Никаких дат без команды. Продажи не называют сроки, не согласованные с продуктом; продукт называет вероятностные окна, а не точки (https://courses.digitable.life/post/product-management/04-strategy-and-roadmap/).
2. Три категории ответа: «есть», «будет — вот в каком квартале», «не будет — вот как решают это другие клиенты». Третий ответ — самый ценный и самый редкий.
3. Все обязательства в одном журнале: кому, что, к какому сроку, кто согласовал. Иначе через полгода никто не помнит, а клиент помнит.
4. Roadmap-звонок вместо роадмап-документа. Внешний роадмап показывают в формате «направления и Now/Next/Later», без дат и без списка задач.
5. Отказ объясняется. «Нет, потому что это нужно одному клиенту из ста, а стоит квартал» — нормальный ответ, который сохраняет отношения. «Мы подумаем» — не ответ.

5. Внедрение и жизненный цикл аккаунта

5.1. Аккаунт как объект со своим состоянием

Два состояния заслуживают отдельного внимания.

Застрял. Классическая B2B-патология: договор есть, деньги пришли, продукт не используется. Через год такой клиент не продлевается, и это выглядит внезапно, хотя было предсказуемо с первой недели. Лечится продуктом (сокращать время до первой ценности, показывать прогресс внедрения), а не только людьми.

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

5.2. Данные, без которых B2B-аналитика не существует

В B2C единица анализа — пользователь. В B2B их две: пользователь и аккаунт, и метрики нужно считать на обоих уровнях.

Такая модель позволяет отвечать на вопросы, недоступные при пользовательской аналитике: какая доля оплаченных мест реально используется, сколько отделов вовлечено, растёт ли использование перед продлением, коррелирует ли число тикетов с оттоком, и — отдельной сущностью — какие обещания кому даны. Общая гигиена событийной модели и tracking plan — в https://courses.digitable.life/post/product-management/08-analytics-and-decisions/.

6. Enterprise-гигиена: набор, без которого не пускают

Эти функции почти никогда не приносят радости пользователю и почти всегда определяют, состоится ли сделка. В терминах Кано (https://courses.digitable.life/post/product-management/03-prioritization/) это чистые must-be: их наличие не замечают, отсутствие блокирует.

Технические детали разбираются в соседних треках: аутентификация и SSO — https://courses.digitable.life/post/security/06-oauth-and-oidc/, модели доступа — https://courses.digitable.life/post/security/08-authorization/, приватность и соответствие — https://courses.digitable.life/post/security/15-privacy-and-compliance/, уровни изоляции клиентов — https://courses.digitable.life/post/software-distribution/03-multitenancy/, SLA и цели надёжности — https://courses.digitable.life/post/sre/02-sli-slo/.

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

Отдельный совет: заведите опросник безопасности как продукт. Стандартный документ с ответами на 100 типовых вопросов, обновляемый раз в квартал, экономит недели на каждой сделке и снимает с инженеров повторяющуюся работу.

7. Метрики B2B

7.1. Что смотреть

• ARR / ACV — годовая повторяющаяся выручка и средний размер контракта.
• Logo retention и net revenue retention. Разница между ними — вся суть B2B: можно терять 10% клиентов в год и расти на 120% по выручке за счёт расширения. Формулы и подводные камни — https://courses.digitable.life/post/product-management/07-pricing-and-growth/.
• Seat adoption — доля оплаченных мест, реально активных за 30 дней. Лучший ранний предиктор непродления.
• Depth: число отделов и сценариев в аккаунте.
• Time to value — дни от подписания до первого результата. Прямо влияет на продление.
• Концентрация выручки — какая доля денег приходится на крупнейших клиентов.

7.2. Концентрация: риск, который заметен только числом

def revenue_concentration(arr_by_account: dict) -> dict:
    """Концентрация выручки: доля топ-клиентов и индекс Херфиндаля (HHI).

    HHI = сумма квадратов долей. 1.0 — весь доход от одного клиента,
    близко к 0 — идеально распылён. Порог тревоги в B2B-SaaS: HHI > 0.15
    или доля топ-3 больше трети выручки.

    Время: O(n log n) из-за сортировки, память: O(n).
    """
    total = sum(arr_by_account.values())
    shares = sorted((v / total for v in arr_by_account.values()), reverse=True)
    hhi = sum(s * s for s in shares)
    return {
        "top1": round(shares[0], 3),
        "top3": round(sum(shares[:3]), 3),
        "hhi": round(hhi, 3),
        "alert": hhi > 0.15 or sum(shares[:3]) > 0.33,
    }


print(revenue_concentration({"А": 30_000_000, "Б": 12_000_000, "В": 9_000_000,
                             "Г": 4_000_000, "Д": 3_000_000, "прочие": 22_000_000}))
# {'top1': 0.375, 'top3': 0.638, 'hhi': 0.213, 'alert': True}

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

8. Как это выглядит в проде

• Еженедельная встреча продукта и продаж на 30 минут: топ-5 причин проигрыша за неделю, новые запросы, статус обещаний. Без неё запросы приходят через эскалации.
• Единый журнал обязательств (см. таблицу COMMITMENT выше), доступный обеим сторонам.
• Квартальный обзор аккаунтов: seat adoption, глубина, риски, обещания. Продакт участвует — не для продажи, а чтобы видеть реальность внедрения.
• Опросник безопасности и архитектурная справка как поддерживаемые артефакты.
• Разделение бэклога на «ядро стратегии», «enterprise-гигиена» и «сделочные запросы» с явными квотами ёмкости, например 60/25/15. Квота — это способ говорить «нет», не вступая в спор каждый раз (https://courses.digitable.life/post/product-management/03-prioritization/, раздел про MoSCoW).

9. Типичные ошибки

• Считать активацию только по пользователям. Аккаунт с высокой активацией трёх человек из двухсот — кандидат на отток.
• Слушать только продажи. Их голос — это голос покупателя; голос пользователя нужно добывать отдельно, интервью и наблюдением (https://courses.digitable.life/post/product-management/01-discovery-and-research/).
• Соглашаться на кастом ради закрытия квартала. Разработка разовая, поддержка вечная; считайте NPV, а не сумму контракта.
• Бесконечный пилот. Без критерия и срока он становится бесплатной эксплуатацией.
• Откладывать enterprise-гигиену до последнего. SSO, права и аудит-логи — это не «скучные фичи», а разблокированные сделки.
• Игнорировать концентрацию выручки. Один клиент на 40% — это внешнее управление роадмапом.
• Обещать даты. Каждое невыполненное обещание стоит дороже, чем отсутствие функции.
• Считать, что внедрение — не продуктовая работа. «Застрявшие» аккаунты — это дефект продукта, а не лень клиента.

10. Мини-итог

• В B2B роли платящего, решающего, использующего и блокирующего разделены; ценность нужно формулировать на языке каждого, а метрики считать и на пользователе, и на аккаунте.
• Пилот полезен только с записанным критерием успеха, сроком, объёмом и телеметрией.
• Модель продажи выбирается по времени до ценности, размеру чека и тому, может ли пользователь начать без разрешения; гибрид с PQL — современный дефолт.
• Давление сделок на роадмап лечится классификацией запросов (конфигурация / обобщаемое / платформа / кастом), расчётом NPV с учётом вечной поддержки и правилами обещаний.
• Жизненный цикл аккаунта содержит два опасных состояния: «застрял» и «ушёл чемпион» — оба лечатся продуктом, а не только людьми.
• Enterprise-гигиена (SSO, права, аудит, SLA, резидентность) приоритизируется по объёму заблокированных денег, а не по числу просьб.
• Концентрация выручки — продуктовая метрика: высокий HHI означает, что роадмапом управляет чужой отдел закупок.

Источники

• Mark Roberge, «The Sales Acceleration Formula» — как устроена повторяемая B2B-продажа: https://www.markroberge.com/
• Wes Bush, «Product-Led Growth» — критерии применимости PLG: https://productled.com/book/product-led-growth
• OpenView, «Product Qualified Leads» — определения и практика PQL: https://openviewpartners.com/product-led-growth/
• Elena Verna о гибридных моделях роста и land-and-expand: https://www.lennysnewsletter.com/p/how-to-know-if-plg-is-right-for-you
• Christopher Lochhead, Al Ramadan, Dave Peterson, «Play Bigger» — про создание категории в B2B: https://www.playbigger.com/
• Google SRE Workbook, «Implementing SLOs» — как формулировать обязательства по надёжности, которые попадают в договор: https://sre.google/workbook/implementing-slos/

Что дальше

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

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