Марк Тьюрин
Сделка с организацией: Пошаговый путь поставщика к первому контракту

Почему организации покупают не продукт, а предсказуемый результат

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

Марина Орлова из региональной сети строительных магазинов выслушала его до слайда про мобильное приложение, а потом спросила:

— Сколько времени у нас займёт переход?

— Обычно две-три недели на один объект, — ответил Андрей.

— А если сотрудники не будут вносить данные?

Андрей открыл рот, но не сразу нашёл ответ. В презентации было написано, что система «повышает дисциплину учёта». Там не было сказано, кто каждый вечер проверяет расхождения, что происходит при сбое интернета в магазине и кто отвечает за остатки в переходный период.

Марина пролистала несколько страниц.

— Вы продаёте программу?

— Сервис автоматизации складского учёта.

— Я спрашиваю не о названии. Что изменится у нас через месяц после запуска?

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

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

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

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

Характеристика, выгода и результат

Представьте, что вы продаёте не сервис, а обычный бытовой предмет. Производитель термоса говорит: «Двойные стенки из нержавеющей стали, объём 0,7 литра, герметичная крышка». Это характеристики. Они описывают устройство товара, но не объясняют, зачем он нужен конкретному человеку.

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

Но результат звучит иначе: «Вы берёте горячий обед на смену и получаете его тёплым через шесть часов, не рискуя залить документы в рабочей сумке». Результат связан с ситуацией, временем, риском и конкретным действием пользователя.

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

Разницу удобно проверять вопросом: «Что заказчик сможет сделать, получить или перестать терять после покупки?»

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

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

Характеристика «обучение сотрудников» превращается в выгоду «персонал умеет работать в системе». Результат: «Новый кладовщик осваивает приёмку за одну смену по короткому сценарию и не зависит от единственного опытного сотрудника».

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

Именно поэтому фраза «у нас есть удобная платформа» почти бесполезна. Удобная для кого? В каком процессе? По сравнению с чем? Как заказчик поймёт, что внедрение окупилось или хотя бы оправдало затраты?

Проверка на примере «Северного учёта»

Первая версия предложения Андрея выглядела так:

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

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

Андрей мог бы перевести предложение в рабочую гипотезу так:

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

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

В новой формулировке появились четыре элемента.

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

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

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

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

Кто чувствует проблему, а кто принимает решение

Андрей сначала думал, что его собеседник — Марина. Она отвечает за закупки, значит, именно ей нужно доказать ценность сервиса. После первой встречи Ирина Белова, операционный руководитель «Северного учёта», задала ему простой вопрос:

— А Марина сама каждый вечер сводит остатки?

— Нет, наверное, этим занимаются управляющие магазинов.

— Тогда почему ты рассказывал ей о скорости работы кладовщика?

Этот вопрос вскрыл типичную путаницу. В организации у проблемы и решения почти никогда нет одного владельца. Один человек живёт с последствиями сбоя. Другой формулирует требования. Третий согласует бюджет. Четвёртый проверяет договор и безопасность. Пятый будет пользоваться системой каждый день. Иногда все эти роли выполняет один руководитель, но рассчитывать на это не стоит.

Для поставщика полезно различать пять ролей.

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

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

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

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

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

Одна и та же ценность звучит для этих ролей по-разному. Пользователю нужно сказать: «При пересчёте товар сканируется по короткому сценарию, а спорные позиции попадают в отдельный список». Руководителю: «Вы видите, где именно возникло расхождение и какой магазин требует проверки». Финансовому директору: «На пилоте мы сравним затраты времени и количество корректировок с текущим процессом». Закупщику: «Есть этапы, сроки, ответственные, порядок приёмки и понятные условия поддержки».

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

Разговор с закупщиком

На второй встрече Марина могла бы сказать:

— У нас уже есть учётная система. Зачем нам ещё один сервис?

Слабый ответ звучит так:

— Наш сервис современнее и удобнее. В нём больше функций, есть мобильное приложение и гибкие настройки.

Сильнее ответить вопросом, который не уходит от сути:

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

После ответа Марины Андрей мог бы продолжить:

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

Здесь поставщик не спорит с текущей системой и не объявляет её устаревшей. Он уменьшает масштаб решения до проверяемого участка.

Если Марина отвечает: «Нам нужно только сравнить цены», не следует немедленно отправлять прайс. Можно сказать:

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

Если собеседник говорит: «Пришлите общую презентацию», уместно отправить короткий материал, но не останавливаться на нём:

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

Такой ответ превращает презентацию из каталога функций в повод для предметного разговора.

Цена бездействия

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

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

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

Андрей сначала говорил Марине:

— Наш сервис стоит 480 тысяч рублей за внедрение и 65 тысяч в месяц за сопровождение.

Ирина попросила его собрать другую картину:

— Сколько часов в неделю потенциальные пользователи тратят на сверку? Сколько стоит час их работы? Сколько раз в месяц возникает корректировка? Какие решения откладываются из-за недоверия к остаткам?

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

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

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

Это звучит скромнее, зато выдерживает проверку.

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

Доказательство надёжности важнее впечатляющей презентации

Когда поставщик неизвестен, заказчик оценивает не только полезность продукта. Он пытается предсказать поведение поставщика после подписания договора.

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

Надёжность — это не заявление «мы ответственные», а набор наблюдаемых доказательств.

Сроки подтверждаются планом с этапами, результатами и ответственными. Не «внедрение в течение месяца», а «до 5-го числа — обследование процесса, до 10-го — настройка справочников, до 15-го — тестирование на двух точках, до 20-го — обучение, до 25-го — запуск пилота».

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

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

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

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

На встрече Андрей мог сказать:

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

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

Четыре ошибки в первых предложениях

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

Вторая — обещать финансовый эффект без исходных данных. «Сократим расходы на 30 процентов» выглядит эффектно, но вызывает вопросы: от какой базы, за какой период и за счёт чего? Исправление: сначала определить показатели, затем подтвердить изменение.

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

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

Первая версия ценностного предложения «Северного учёта»

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

Фраза «облачный сервис» отвечала на вопрос о технологии, но не о задаче сети. Её оставили только в техническом описании.

Фраза «остатки в режиме реального времени» оказалась слишком широкой. В некоторых операциях данные появлялись с задержкой, а сама по себе скорость обновления не гарантировала точности. Формулировку заменили на более честную: «Данные по операциям отображаются в едином интерфейсе после подтверждения операции; задержки и исключения фиксируются отдельно».

