Продажа облака компании с собственной инфраструктурой — не презентация, а сопровождение клиента через шесть этапов, где на каждом снимается конкретное возражение. Главная ошибка — говорить о технологии там, где нужно говорить о деньгах, сроках и рисках. Ниже разбор каждого шага и того, что на нём реально решается.
Почему обычная схема здесь не работает
Крупные компании в регионе до сих пор во многом опираются на собственные дата-центры. Для них переход в облако — не апгрейд, а смена модели: капитальные затраты превращаются в операционные, часть контроля уходит наружу, а служба безопасности получает новый класс вопросов, на которые у неё нет готовых ответов.
Отсюда следствие, которое определяет всю тактику: вы продаёте не сервисы, а изменение способа работы. Такое решение принимает не технический директор в одиночку — его принимает группа, где у каждого свои критерии. И почти всегда есть тот, кому переход невыгоден лично: у него уже есть подрядчик, компетенция или бюджет, привязанный к текущей схеме.
Поэтому фреймворк ниже устроен не как последовательность презентаций, а как последовательность снятых возражений — техническое, экономическое, организационное.
Шаг 1. Начать с потребности, а не с продукта
Первый разговор проваливается чаще всего одинаково: продавец приходит рассказать про облако. Клиент вежливо слушает и не покупает, потому что не услышал ничего про себя.
Задача первого шага — найти инициативу, которая уже существует внутри компании. Не создать её, а найти. Формулировки, которые работают: дата-центр переполнен и на горизонте дорогая закупка; конкурент запускает новое быстрее; закончилась поддержка ключевой платформы; регулятор изменил требования; после аварии стало ясно, что резервирования нет.
Зафиксируйте эту инициативу словами клиента и с цифрой. Не «ускорить вывод продуктов», а «сократить срок запуска нового сервиса с четырёх месяцев до шести недель». Дальше вы будете возвращаться к этой формулировке на каждом шаге, и она же станет критерием успеха.
Шаг 2. Связать задачу с сервисами, а не наоборот
На этом шаге ошибка обратная: продавец, разобравшись в потребности, вываливает список сервисов. Клиент видит незнакомые названия и делает вывод, что решение сложное.
Правило простое: каждый сервис называется только после того, как названа задача, и сразу переводится в последствие для клиента. Не «данные реплицируются между зонами размещения», а «при отказе площадки сервис продолжит работать, и вы не попадёте в ситуацию прошлого года». Не «инстансы поднимаются за минуты», а «новая среда для тестирования появляется в тот же день, а не через квартал после закупки».
Отдельно готовьтесь к техническим вопросам. Компания с собственной инфраструктурой спросит про безопасность, про то, где физически лежат данные, про интеграцию с тем, что остаётся у них. Уклончивый ответ здесь стоит дороже, чем честное «этого мы не знаем, выясню к пятнице».
Шаг 3. Подключить архитектора
В корпоративной сделке продавец в одиночку не проходит дальше третьей встречи. Нужен человек, который отвечает за техническую сторону и которому поверят инженеры заказчика.
Что даёт совместная работа. Во-первых, доверие: клиент видит, что решение прорабатывается, а не подбирается по прайсу. Во-вторых, ранние ограничения — архитектор находит проблему с сетевой связностью или требованием к размещению данных на этапе обсуждения, а не на внедрении. В-третьих, артефакт: схема на одну страницу, написанная языком заказчика, которую он сможет показать своему руководству без вас.
Здесь же обсуждаются неудобные вещи. Если у клиента есть требование хранить определённые данные внутри страны, об этом нужно говорить сразу и честно, показывая гибридные варианты. Попытка обойти вопрос молчанием заканчивается тем, что его поднимает служба безопасности за неделю до подписания.
Шаг 4. Пилот с критериями, а не демонстрация
Самая убедительная презентация проигрывает собственному опыту клиента. Но пилот работает, только если у него есть измеримые условия успеха, согласованные до начала.
Как выбрать пилот. Берите одну задачу из числа приоритетных, ограничьте срок несколькими неделями и договоритесь, что считается успехом. Не «попробуем облако», а «переносим это приложение, оно выдерживает двукратную нагрузку, время отклика не хуже текущего, восстановление после имитации отказа занимает меньше получаса».
Что даёт пилот помимо результата: клиент лично трогает облако и перестаёт его бояться; обе стороны находят проблемы заранее; появляются цифры, которые заказчик понесёт своему руководству. Последнее важнее всего — вы не убеждаете лицо, принимающее решение, вы вооружаете того, кто будет убеждать его вместо вас.
Шаг 5. Экономика: считаем владение, а не цену
Техническая состоятельность доказана — остаётся вопрос денег. И здесь решает не сравнение цен, а сравнение стоимости владения.
Начните с текущей картины и считайте всё: закупку и продление оборудования, электроэнергию и охлаждение, площадь, лицензии, поддержку, зарплаты тех, кто это обслуживает, стоимость простоев за прошлый год, вывод оборудования из эксплуатации. Скрытые статьи собственной инфраструктуры обычно оказываются больше очевидных, и заказчик сам этого не считал.
Отдельная статья, которую почти никогда не учитывают, — дефицит квалифицированных людей. Найти и удержать инженера, который поддерживает сложную локальную инфраструктуру на должном уровне, в регионе сложно и дорого. Это реальный фактор, и он звучит убедительно, потому что каждый технический руководитель это уже пережил.
Дальше покажите модель затрат в облаке честно: зарезервированные мощности для постоянной нагрузки, оплата по факту для переменной. Если в текущей схеме заказчик держит запас под пики, который простаивает одиннадцать месяцев в году, это и есть ваш главный аргумент.
Хорошая практика — сравнительный расчёт на три-пять лет. Не забудьте показать строки, невыгодные для вас: расчёт, где всё складывается в вашу пользу, вызывает недоверие у любого финансового директора.
И осторожно с типовыми процентами экономии. Заказанное AWS исследование даёт ориентир около трети экономии на инфраструктуре при переносе унаследованных приложений — но это средняя цифра по чужой выборке. В конкретном проекте она может быть другой, а иногда облако выходит дороже, и выигрыш лежит в скорости и гибкости, а не в прямой экономии. Об этом лучше сказать самому.
Шаг 6. Сопровождение: сделка это начало
Подписанный договор — не финал, а точка, где начинается настоящий риск. Проект, который не прижился, через год превращается в аргумент против вас на всём рынке.
Что делать. Обеспечить переход в эксплуатацию: мониторинг, журналирование, резервное копирование, обученные люди на стороне клиента. Договориться о регулярном разборе результатов — раз в квартал, с цифрами по тем метрикам, которые вы зафиксировали на первом шаге. Искать следующую инициативу: первый успешный перенос открывает разговор о втором, и лучше начать его вы, чем конкурент.
И отдельно — следить, чтобы счёт не рос сверх необходимого. Клиент, которому вы сами предложили оптимизацию и уменьшили его расход, становится источником рекомендаций. Клиент, обнаруживший неоправданный рост счёта самостоятельно, становится источником другого рода историй.
Как это выглядит целиком
| Шаг | Что снимаем | Признак, что можно идти дальше |
|---|---|---|
| 1. Потребность | Непонимание, зачем это им | Инициатива названа словами клиента и с цифрой |
| 2. Связка с сервисами | Ощущение сложности | Каждый сервис назван через последствие для бизнеса |
| 3. Архитектор | Недоверие инженеров | Есть схема, которую заказчик покажет сам |
| 4. Пилот | Страх неизвестности | Критерии выполнены, следующий этап согласован письменно |
| 5. Экономика | Возражение по деньгам | Расчёт владения принят финансовой стороной |
| 6. Сопровождение | Риск, что не приживётся | Прошёл первый квартальный разбор с цифрами |
Про кейсы, на которые принято ссылаться
Из публичных примеров промышленной трансформации хорошо работает история Volkswagen Group: концерн строит единую промышленную облачную платформу для своих производственных площадок — по данным официального кейса AWS, более ста двадцати заводов. Заявленные цели — рост производительности и сокращение операционных затрат заводов примерно на треть, а также экономия порядка миллиарда евро в цепочке поставок. Для разговора с промышленным заказчиком это сильный аргумент: если консервативнейшая отрасль доверила облаку критичную инфраструктуру, разговор о принципиальной невозможности закрыт.
Важная оговорка о региональных кейсах. В обзорах и презентациях по Центральной Азии часто ссылаются на историю одного финтеха как на официальный кейс AWS с гибридной архитектурой, одобренной регулятором. При проверке в сентябре 2026 года найти этот кейс на сайте AWS не удалось — ссылка ведёт на общий раздел. Возможно, материал убрали, как это регулярно происходит со старыми кейсами. Практический вывод: перед тем как ссылаться на кейс в коммерческом предложении, откройте ссылку. Заказчик, который её откроет и не найдёт, сделает выводы не о кейсе, а о вас.
Оговорка
Частые вопросы
Каждый шаг снимает одно конкретное возражение, и пропустить шаг нельзя — возражение вернётся позже и дороже. Самое опасное место — пятый шаг: там выигрывает не тот, у кого дешевле, а тот, кто честно посчитал владение целиком и показал невыгодные для себя строки.
Материал обновлён 5 сентября 2026