Интернет-магазину показали, как новый сервис передает заказ в учетную систему. На встрече все получилось. После покупки выяснилось, что отмены нужно переносить вручную, а нужный магазину способ доставки в демонстрацию не попал. Проблема возникла между красивым показом и проверкой рабочего сценария.
Разбираемся, что такое пресейл, как он помогает проверить применимость решения до сделки и что передать команде внедрения. В статье — пример небольшого магазина, таблица ролей и готовая карточка итогов. Все ситуации и числа учебные.
Пресейл: проверить, подходит ли решение
Пресейл — предпродажная подготовка решения под задачу клиента. В нее могут входить исследование потребности, уточнение требований, подготовка предложения, демонстрация и пробная проверка. Границы работы зависят от компании. Здесь сосредоточимся на моменте, когда нужно понять, выполнит ли продукт или услуга обещанное в условиях клиента.
В обзоре Salesforce о пресейле определение шире: оно включает подготовительные действия и поддержку до завершения продажи. Отдельный технический специалист — один из возможных участников, а не обязательная должность в каждом бизнесе. В небольшой компании эту работу могут делить руководитель, продавец и исполнитель.
Полезный результат пресейла — согласованное описание задачи и проверенного решения. В нем видно, что входит в предложение, что показали, какие ограничения обнаружили и что предстоит уточнить. Тогда клиент принимает решение по понятным условиям, а исполнитель получает исходные сведения для начала работы.
Это отличается от обычного разговора о покупке. Менеджер может выяснить потребность и согласовать следующий шаг, но не знать, как конкретная учетная система обрабатывает отмену заказа. Такой вопрос стоит проверить с человеком, который разбирается в продукте, до обещания «все работает автоматически».
Кто за что отвечает до и после сделки
Роли полезнее разделять по результату, чем по названию должности. Один человек может совмещать их, сохраняя разные задачи.
Роль | Основной вопрос | Что передает дальше |
|---|---|---|
Продажи | Какая покупка нужна, кто принимает решение и как согласовать условия? | Контекст клиента, коммерческие условия, договоренности |
Пресейл | Подойдет ли предложенное решение под требования? | Проверенные сценарии, ограничения, состав работ и открытые вопросы |
Внедрение или исполнение | Как выполнить согласованные работы и принять результат? | Настроенное решение или выполненную услугу по согласованным условиям |
Например, продавец согласовал бюджет и участников встречи. Специалист проверил, как передаются заказы и отмены. Исполнитель после сделки настраивает согласованный вариант и проверяет его в рабочей среде. Если отмены остались открытым вопросом, их нельзя потерять при передаче.
Лучше заранее назвать ответственного за ответ на технический вопрос. Иначе клиент слышит несколько версий: продавец обещает функцию, специалист говорит о доработке, исполнитель узнает о требовании уже после оплаты. Единая запись по вопросу помогает избежать такого расхождения.
Когда нужна отдельная проверка
Пресейл полезен там, где цена ошибки в выборе заметна: сложное подключение, несколько участников согласования, нестандартная услуга, зависимость от оборудования или процессов клиента. Не каждый заказ требует многочасовой подготовки. Для понятного товара с подтвержденными характеристиками может хватить короткого уточнения совместимости и условий.
Ориентир — неизвестное, которое мешает обещать результат. Магазин покупает готовую подписку, но еще не проверил передачу отмен. Студия берется за съемку, но не выяснила ограничения площадки. Поставщик предлагает оборудование, не получив размеры места установки. В каждом случае сначала нужно закрыть конкретный вопрос.
- Какое требование еще не подтверждено?
- Что случится, если после покупки оно не выполнится?
- Кто и каким способом может его проверить?
- Какой результат проверки нужен для решения?
Если ответ можно получить по документации, нет смысла сразу запускать пробный проект. Если документ описывает только общий случай, стоит проверить нужный сценарий. Масштаб подготовки должен соответствовать вопросу, а не размеру презентации продавца.
Сначала описать задачу и ограничения
Фраза «нужна автоматизация заказов» слишком широка для предложения. В учебном магазине сотрудник вручную переносит заказ с сайта, затем отдельно исправляет запись после отмены. Клиент хочет сократить повторный ввод, но сохранить контроль над изменениями. Это уже описание процесса, который можно обсуждать.
Для первого разбора пригодится один обычный заказ и один проблемный случай. Уточните, где появляется заказ, какие сведения переходят дальше, кто меняет статус и что должно произойти при отмене. Названия систем без последовательности действий не объясняют задачу.
Требование стоит формулировать через наблюдаемый результат. Вместо «удобная интеграция» — «после подтверждения заказа в учете появляется запись с тем же номером, составом и суммой». Вместо «поддержка отмен» — описание того, какой статус и когда должен измениться. Срок и допустимые отклонения стороны согласуют отдельно.
Рядом с требованиями запишите ограничения: доступная версия системы, способ обмена, ответственный за настройку, время на проверку. Если часть сведений клиент еще собирает, обозначьте это как условие дальнейшего расчета. Не стоит подставлять конфигурацию похожего покупателя без подтверждения.
Не все пожелания одинаково важны. Для магазина корректная отмена может быть обязательным условием, а цвет кнопки в интерфейсе — предпочтением. Если смешать их в одном списке без приоритетов, успешный показ второстепенных функций скроет нерешенный основной вопрос.
Выбрать демонстрацию или пробную проверку
Демонстрация показывает, как устроен продукт и как пройти сценарий в подготовленных условиях. Она помогает понять логику работы. Но показ на заранее настроенном стенде не подтверждает совместимость с любой системой клиента.
Пробная проверка отвечает на ограниченный вопрос применимости: получится ли передать нужные сведения, обработать отмену или выполнить другой согласованный сценарий. Ее часто называют проверкой концепции, или PoC. Содержание такой работы нужно определить заранее, а не считать любое тестирование готовым внедрением.
В руководстве AWS по пробной проверке Amazon Redshift отдельно рассматривают цели, критерии и набор проверок. Это инструкция для конкретного продукта. Для своей задачи можно взять принцип: сначала определить, что именно проверяем и какой результат примем, затем выбирать средство проверки.
В нашем примере стандартный показ объяснит, где смотреть заказ и его статус. Проверка на согласованных тестовых примерах уточнит, что происходит при изменении состава и отмене. Полное подключение рабочего магазина, обучение сотрудников и сопровождение после запуска — отдельный объем работ.
Лучше остановить показ на нерешенном ограничении, чем обходить его незаметно для клиента. Если демонстрационная запись создана вручную, это стоит сказать прямо. Тогда покупатель понимает, какую часть процесса он увидел, а какая еще требует подтверждения.
Договориться о границах пробной работы
Перед началом нужны вопрос проверки, сценарии, критерии, срок, участники и итоговый документ. Отдельно согласуйте расходы и доступные ресурсы. Пресейл не означает, что любая подготовительная работа бесплатна или не ограничена по времени.
Для учебного магазина список может включать создание заказа, изменение состава, отмену до передачи, повторную отправку, обработку ошибки и восстановление после сбоя. Это пример, а не готовый универсальный перечень. Конкретные проверки зависят от процесса и возможностей систем.
Если для работы нужны сведения клиента, заранее определите, что действительно необходимо и где это допустимо использовать. Для первого показа могут подойти синтетические примеры без имен, телефонов и других сведений реальных покупателей. Передачу рабочих данных и доступов нельзя считать автоматической частью договоренности о демонстрации.
Важен и момент остановки. Допустим, обнаружилось, что обязательный сценарий требует разработки, которой нет в исходном предложении. Дальше стоит выбрать: оценить отдельную работу, изменить требования или отказаться от решения. Продолжать показывать остальные функции без обсуждения этого ограничения бесполезно для выбора.
Учебный пример: 6 сценариев и открытый вопрос
Предположим, команда согласовала 6 тестовых сценариев передачи заказов. По итогам 4 прошли проверку, для 1 нужна доработка, еще 1 не проверили из-за отсутствия исходных сведений. В отчете нужно сохранить все 3 результата.
Расчет 4 / 6 дает около 67%, но писать «решение готово на 67%» неправильно. Сценарии могут различаться по значимости. Если среди неподтвержденных осталась обязательная отмена, большинство успешных проверок не снимает это ограничение. Лучше перечислить результаты по требованиям и назвать, что мешает решению.
Учет времени тоже помогает договориться о дальнейшем объеме. Учебный расчет: 2 часа на уточнение процесса, 3 часа на подготовку, 1 час на показ и 2 часа на описание итогов — всего 8 часов. Это затраты на конкретную условную проверку, не норматив работы специалиста.
Теперь руководитель видит, на что ушло время и что осталось. Он может согласовать оценку доработки или завершить обсуждение. Сам факт затраченных 8 часов не делает покупку подходящей и не дает основания обещать результат внедрения.
Передать итог, а не только запись встречи
Запись демонстрации помогает восстановить разговор, но исполнителю нужен короткий итог. Иначе он будет искать среди реплик, какое условие согласовали окончательно и относилось ли обещание к стандартной версии или к возможной доработке.
Готовый учебный пример карточки после проверки:
Задача: передавать заказы интернет-магазина в учетную систему и сохранять согласованный порядок обработки изменений.Проверено: 4 сценария из согласованного списка. Требует доработки: 1 сценарий. Не проверено: 1 сценарий, нужны исходные сведения от клиента.Следующий шаг: специалист описывает объем доработки, клиент подтверждает приоритет и недостающие условия. Стоимость и срок внедрения согласуются после этого. До проверки обязательного сценария готовность решения не подтверждена.
К карточке стоит приложить перечень сценариев с фактическими результатами и версию предложения. Если после встречи изменили состав работ, обновление нужно согласовать с участниками. Нельзя тихо заменить документ и считать прежнее согласие подтверждением новых условий.
На передаче внедрению полезно пройти 3 пункта: что обещано, что исключено и какие вопросы открыты. Исполнитель может заметить зависимость, которую не обсуждали. Лучше уточнить ее до старта работ, сохранив уже согласованные условия видимыми.
Рядом с результатом проверки укажите дату и проверенную конфигурацию. После изменения настроек прежний успешный тест не стоит автоматически переносить на новую версию: сначала выясните, затрагивает ли изменение нужный сценарий.
Как организовать пресейл без отдельного отдела
Для начала можно назначить одного владельца подготовки и договориться, когда он подключает специалиста. Например, продавец собирает задачу и вопросы, руководитель проверяет соответствие услуги, исполнитель оценивает нестандартную часть. Клиенту понятно, кто вернется с ответом.
Повторяющиеся вопросы удобно превращать в материалы: короткую демонстрацию, список совместимости, пример результата, описание ограничений. Сначала проверьте содержание с человеком, который отвечает за продукт. Устаревшая заготовка опаснее открытого вопроса, если на ее основе начинают обещать уже недоступную функцию.
Источником таких вопросов служат и отзывы после покупки. В опубликованном кейсе Jarvi и Спикса описана работа с обратной связью о продукте и сервисе. В аналитике отзывов Спикс темы обращений помогают увидеть, что стоит объяснить покупателю заранее. Применимость конкретного технического решения команда проверяет отдельно.
Не стоит оценивать пресейл только числом проведенных показов. Добавьте причины, по которым решение не подошло, затраты времени и вопросы, которые перешли во внедрение. Отказ после обнаружения несовместимости может сэкономить обеим сторонам работу над неподходящим проектом, хотя в отчете продаж он остается отказом.
Что спросить на встрече по итогам
Итоговую встречу лучше строить вокруг решения клиента. Начните с исходной задачи: какой ручной шаг хотели убрать и какое условие было обязательным. Затем покажите результат именно этой проверки. Если обсуждение сразу уйдет в новые функции, участники могут разойтись с разным пониманием готовности.
В учебном магазине полезно спросить: «Правильно ли мы описали порядок отмены?» Ответ может изменить оценку. Допустим, команда проверяла отмену до сборки, а клиент имел в виду отмену уже переданного заказа. Название сценария совпадает, содержание различается. Это повод уточнить требование, а не спорить о том, была ли проверка успешной.
Следующий вопрос: «Какие из открытых условий мешают выбрать вариант?» Так стороны отличают обязательное ограничение от пожелания на будущее. Если без одного сценария магазин не может работать, это нужно отразить в решении. Добавление второстепенных функций не компенсирует отсутствие обязательной.
Затем согласуйте, кто принимает результат. Руководитель магазина может одобрить расходы, а сотрудник учета — проверить правильность статусов. Если один участник не видел итогов, его требования не стоит считать согласованными заочно. Можно отправить короткую карточку с конкретным вопросом и сроком ответа, который участник подтвердил.
Наконец, выберите дальнейшее действие: уточнить сведения, оценить доработку, перейти к предложению или закончить проверку. Для каждого варианта нужен ответственный. Фраза «продолжим сотрудничество» не объясняет, должен ли специалист уже настраивать систему или ждать решения клиента.
После встречи проверьте письмо с итогами глазами исполнителя, который не участвовал в разговоре. Поймет ли он, какая версия решения обсуждалась, какие сценарии проверили и что осталось за пределами работы? Если приходится додумывать, добавьте недостающее условие. Такой документ полезнее подробного пересказа всех реплик: он сохраняет договоренности и основания следующего решения.
Частые вопросы
Пресейл нужен только в ИТ?
Термин часто используют при продаже сложных программных решений. Саму подготовку и проверку применимости можно встретить и в услугах, оборудовании и проектах с нестандартными требованиями. Объем определяется риском ошибки и условиями заказа.
Чем пресейл отличается от внедрения?
В пресейле уточняют задачу и проверяют предложенный вариант до окончательных обязательств. При внедрении выполняют согласованный объем работ. Если подготовка включает разработку или настройку, ее границы и оплату нужно обсудить отдельно.
Успешная пробная проверка гарантирует запуск?
Она подтверждает результат в проверенных условиях. Для запуска могут потребоваться дополнительные настройки, проверки нагрузки, обучение и другие работы. Их стоит перечислить при передаче, а не считать автоматически выполненными.
Что в итоге
- Пресейл помогает проверить применимость решения до обещаний и покупки.
- Опишите задачу, обязательные требования и открытые ограничения.
- Выберите способ проверки под вопрос: документацию, показ или ограниченную пробную работу.
- Сохраните результаты по сценариям, не подменяйте готовность долей успешных тестов.
- Передайте исполнителю согласованный состав работ и вопросы, которые еще предстоит закрыть.
Источники
- Salesforce: Presales vs. Sales. Прочитано 19.10.2026.
- AWS: Conduct a proof of concept for Amazon Redshift. Прочитано 19.10.2026.
- Спикс: кейс Jarvi. Прочитано 19.10.2026.
Разбирайте обратную связь покупателей в Спикс
Темы отзывов помогают выбрать, что уточнить в товаре и объяснениях для покупателей. Посмотрите, как организовать эту работу в Спикс.
Попробовать Спикс