Клиент сказал „да“. Что я фиксирую до начала работы

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

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

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

1. Я описываю результат первого этапа и его границы

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

«Внедрить AI в продажи» слишком широко для запуска задачи. В такой формулировке легко смешать поиск контактов, переписку, CRM, подготовку предложений и аналитику руководителя. У каждого участника может оказаться своя картина проекта.

Условный пример для этой статьи: компания хочет AI-помощника, который готовит черновики ответов на входящие обращения. Это учебная ситуация, а не описание проекта автора.

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

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

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

2. Я договариваюсь, как мы проверим готовность

Следующий вопрос: что клиент должен увидеть, чтобы подтвердить выполнение этапа?

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

Для нашего условного помощника я бы включил такие проверки:

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

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

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

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

3. Я называю ответственных с обеих сторон

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

Я предлагаю определить:

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

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

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

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

4. Я связываю сроки с условиями старта

Дата в календаре полезна, когда понятно, на каких условиях она рассчитана.

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

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

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

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

5. Я заранее обсуждаю, как будут появляться изменения

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

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

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

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

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

6. Я собираю договорённости в короткую запись

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

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

Условный текст сообщения после обсуждения:

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

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

7. AI помогает собрать запись, а решения подтверждают люди

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

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

Материалы для этой работы должны быть разрешены к использованию в выбранном инструменте. Сам текст затем проверяет человек, который понимает контекст и полномочия участников. Отправка клиенту и изменение условий требуют отдельного подтверждения; подробнее эту границу я разбирал в статье о полномочиях AI-агента.

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

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