Фраза «сокращает количество ошибок» требовала доказательств. Её заменили на план проверки: «На пилоте сравниваем количество ручных корректировок и расхождений по выбранным группам товара до и после запуска».

Фраза «быстрое внедрение» тоже не выдерживала уточнения. Быстрое для кого? При каких исходных данных? С каким участием заказчика? В новой версии появились зависимости: «Пилот на двух магазинах — до четырёх недель при готовых справочниках, назначенных ответственных и доступе к тестовым данным».

После разбора предложение стало выглядеть так:

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

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

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

Формула здесь не магическая, но рабочая:

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

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

Короткая практика: перевести продукт на язык заказчика

Возьмите один свой продукт или услугу и запишите три версии описания.

Сначала — характеристику. Что входит в продукт, из каких модулей он состоит, какие функции доступны?

Затем — выгоду. Что становится удобнее, быстрее, дешевле или безопаснее благодаря этой характеристике?

Наконец — результат. Что конкретно меняется в работе заказчика, кто это замечает, за какой срок и по какому признаку?

Например:

Характеристика: «Мы внедряем электронный маршрут согласования заявок».

Выгода: «Сотрудникам не нужно пересылать документы по почте и уточнять статус в нескольких чатах».

Результат: «Руководитель видит все заявки на закупку в одном списке, а средний срок согласования можно сравнить с текущим показателем и сократить за счёт устранения ручных пересылок».

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

Теперь сформулируйте первую гипотезу ценности по шаблону:

«Для [конкретный тип организации], у которой [наблюдаемая проблема], мы предлагаем [первый шаг или решение], чтобы проверить [измеримый результат]. Надёжность обеспечиваем через [доказательство: опыт, план, пилот, критерии приёмки, поддержку]. Решение имеет смысл масштабировать, если [условие перехода]».

Например:

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

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

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

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

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

Портрет заказчика без догадок

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

У Андрея Власова сначала был именно такой список. В нём соседствовали небольшая сеть строительных магазинов с четырьмя точками, федеральный дистрибьютор, муниципальное учреждение и компания, которая вообще не вела складской учёт самостоятельно. Всем им «Северный учёт» теоретически мог предложить автоматизацию. На практике лишь у двух организаций были признаки того, что разговор может закончиться контрактом.

Мифы, из-за которых список не работает

Миф первый: хороший заказчик — это любая организация, которой нужен наш продукт

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

Проблема становится коммерческой возможностью только при совпадении четырёх условий:

организация признаёт проблему;

у проблемы есть измеримые последствия;

у кого-то есть полномочия или влияние, чтобы начать изменения;

на решение можно выделить деньги, время и сотрудников.

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

Миф второй: крупная организация надёжнее и выгоднее небольшой

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

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

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

Миф третий: достаточно найти закупщика

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

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

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

Миф четвёртый: если компания недавно проявила интерес, сделка уже близка

Запрос на презентацию, скачивание материала или ответ «пришлите коммерческое предложение» — слабые сигналы. Они показывают интерес, но не готовность пройти путь до договора.

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

Поставщику полезно различать любопытство и проект. Любопытство требует информации. Проект требует следующего шага, ответственного лица и даты.

Миф пятый: отрасль автоматически определяет потребность

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

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

Правильная модель: профиль — это проверяемая гипотеза

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

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

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

Такой профиль уже можно проверять. В нём есть конкретные признаки, а не только привлекательная отрасль.

Профиль удобно собирать из шести слоёв.

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

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

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

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

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

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

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

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

Готовность редко объявляется прямой фразой «мы готовы покупать». Её приходится собирать из наблюдаемых сигналов.

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

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

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

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

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

Сигналы бывают не только положительными. Тревожный признак — разрыв между словами и действиями. Заказчик называет проект приоритетным, но не выделяет сотрудника на встречу. Говорит о срочности, но не предоставляет данные. Просит детальный расчёт, хотя не объясняет процесс и критерии выбора. В таких случаях нужно не убеждать сильнее, а проверить реальность проекта.

Размер, отрасль и зрелость: что действительно влияет на сделку

Оценка размера нужна не ради статуса компании. Она помогает предсказать объём потребности, число участников и нагрузку на поставщика.

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

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

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

Зрелость процесса лучше проверять по поведению, а не по словам. У зрелой организации обычно можно найти:

описание текущего порядка работы хотя бы в виде регламента или инструкции;

ответственного за процесс;

регулярные показатели;

историю проблем и попыток их решить;

понятный порядок согласования изменений;

готовность выделить сотрудников на внедрение.

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

Андрей сначала считал зрелость сети низкой: сотрудники пользовались разными способами учёта, а единых отчётов не было. Но в разговоре выяснилось, что Марина вела журнал расхождений, операционный директор еженедельно обсуждал списания, а руководители магазинов уже согласовали необходимость единого порядка инвентаризации. Инструменты были разрозненными, зато управленческая готовность оказалась выше, чем предполагалось.

Кто инициирует, кто согласует, кто блокирует

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

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

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

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

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

Финансовый согласующий смотрит на бюджет, график платежей, экономический эффект и финансовые риски. Юрист проверяет обязательства, ответственность, порядок приёмки, конфиденциальность и расторжение. ИТ-служба оценивает интеграции, доступы и защиту данных.

Лицо, принимающее решение, не всегда занимает самую высокую должность. Владелец бизнеса может утвердить расходы, но опираться на заключение операционного руководителя. Поэтому вопрос «кто директор?» менее полезен, чем вопрос «кто должен подтвердить, что проблема решена?».

Для первого разговора подойдут спокойные формулировки:

«Кто внутри компании отвечает за результат, который должен измениться после внедрения?»

«Кого нужно подключить, чтобы проверить описание текущего процесса?»

«Кто будет оценивать экономику и условия договора?»

«Если решение подойдёт, какие этапы согласования оно пройдёт до подписания?»

«Что обычно останавливает такие проекты у вас: бюджет, безопасность, загрузка сотрудников или необходимость согласовать изменения между филиалами?»

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

Бюджетный цикл и сезонность

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

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

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

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

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

Сигналы бюджета можно обнаружить в разговоре:

«Мы формируем план расходов на следующий год».

«До конца квартала нужно выбрать решение».

«В этом месяце открывается новый склад».

«Текущий договор заканчивается в июне».

«После инвентаризации руководство потребовало устранить расхождения».

«Сейчас сравниваем варианты для включения в бюджет».

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

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

