Вопросы покупателя до подключения юристов

Почему этот этап тормозит сделку

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

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

Сами вопросы обычно простые. Задержка начинается тогда, когда ответы звучат неуверенно или меняются в зависимости от того, кто говорит. Sales утверждает, что доступ жёстко ограничен. Engineering признаёт, что у нескольких человек всё ещё общий админский доступ, потому что так быстрее. Customer success обещает быстрые ответы, но часы поддержки нигде не записаны. Такие мелкие пробелы делают риск в глазах покупателя больше, чем реальная выгода.

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

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

Когда ничего из этого не записано, люди отвечают по памяти. Вот тут сделки и начинают буксовать. Одно письмо превращается в шесть. Один звонок с покупателем превращается в переписку с sales, engineering и legal, которые пытаются сказать одно и то же разными словами.

Короткий лист фактов решает больше проблем, чем ожидают многие основатели. Одна страница с простыми ответами, проверенная sales и engineering, быстро снимает путаницу. Ей не нужен юридический язык. Ей нужны ясные факты, которые все в вашей компании могут повторить одинаково.

Что покупатели обычно хотят подтвердить

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

Чаще всего сначала спрашивают про доступ. Покупатель хочет услышать, что к продакшен-системам или данным клиентов могут подходить только конкретные люди, что доступ соответствует обязанностям каждого сотрудника и что вы быстро убираете его, когда человек меняет роль или уходит. Общие логины вызывают тревогу. Как и расплывчатый ответ вроде «при необходимости зайти может команда engineering».

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

Логи важны по той же причине. Если что-то пойдёт не так, сможете ли вы понять, что произошло? Большинство покупателей ожидает логи входов в систему, действий администратора, изменений в продакшене и серьёзных ошибок. Им также нужен понятный срок хранения. Фраза «у нас есть логи» слишком общая. «Мы храним логи доступа X дней, а audit logs — Y дней» вызывает гораздо больше доверия.

Покрытие поддержки часто решает, будет ли сделка двигаться дальше. Покупатель хочет знать, когда support отвечает, что считается срочным случаем и кто дежурит вечером, ночью или в выходные. Если после рабочего времени поддержку обеспечивает один основатель, который проверяет сообщения, когда просыпается, скажите это прямо. Большинство покупателей не ждут идеала. Им нужно понять, что у вас схема настоящая.

Важен и владелец каждого блока. У каждого ответа внутри компании должен быть свой ответственный. Обычно инженерный лидер отвечает за бэкапы и восстановление. CTO или security lead — за доступ и права. Руководитель поддержки объясняет время реакции и эскалацию. Кто-то ещё должен хранить финальные ответы в одном месте, чтобы покупатели каждый раз слышали одну и ту же версию.

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

Как подготовить ответы

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

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

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

Хорошо работает простой формат. Начните с одного прямого предложения, которое отвечает на вопрос. Затем добавьте одну-две строки о том, как это устроено сейчас. Вставьте число или временной интервал, например частоту бэкапов или время реакции поддержки. Закончите тем, кто за это отвечает.

Цифры успокаивают людей. «Мы делаем бэкап production data каждые 6 часов и тестируем восстановление раз в месяц» звучит лучше, чем «мы регулярно делаем бэкапы». «К доступу к продакшену имеют право два инженера» звучит лучше, чем «доступ ограничен».

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

И наконец, сверяйте формулировки между командами. Sales не должна говорить «поддержка 24/7», если engineering имеет в виду «уведомления после работы только по инцидентам в продакшене». Такое расхождение создаёт больше трения, чем скромная, но честно описанная политика поддержки.

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

Доступ и права

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

Начните с ролей, а не с инструментов. Назовите людей или типы должностей, которые могут иметь доступ к продакшен-системам и данным клиентов. У многих команд этот список короткий: основатели или senior engineers с админскими обязанностями, владельцы инфраструктуры и сотрудники поддержки с ограниченным доступом по конкретным случаям. Если доступ получают подрядчики, скажите об этом прямо и объясните ограничения.

Если ваша support-команда по умолчанию не видит полные данные клиентов, скажите это ясно. Если инженеры используют отдельные админские аккаунты для продакшена, тоже упомяните это. Небольшие детали делают ответ живым и убедительным.

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

Вывод доступа при увольнении важен не меньше. Скажите, кто убирает доступ, из каких систем вы его снимаете и как быстро это происходит. Хорошо работает простой ответ: команда отключает почту, VPN, облачные аккаунты, систему контроля кода и внутренние инструменты в последний рабочий день или раньше, если уход срочный. Если за этим чек-листом закреплена одна роль, назовите её.

Подрядчики заслуживают отдельного предложения. Некоторые покупатели спрашивают о них сразу, потому что внешний персонал может создавать дополнительный риск. Если подрядчики получают те же права, что и сотрудники, скажите это и объясните почему. Если доступ у них меньше, объясните ограничения, например временные аккаунты или отсутствие прямого доступа к продакшену без одобрения senior сотрудника.

Держите подтверждения под рукой для следующего этапа. Скриншоты настроек ролей, форма запроса доступа, чек-лист на увольнение или группы в identity provider могут сэкономить дни переписки. Не обязательно отправлять всё на первом звонке, но вы должны знать, где это лежит.

Бэкапы, логи и поддержка

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

