2. Для чего мы сами используем свою СУЗ: 1
1. Определить наши недоработки в ходе пре-сейлов.
2. Найти способы отработки возражений заказчика.
3. Понять, какие продукты нуждаются в совершенствовании
маркетинговых материалов, и в чем именно их нужно улучшить.
4. Выявить самые «выигрышные» в глазах заказчика аргументы.
5. Понять, какие пре-сейлы закончились неудачей
по объективным причинам, а какие – по субъективным.
6. Начиная новый пре-сейл, заранее выявить наиболее
вероятные проблемы, которые следует отработать.
7. Выявить преимущества конкретных продуктов,
оказавшиеся решающими для заказчика в прошлых продажах,
и получить презентационные материалы по ним.
3. В СУЗ создана простая онтология: 2
Наличие признака
«Доказано заказчику»
или «Принято
заказчиком»
Элементы этого типа
имеют собственную
внутреннюю
классификацию
4. Как выявить наши недоработки? 3
Не всегда известно заранее, в чем состоит интерес заказчика. В таких случаях сначала мы предлагаем
те или иные идеи, которые с нашей точки зрения несут ценность для заказчика.
Если заказчик соглашается с тем, что достижение названного нами результата для него интересно –
это первый шаг к формулированию успешного предложения. Следовательно, интересно выявить
пре-сейлы, в которых заказчик подтвердил наличие у него того или иного интереса или задачи,
но предложение в конечном счете не было им принято. Скорее всего, это наши недоработки.
Запрос построим так:
Имеется предложение для удовлетворения
определенного интереса заказчика,
И интерес подтвержден заказчиком,
И предложение не принято заказчиком.
6. Как найти способы отработки возражений? 5
Теперь выявим предложения, к которым заказчик выдвинул контраргумент,
для которого существует способ опровержения.
Запрос будет таким (режим «Поиск по связям»):
Результат запроса:
Нажав на причину неудачи,
увидим способ отработки возражения.
7. Как предсказать возможные проблемы? 6
У интересов заказчика в модели
есть собственная классификация.
Один из наиболее очевидных
и часто встречающихся в наших
пре-сейлах интересов –
«снизить затраты на интеграцию
информационных систем».
Предположим, мы начинаем новый
пре-сейл, в котором заказчик
демонстрирует такой интерес.
Посмотрим, по каким причинам
заканчивались неудачей сделки,
в которых заказчик подтверждал
наличие у него такого интереса.
Запрос будет таким:
8. Как предсказать возможные проблемы? 7
Результат содержит, например, такие причины:
Собственный отдел ИТ блокирует работу с подрядчиками, предпочитая делать
все своими силами (Субъективная, организационная причина).
У заказчика нет действительной заинтересованности в снижении объемов
и стоимости работ по интеграции (Несоответствие поставленных и решаемых задач).
Уже идет создание собственного решения для той же проблемы, но без семантики
(Объективная причина).
Посмотрев на эти причины, и исключив те, которые заведомо возникли только в одной
конкретной организации, можем сделать вывод о том, на чем следует сосредоточиться
при работе с заказчиком.
9. Проанализируем положительный опыт! 8
Предположим, мы хотим
предложить заказчику продукты
Onto.pro и АрхиГраф.MDM.
Построим список принятых
предложений, содержащих
эти продукты, и выведем
список преимуществ, которые
сыграли роль в их успехе:
Запрос будет таким:
10. Проанализируем положительный опыт! 9
Результаты запроса:
Нажав на каждое из преимуществ,
получим список презентационных
материалов, в которых оно
представлено и обосновано.
Другими интересными кейсами мы готовы поделиться
в частной демонстрации