Упражнение: соберите профиль за один рабочий вечер

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

По каждой организации заполните шесть строк.

Кого и какой процесс вы считаете подходящими.

Какой внешний или внутренний признак указывает на проблему.

Кто может быть инициатором и владельцем процесса.

Какое событие способно запустить закупку в ближайшие шесть — двенадцать месяцев.

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

Какой следующий шаг подтвердит или опровергнет гипотезу.

Затем поставьте каждой компании оценку от нуля до двух по пяти критериям.

Срочность проблемы: ноль — признаков нет, один — проблема вероятна, два — есть конкретное событие или срок.

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

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

Готовность к закупке: ноль — бюджет и процедура неизвестны, один — проект обсуждается, два — есть бюджетное окно, процедура или подтверждённый план.

Экономика сделки: ноль — вероятно, внедрение съест маржу, один — расчёт требует уточнения, два — стоимость привлечения и исполнения понятна.

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

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

Кейс «Северного учёта»: как список сократился втрое

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

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

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

У первой крупной сети было двадцать два магазина, но решения по учёту принимались центральной ИТ-службой в другом регионе. На сайте организации не было признаков расширения, а закупки проходили через длинный внутренний контур. Компания оставалась привлекательной, но получила средний приоритет.

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

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

Разговор начался с осторожности.

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

Андрей ответил иначе:

«Я не хочу присылать расчёт без понимания процесса. У вас расширяется сеть, и в такой момент обычно меняется порядок перемещения товара и инвентаризации. Подскажите, кто отвечает за то, чтобы остатки между складом и магазинами сходились после открытия новых точек?»

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

Андрей задал следующий вопрос:

«Если оставить порядок без изменений, какой риск для вас самый неприятный: задержка открытия, ошибки в заказах или дополнительная нагрузка на сотрудников?»

«Скорее, потеря контроля, — ответила Марина. — Но решение будет оценивать операционный директор. Я могу подключить его, если пойму, что вы говорите не только о программе».

Это был первый момент квалификации. У организации обнаружились проблема, владелец результата, событие с датой и возможный следующий шаг. Но сделка ещё не была близка. Андрей попросил короткую встречу с Мариной и операционным руководителем, чтобы за сорок минут описать текущий процесс и понять, нужен ли пилот.

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

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

«Мы пока не знаем, кто будет поддерживать справочники и сколько времени займут настройки. Если обещаем весь пакет, мы продаём не пилот, а будущую проблему».

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

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

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

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

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

Разбор типичных сбоев

Первый сбой — подмена портрета списком отраслей. Формулировка «торговые сети» ничего не говорит о сложности сделки. Добавьте процесс, симптом, масштаб и событие. Если этих элементов нет, у вас не профиль, а направление поиска.

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

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

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

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

Как расставить приоритеты

Список компаний имеет смысл разделить на три потока.

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

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

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

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

Перед активной работой задайте себе пять вопросов:

Есть ли у организации проблема, которую она уже признаёт?

Могу ли я выйти на человека, отвечающего за изменение результата?

Есть ли событие или бюджетное окно, из-за которого решение нужно принимать в обозримый срок?

Понимаю ли я, как будет приниматься решение и какие документы понадобятся?

Останется ли у поставщика приемлемая экономика после внедрения, поддержки и отсрочки платежа?

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

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

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

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

Комплект поставщика, которому отвечают

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

Андрей Власов отправил Марине Орловой презентацию «Северного учёта» на 27 слайдов. В ней были фотографии складов, перечень функций, схема интеграции, описание мобильного приложения, отзывы двух небольших клиентов и слайд «Наши преимущества». Через три дня Марина ответила одной строкой:

«Спасибо, получили. При появлении потребности вернёмся».

Андрей перечитал письмо несколько раз. Он не понимал, что сделал неправильно. Продукт работал, демонстрация проходила хорошо, цены они не скрывали. Ирина Белова, отвечавшая за операционную часть, открыла файл с расчётами и спросила:

— Если Марина завтра передаст это директору по операциям, что именно директор сможет решить по презентации?

Андрей показал на слайд с перечнем функций.

— Он увидит, что мы умеем.

— А что ему нужно будет согласовать?

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

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

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

Сигнал: после отправки материалов вам пишут «интересно», но не назначают следующий шаг

Что это значит

Чаще всего проблема не в отсутствии интереса. Фраза «интересно» позволяет вежливо завершить разговор, когда человек не может быстро ответить на три вопроса:

1. Какую конкретную задачу решает предложение?

2. Почему эту задачу нужно решать сейчас?

3. Какой безопасный следующий шаг можно сделать без большой закупочной процедуры?

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

Что делать

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

В конце одностраничного предложения должно быть написано не «будем рады обсудить сотрудничество», а, например:

«Предлагаем за 30 минут проверить, можно ли сократить ручную сверку складских остатков в двух магазинах. Для разговора достаточно текущего описания процесса и примерного количества операций. По итогам определим, есть ли основания для расчёта пилота».

Такая формулировка не давит на покупателя и не требует от него немедленно запускать закупку. Она превращает абстрактное «интересно» в проверяемое действие.

Одностраничное предложение: документ для внутренней пересылки

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

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

В одностраничном предложении нужны семь блоков.

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

Второй — наблюдаемый результат. Формулируйте его через процесс и показатель:

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

Если точный результат зависит от исходных данных, это нужно прямо написать:

«Фактический эффект определяется после оценки текущего процесса; до этого момента мы фиксируем только диапазон и условия проверки».

Третий — как работает решение. Достаточно трёх-четырёх действий, а не перечня из двадцати функций:

«Собираем данные о движении товара, выявляем расхождения, назначаем ответственному задачу на проверку, формируем отчёт для руководителя».

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

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

Пятый — формат запуска:

«Начинаем с двух магазинов. За первую неделю описываем процесс и настраиваем обмен данными, затем четыре недели сравниваем исходные и итоговые показатели».

Шестой — экономика в понятной форме. Если цену пока нельзя назвать точно, укажите принцип расчёта и диапазон:

«Стоимость пилота зависит от количества точек и состава интеграции. Предварительный диапазон для двух магазинов — от … до … рублей; окончательная сумма определяется после проверки исходных данных».

Седьмой — следующий шаг. Он должен быть конкретным и ограниченным по объёму.

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

Проверка одностраничного предложения

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

«Что предлагает поставщик?»

«Для какой ситуации это нужно?»

«Какой результат обещан?»

«Что будет происходить после согласия на следующий шаг?»