Начните с бэкапов. Скажите точно, что именно вы бэкапите, как часто это делаете и покрывает ли резервная копия только базу данных или ещё файлы, конфигурации и другие важные данные приложения. Фраза «Мы делаем бэкап production PostgreSQL каждые 6 часов, храним ежедневные снимки 30 дней и раз в день сохраняем загруженные файлы» звучит намного сильнее, чем «мы регулярно сохраняем данные».

Укажите, где лежат эти бэкапы. Покупатели часто спрашивают, храните ли вы их в том же облачном аккаунте, в отдельном регионе или у другого провайдера. Им также важно знать, кто может запустить восстановление. Назовите роль, а не только человека. Например: «Запустить restore могут только senior engineers и CTO, и каждое действие по восстановлению мы логируем».

Логи важны по двум причинам: безопасность и поддержка. Security logs должны показывать входы в систему, неудачные попытки входа, изменения прав, действия администратора и доступ к чувствительным разделам. Support logs должны помогать команде отслеживать ошибки, сбои и проблемы, о которых сообщили клиенты, без догадок.

Срок хранения тоже важен. Если вы храните логи 7 дней, скажите 7 дней. Если audit logs хранятся год, а application logs — 30 дней, скажите это прямо. Покупатели не ждут, что каждая компания хранит всё вечно. Они ждут реальную политику.

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

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

Простой пример на фоне растущей SaaS-команды

Команда из 14 человек проходит демо продукта, разговор о цене и хороший звонок с покупателем. Потом кто-то задаёт простой вопрос: «Кто сегодня может открыть production database?» Основатель отвечает по памяти. Он называет себя, руководителя engineering и одного senior developer.

Примерно на шесть часов это звучит нормально.

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

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

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

Компания может ответить на всё, но не из одного места. Engineering знает расписание бэкапов. Основатель помнит, что обещал на звонках с продажами. Support знает, кто проверяет срочные тикеты ночью. У команды нет короткого документа, который соответствует реальной работе.

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

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

Короткий внутренний документ сэкономил бы эту неделю. В нём было бы всего четыре вещи: кто сегодня имеет доступ к продакшену, как команда убирает старые аккаунты, где запускаются бэкапы и кто может восстановить данные, а также какие часы поддержки и on-call покрытие реально есть у команды.

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

Ошибки, которые заставляют покупателей нервничать

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

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

Конкретика помогает. Фраза «Доступ к продакшену: CTO и один senior engineer» вызывает гораздо больше доверия, чем «доступ к продакшену жёстко контролируется». То же самое относится к платёжным системам, инструментам поддержки клиентов и внутренним админ-панелям.

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

Поддержка постоянно выпадает из поля зрения. Основатель говорит: «Мы поддерживаем клиентов семь дней в неделю», хотя правда ближе к «срочные вопросы после работы мы смотрим, когда кто-то увидит уведомление». Это не одно и то же. Покупателю нужно понимать, у вас поддержка в рабочие часы, настоящая on-call схема или помощь по возможности вне обычного времени.

С бэкапами тоже часто теряется доверие. Многие команды утверждают, что бэкапы есть, потому что в базе включена настройка или облачный провайдер говорит о снапшотах. Покупатели обычно задают следующий очевидный вопрос: когда вы в последний раз восстанавливались из такого бэкапа? Если restore никто не тестировал, ответ слабый. Бэкап действительно считается только тогда, когда команда может восстановить данные и сказать, сколько это занимает.

Sales тоже может всё ухудшить, если пообещает больше, чем команда реально может дать. Обычно это происходит, когда сделка разогрета и всем хочется сохранить темп. Менеджер говорит, что у вас уже есть enterprise logging, поддержка 24/7, кастомные настройки доступа или время реакции в один час. Потом технической команде приходится это откатывать. Немногие вещи ломают доверие быстрее.

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

Быстрая проверка перед следующим звонком с покупателем

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

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

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

Последовательность важнее блеска. Маленькой SaaS-команде не нужен корпоративный язык. Ей нужны понятные правила, реальные цифры и ответы, которые не меняются от звонка к звонку.

Хороший тест — попросить коллегу сыграть покупателя и задать пять простых вопросов подряд. У кого есть доступ к продакшену? Как часто вы делаете бэкап данных? Как долго храните логи? Кого уведомляют, если ночью что-то сломается? Кто отвечает клиентам по выходным? Если ответы звучат чётко и совпадают с вашими инструментами, у вас всё в порядке.

Если после звонка нужно отправить follow-up заметки, отправляйте те же цифры и те же формулировки. Такая стабильность строит доверие быстрее, чем отшлифованный слайд.

Что делать дальше

Относитесь к текущим ответам как к рабочему инструменту продаж, а не как к куче заметок в Slack или у кого-то в голове. Когда крупные покупатели дважды задают одни и те же вопросы, это сигнал превратить ответы в короткий лист due diligence.

Сделайте его простым и коротким. На этом этапе часто хватает одной-двух страниц. Покупателям обычно нужны ясные ответы на вопросы о том, кто получает доступ, как вы его убираете, как работают бэкапы, какие логи вы храните и когда доступна поддержка.

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

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

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

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

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

Если ответы всё ещё кажутся рыхлыми, поможет внешний разбор. Oleg Sotnikov на oleg.is работает как Fractional CTO и советник для стартапов, и именно такую операционную доводку он помогает командам подтянуть до того, как перспективная сделка застынет.