Технический пресейл: задачи, роли и передача проекта
Технический пресейл — работа до коммерческого обязательства, которая помогает понять, применимо ли предлагаемое решение к задаче заказчика, что подтверждено и какие проверки ещё нужны. Его результат — понятный объём решения с ограничениями и основанием каждого существенного ответа.
В описании Salesforce о роли sales engineer технический специалист связывает команду продаж и техническую сторону клиента, выясняет задачи и требования. Это описание роли. Порядок работы и формы ниже — авторская практическая схема; они не подтверждают возможности конкретного продукта или компетенции «Кирпича».
Когда подключать технического специалиста
Подключай его, когда ответ зависит от условий применения: интеграции, исходных данных, совместимости, режима работы, ограничений оборудования или состава проекта. Не обязательно ждать полного технического задания. Достаточно определить вопрос, по которому продавец не может дать обоснованный ответ.
«Есть интеграции» — слишком широкий вход. «Нужно передавать заявки из системы заказчика, формат и доступ ещё неизвестны» — уже проверяемая задача. Она помогает выбрать нужного специалиста и не обещать готовое подключение по одному слову в презентации.
Раздели роли
| Участник | За что отвечает в этой схеме | Что не должен подменять |
|---|---|---|
| Менеджер по продажам | Контекст задачи, участники, коммерческая граница, договорённости о следующем шаге | Техническое подтверждение без основания |
| Технический пресейл | Уточнение требований, сопоставление с документацией, план проверки и ограничения | Гарантию любой будущей доработки |
| Технический представитель заказчика | Исходные данные, ограничения среды, согласование критериев со своей стороны | Подтверждение возможностей поставщика |
| Будущий исполнитель | Оценку способа реализации и получение согласованного пакета | Угадывание обещаний, оставшихся только в переписке продавца |
В маленькой команде несколько ролей может выполнять один человек. Ответственность всё равно стоит записать раздельно: кто формулирует требование, кто отвечает на него, кто согласует проверку и кто получает проект.
Что должно быть на входе
Подготовь описание процесса и желаемого изменения, состав участников, известные ограничения, исходные документы и срок принятия решения. Для каждого сведения укажи источник. Рассказ сотрудника, актуальная спецификация и наблюдение на стенде — разные основания.
Отдельно выпиши то, что пока неизвестно. Если заказчик не может раскрыть данные, предложи допустимый обезличенный образец или описание структуры. Не загружай закрытые материалы в сторонние сервисы ради удобства. Если без них нельзя проверить требование, сохрани зависимость в ответе.
Матрица требования и ответа
Одно требование должно позволять принять отдельное решение. Вместо «нужна надёжная интеграция» запиши, какой объект передаётся, в каком направлении, что считается успешным результатом и в каких условиях предстоит проверка.
| Поле | Что записать |
|---|---|
| Требование | Проверяемая задача и её приоритет |
| Источник | Документ, версия, дата или подтверждение участника |
| Ответ и основание | Что следует из документации или выполненной проверки |
| Статус | Подтверждено в границах; нужна проверка; не поддерживается по установленному основанию; неизвестно |
| Ограничение | Условия, исключения, зависимости |
| Следующий шаг | Способ проверки, владелец и дата |
Не используй «частично поддерживается» без расшифровки. Укажи поддерживаемую часть и неподтверждённый остаток. Иначе продавец и исполнитель прочитают одну строку по-разному.
Учебная матрица: передача заявок
Это вымышленный проект и условные результаты разбора, а не характеристики существующего решения. Для упражнения заказчик хочет передавать заявки между двумя системами.
| Требование | Условное основание | Статус и следующий шаг |
|---|---|---|
| Согласовать состав полей заявки | В учебном образце перечислены номер, дата и описание; обязательность полей не определена | Состав исходного образца известен; обязательность полей уточняет заказчик |
| Принять файл в нужном формате | Есть образец выгрузки; документация принимающей стороны ещё не получена | Применимость неизвестна; технический пресейл запрашивает описание интерфейса |
| Разграничить доступ | Роли пользователей не описаны | Нужна карта ролей и проверка прав; готовность не заявляется |
| Обработать повторную передачу | Заказчик обозначил риск дублирования | Критерий и способ проверки согласуются с исполнителем |
| Выдержать пиковый поток | Исходных данных о пике нет | Не проверено; нельзя делать вывод из показа одной заявки |
Матрица показывает, какой вопрос отделяет текущий разговор от обоснованного предложения. Если критическое требование не подтверждено, коммерческий ответ должен содержать условие проверки, а не обещание закрыть его после оплаты.
Что передать исполнителю
В пакет входят согласованный объём, матрица требований с основаниями, версии исходных данных, исключения, открытые вопросы, результаты проверок и следующий план. Для каждого обещанного действия нужен владелец. Приложи историю значимых изменений: какая версия требования была заменена и кем.
Передачу завершают сверкой. Исполнитель должен понимать, что предстоит сделать и что заказчику уже сообщено. В учебном примере продавец не передаёт «интеграцию под ключ», если интерфейс ещё неизвестен. Он передаёт этап уточнения применимости с конкретными выходами.
Скачать матрицу пресейла и пакет передачи. Готовность к коммерческому предложению, готовность к реализации и успешная техническая проверка фиксируются отдельно. Посещение демо не закрывает их автоматически.
Источники и документация
- What Is a Sales Engineer, and What Do They Do? · проверено 18.10.2026