«Какие данные или ресурсы потребуются от заказчика?»

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

Сигнал: в документе много функций, но мало условий результата

Что это значит

Поставщик описывает то, чем гордится. Заказчик пытается понять, что изменится в его рабочем дне. Эти точки зрения редко совпадают сами собой.

Андрей сначала написал в одностраничном документе:

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

Описание было точным, но не отвечало на вопрос Марины: «Как внедрение повлияет на работу магазинов и кто будет отвечать за последствия?»

Ирина переписала блок:

«Сотрудник фиксирует приёмку и перемещение товара в одном порядке. Руководитель магазина видит расхождения в течение смены, а не после итоговой сверки. Ответственные получают список операций, которые нужно проверить. На пилоте сравниваем время сверки, количество корректировок и число повторных пересчётов с исходными показателями».

Функции никуда не исчезли. Они заняли правильное место — стали объяснением механизма результата.

Что делать

Каждую функцию переводите в цепочку:

«Функция — действие — изменение процесса — показатель».

Например:

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

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

Кейс без приукрашивания

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

Слабый кейс звучит так:

«Клиент увеличил эффективность склада на 40 процентов благодаря современному решению “Северного учёта”. Внедрение прошло быстро и позволило достичь отличных результатов».

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

Кейс, которому верят, состоит из шести частей.

Исходная ситуация. Сколько было точек, какой процесс существовал, где возникала проблема. Не «клиент испытывал сложности», а «в сети было 14 магазинов, остатки сверяли раз в неделю, расхождения закрывали вручную, данные по части операций приходили с задержкой».

Цена проблемы. Что происходило из-за сбоя: задержки отгрузки, повторные пересчёты, перегрузка руководителей, возвраты, потеря времени. Если финансовая сумма неизвестна, не выдумывайте её. Описывайте измеримые последствия.

Границы проекта. Что входило в работу, а что осталось за её пределами. Например: «Пилот проводился в двух магазинах, без изменения центральной системы закупок и без автоматизации списаний».

Действия поставщика. Не «внедрили решение», а конкретно: «описали порядок приёмки, настроили обмен справочниками, обучили четырёх сотрудников, установили еженедельный контроль показателей».

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

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

Такой кейс выглядит менее эффектно, чем рекламная история о «росте эффективности в разы». Зато он помогает заказчику оценить, можно ли перенести результат в его условия. Для Марины это особенно важно: она рискует не личными деньгами, а своим решением внутри организации. Ей нужно понимать не только, что у кого-то получилось, но и при каких обстоятельствах.

Если клиент не разрешает называть компанию, используйте обезличенное описание, но не превращайте его в туман:

«Региональная сеть из 12 торговых точек» — достаточно для понимания масштаба.

«Крупный заказчик из сферы розницы» — почти бесполезно.

Не приписывайте поставщику весь результат клиента. На него могли повлиять смена руководителя, изменение ассортимента, сезонность или параллельный проект. Формулировка «после запуска на пилотном участке показатель изменился» честнее, чем «наше решение увеличило показатель».

Сигнал: потенциальный клиент просит «прислать всё, что есть»

Что это значит

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

За перегрузкой иногда скрывается и другая причина: собеседник пока не хочет вступать в предметный разговор. В этом случае объём материалов не приблизит сделку.

Что делать

Соберите два уровня информации.

До первого содержательного разговора отправляйте:

1. Одностраничное предложение под ситуацию заказчика.

2. Один подходящий кейс.

3. Краткое описание команды и зоны ответственности.

4. Предварительный принцип расчёта или диапазон.

5. Предложение следующего шага.

После подтверждения интереса добавляйте:

1. Подробное коммерческое предложение.

2. План работ и роли сторон.

3. Техническое описание.

4. Проект договора или существенные условия.

5. Документы о компании.

6. Требования к информационной безопасности и обработке данных, если они относятся к проекту.

7. Расширенные кейсы и рекомендации.

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

Один и тот же проект нельзя одинаково объяснить всем участникам. Но нельзя и делать четыре противоречивые версии. Факты, цены, сроки и границы ответственности должны оставаться едиными; меняется только порядок акцентов.

Коммерческое предложение для разных ролей

Представим, что после первого разговора Марина пересылает материалы директору по операциям и начальнику ИТ-службы. Если отправить всем одинаковые десять страниц, каждый найдёт там то, что не отвечает именно на его вопросы.

Для директора по операциям коммерческое предложение может начинаться так:

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

Далее нужны стоимость, календарный план, необходимые ресурсы заказчика и риски.

Для владельца процесса акцент будет другим:

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

Для ИТ-службы:

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

Для закупок:

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

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

Проверка реальности: может ли каждый участник пересказать вашу позицию?

Возьмите текущий документ и напишите на полях четыре вопроса:

«Что изменится в процессе?»

«Как это будет работать технически?»

«Сколько это стоит и что входит?»

«Какие риски я беру на себя?»

Затем отметьте, где именно в документе есть ответ. Если его приходится искать по всему тексту, перестройте документ. Если ответа нет, не маскируйте пробел красивым дизайном.

Документы о компании и полномочиях

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

Для первого этапа обычно достаточно подготовить в актуальном виде:

1. Карточку организации с полным и сокращённым наименованием, ИНН, ОГРН, адресом, банковскими реквизитами и контактами.

2. Выписку из ЕГРЮЛ или сведения о регистрации в форме, которую принимает заказчик.

3. Информацию о системе налогообложения, если она влияет на цену и оформление документов.

4. Сведения о руководителе и лице, которое ведёт переговоры.

5. Документ или основание, подтверждающее полномочия подписанта.

6. Краткое описание опыта и команды проекта.

7. Информацию о применяемых мерах защиты данных и порядке доступа, если сервис работает с данными заказчика.

8. Проект договора или перечень существенных условий сделки.

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

Андрей однажды указал в презентации руководителя проекта, который уже не работал в компании. Марина заметила это во время проверки и спросила, кто будет отвечать за внедрение. Андрей ответил:

— Мы просто не обновили слайд.

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

Сделайте внутреннюю проверку комплектности:

Названия организации и реквизиты совпадают во всех документах.

Фамилии и должности актуальны.

Цена указана с одинаковым пониманием налогов.

Сроки в презентации, расчёте и проекте договора не расходятся.

За каждым обещанием закреплён ответственный.

Понятно, кто подписывает договор и кто ведёт проект.

Ограничения решения написаны прямо.

