Технические вопросы клиентов: что отдавать инженеру, а что закрывать на сайте
·13 мин чтения
Коротко о главном:
Вопрос уходит инженеру не потому, что он сложный, а потому, что на него нет письменного ответа. Прайс есть — вопрос о цене до инженера не доходит; диапазона допусков нигде не записано — доходит каждый раз.
Четыре типа вопросов с заводского сайта: «есть ли и сколько» (ответ есть), «а сможете ли в принципе» (нужен человек, но ответ типовой), «вот чертёж, посчитайте» (человек плюс данные), «вопрос по действующему заказу» (сразу человек).
Три признака «это к инженеру»: нужно инженерное суждение, а не данные; за ответ отвечают деньги или гарантия; ответ зависит от загрузки производства.
Считать нужно не заявки, а часы: время инженера на типы 1 и 2 плюс время, которое вопрос ждал владельца.
1. Короткий ответ: инженеру уходят не сложные вопросы, а те, у которых нет письменного ответа
Тезис, вокруг которого построен весь разбор: вопрос уходит инженеру не потому, что он сложный, а потому, что на него нет зафиксированного ответа.
Проверить это легко на себе. Возьмите любой вопрос, который менеджер пересылает инженеру, и спросите: где лежит письменный, актуальный, утверждённый ответ на него? Прайс — лежит, и поэтому вопрос «сколько стоит» до инженера не доходит. Срок по типовой позиции — обычно лежит, хотя бы в виде «мы делаем такие детали за две недели». А вот диапазон допусков, который вы держите стабильно, правила приёма давальческого материала, требования к документации заказчика, минимальный объём партии — на эти вопросы письменного ответа чаще всего нет нигде. Он живёт в голове инженера и воспроизводится заново на каждый запрос.
Типичный пример, который узнают почти все. Клиент спрашивает: «какие допуски вы держите по диаметру на партии 200 штук». Менеджер знает, что ответ где-то есть, но не знает где; инженер знает ответ, но у него смена. Дальше вопрос либо ждёт, либо задаётся заново через неделю другому клиенту — и всё повторяется.
Отсюда следует неприятное: причина — не сложность продукта, а отсутствие зафиксированного знания. И лечится это не покупкой технологии, а тем, что кто-то один раз сядет и запишет то, что знает производство.
Общий контекст. Gartner в пресс-релизе от 15 сентября 2020 года прогнозировала, что к 2025 году 80 % B2B-взаимодействий поставщика и покупателя будут происходить в цифровых каналах — источник прочитан в архивной копии, живая страница закрыта Cloudflare.
Оговорки обязательны, и их три. Это прогноз 2020 года, а не замер: 2025 год прошёл, факт-чек своего прогноза Gartner не публиковала, выборка и методология в пресс-релизе не раскрыты. В понятие «цифровой канал» входят и маркетплейсы, и электронные закупочные площадки — то есть это не обязательно сайт поставщика. И главное: к российским заводам эта цифра не относится никак.
Там же Gartner приводит ещё одну оценку из своей клиентской исследовательской базы: покупатели тратят лишь 17 % времени на встречи с потенциальными поставщиками, когда рассматривают покупку. Это оценка консультанта, а не измерение, выборка не раскрыта, речь про B2B вообще. Читать её стоит так: покупатель большую часть времени проводит не с вами — значит, то, что вы успеваете сказать в цифровом канале, весит больше, чем то, что скажете на встрече.
Из свежих обзоров к этому добавляется тезис без цифры, который стоит держать в голове: окно влияния на B2B-покупателя сжимается, значительная часть решения формируется до контакта с продавцом — по пересказу обзора 6sense 2025 года; страница отдаёт 403, конкретных цифр с методологией мы не получили, и это обзор вендора, заинтересованного в тезисе.
И то, что нужно сказать прямо, без всяких оговорок: сопоставимых российских замеров по обращениям на сайтах производителей нет. Ни по доле вопросов, которые доходят до инженера, ни по времени ответа на них, ни по тому, какая часть обращений закрывается письменно. Придумывать эти проценты мы не будем — вместо них ниже рабочая рамка и способ проверить её на своих данных.
2. Что происходит с вопросом между сайтом и инженером
Коротко: вопрос проходит через несколько рук, и на каждом переходе теряется своё — сначала владелец, потом контекст, потом время.
Разберём маршрут по этапам, а не по часам: часы у каждого свои, а этапы одинаковые.
Этап
Что происходит
Где вопрос
Приход
Клиент спрашивает про допуск, материал или срок
В форме или почте, владельца нет
Автоответ
«Мы свяжемся в рабочее время»
Формально обработан, содержательно — нет
Менеджер
Читает и понимает, что ответить не может
У менеджера
Передача
«Посмотри, пожалуйста» — без контекста
У инженера, в смене
Уточнение
Инженер переспрашивает про материал и чертёж
У инженера
Ответ
Уходит клиенту
Клиент мог уже выбрать другого
Посчитаем, сколько вопрос был «ничьим». Между приходом вопроса и появлением конкретного владельца с ответственностью проходит время, которое не тратится на работу: оно тратится на то, что вопрос лежит в очереди, которой никто не управляет. Это самая дешёвая для устранения потеря в цепочке — она не требует ни инженера, ни новых людей, только маршрут.
Второй отрезок — от менеджера до инженера. Здесь потеря возникает дважды: сначала менеджер переспрашивает у клиента то, что можно было спросить сразу, потом инженер переспрашивает у менеджера то, что тот не записал. Каждый переспрос — ещё один круг ожидания.
Важная оговорка: этапы в таблице — иллюстрация маршрута, а не замер вашей ситуации. Замер делается на ваших тридцати обращениях, и как именно — в §5.
И почему скорость маршрута вообще имеет значение. Исследование Lead Response Management Study (2007) на данных одной платформы за три года (свыше 15 000 веб-лидов и свыше 100 000 попыток дозвона) показало: шансы дозвониться до лида в первые пять минут примерно в 100 раз выше, чем на тридцатой минуте, а шансы его квалифицировать — примерно в 21 раз выше. Цифры приводим по пересказу и PDF-зеркалу исследования.
Оговорки: это не «исследование MIT» — данные платформы проанализировал Джеймс Олдройд, работавший тогда в MIT Sloan; это данные по звонкам и по зарубежному рынку, и они говорят про дозвон, а не про качество письменного ответа на технический вопрос. Для нас здесь важен не размер эффекта, а сам факт: маршрут заявки имеет цену.
3. Четыре типа вопросов с заводского сайта
Ниже — рабочая рамка. Это редакционное разделение, а не результат исследования: оно собрано из реальных писем и разговоров на производственных предприятиях, но пропорции у вас будут свои — их видно только в ваших логах. Это единственная честная формулировка, потому что подтверждённой статистики по типам обращений не существует.
3.1. «Есть ли, сколько стоит, какие сроки» — письменный ответ есть, инженер не нужен
Наличие по номенклатуре, цена по прайсу, срок по типовой позиции, условия доставки, документы для закупки, реквизиты. У всего этого есть источник данных, который не зависит от инженера. Если ответ на эти вопросы доходит до инженера — проблема не в продукте, а в том, что данные лежат не там, где их видит менеджер.
3.2. «А сможете ли в принципе» — нужен человек, но закрывается типовыми ответами
Самый интересный тип и самый большой по объёму переспросов. Формулировки: «а сможете ли сделать из 12Х18Н10Т вместо AISI 304», «а какие допуски держите по диаметру», «а минимальная партия какая», «а давальческое сырьё принимаете».
Формально это про возможность, и поэтому письма уходят инженеру. Фактически значительная часть таких вопросов повторяется из запроса в запрос, то есть ответ на них может быть записан заранее: диапазон допусков, который вы держите стабильно; список материалов, с которыми у вас есть опыт; минимальные партии по типовым операциям; правила приёма давальческого материала и входного контроля. Такие ответы не заменяют инженера — они снимают с него переспросы.
3.3. «Вот чертёж, посчитайте» — человек плюс данные
Здесь ответить заранее нельзя по определению: результат зависит от конкретной геометрии, материала и допусков. Роль сайта в этом типе не в том, чтобы ответить, а в том, чтобы собрать входные данные до того, как заявка дойдёт до инженера: материал, объём партии, чертёж или его номер, допуски, требования к документации, желаемый срок. Заявка, дошедшая до инженера с этими шестью пунктами и историей диалога, экономит ему один круг переспросов. Заявка без них — это пинг-понг на два дня.
3.4. «Мы уже работаем, вопрос по заказу» — сразу человек, автоматике туда нельзя
Статус действующего заказа, изменение спецификации, сроки по конкретной партии, претензия по качеству, вопрос по оплате. Здесь любой автоматический ответ опасен: клиент ждёт не информации, а решения, и любой ответ не от того человека воспринимается как отписка. Такие обращения должны уходить человеку немедленно, с приложенной историей диалога, а не «до выяснения».
Отдельно про проверяемую замену расхожему «кто ответил первым, тот и получил сделку»: XANT, 2021 — конверсия примерно в 8 раз выше, если попытка контакта сделана в первые пять минут (5,7 млн лидов, 400+ компаний, по лендингу исследования). Источник прочитан. И то же ограничение, что и выше: это данные по контактам за рубежом, а не про технические вопросы на заводском сайте.
4. Что реально уходит инженеру: три признака
Коротко: нужно инженерное суждение, а не данные; за ответ отвечают деньги или гарантия; ответ зависит от загрузки производства — если хотя бы один признак есть, вопрос к человеку.
Если рамка из четырёх типов кажется слишком крупной, есть три признака, каждый из которых означает «это к инженеру».
Первый: в ответе нужно инженерное суждение, а не данные. «Какой допуск у нас в справочнике» — данные. «Выдержите ли этот допуск на партии 200 штук из этого материала с учётом того, что у нас загружено в этом месяце» — суждение. Второе зависит от состояния производства в моменте, и никакая таблица его не заменит.
Второй: за ответ отвечают деньги или гарантия. Если ошибка в ответе приведёт к возврату партии, переделке за наш счёт или срыву срока по договору — отвечать должен тот, кто отвечает и головой, и должностью. Особенно это касается гарантийных обязательств и любых обещаний по допускам.
Третий: ответ зависит от загрузки производства. «Когда мы сможем» — это всегда вопрос к плану, а не к прайсу. Если менеджер отвечает на него «в среднем две недели», он угадывает.
Важный вывод из этих трёх признаков: уход вопроса к инженеру — не сбой, а нормальный процесс. Плохо не то, что инженер отвечает. Плохо, когда он отвечает на первый и второй тип вопросов — то есть на то, что можно было записать один раз.
5. Что можно забрать обратно на сайт и как это проверить
Коротко: выгрузить тридцать последних обращений, разметить по четырём типам и посчитать часы инженера, которые ушли на первые два типа.
Инструкция ровно на один вечер плюс неделя на обработку.
Шаг 1. Выгрузите тридцать последних обращений с сайта. Форма, чат, письма «напишите нам», сообщения в мессенджеры, если они приходят на сайт. Тридцать — минимальный объём, при котором видна картина; если у вас их сто, берите сто.
Шаг 2. Разметьте каждое по четырём типам из §3. Не пытайтесь быть точным до последней запятой: спорные случаи отправляйте в тот тип, где требуется больше человеческого участия. Получится четыре кучки, и вы впервые увидите, какую долю занимает каждая.
Шаг 3. Посчитайте, сколько времени инженера ушло на типы 1 и 2. Не «сколько заявок», а часы: сколько времени инженер потратил на вопросы, ответы на которые либо были в чужой таблице, либо повторялись из письма в письмо. Это ваша первая честная цифра, и она получена не из чужого отчёта, а из ваших логов.
Шаг 4. Отдельно выпишите те случаи, где вы уже кому-то отвечали — в прошлом месяце, в переписке, в прайсе, в регламенте. Это и есть ядро письменных материалов, которое не нужно придумывать: оно уже существует, но разбросано по почтовым ящикам и головам.
Только после этих четырёх шагов имеет смысл решать, что отдавать первой линии. Обратный порядок — сначала выбрать инструмент, потом искать задачу — заканчивается отключением инструмента через месяц.
6. Сколько стоит вопрос, который дошёл до инженера
Коротко: три слагаемых — часы инженера на нецелевые вопросы, время ожидания заявки и цена переделок из-за ответа «примерно».
Считаем по своим данным, без чужих ставок. Формула простая и состоит из трёх слагаемых.
Первое: часы инженера на нецелевые вопросы. (Количество вопросов типов 1 и 2 за месяц) × (среднее время на ответ, включая чтение и переспросы) × (стоимость часа инженера с налогами). Если в вашей компании инженер — самый дорогой человек по часовой ставке, это слагаемое окажется больше, чем ожидается.
Второе: время, которое заявка ждала. (Медиана часов до первого содержательного ответа) × (стоимость часа ожидания). Здесь есть неочевидная деталь: пока заявка ждёт, она не обязательно «теряется» — но она занимает место в потоке, и следующая за ней тоже ждёт.
Третье: переделки из-за того, что вопрос ушёл не туда. Ошибки в обещаниях по срокам и допускам, которые менеджер дал, не имея данных: возврат партии, переделка, скидка на следующую поставку. Это самая дорогая часть и самая редкая — но она есть почти у всех, кто отвечает на технические вопросы «примерно».
Оговорка, и мы её повторяем: ставки инженеров и менеджеров в разных отраслях и регионах разные, и мы намеренно не подставляем среднюю по стране — её негде проверить. Подставьте свою. Формула работает при любой ставке; важен не абсолют, а то, как меняется сумма, когда вы убираете из неё первое слагаемое.
7. Что из этого уже умеет ИИ-консультант, а что не должен
Коротко: забирает вопросы первого и второго типа — из ваших данных и утверждённых материалов; третий и четвёртый типы целиком передаёт человеку вместе с историей диалога.
Что забирает. Вопросы первого типа — из ваших данных: наличие, цена, срок по типовой позиции, доставка, документы. И вопросы второго типа — из ваших же материалов: диапазоны допусков, материалы, с которыми есть опыт, минимальные партии, правила по давальческому материалу, требования к документации. В обоих случаях работает один принцип: он отвечает тем, что вы утвердили, и не придумывает того, чего в материалах нет.
Что передаёт человеку. Третий и четвёртый типы целиком, вместе с историей диалога: заявки с чертежами, запросы по действующим заказам, любые отклонения. Плюс стоп-темы, которые не обсуждаются автоматически ни при каких условиях: гарантийные обязательства, сроки вне прайса, юридические вопросы, всё, что касается изменений в договоре.
Логика, почему граница проходит именно здесь и почему попытка автоматизировать «всё» заканчивается тем, что бота отключают через две недели, подробно разобрана в статье чат-бот на сайте: что он реально даёт и когда от него больше вреда. Коротко: клиент прощает боту «это я передам инженеру» и не прощает выдуманный допуск.
И самое дорогое предупреждение этого раздела. Консультант, обученный по общим знаниям модели, а не по вашим материалам, будет выдумывать допуски и сроки с той же уверенностью, с какой называет верные. Это самая дорогая ошибка внедрения, и она тем вероятнее, чем меньше у вас зафиксировано. Почему это происходит технически и что с этим делать — в статье почему бот не отвечает по базе знаний. Поэтому порядок обратный тому, как обычно продают: сначала письменные ответы на типы 1 и 2, потом инструмент. Как это выглядит для производственной компании — разбор ниши «производство» на странице аналитики.
8. Чего этот подход не решает
Раздел, без которого остальное читается как реклама. Здесь мы честно перечисляем то, что не изменится.
Не решает проблему плохого предложения. Если цена неконкурентная или сроки объективно хуже рынка, никакая скорость ответа этого не исправит: быстрый отказ — тоже отказ.
Не заменяет инженера на нестандарте. Там, где нужно инженерное суждение, отвечает человек. Мы нигде не утверждаем обратного, и ни один из типов вопросов выше не переводится в автоматический режим целиком.
Не работает без владельца процесса. Если в компании нет человека, который отвечает за содержание письменных ответов, любые материалы устареют и начнут врать — что хуже, чем их отсутствие.
Не отменяет необходимость маршрута эскалации. Система без маршрута опаснее, чем её отсутствие.
И общий контекст, который стоит знать до того, как вы согласитесь на пилот. По докладу MIT NANDA «The GenAI Divide: State of AI in Business 2025» (август 2025), приведённому Fortune: аналитики собрали 150 интервью с руководителями, опрос 350 сотрудников и анализ 300 публичных внедрений ИИ и обнаружили, что лишь около 5 % пилотов дают быстрый рост выручки, а остальные не приносят измеримого эффекта на P&L. Источник прочитан; сам PDF отчёта публично не скачивается.
Оговорки: формулировка доклада — «около 5 % достигают быстрого роста выручки», а «95 % неудач» — уже интерпретация заголовка. Это данные по корпоративным пилотам вообще, не по российским заводам. И причина неудач, по докладу, не в моделях, а в разрыве интеграции: инструменты не учатся на процессах организации.
Там же есть вещь, которая бьёт прямо в тему этой статьи. По данным того же доклада, закупка готовых инструментов у специализированных вендоров и партнёрства оказываются успешными примерно в 67 % случаев, тогда как внутренняя разработка — примерно в три раза реже по частоте успеха (в формулировке доклада: «internal builds succeed only one-third as often»). Формулировка полезна тем, кто собирается «написать своего бота»: чаще всего проблема не в том, что не хватило разработчика, а в том, что не хватило описанного процесса. У нас это ровно тот случай: пока ответы на типы 1 и 2 не зафиксированы, никакой бот их не найдёт — ни купленный, ни свой.
9. С чего начать на этой неделе: три шага
Коротко: выгрузить тридцать обращений, разметить по четырём типам и выписать пять–десять повторяющихся ответов, которые вы уже кому-то давали.
Шаг 1. Выгрузить тридцать обращений с сайта. За месяц, с текстом и временем. Это делается за час и не требует ни бюджета, ни согласований.
Шаг 2. Разметить их по четырём типам из §3 и посчитать две суммы: сколько времени инженера ушло на типы 1 и 2 и сколько часов заявки ждали владельца. Это ваш ответ на вопрос «есть ли вообще задача».
Шаг 3. Выписать те ответы, которые вы уже кому-то давали. Пять–десять повторяющихся формулировок: диапазон допусков, список материалов, минимальные партии, правила по давальческому материалу, требования к документации. Это ядро материалов, и оно у вас уже есть — просто разбросано.
После третьего шага станет видно главное: у вас проблема с носителем знаний или с маршрутом. Если ответы есть, но их никто не может найти — вопрос в системе первой линии. Если ответов нет нигде — сначала нужно записать, и никакая автоматизация этот шаг не пропустит.
FAQ
«У нас нестандартное производство. Как консультант может отвечать, если каждый заказ уникален?»
Он и не должен считать уникальный заказ. Он отвечает на то, что повторяется: наличие материала, диапазон допусков, который вы держите, сроки по типовым позициям, правила по давальческому сырью, требования к документации. Уникальное уходит инженеру — но уже с собранными входными данными (материал, объём, чертёж, допуски, срок), а не с письмом «посмотри, пожалуйста».
«Наши менеджеры боятся, что консультант наобещает и мы попадём на убыток»
Это решается стоп-темами. Консультант не называет сроки вне прайса, не подтверждает допуск, которого нет в ваших материалах, и не даёт гарантий. Всё, что выходит за границы зафиксированных ответов, передаётся человеку, а не додумывается. Если такой границы нет, система действительно опасна — поэтому стоп-темы утверждаются до запуска, а не после первого инцидента.
«Инженер и так загружен. Не станет ли ему хуже, если заявок прибавится?»
Цель обратная. Инженер перестаёт получать вопросы «есть ли в наличии» и «какой у вас допуск по справочнику» и получает только те, где нужно инженерное суждение, — но вместе с собранным контекстом, без предварительных переспросов. Утверждать, что это сократит его нагрузку на конкретный процент, мы не будем: такой цифры у нас нет и взять её негде.
«У нас есть страница с вопросами и ответами, но её никто не читает»
Страница FAQ помогает, когда человек ищет ответ, а не когда он задаёт вопрос. Разница в том, что в диалоге он получает ответ на свой вопрос, а на странице находит похожий. Поэтому страница и диалог не заменяют друг друга: страница — для тех, кто сравнивает и ищет, диалог — для тех, кто уже пишет.
«Сколько времени займёт собрать материалы?»
Виджет на сайте ставится быстро, но это не запуск. Дальше собирается база знаний по вашим материалам и утверждается вами. По нашим собственным данным у клиентов платформы запуск занимал от нескольких часов до нескольких дней — разброс зависит от объёма материалов и числа интеграций. Это внутренняя статистика компании о своих проектах, а не исследование. Обещать «настроим за 15 минут» мы не будем.
«Что будет с заявкой, если консультант не понял вопрос?»
Он должен передать разговор человеку, а не «дотянуть» ответ. Система без маршрута эскалации опаснее, чем её отсутствие, — это касается и непонятого вопроса, и нетипового.
Что можно сделать прямо сейчас: выгрузить тридцать последних обращений с сайта и разметить их четырьмя пометками — «есть письменный ответ», «нужен человек, но ответ типовой», «нужен человек и данные», «действующий заказ». Через час вы увидите свою пропорцию, которая, скорее всего, окажется непохожей ни на одну публичную статистику.
Получить демо на своём сайте — пришлите десять вопросов с вашего сайта, и мы покажем на ваших формулировках, на какие из них консультант ответит сам, а какие честно передаст инженеру. Состав и цены — на странице тарифов.
Павел Гмир, основатель LeanAgent. Работал на производстве: запуск RAV4 на «Тойота СПб», два цеха — окраска и литьё пластика. Разбираю, где в производственном бизнесе теряются обращения и что с этим можно сделать без обещаний кратного роста. Обсудить можно в Telegram или в TenChat.
ПГ
Павел Гмир, основатель LeanAgent
Работал на производстве: запуск RAV4 на «Тойота СПб», два цеха — окраска и литьё пластика. Пишу о том, как бизнес теряет заявки на скорости ответа и что из этого реально исправить.