Как с помощью ИИ подготовить переговоры с клиентом: от исследования к вопросам SPIN и MEDDPICC

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

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

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

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

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

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

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

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

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

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

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

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

Такой результат можно обсудить с клиентом в начале разговора:

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

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

Отсюда и начинается применение SPIN.

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

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

Ситуационный вопрос может звучать так: «Как вы сейчас собираете и согласуете требования к насосным узлам и кто участвует в этой работе?»

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

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

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

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

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

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

Здесь важно сохранить смысл буквы I — Implication. Менеджер исследует последствия уже названного затруднения. Ему нужно понять, кто возвращается к выполненной работе, какие действия приходится повторять, затрагивает ли это сроки и насколько существенны последствия.

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

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

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

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

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

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

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

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

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

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

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

Часть сведений менеджер уже получил в разговоре по SPIN. Названное затруднение относится к проблеме клиента — I. Обсуждение результата и способа его проверки даёт материал для метрик — M. Повторять те же вопросы под названием другой модели не требуется.

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

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

Дальше возникают критерии выбора — первый D, Decision Criteria. Что в решении обязательно, какие варианты допустимы и как клиент будет их оценивать?

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

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

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

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

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

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

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

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

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

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

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

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

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

До встречи эти пробелы помогают выбрать вопросы. После встречи — оценить полученные сведения. Требование заполнить всю модель за один разговор способно испортить обе задачи: продавец начнёт торопить обсуждение и принимать приблизительные ответы за достаточные.

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

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

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

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

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

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

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

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

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

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

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

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