Сигнал: заказчик сразу спрашивает о договоре, оплате и ответственности

Что это значит

Это не обязательно признак недоверия. Так закупочная или юридическая функция проверяет, можно ли перевести интерес в управляемую процедуру. Если поставщик в ответ начинает рассказывать только о ценности продукта, он пропускает реальный этап сделки.

Вопрос «кто несёт ответственность, если интеграция задержится?» нельзя закрыть фразой «мы всегда всё решаем». Нужны границы, условия и порядок действий.

Что делать

В коммерческом предложении заранее укажите:

Что поставщик передаёт заказчику.

Что должен предоставить заказчик.

Какие сроки зависят от доступа к системам, данным и сотрудникам.

Как принимаются результаты.

Что считается доработкой, а что входит в исходный объём.

Как происходит поддержка после запуска.

Какие события влияют на цену.

Какие данные нужны для окончательного расчёта.

Чем меньше определённости в этих пунктах, тем выше риск, что первый контракт окажется убыточным. Ирина Белова обнаружила это, когда пересчитала проект для «Северного учёта». Андрей обещал «быстрое подключение к учётной системе», но в расчёте не были учтены подготовка справочников, проверка прав доступа, обучение сменных сотрудников и два выезда в магазины.

— Мы продавали сервис за 480 тысяч, — сказала Ирина. — А дополнительные часы команды и поездки съедят почти половину маржи.

— Но это же первый крупный клиент. Можно сделать больше ради кейса.

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

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

Что показывать до запроса заказчика

До запроса можно и нужно показывать только то, что помогает квалифицировать ситуацию:

1. Для каких задач подходит решение.

2. Какой результат измеряется.

3. Как выглядит запуск.

4. Какой опыт уже есть.

5. Как формируется цена.

6. Какие данные нужны для следующего шага.

7. Какие ограничения есть у решения.

Не стоит заранее отправлять:

1. Полную внутреннюю инструкцию.

2. Все технические схемы, если техническая оценка ещё не началась.

3. Длинный список функций, не связанных с задачей.

4. Десятки отзывов без контекста.

5. Неподтверждённые прогнозы экономии.

6. Проект договора на двадцать страниц в первом письме.

7. Коммерческую тайну других клиентов.

8. Материалы, которые требуют от получателя часовой расшифровки.

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

Минимальный комплект для первого контакта

К концу подготовки у вас должны быть четыре основных материала.

Описание решения на одной странице. Оно объясняет ситуацию заказчика, изменение процесса, способ запуска, показатели, диапазон стоимости и следующий шаг.

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

Предварительный расчёт. Он содержит состав работ, зависимости от исходных данных, диапазон или цену, сроки и то, что не входит в предложение.

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

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

Упражнение: соберите комплект за один рабочий день

Откройте пустую папку с названием потенциального заказчика. Создайте в ней четыре файла:

«01. Решение на одной странице».

«02. Релевантный кейс».

«03. Предварительный расчёт».

«04. О компании и команде».

В первом файле напишите заголовок, который описывает не продукт, а задачу. Затем добавьте результат, процесс запуска, показатели и следующий шаг.

Во втором зафиксируйте только проверяемые факты. Если точных данных нет, укажите это. Не подставляйте красивые проценты из предположений.

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

В четвёртом проверьте реквизиты, полномочия, состав команды и опыт именно в похожем процессе.

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

Сценарий if/then для отправки материалов

Если человек впервые откликнулся на общее описание проблемы, отправляйте одностраничное предложение и один кейс. Не прикладывайте техническую документацию.

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

Если в разговор вошёл специалист по закупкам, подготовьте карточку компании, реквизиты, состав поставки и порядок оформления.

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

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

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

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

Если клиент отвечает, что «нужно прислать больше информации», спросите, для какого решения она нужна: операционного, технического, финансового или закупочного. Тогда вы отправите не больше, а точнее.

Новый баланс: поставщик не доказывает ценность, а делает её проверяемой

После переработки материалов Андрей снова связался с Мариной. Он отправил не презентацию, а короткое письмо:

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

Марина ответила в тот же день:

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

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

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

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

Перед первым контактом пройдите финальную проверку.

В документе названа задача, а не только продукт.

Есть измеримый или проверяемый результат.

Понятно, кто получает пользу и кто участвует в запуске.

Описан следующий шаг с ограниченным объёмом.

Есть релевантный кейс с условиями и ограничениями.

Цена дана как сумма или прозрачный принцип расчёта.

Разделены обязательства поставщика и заказчика.

Реквизиты и сведения о компании актуальны.

Материалы не требуют устного переводчика.

Каждый файл отправляется конкретному адресату и отвечает на его вопрос.

Обещания соответствуют реальным ресурсам команды.

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

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

Экономика сделки до первого разговора

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

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

Для Андрея это выглядело как шанс получить первый крупный контракт. Для Ирины Беловой, операционного руководителя «Северного учёта», — как набор пока неизвестных расходов.

Ирина не стала обсуждать процент скидки. Она открыла расчёт и задала Андрею четыре вопроса:

— Сколько месяцев мы будем работать до первого платежа?

— Думаю, месяц или два. Как договоримся.

— Сколько часов консультанта уйдёт на один магазин?

— В типовом случае около сорока.

— А если заказчик попросит интеграцию с учётной системой и выезды в удалённые магазины?

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

Экономика сделки начинается не с прайс-листа

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

Организация обычно видит одну строку: «Итого к оплате». Поставщик обязан видеть как минимум пять слоёв:

выручку по договору;

переменные и постоянные затраты на исполнение;

валовую маржу;

денежный разрыв между расходами и поступлениями;

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

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

Валовая маржа показывает, сколько остаётся после прямых затрат на исполнение заказа. Упрощённая формула выглядит так:

Валовая маржа = выручка без НДС − прямые затраты на сделку.

В процентах:

Валовая маржа = (выручка без НДС − прямые затраты) / выручка без НДС × 100 процентов.

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

Денежный разрыв — это период, когда расходы по заказу уже возникли, а деньги от заказчика ещё не поступили. Он может появиться даже в прибыльной сделке. Например, договор принесёт 1,2 миллиона рублей, прямые затраты составят 700 тысяч, а валовая маржа — 500 тысяч. Но если 400 тысяч нужно потратить в первые две недели, а заказчик платит через 60 дней после подписания акта, компании придётся заранее найти деньги на финансирование исполнения.

