ООО Органайзер ЛидерТаск 
Тендеры и лиды
Информация
Сделка уже закрыта, клиент ждёт начала работ, а команда реализации впервые видит проект. Часть условий зафиксирована в договоре, часть осталась в переписке и записях звонков, а некоторые обещания — только в памяти менеджера по продажам. Поэтому передача проекта от отдела продаж в производство нередко начинается с уточнений вместо работы.
Под производством в этой статье мы понимаем не физический цех, а команду, которая выполняет проданную работу: проджект-менеджеров, аналитиков, дизайнеров, разработчиков, маркетологов и других специалистов.
Представим digital-агентство, которое продало клиенту разработку и продвижение сайта. Запуск обещан через шесть недель, в переписке упомянута интеграция, контент должен предоставить клиент, но срок его передачи не определён, а необходимых доступов у команды пока нет.
Разберём, как передать проект из продаж в производство без потери договорённостей: выстроить понятный регламент передачи, собрать паспорт проекта, определить правила приёмки и использовать готовый чек-лист.
Чтобы передать проект в работу без потери контекста, недостаточно переслать договор и открыть команде доступ к файлам. Нужен короткий процесс, в котором информация проверяется, а ответственность явно переходит от продавца к руководителю проекта.
Проверьте готовность проекта. Уточните результат, состав работ, сроки, ресурсы и критичные зависимости.
Назначьте принимающего руководителя. Один человек должен проверить вводные и отвечать за следующий этап.
Соберите паспорт проекта. Зафиксируйте цели клиента, границы работ, участников, материалы, риски и ближайшие действия.
Разделите договорённости по статусам. Отделите подтверждённые условия от обещаний продавца, пожеланий клиента, предположений и открытых вопросов.
Проведите внутреннюю встречу. Продажи передают контекст, а команда реализации проверяет сроки и выполнимость требований.
Зафиксируйте результаты. Для каждого пробела и решения укажите ответственного, срок и влияние на проект.
Подтвердите приёмку. Проект должен получить понятный статус: принят, принят с условиями или возвращён на уточнение.
Проведите стартовую встречу с клиентом. Представьте команду, подтвердите цели, этапы, роли, правила согласования и первый шаг.
В примере с агентством такой алгоритм позволит ещё до начала работ заметить, что интеграция не оценена, дата передачи контента не согласована, а доступы не получены. Команда сможет обсудить эти пробелы до того, как шестинедельный срок начнёт срываться.
Передача проекта заканчивается не тогда, когда продавец отправил файлы, а когда новая команда проверила информацию, приняла ответственность и понимает, что делать дальше.
Передача проекта — это не отправка договора, брифа и файлов. Handoff проекта — это структурированный переход контекста, обязательств, материалов, рисков, принятых решений и ответственности от отдела продаж к команде реализации.
Договор, коммерческое предложение и техническое задание содержат только часть информации. В них могут не попасть устные обещания, особенности коммуникации с клиентом, внутренние ограничения команды, предположения, на которых строилась оценка, причины выбора решения и сведения о лицах, принимающих решения.
Поэтому передача проекта между отделами всегда двусторонняя. Продавец объясняет вводные, а принимающая сторона проверяет их полноту и реализуемость. Пока команда не выявила критичные пробелы и не приняла ответственность, проект нельзя считать переданным.
Договорённости обычно теряются не в момент передачи проекта, а задолго до неё. Пока идут переговоры, информация распределяется между договором, коммерческим предложением, перепиской, созвонами и личными заметками менеджера. В итоге команда реализации получает только часть контекста.
Чаще всего это происходит по нескольким причинам.
Данные находятся в разных каналах. Сроки — в коммерческом предложении, пожелания клиента — в переписке, важные детали — в созвонах. В результате участники работают по разным версиям договорённостей.
Продавец фиксирует коммерческие условия, но не рабочий контекст. В документах есть стоимость и сроки, но нет внутренних ограничений, зависимостей, причин принятых решений и предположений, на которых строилась оценка.
Устные обещания не получают отдельного статуса. Клиент воспринимает их как часть проекта, а команда реализации — как пожелания, которые ещё предстоит обсудить.
Технических специалистов подключают слишком поздно. Пока разработчики или аналитики не проверили требования, оценка может выглядеть реалистичной только на бумаге.
Одни и те же термины участники понимают по-разному. Например, под «интеграцией с CRM» продавец может подразумевать подключение формы, а клиент — полноценный обмен данными между системами. Пока не определены сценарии работы и ограничения, оценить объём проекта невозможно.
Не назначен владелец передачи, нет критериев готовности и подтверждения приёмки. Никто не отвечает за полноту информации, поэтому производство начинает работу с пробелами.
Вернёмся к примеру с digital-агентством. Запуск сайта обещан через шесть недель, но срок зависит от контента, который клиент ещё не подготовил. Интеграция упомянута только в переписке, продавец считает её простой, а разработчики ещё не проверяли требования. Формально проект продан, но команда реализации ещё не готова принять его в работу.
Избежать таких ситуаций помогает единый процесс передачи проекта. Когда все договорённости, документы, комментарии и ответственные собраны в одном месте, а команда подтверждает полноту информации до старта работ, риск потерять важные детали значительно снижается.
Проект готов к передаче, когда команда понимает, что нужно сделать, в какие сроки, какими ресурсами и с какого шага начать. Для проверки используют Definition of Ready — набор критериев готовности проекта к работе.
При этом проект не обязан быть описан идеально. Важно отделить критичные вопросы, без которых старт невозможен, от пробелов, которые можно закрыть уже после приёмки.
Производство не должно принимать проект, если хотя бы по одному из этих пунктов нет ясности:
понятен ожидаемый результат;
определён состав работ;
перечислено, что не входит в проект;
проверены ключевые сроки и зависимости;
назначен принимающий руководитель;
подтверждена доступность нужных специалистов;
отмечены нестандартные требования;
определён ближайший шаг.
Такие пробелы влияют на объём работ, сроки или возможность приступить к реализации. Пока они не устранены, передача остаётся незавершённой.
Некоторые сведения можно уточнить позже, если они не мешают начать первый этап:
часть доступов;
дополнительные материалы;
финальный список участников со стороны клиента;
отдельные референсы;
формат будущей отчётности.
У каждого такого вопроса должны быть владелец и срок. Иначе допустимый пробел быстро превращается в причину задержки.
Проверим по этим критериям проект digital-агентства. Ожидаемый результат понятен, но срок запуска не проверен с учётом подготовки контента. Интеграция упомянута, однако её объём ещё не оценили разработчики. Дата получения материалов неизвестна, доступов у команды нет.
Такой проект нельзя принять без условий: сначала нужно проверить интеграцию и реалистичность срока, а для контента и доступов — определить ответственных и даты. После этого можно собирать паспорт проекта и готовить внутреннюю встречу.
Передача проекта не должна зависеть от одного продавца или проджект-менеджера. В процессе участвуют несколько ролей: одна сторона собирает и объясняет контекст, другая проверяет реализуемость, третья принимает ответственность, а клиент подтверждает ключевые условия.
Готовит: контекст сделки, договорённости, материалы и обещания, которые появились во время переговоров.
Объясняет: почему клиент выбрал конкретное решение, какой результат ожидает и какие условия для него особенно важны.
Отвечает: на вопросы команды в переходный период.
Не должен: исчезать сразу после закрытия сделки и оставлять коллег разбираться с противоречиями самостоятельно.
Проверяет: полноту паспорта проекта, наличие материалов и открытых вопросов.
Принимает: ответственность за следующий этап и дальнейшее взаимодействие с клиентом.
Организует: устранение пробелов, внутреннюю сверку и стартовую встречу.
Не должен: молча принимать условия, которые противоречат друг другу или не прошли проверку.
Проверяет: сроки, ресурсы, компетенции команды и общую реализуемость проекта.
Подключает: профильных специалистов, если есть нестандартные технические, дизайнерские или маркетинговые требования.
Решает: можно ли принять проект, принять его с условиями или вернуть на уточнение.
Проверяют: технические, дизайнерские, рекламные и аналитические требования.
Фиксируют: ограничения, зависимости, риски и вопросы, которые влияют на объём работ или сроки.
Их особенно важно подключать до старта, если продавец не может самостоятельно оценить сложность требования.
Подтверждает: цели, ответственных со своей стороны, материалы, сроки согласования и ближайшие действия.
Не участвует: во внутреннем выяснении противоречий между продажами и производством. Команда должна согласовать единую позицию до разговора с ним.
В проекте агентства продавец передаёт историю договорённостей и поясняет ожидания клиента. Проджект-менеджер проверяет паспорт, руководитель производства оценивает шестинедельный срок, а разработчики уточняют объём интеграции. Только после этого клиенту можно подтвердить реалистичный план и ближайший шаг.
Паспорт проекта — это не обязательно отдельный многостраничный документ. Это единая структурированная запись с актуальными вводными, по которой команда может понять задачу, проверить условия и принять проект в работу.
Главное требование к паспорту — не объём, а полнота. В нём должны быть собраны сведения, которые влияют на результат, сроки, ответственность и ближайшие действия.
Компания и продукт.
Бизнес-задача.
Причина запуска проекта.
Ожидаемый эффект.
Предыдущий опыт клиента с похожими задачами или подрядчиками.
Этот блок помогает понять не только что нужно сделать, но и зачем клиенту проект. Без контекста команда может формально выполнить работы, но не решить исходную задачу.
Что должна передать команда по итогам проекта.
Какие услуги входят в состав работ.
Что явно не входит в проект.
По каким критериям результат считается готовым.
Какие ограничения уже известны.
Особенно важно зафиксировать исключения. Они защищают команду от ситуации, когда клиент считает часть работ согласованной, хотя её не было в оценке.
Основные этапы.
Плановая дата запуска.
Контрольные точки.
Зависимости между работами.
Сроки предоставления материалов клиентом.
Недостаточно указать только финальную дату. Нужно показать, от каких действий клиента и команды зависит график проекта.
Лицо, принимающее решение со стороны клиента.
Рабочие контакты.
Участники со стороны клиента и исполнителя.
Основной канал общения.
Порядок согласования.
Допустимые сроки обратной связи.
Если не определены участники и правила коммуникации, даже понятный проект может остановиться на первом согласовании.
Договор и финальное коммерческое предложение.
Техническое задание или бриф.
Протоколы встреч.
Референсы и аналитика.
Необходимые доступы.
Актуальные версии файлов.
В паспорт не нужно переносить весь архив переписки. Достаточно собрать финальные документы, ссылки и решения, на которые должна опираться команда. Подробный комплект материалов разберём отдельно ниже.
Дополнительные обещания продавца.
Условия, которые не вошли в основные документы.
Предположения, использованные при оценке.
Ожидания клиента, которые ещё не подтверждены.
Например, оценка могла строиться на предположении, что клиент передаст готовый контент до начала дизайна. Если это условие не подтвердить, срок запуска перестаёт быть реалистичным.
Что может повлиять на сроки или объём работ.
Что требует дополнительной проверки.
Кто отвечает за уточнение.
К какой дате нужен ответ.
Можно ли начать работу до получения ответа.
Каждый открытый вопрос должен иметь владельца и срок. Иначе он остаётся заметкой, а не частью управляемого процесса.
Кто принимает проект.
Что должно произойти после передачи.
Когда пройдёт внутренняя встреча.
Когда команда встретится с клиентом.
Паспорт должен завершаться конкретным действием. Если следующий шаг не определён, проект формально описан, но фактически ещё не запущен.
До внутренней сверки часть паспорта может выглядеть так:
Проект: разработка и продвижение сайта.
Ожидаемый результат: новый сайт и запуск SEO-работ.
Срок запуска: шесть недель.
Интеграция: уточняется.
Контент: предоставляет клиент.
Дата передачи контента: не назначена.
Доступы: отсутствуют.
Такой паспорт уже показывает общую картину, но одновременно делает проблемные места заметными. Команда видит, что срок нельзя подтвердить без даты получения контента, а интеграцию — без технической оценки.
Не все договорённости имеют одинаковый статус. Перед стартом проекта важно понять, что уже подтверждено, что требует проверки, а что пока остаётся ожиданием или открытым вопросом. Иначе пожелание клиента легко превращается в «обязательную» работу, а предположение — в скрытый риск для сроков.
Что это: условие, закреплённое в договоре, приложении или согласованном объёме работ.
Что делать: перенести в план проекта и проверить, нет ли противоречий со сроками и ресурсами.
Кто подтверждает: продавец и принимающий руководитель.
Можно ли стартовать: да, если условие понятно и реализуемо.
Что это: условие, которое менеджер озвучил клиенту во время переговоров, но оно могло не попасть в основные документы.
Что делать: проверить, входит ли обещание в согласованный объём и учитывалось ли при оценке.
Кто подтверждает: руководитель производства и ответственный за проект.
Можно ли стартовать: зависит от того, влияет ли обещание на сроки, стоимость или состав работ.
Что это: функция, результат или формат работы, которые клиент упомянул, но стороны ещё не согласовали.
Что делать: отделить пожелание от подтверждённых условий и вынести на отдельное обсуждение.
Можно ли стартовать: да, если вопрос не блокирует ближайший этап.
Что это: условие, на котором строились сроки или оценка. Например, клиент передаст готовый контент до начала дизайна.
Что делать: подтвердить предположение и заранее показать, как его нарушение повлияет на проект.
Можно ли стартовать: только если риск понятен, зафиксирован и принят ответственными.
Что это: важная информация, которой пока нет.
Что делать: назначить владельца, срок ответа и определить, какие работы зависят от решения.
Можно ли стартовать: зависит от того, блокирует ли вопрос первый этап.
В проекте агентства разработка и продвижение сайта входят в согласованный объём. Интеграция, упомянутая в переписке, пока остаётся обещанием продавца. Ожидание клиента увидеть её в первой версии — пожелание, а готовность контента к началу дизайна — рабочее предположение. Дата передачи материалов при этом остаётся открытым вопросом.
После такой классификации становится понятно, что можно сразу включить в план, что нужно оценить, а что — уточнить у клиента.
Паспорт проекта показывает, какие сведения нужны команде, а комплект передачи подтверждает эти сведения документами, материалами, контактами и доступами. Передавать нужно не весь накопленный архив, а только актуальные версии и решения, на которых строится дальнейшая работа.
финальная версия коммерческого предложения;
договор и приложения;
согласованный состав работ;
оценки и калькуляции, доступные принимающим ролям.
Эти документы подтверждают объём проекта, ограничения и условия, которые уже согласованы с клиентом.
бриф;
техническое задание;
протоколы встреч;
исследования и аналитика;
референсы;
исходные материалы клиента.
Для передачи ТЗ команде важно выбрать актуальную версию. Черновики и устаревшие файлы лучше убрать из рабочего пространства или явно отметить, чтобы команда не опиралась на неверные данные.
основные участники со стороны клиента и исполнителя;
лицо, принимающее решение;
рабочие каналы связи;
сроки обратной связи;
порядок согласования результатов.
Этот блок помогает избежать ситуации, когда команда не понимает, кому отправлять результат, кто может его утвердить и сколько времени закладывать на согласование.
сайт и хостинг;
аналитические системы;
рекламные кабинеты;
CRM и другие сервисы;
репозитории;
хранилища файлов.
Отсутствующие доступы нужно не просто перечислить, а назначить ответственных и сроки получения. При этом права выдаются по ролям: внутренние финансовые данные, маржинальность и расчёты не обязаны быть доступны всей команде.
В проекте агентства к моменту передачи должны быть собраны финальное предложение, договор, бриф, протоколы встреч, исходные материалы и контакты клиента. Доступы к сайту, аналитике и CRM пока отсутствуют, поэтому для каждого из них нужно определить владельца и дату получения.
Передавать весь архив переписки не нужно. В рабочем пространстве должны остаться итоговые договорённости, актуальные файлы и ссылки на подтверждённые решения.
Внутренняя встреча по передаче нужна не для повторного пересказа документов, а для проверки реализуемости проекта. За 30–60 минут продажи и команда реализации должны сверить ожидания клиента, объём работ, сроки, риски и завершить обсуждение конкретным статусом приёмки.
Цель клиента и ожидаемый результат. Что клиент хочет изменить с помощью проекта и какой итог считает успешным.
Что именно продано. Какие услуги, этапы и результаты входят в согласованный объём.
Что не входит в проект. Какие работы обсуждались, но не были включены в договорённости и оценку.
Сроки и зависимости. Когда должен быть готов результат, от каких материалов, решений и действий клиента зависит график.
Обещания и рабочие предположения. Что продавец озвучил дополнительно и на каких неподтверждённых условиях строилась оценка.
Участники и порядок согласования. Кто принимает решения, кто участвует в работе и сколько времени отводится на обратную связь.
Материалы и доступы. Что уже получено, чего не хватает и какие пробелы мешают начать ближайший этап.
Риски и вопросы производства. Какие требования нужно проверить, что может изменить объём работ и сроки.
Решения, ответственные и сроки. Каждый открытый вопрос получает владельца и дату ответа.
Статус приёмки проекта. Встреча заканчивается одним из решений: проект принят, принят с условиями или возвращён на уточнение.
Паспорт проекта участники получают заранее, чтобы не тратить время на чтение вводных. Продавец объясняет контекст сделки, ожидания клиента и логику решений, а не зачитывает договор или бриф.
Вопросы нельзя откладывать формулировкой «уточним позже». Если ответ пока неизвестен, сразу назначают владельца и срок. Решения фиксируют во время обсуждения, чтобы после встречи не восстанавливать их по памяти.
В проекте нашего агентства такая сверка показывает, что шестинедельный срок рассчитан без интеграции, хотя клиент ожидает её уже в первой версии. Дизайн зависит от контента, но дата передачи материалов не согласована. Значит, команда пока не может безусловно подтвердить объём и график.
Внутренняя встреча должна завершаться одним из трёх статусов. Именно он показывает, можно ли начинать работу или проект нужно вернуть на уточнение.
критичные сведения подтверждены;
состав работ и сроки согласованы;
команда и ресурсы доступны;
ближайший шаг определён.
Проект можно передавать в реализацию.
Работу можно начинать, если оставшиеся вопросы:
не блокируют первый этап;
имеют владельцев;
имеют сроки;
зафиксированы вместе с последствиями.
Передача не завершена, если:
состав работ противоречив;
сроки не проверены;
неизвестен итоговый результат;
отсутствует критичный доступ;
не определено лицо, принимающее решение;
нестандартное обещание не оценено.
Возврат проекта — это не конфликт между отделами, а нормальная часть контроля качества. Лучше скорректировать вводные до старта, чем переделывать работу после него.
В нашем примере проект получает статус «принят с условиями». До начала работ нужно согласовать состав интеграции, получить контент к определённой дате, скорректировать этапность и назначить ответственного за доступы.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Внутренняя встреча помогает команде проверить проект и устранить противоречия. Стартовая встреча с клиентом (kickoff) нужна уже для другого — подтвердить согласованные условия и начать совместную работу.
Представить команду и ответственных.
Подтвердить цель проекта и ожидаемый результат.
Ещё раз согласовать состав работ и исключения.
Обсудить этапы, ключевые даты и зависимости.
Определить каналы связи и порядок согласования.
Уточнить, какие материалы и к какому сроку должен предоставить клиент.
Зафиксировать ближайшие шаги обеих сторон.
Продавца стоит пригласить, если клиенту давали нестандартные обещания, переход проходит чувствительно, аккаунт-менеджер ещё не выстроил отношения или остались вопросы по договорённостям, достигнутым во время продажи.
В нашем примере агентство подтверждает обновлённый план: сначала команда готовит структуру и прототип, интеграция оценивается отдельным этапом, клиент передаёт контент к установленной дате, а запуск рекламы начинается только после готовности сайта и аналитики.
После встречи договорённости лучше сразу перенести в рабочий план.
После передачи проекта у команды должен быть единый источник правды — рабочее пространство, где собраны все актуальные данные по проекту. Не архив переписки, а информация, по которой команда действительно работает.
В нём должны храниться:
актуальный паспорт проекта;
задачи, сроки и ответственные;
финальные версии файлов;
открытые вопросы;
подтверждённые решения;
история изменений.
Для каждого важного решения стоит фиксировать:
дату;
участников;
точную формулировку;
основание;
влияние на объём, сроки или стоимость;
связанные задачи.
Например, если интеграцию решили вынести в отдельный этап, важно зафиксировать не только само решение, но и его причины, последствия для сроков и задачи, которые нужно изменить.
CRM хранит историю сделки, а система управления задачами — план реализации проекта. После выигрыша сделки ключевые сведения переносят из CRM в рабочее пространство, где команда ведёт проект дальше.
Даже если часть данных переносится автоматически, их всё равно нужно проверить на полноту и актуальность. Автоматизация передаёт информацию, но не проверяет её смысл.
Любую новую просьбу клиента нужно оформлять как запрос на изменение (change request), а не добавлять незаметно в согласованный объём работ.
Сам процесс выглядит так:
Зафиксировать новый запрос.
Сравнить его с исходным объёмом работ.
Оценить влияние на сроки, ресурсы и стоимость.
Назначить ответственного.
Согласовать изменение внутри команды.
Получить подтверждение клиента.
Обновить паспорт проекта, план и связанные задачи.
Нельзя незаметно добавлять новую работу в существующие задачи, считать любое сообщение клиента подтверждённым изменением, менять сроки без объяснения причины или работать по устаревшей версии договорённостей.
Например, после старта клиент просит добавить личный кабинет. Команда фиксирует запрос, подтверждает, что он не входил в исходный объём, оценивает дополнительный этап, согласовывает новые сроки и только после подтверждения клиента обновляет план.
Передачу проекта стоит разбирать после приёмки или завершения первого этапа. Такой разбор помогает понять, где процесс дал сбой и что изменить в брифах, коммерческих предложениях и пресейле.
Команде полезно проверить:
каких сведений не хватало;
какие обещания пришлось пересматривать;
какие услуги продали без технической проверки;
где возникали повторные уточнения;
какие поля паспорта не использовались;
каких полей, наоборот, не хватило.
Для контроля передачи достаточно нескольких показателей:
доля проектов, принятых с первого раза;
время от закрытия сделки до приёмки;
количество критичных уточнений после передачи;
переделки из-за неполных вводных;
изменения, не прошедшие согласование;
соблюдение даты стартовой встречи.
Метрики передачи проекта нужны не для наказания продавцов. Они показывают, какие обещания регулярно создают риски, где нужно раньше подключать производство и как улучшить взаимодействие отдела продаж и команды реализации.
Например, если проекты с интеграциями часто возвращают на уточнение, стоит добавить техническую проверку ещё на пресейле и расширить соответствующий блок в паспорте проекта.
Общий процесс передачи остаётся одинаковым, но для разных услуг команда проверяет разные сведения.
Особое внимание:
функциональным требованиям;
интеграциям;
архитектурным ограничениям;
доступам;
контенту;
этапам тестирования.
Особое внимание:
составу макетов;
количеству концепций;
числу итераций;
референсам;
бренд-материалам;
порядку согласования.
Особое внимание:
доступам к аналитике и рекламным кабинетам;
исходным показателям;
географии;
бюджету;
ограничениям площадок;
формату отчётности.
Особое внимание:
зависимостям между направлениями;
единому руководителю;
очередности этапов;
общим контрольным точкам;
границам ответственности команд.
Например, запуск рекламы нельзя планировать раньше готовности сайта и настройки аналитики, а дизайн — без контента и утверждённой структуры.
Этот пример показывает, как регламент передачи помогает превратить разрозненные договорённости в реалистичный план работы.
запуск сайта обещан через шесть недель;
интеграция упомянута только в переписке;
контент должен предоставить клиент;
сроки передачи материалов не согласованы;
необходимые доступы отсутствуют.
интеграция не входит в первоначальную оценку;
шестинедельный срок возможен только при своевременной передаче контента;
запуск рекламы зависит от готовности сайта, аналитики и доступов;
часть решений ещё не подтверждена клиентом.
интеграцию вынесли на отдельную оценку;
назначили срок передачи контента;
разбили проект на этапы;
назначили ответственных за доступы;
зафиксировали зависимости;
обновили дату запуска;
провели стартовую встречу с клиентом по согласованному плану.
Команда реализации приняла реалистичный план, клиент увидел границы работ, спорные обещания разрешили до старта, а у каждого открытого вопроса появился ответственный и срок.
Так передача проекта перестала быть формальной пересылкой документов и стала управляемым процессом: команда проверила вводные, согласовала изменения и начала работу по подтверждённым условиям.
Большинство проблем возникает не из-за сложного проекта, а из-за нарушений самого процесса передачи. Вот ошибки, которые чаще всего приводят к повторным уточнениям, задержкам и конфликтам между продажами и командой реализации.
Переслать переписку вместо структурированного паспорта. Команде приходится самой восстанавливать контекст и искать актуальные договорённости.
Не отделить договорные условия от устных обещаний. Клиент считает всё согласованным, а производство узнаёт о дополнительных ожиданиях уже после старта.
Подключить производство только после подписания нестандартного проекта. Сложные требования и сроки остаются без технической проверки.
Не указать, что не входит в объём работ. Пожелания клиента постепенно превращаются в обязательства и дополнительную работу.
Не назначить принимающего владельца. Никто не отвечает за полноту данных, устранение пробелов и следующий шаг.
Провести встречу с клиентом до внутренней сверки. Команда выходит к клиенту с противоречивыми позициями и не может подтвердить реалистичный план.
Считать молчание производства подтверждением приёмки. Проект формально передан, но ответственность за него никто не принял.
Оставить вопросы без владельцев и сроков. Уточнения откладываются и начинают блокировать работу уже после старта.
Хранить решения только в чатах. Команда теряет актуальную версию договорённостей и продолжает работать по старым вводным.
Добавлять новые требования без отдельного согласования. Объём работ растёт незаметно, а сроки и стоимость остаются прежними.
Проверить себя по этим пунктам полезно перед каждой приёмкой проекта. Следующий чек-лист поможет быстро понять, собраны ли ключевые сведения, назначены ли ответственные и можно ли передавать проект в работу.
Этот чек-лист помогает проверить процесс передачи проекта на трёх этапах: до внутренней встречи, во время обсуждения и после приёмки.
назначен принимающий руководитель;
сформулирована цель клиента;
определён ожидаемый результат;
зафиксирован состав работ;
перечислены исключения;
проверены сроки;
собраны ключевые материалы;
отмечены обещания продавца;
перечислены рабочие предположения;
зафиксированы риски;
собраны открытые вопросы;
определены участники встречи.
продавец объяснил контекст сделки;
команда сверила состав работ;
производство проверило сроки и зависимости;
нестандартные требования переданы профильным специалистам;
определены критичные пробелы;
каждому вопросу назначены владелец и срок;
зафиксированы решения;
выбран статус приёмки проекта.
обновлён паспорт проекта;
назначены ближайшие задачи;
получены или запрошены доступы;
подготовлена стартовая встреча с клиентом;
клиент подтвердил роли и этапы;
решения сохранены в рабочем пространстве;
новые запросы отделены от исходного объёма работ;
ответственность передана руководителю проекта.
Например, в LeaderTask регламент передачи можно собрать в одном рабочем пространстве: проекте клиента с задачами, сроками, файлами, комментариями и ответственными. Сервис не заменяет сам процесс, а помогает сделать его прозрачным и проверяемым.
Подключите продавца, руководителя производства, проджект-менеджера и специалистов, которые проверяют нестандартные требования.
Добавьте в неё:
чек-лист готовности;
актуальные файлы и ссылки;
сроки;
одного ответственного за передачу;
комментарии с итоговыми решениями.
Для каждой укажите исполнителя и срок. Например:
оценить интеграцию;
получить контент;
запросить доступы;
подтвердить дату запуска.
Так спорные условия не растворяются в описании проекта и не остаются без владельцев.
Создайте колонки:
готовится передача;
на проверке;
требуется уточнение;
принято с условиями;
принято;
встреча с клиентом проведена.
Карточка проекта перемещается между колонками по мере проверки и приёмки. Для отдельных задач внутри проекта используются стандартные статусы LeaderTask: «Не началось», «В работе», «Отложено», «Отменено» и «Завершено».
После того как проект получил статус «Принято» или «Принято с условиями», назначьте проджект-менеджера ответственным за дальнейшую работу, обновите ближайшие задачи и завершите мастер-задачу «Передача проекта».
LeaderTask и другие таск-менеджеры не заменяет CRM: коммерческая история остаётся в CRM, а в рабочий проект переносится проверенная информация для реализации. Автоматическое создание проекта или синхронизацию сделок стоит упоминать только при наличии подтверждённой интеграции.
Можно начать подготовку и техническую проверку, особенно если проект включает нестандартные требования или жёсткие сроки. При этом важно обозначить статус каждого условия: что уже согласовано, а что пока остаётся предварительным. Оценивать юридическую достаточность документов должны профильные специалисты.
Продавец готовит и объясняет коммерческий контекст, договорённости и обещания. Принимающий руководитель проверяет полноту информации и не подтверждает передачу, пока критичные пробелы не устранены.
Зафиксировать его отдельно, проверить влияние на объём работ и сроки, затем получить решение ответственных. Устное обещание нельзя автоматически включать в утверждённый объём проекта.
Не всегда. Его участие желательно, если были нестандартные обещания, сложные переговоры, чувствительная передача отношений или у новой команды остались вопросы по контексту сделки.
Не отменять проверку, а сократить её до критичного минимума. До старта должны быть понятны результат, состав работ, исключения, сроки, ресурсы, риски, ответственный и ближайший шаг.
Да. Нужно определить, кто после закрытия сделки создаёт рабочий проект, какие данные переносит и кто проверяет их полноту. Например, сведения можно вручную перенести в общий проект таск-менеджера. Понятный ручной процесс надёжнее автоматической передачи непроверенной информации.
Те, которые блокируют ближайший этап: неизвестен итоговый результат, не определён состав работ, не подтверждён ключевой срок, не хватает ресурсов или критичных доступов, не назначен ответственный за решение.
Чтобы передача проекта не зависела от памяти продавца и разовых договорённостей, закрепите короткий повторяемый регламент:
подготовьте один актуальный паспорт проекта;
назначьте одного принимающего руководителя;
проведите внутреннюю сверку продаж и команды реализации;
получите явное подтверждение приёмки;
отдельно проведите стартовую встречу с клиентом;
фиксируйте новые требования вне исходного объёма работ.
Так проект переходит в реализацию только после проверки вводных, а изменения не смешиваются с первоначальными договорённостями.
Создайте общий проект клиента в таск-менеджере, добавьте мастер-задачу «Передача проекта», назначьте ответственного и соберите в ней чек-лист, сроки, файлы и решения.
