Технические продажи между компаниями (B2B)
От технической заявки до готового коммерческого предложения
В компаниях, которые продают сложное оборудование, предложение готовят менеджер, инженер и закупка — по данным из разных мест.
Часть этой работы требует знаний инженера. Другая — это поиск, перенос и сверка уже известного.
Можно ли обрабатывать больше заявок той же командой, подключая инженера только там, где нужно его решение?
Как это выглядит сейчас
- Заявка
- Разбор
- Данные
- Решение инженера
- Цена / наличие
- КП
Условная схема процесса.
Где встречается
Устройство процесса важнее отрасли
Так работают компании, которые продают оборудование и компоненты: клиент присылает спецификацию, а до предложения нужен подбор, проверка совместимости или инженер.
Признаки такого процесса
- запросы приходят в Excel / PDF / письмах
- ассортимент широкий
- есть аналоги и технические ограничения
- в подготовке участвуют несколько ролей
- цены, наличие и сроки находятся в разных системах
- инженер регулярно подключается к запросам
Что происходит между входящей спецификацией и готовым предложением
Со стороны — одна задача: ответить клиенту. Внутри — переходы между людьми, документами и системами.
Условная схема процесса, а не данные конкретной компании.
Маршрут одного запроса
- Запрос клиента
- Разбор разобрать входящий документ
- Подбор найти позицию, сопоставить обозначения
- Техническая проверка ожидание специалиста
- Цена / наличие / сроки данные в разных системах
- Сборка предложения перенос и повторная проверка
- Коммерческое предложение
Кто участвует: Клиент · Менеджер · Инженер · Закупка · Учётная система
Работа и ожидание
Без реальных цифр. Длины полос показывают только идею соотношения.
Что собрать на одном запросе
- время менеджера
- время инженера
- время закупки / снабжения
- время ожидания
- количество возвратов
- количество уточнений
- полный срок от запроса до КП
- 01
Сначала виден только маршрут
Запрос идёт через менеджера, инженера и закупку. Дело обычно не в одном этапе, а в количестве ручных переходов.
- 02
Проблема не обязательно в самом техническом решении
Часть времени уходит на работу инженера. Вокруг неё — слой подготовки: разобрать документ, найти позицию, сверить обозначения, проверить цену.
- 03
Время работы и срок ответа клиенту — не одно и то же
Сотрудники тратят на запрос часы, а клиент ждёт дни. Большая часть срока — ожидание между этапами.
- 04
Поэтому начинать стоит с одного реального запроса
Не с проектирования системы, а с замера: сколько заняли действия, сколько — ожидание, сколько раз запрос вернулся.
Часть этих действий создаёт результат. Часть просто обслуживает неудобный порядок работы.
Распределение работы
Что требует экспертизы, а что только готовит решение
Можно подготовить
- разобрать документ
- привести данные к понятной структуре
- найти известные позиции
- собрать характеристики
- подтянуть цену
- проверить наличие
- получить срок
- отметить неоднозначные позиции
- подготовить черновик ответа
Требует решения специалиста
- проверить применимость
- выбрать аналог
- оценить технический риск
- разобраться с исключением
- принять решение при недостатке данных
- взять ответственность за технический выбор
Чем меньше инженер занят подготовкой, тем больше его времени уходит на решения.
Подготовку можно передать системе. Ответственность — нет.
Экономика процесса
Как понять, достаточно ли проблема дорогая
Количество запросов время на один запрос стоимость рабочего времени
переделки задержки дополнительный найм при росте
Имеет смысл проверить
- остаются ли запросы необработанными в нужный срок
- приходится ли добавлять людей при росте
- теряете ли клиентов из-за задержки
- сколько запросов способна обработать текущая команда
Что произойдёт, если запросов станет на 20–30% больше?
Справится ли текущая команда — или сразу понадобится ещё менеджер, инженер или закупщик?
Эффект появляется, если команда берёт больше запросов, быстрее отвечает, меньше переделывает или не растёт вместе с объёмом.
Это способ посчитать, а не обещание. Цифры — на данных вашей компании.
Что можно упростить
Задача не в том, чтобы убрать инженера из процесса
Задача — убрать работу вокруг его решения, если она не требует инженера. Ниже типовой поток и один из вариантов, который стоит проверить.
Типовой текущий поток
- Заявка
- Разбор
- Поиск
- Сверка
- Инженер
- Цена / наличие
- Сборка
- КП
Один из возможных вариантов
- Заявка
- Подготовленные данные
- Очевидные позиции
- Спорные позиции специалисту
- Решение инженера
- КП
Возможный вариант, а не готовое решение.
Какой именно способ изменения понадобится — заранее неизвестно
Иногда главная проблема вообще не требует новой технологии.
Сначала причина и её цена, потом инструмент. И проверка: какие данные уже есть, что умеют текущие системы, насколько это встроится в ежедневную работу.
Проверка результата
Что измерять, если процесс действительно меняется
Не целевые цифры, а то, что сравниваем до и после — на данных вашей компании.
- Время от запроса до коммерческого предложения
- Время менеджера на один запрос
- Время инженера на один запрос
- Количество запросов на текущую команду
- Количество уточнений и переделок
- Доля позиций, где действительно требуется инженер
- Время ожидания между этапами
Когда такой процесс, скорее всего, не стоит менять отдельным проектом
- запросов мало
- ассортимент небольшой и стабильный
- почти каждый запрос требует полноценной работы инженера
- нужные данные уже в одной системе
- процесс и так достаточно быстрый
- готовое решает задачу дешевле
- узкое место в другом месте
Возможность что‑то автоматизировать ещё не означает, что это стоит делать.
Для начала достаточно нескольких реальных запросов
Проектировать систему и писать задание заранее не нужно. Возьмём несколько недавних запросов и посмотрим, что происходило между спецификацией и готовым предложением.
Дальше решаем, нужен ли следующий шаг: изменить порядок работы, настроить системы, проверить идею, сделать пилот или разработку.
Если проблемы и экономики нет — проект не нужен.
Как выглядит первый шаг
- Взять 3–10 реальных запросов.
- Разложить процесс по действиям и ролям.
- Измерить время работы и ожидания.
- Отделить инженерное решение от подготовительной работы.
- Понять причины задержек и возможный эффект.