Прибыль отвечает на вопрос: «Заработаем ли мы на этой сделке?» Денежный разрыв отвечает на другой: «Сможем ли мы дожить до момента, когда эта прибыль станет деньгами на счёте?»

Эти вопросы нельзя смешивать.

Мастерская 1. Разложить договор на деньги и работу

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

Для «Северного учёта» исходная версия заказа выглядела так:

лицензия на сервис для пятнадцати магазинов — 900 000 рублей в год;

первичное внедрение — 600 000 рублей;

обучение сотрудников — 180 000 рублей;

интеграция с учётной системой заказчика — 350 000 рублей;

сопровождение в течение первого года — 360 000 рублей.

Общая сумма договора составляла 2 390 000 рублей, если включить все работы и услуги в один документ. Но сама по себе эта цифра ещё ничего не говорила о реальной выгодности проекта.

Ирина разложила сумму на типы дохода.

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

Внедрение — разовая выручка. Она возникает один раз, зато требует значительного объёма работ за короткий период.

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

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

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

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

Сколько рабочих часов потребуется специалистам?

Какие внешние услуги, оборудование, поездки и материалы понадобятся?

Какие расходы возникнут до первого платежа?

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

Ирина получила такой расчёт:

внедрение: 420 часов работы команды по средней внутренней стоимости 1 500 рублей — 630 000 рублей;

обучение: 90 часов подготовки и проведения занятий по 1 200 рублей — 108 000 рублей;

интеграция: 180 часов работы разработчика и аналитика по 1 800 рублей — 324 000 рублей;

сопровождение: 25 часов в месяц по 1 500 рублей — 37 500 рублей в месяц, или 450 000 рублей за год;

поездки и проживание — предварительно 120 000 рублей;

дополнительные сервисы и резерв на технические расходы — 80 000 рублей.

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

Предварительные прямые затраты составляли 1 811 000 рублей, если включить год сопровождения и все заявленные расходы. При выручке 2 390 000 рублей оставалось 579 000 рублей валовой маржи, или около 24 процентов до учёта общехозяйственных расходов.

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

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

что именно поставщик обязан сделать;

что считается результатом;

сколько времени на это запланировано;

какие условия должен выполнить заказчик;

какие расходы возникнут у поставщика;

что произойдёт, если исходные условия изменятся.

Если на эти вопросы нельзя ответить, цена ещё не готова к переговорам.

Типичная ошибка: считать только часы исполнителя

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

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

В расчёт нужно включать не только «чистую работу», но и коэффициент загрузки. Например, если по опыту на каждую оплачиваемую единицу работы приходится 20–30 процентов внутреннего времени, эти часы нельзя прятать в надежде, что они исчезнут.

Типичная ошибка: считать подрядчиков бесплатным резервом

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

Типичная ошибка: смешивать повторяющуюся и разовую выручку

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

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

Кейс «Северного учёта»: как прибыль исчезла в календаре

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

Ирина не спорила с ценностью клиента. Она перевела скидку в рабочие часы.

Скидка от суммы 2 390 000 рублей составляла 358 500 рублей. При этом заказчик просил оплату по схеме: 30 процентов авансом, 70 процентов — через 60 календарных дней после подписания итогового акта. Внедрение и интеграция должны были начаться сразу после получения аванса. Получалось, что аванс в размере 717 000 рублей нужно было растянуть на первые недели работы, а затем ещё два месяца финансировать команду, поездки и внешние услуги.

Оценка расходов по месяцам выглядела так:

в первый месяц — 520 000 рублей;

во второй месяц — 430 000 рублей;

в третий месяц — 310 000 рублей;

в четвёртый месяц — 180 000 рублей;

далее сопровождение — около 37 500 рублей ежемесячно плюс обращения сверх лимита.

Всего до получения основной части оплаты нужно было потратить 1 440 000 рублей. После скидки выручка без учёта налоговой модели уменьшалась до 2 031 500 рублей. На бумаге проект оставался прибыльным. На счёте компании мог возникнуть недостаток примерно в 700–800 тысяч рублей, если параллельно нужно было выплачивать зарплаты и вести другие проекты.

Андрей спросил:

— Но ведь деньги в итоге придут?

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

Так появился первый принцип переговоров «Северного учёта»: скидку нельзя обсуждать отдельно от графика работ и оплаты.

Если заказчик хочет снизить цену, поставщик должен менять не только сумму, но и конструкцию сделки. Например:

сократить объём внедрения на первом этапе;

разнести запуск по очередям;

взять оплату за интеграцию отдельно;

увеличить аванс;

сократить отсрочку;

зафиксировать лимит часов сопровождения;

исключить выезды из базовой цены;

заменить постоянные доработки отдельными заявками.

Скидка — не жест вежливости. Это обмен: поставщик получает что-то, что снижает его затраты или риски, а заказчик — снижение цены.

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

Мастерская 2. Найти денежный разрыв по месяцам

Второе упражнение — составить не только смету, но и календарь денег. Для этого достаточно взять четыре строки:

расходы до запуска;

расходы по месяцам исполнения;

даты выставления документов;

ожидаемые даты фактического поступления средств.

Расчёт нужно делать по консервативному сценарию. Если договор говорит: «Оплата в течение 30 календарных дней после подписания акта», нельзя ставить деньги на счёт в день передачи результата. Нужно учитывать время на проверку, замечания, исправление и прохождение внутреннего согласования у заказчика.

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

Минимальный запас оборотных средств равен наибольшему отрицательному накопленному разрыву с учётом обычных расходов компании. Если проект требует 900 000 рублей до первого существенного платежа, а свободных средств у поставщика только 300 000, проблему не решить убеждением команды: «Зато контракт большой».

Есть несколько способов сократить разрыв:

получить аванс до начала работ;

разбить внедрение на этапы с отдельной приёмкой;

выставлять оплату за лицензии заранее;

отделить поставку оборудования и внешние расходы от собственно услуг;

согласовать ежемесячную оплату сопровождения;

включить оплату подтверждённых расходов на поездки;

сократить отсрочку или установить её только для части цены.

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

Типичная ошибка: считать отсрочку только коммерческим условием

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

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

Можно не выносить её отдельной строкой в коммерческое предложение, но нельзя делать вид, что её нет внутри цены.

Налоговая нагрузка и деньги на счёте

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

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

Есть несколько типичных ситуаций.

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

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

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

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

Практическое правило: в расчёте держите отдельно три суммы.

Первая — цена для заказчика.

Вторая — сумма без НДС, если НДС применяется.

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

Не пытайтесь угадать налоговый результат «на глаз». Ошибка в несколько процентных пунктов при крупном договоре может превратить приемлемую скидку в убыток.

Мастерская 3. Посчитать стоимость невидимых обязательств

Обычно поставщик хорошо считает то, что записал в техническом задании, и плохо — то, что назвал «обычной поддержкой». Именно в этих словах часто прячется будущая бесплатная работа.

Возьмите любой пункт будущего предложения и продолжите его фразой: «Это означает, что мы должны будем…»

Например:

«Обучить сотрудников» означает подготовить программу, собрать вопросы, провести занятия, проверить усвоение материала, ответить тем, кто пропустил встречу, и, возможно, обучить новых сотрудников после увольнения первых.

«Интегрировать с системой заказчика» означает изучить документацию, получить доступы, согласовать форматы данных, провести тестовый обмен, исправить ошибки и повторить проверку после изменений на стороне клиента.

«Обеспечить сопровождение» означает определить канал обращений, рабочее время, срок реакции, срок решения, перечень поддерживаемых вопросов и то, что оплачивается отдельно.

«Запустить во всех филиалах» означает учитывать расписание магазинов, доступность сотрудников, поездки, различия в процессах и необходимость повторного визита.

Теперь разделите обязательства на три группы.

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

Во вторую — полезные, но отдельные услуги, которые можно заказать дополнительно.

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

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

Стоимость доработок

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

Поставщик часто недооценивает доработки по трём причинам.

Первая: он считает только разработку, но не анализ требований и тестирование.

Вторая: он предполагает, что сделанная для одного клиента функция потом пригодится всем, и потому часть расходов можно «списать» на развитие продукта.

Третья: он не учитывает сопровождение нового решения. Любая добавленная функция увеличивает число сценариев, которые нужно поддерживать, объяснять и проверять после обновлений.

Перед тем как включить доработку в первый контракт, задайте три вопроса.

Кто получает основную выгоду от этой функции?

Станет ли она стандартной частью продукта или останется индивидуальным исключением?

Есть ли у поставщика ресурс поддерживать её после запуска?

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

Фраза «сделаем в рамках внедрения» опасна до тех пор, пока не определено, что именно значит «сделаем».

Полевой алгоритм до первого разговора

До встречи с заказчиком пройдите сделку по следующему порядку.

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

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

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

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

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

Потом постройте денежный календарь: когда возникает каждый расход и когда поступает соответствующий платёж.

Затем рассчитайте три цены:

целевую цену — при которой сделка соответствует плановой марже и уровню риска;

минимально приемлемую цену — ниже неё сделка возможна только при изменении объёма или условий;

точку отказа — цену или набор условий, при которых поставщик не входит в сделку.

После этого подготовьте несколько сценариев, а не одну цифру. Минимум три:

базовый — ожидаемый объём и обычный график оплаты;

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

выгодный — сокращённый объём, быстрый доступ к данным, аванс и поэтапная приёмка.

Только после этого можно обсуждать скидку. Не раньше.

Минимальная цена и точка отказа

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

Если прямые затраты по проекту составляют 1 200 000 рублей, а поставщик планирует получить валовую маржу не менее 30 процентов, минимальная выручка без НДС рассчитывается так:

1 200 000 / 0,70 = примерно 1 714 000 рублей.

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

1 350 000 / 0,70 = примерно 1 929 000 рублей.

Это не означает, что заказчику нужно сразу назвать 1 929 000 рублей. Это означает, что поставщик знает границу, ниже которой он должен менять состав сделки.

Точка отказа шире, чем одна цена. Иногда цена выглядит приемлемой, но условия делают сделку опасной. Например:

оплата через 90 дней после финального акта;

неограниченные доработки в рамках фиксированной суммы;

штрафы за сроки, зависящие от доступа заказчика к данным;

обязательство поддерживать сервис круглосуточно без отдельной оплаты;

право заказчика в одностороннем порядке менять объём;

неопределённая приёмка без срока на замечания;

необходимость финансировать закупку оборудования за свой счёт.

В таком случае точкой отказа может быть не «цена ниже миллиона», а сочетание условий: цена ниже целевой, отсрочка больше 60 дней и отсутствие аванса.

Полезно заранее записать границы в рабочем документе:

целевая цена — 2 390 000 рублей;

допустимая скидка при сохранении объёма — до 5 процентов;

скидка до 10 процентов возможна только при авансе не менее 50 процентов и поэтапной приёмке;

скидка свыше 10 процентов возможна только при сокращении объёма или отказе от части интеграции;

точка отказа — цена ниже 2 050 000 рублей при сохранении полного объёма, отсрочке более 60 дней и неограниченном сопровождении.

Такая запись защищает от эмоционального решения на встрече. Когда заказчик говорит: «Если дадите ещё 7 процентов, мы подпишем сегодня», поставщик не обязан отвечать сразу. Он сравнивает новые условия с заранее установленными границами.

Разговор о скидке

Марина Орлова на встрече с Андреем могла бы сказать:

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

Неудачный ответ:

— Хорошо, какую скидку вы считаете приемлемой?

Так поставщик отдаёт инициативу и показывает, что цена взята с запасом, а собственных критериев у него нет.

Другой неудачный ответ:

— Мы небольшая компания, поэтому и так поставили минимальную цену.

Он не объясняет, из чего складывается стоимость и что можно изменить.

Рабочий ответ:

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

Такой ответ не звучит как торг ради торга. Он связывает цену с результатом и условиями исполнения.

Сценарий небольшого заказа

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

Представим, что сеть хочет начать с одного магазина. Лицензия стоит 90 000 рублей в год, внедрение — 160 000 рублей, обучение — 50 000 рублей, интеграция — 180 000 рублей. Общая цена — 480 000 рублей.

Прямые затраты:

внедрение — 130 000 рублей;

обучение — 30 000 рублей;

интеграция — 165 000 рублей;

поездка — 25 000 рублей;

подготовка и управление проектом — 45 000 рублей.

Итого — 395 000 рублей. Валовая маржа — 85 000 рублей, или около 18 процентов. Если заказчик задержит запуск, потребует повторного обучения и попросит ещё один выезд, маржа исчезнет.

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

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

Для небольшого заказа особенно важны:

минимальная стоимость выезда;

минимальный объём оплаты за управление проектом;

ограничение числа обучаемых групп;

отдельная цена интеграции;

оплата обследования до составления детального плана;

заранее определённая возможность масштабирования.

Не нужно стыдиться минимального чека. Если запуск стоит компании 150 000 рублей независимо от размера заказа, это должно быть отражено в цене.

Сценарий крупного заказа

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

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

Для крупного заказа разумна поэтапная модель:

этап обследования;

пилот на ограниченном числе объектов;

оценка результатов и корректировка плана;

масштабирование очередями;

сопровождение по отдельному регламенту.

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

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

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

Два контекста, в которых ошибка особенно заметна

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

Представьте семейный бюджет. Человек получает заказ на ремонт квартиры за 500 000 рублей и обещает выполнить его за два месяца. Заказчик просит скидку 50 000 рублей, и исполнитель соглашается, не проверив стоимость материалов и сроки оплаты. Через месяц выясняется, что материалы подорожали, часть работ не была учтена, а заказчик перечислил только аванс. Формально заказ остаётся прибыльным. Фактически у исполнителя не хватает денег на следующую закупку. Корпоративный контракт устроен так же, только вместо одной семьи появляются акты, согласования, несколько подразделений и более длинная задержка платежа.

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

Проверка реальности перед отправкой предложения

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

За каждой фразой должен стоять расчёт.

«Оперативная поддержка» — это за сколько часов будет дан ответ и за сколько будет решён вопрос?

«При необходимости выезд» — сколько выездов включено и кто оплачивает дорогу?

«Под ключ» — где заканчивается ответственность поставщика и начинается ответственность заказчика?

«Без ограничений» — действительно ли компания готова принять неограниченный объём обращений за фиксированную сумму?

«Обучение сотрудников» — сколько человек, групп, занятий и повторов?

Если расчёта нет, фразу нужно уточнить или убрать.

Критерии готовности к первому разговору

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

Каков полный состав сделки и что не входит в базовую цену?

Какие прямые затраты возникнут по каждой части проекта?

Каковы целевая и минимально приемлемая цены?

Какой объём работы допустим при минимальной цене?

Какой аванс нужен, чтобы начать работу без кассового разрыва?

Как повлияют на цену отсрочка, поэтапная приёмка и дополнительные согласования?

Какие доработки оплачиваются отдельно?

Сколько стоит один дополнительный выезд, час работы, группа обучения или пакет сопровождения?

При каких условиях поставщик отказывается от сделки?

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

Ирина в итоге предложила Андрею не одну цену, а три конструкции.

Первая: полный запуск в пятнадцати магазинах за 2 390 000 рублей, аванс 50 процентов, оставшаяся сумма — по этапам, сопровождение ограничено согласованным количеством часов.

Вторая: пилот на трёх магазинах за 720 000 рублей, отдельная интеграция после обследования, масштабирование по фиксированной цене за объект.

Третья: обследование и проектирование за 180 000 рублей с последующим зачётом части суммы при заключении договора на внедрение.

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

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

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

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

Где начинается корпоративная закупка

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

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

Разница между этими двумя вещами во многом определяет исход сделки. Она решает, успеет ли поставщик вовремя войти в процесс или окажется в длинном списке компаний, приславших предложение уже после того, как решение фактически принято.

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

Популярный миф: закупка начинается с тендера

Поставщик, который впервые выходит на корпоративный рынок, обычно представляет закупку как объявление на электронной площадке. Появилась карточка процедуры, опубликованы требования, указан срок подачи заявки, значит, закупка началась.

Эта картина удобна, но почти всегда запаздывает.

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

Тендер не всегда становится началом корпоративной закупки. Чаще это один из поздних и наиболее формализованных этапов принятия решения.

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

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

Как Андрей перепутал сигнал с закупкой

После того как появилась вакансия, Андрей отправил на общий адрес сети короткое письмо:

«Добрый день. Мы предлагаем сервис автоматизации складского учёта для строительных магазинов. Система позволяет контролировать остатки, сокращать пересортицу и ускорять инвентаризацию. Готовы провести демонстрацию».

Ответа не было.

Через неделю Андрей нашёл на официальном сайте сети раздел «Закупки» и увидел, что компания принимает коммерческие предложения на доработку учётной системы. Он решил, что это и есть нужная точка входа. Ирина Белова, операционный руководитель «Северного учёта», попросила его сначала проверить условия.

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

Ирина быстро пересчитала предложение. Лицензии и основные работы укладывались в 2,4 миллиона рублей. Но командировки, настройка интеграции, обучение смен, поддержка после запуска и финансирование двух месяцев ожидания оплаты добавляли ещё около 900 тысяч. Если приёмка задержится или объём работ вырастет, запас почти исчезнет.

«Мы можем подать заявку?» — спросил Андрей.

«Можем, — ответила Ирина. — Но сначала объясни, почему эта закупка появилась именно сейчас и кто внутри сети будет отвечать за результат».

Андрей снова открыл вакансию и заметил, что её опубликовали ещё три месяца назад. Новый руководитель направления, вероятно, уже вышел на работу. В закупочном документе не было сказано, из-за каких проблем возникла задача. Там содержались только требования к результату и формальные параметры работ.

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

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

Андрей позвонил по номеру, указанному в закупочной документации.

«Мы хотели бы уточнить несколько вопросов по процедуре», — сказал он.

«Все вопросы направляйте через форму на площадке», — ответила сотрудница закупочной службы.

Это был ожидаемый ответ. Закупщик не обязан обсуждать с каждым поставщиком внутренние причины закупки. Но теперь Андрей понимал, что искать нужно не только контакт закупочной службы. В его рабочей карточке появились ещё три роли: новый руководитель складской логистики как возможный владелец процесса, операционный директор как руководитель, заинтересованный в результате, и действующий интегратор, с которым предстояло либо конкурировать, либо вступать в партнёрство.

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

Через несколько дней Андрей получил ответ от Марины Орловой, менеджера по закупкам сети.

«Вы одни из немногих, кто не обещает запустить всё за две недели без доступа к данным», — сказала она на первой встрече. — «Но почему вы решили, что нам нужен именно ваш вариант?»

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

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

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

Факты против иллюзий

Иллюзия первая: достаточно следить за тендерами

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

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

Вторая — неверное понимание цели. Техническое задание часто описывает требуемые работы, но не объясняет, какая управленческая проблема за ними стоит. Поставщик отвечает на документ, не зная, что именно заказчик сочтёт успехом.

Третья — ценовая ловушка. Если видеть только перечень работ, легко недооценить интеграции, обучение, командировки, поддержку, согласование доступа и стоимость ожидания оплаты.

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