Клиент присылает заявку как ему удобно. Мы научились её принимать

Оптовый клиент не обязан заполнять вашу форму. Он присылает свой Excel с объединёнными шапками и подытогами посреди таблицы, или список текстом в мессенджер, или письмо с вложением, а иногда просто звонит и полчаса диктует. На той стороне сидит менеджер и руками ищет каждую строку в номенклатуре: «втулка стабилизатора перед ВАЗ-2108, 20 шт» — это, вероятно, вот этот артикул, а может быть, и вот тот. Свобода клиента оплачивается временем поставщика, и платят его каждый день. Ниже — как мы устроили приёмку таких заявок у себя, что замерили и какие доработки пришлось откатить, потому что замер показал: стало хуже.

Сразу о том, чей это опыт. EorderPRO — наш собственный продукт, кабинет оптовых заказов, он работает в проде на площадке b2motor.ru. Приёмку заявок мы написали и выкатили в августе 2026 года. То есть за ошибки в ней платили своими деньгами — поэтому и показываем их спокойно. И сразу про ограничение, чтобы не тянуть до середины: голосовой канал в кабинете пока не включён. Разговор про него будет ближе к концу — с замером и без обещаний.

Сколько это стоит, когда руками

Возьмём заявку на 107 позиций — обычная накладная постоянного покупателя, ничего экстремального. По нашим прикидкам ручной поиск такой заявки занимает от получаса у человека, который знает номенклатуру наизусть, до двух с половиной часов у того, кто в ней ещё не освоился. Оговорюсь сразу: это оценка, а не хронометраж — с секундомером над менеджером мы пока не стояли.

Дальше начинается арифметика, которую владелец обычно видит не в часах, а в найме. Быстро работает тот, кто помнит, каким сокращением ваши клиенты называют ремкомплект и под каким кодом он у вас лежит. Таких людей в компании один-два, они же самые загруженные, и их знание нигде не записано. Новый сотрудник разбирает заявку в четыре раза дольше — и месяцами.

Почему очевидные решения не помогают

Первое, что приходит в голову: пусть клиент заполняет нашу форму. Не будет. У него пять поставщиков, и подстраиваться под каждого — не его работа. Кто настаивает, тот теряет заявки в пользу того, кто принимает как есть.

Второе: почтовый импорт. Он у нас был и продолжает работать — но рассчитан на файл известной формы, где заранее описано, в какой колонке артикул, а в какой количество. Пока клиент шлёт свой привычный шаблон, всё хорошо. Стоит ему поменять выгрузку или прислать письмо в свободной форме, и импорт разводит руками.

Насколько разводит — видно на конкретном письме. Одно письмо, 80 строк: наш прежний почтовый импорт сопоставил ноль строк, приёмка — 79. Ноль тут закономерен и не является чьей-то виной: старому импорту нечего было делать с файлом, форму которого ему не описали.

Как это устроено: три акта

Заявка из любого канала попадает в один и тот же конвейер. Не важно, пришла она файлом, письмом или списком текстом, — дальше с ней происходит одно и то же.

Акт первый: понять, что написал клиент

Строка заявки — это не поле в базе, а живая человеческая фраза. В ней вперемешку лежат тип детали, модель машины, артикул, количество и иногда цена, причём в любом порядке и с любыми сокращениями. Разбор такой строки — самая скучная часть работы и самая важная: почти всё качество делается здесь, а не там, где нейросети.

Акт второй: найти кандидатов

Сначала система ищет по артикулу и по номеру производителя — если код совпал точно и бренд в строке не противоречит найденному, товар подставляется сам, без вопросов. Если по полному номеру пусто, идёт второй заход по базовому номеру, без хвостового модификатора: у нас это правило добавило ещё три позиции из шестидесяти пяти — на фоне правок, дающих плюс-минус одну, это много.

Дальше — поиск по словам названия, в нескольких вариантах запроса сразу: сначала короткие и очищенные, полная фраза клиента последней. Сокращения раскрываются по словарю, потому что «перед» и «передний» в каталоге и в заявке живут порознь. Про поиск по собственным данным мы писали в статье «RAG и 1С». Задача родственная, но устроено иначе: там смысловой поиск по документам, здесь — поиск по словам и кодам, потому что артикул надо находить точно, а не «примерно по смыслу».

Акт третий: не дать ошибиться

А вот это — главное, и ради этого абзаца стоило писать статью.

Когда мы первый раз прогнали через обычный поиск позиции, надиктованные клиентом в звонке, вышло красиво: по 28 строкам из 31 что-нибудь нашлось. Девяносто процентов. Радость длилась ровно до момента, когда мы посмотрели, что именно нашлось.

Клиент просит	Поиск возвращает
ремень на генератор	ролик натяжной
стойка стабилизатора перед	втулка стабилизатора
фильтр салонный угольный	фильтр масляный
датчик холостого хода	датчик положения дросселя

Пары здесь собирательные: строки из клиентских заявок и записей разговоров мы не публикуем. Явление ровно такое — вместо детали приезжает её соседка по каталогу.

Для менеджера это хуже, чем честное «не найдено». «Не найдено» видно, оно попадает в список на ручной разбор. А правдоподобно неверная позиция уезжает в заказ молча — и всплывает уже на отгрузке, когда клиент звонит и спрашивает, что вы ему прислали.

И тут же поправка к самому себе, потому что она показывает, как это устроено на самом деле. Когда мы разобрали каждый случай поштучно, часть «ошибок» ошибками не оказалась. В одном товар и правда назывался ровно теми словами, которыми спросил клиент, — просто это была другая деталь, у которой то же слово стоит в скобках названия. Поиск был прав, неправ был я. В другом виновата была не логика поиска, а данные: одна и та же марка машины записана в каталоге двумя разными способами, через «е» и через «и», и связать одно с другим было нечем. Обе находки полезные, но записывать их в брак поиска неверно.

Ценность такой системы не в том, что она находит. Находит что-нибудь любой поиск. Ценность в том, что она знает, где остановиться.

Поэтому третий акт — это набор проверок, каждая из которых умеет сказать «нет»:

• Чужая машина. Если модель названа и в заявке, и в карточке товара, и они не совпадают, кандидат отбрасывается. На одной заявке в 80 строк эта проверка выкинула 79 чужих вариантов. На точных совпадениях по артикулу она не применяется: там источник истины — код, а не название.
• Чужой тип детали. Клиент просит шкив — в названии товара должен быть шкив. С предохранителем: если под нож попали вообще все кандидаты, список остаётся как был, потому что молчание тут хуже шума.
• Уценка и б/у. «Без упаковки», «восстановленный», «уценка» опускаются вниз, если клиент про это не писал. Он просил деталь, а не историю её жизни.
• Аналог — никогда сам. Даже если этого клиента уже спрашивали и он соглашался на замену, система предложит её первой строкой, но не подставит. Замена бренда — коммерческое решение, его принимает человек.

И последнее: цены тянутся отдельно, персональные для контрагента, а не базовые из прайса. Разница между ними бывает заметной. Менеджер в спешке ставит базовую — клиент замечает, и дальше это либо неприятный разговор, либо тихая потеря маржи, если не замечает никто.

Заказ по итогу создаёт менеджер. Не система. Это не осторожность формулировок, а устройство: у кнопки «создать заказ» есть живой человек, и он отвечает за то, что нажал.

Что показали замеры

Теперь цифры, и здесь важно не смешать два разных замера. Боевой конвейер на той самой накладной в 107 позиций: четверть строк система подставила сама — это те, где артикул совпал точно, — семь строк из десяти принесла списком кандидатов на выбор, и всего пять строк из ста семи остались вовсе без ответа. Искать с нуля менеджеру пришлось в пяти случаях из ста семи.

Отдельно мы замерили потолок: если разрешить системе ставить позицию не только по точному артикулу, а по уверенности подбора, без вопросов уходит 68% строк — это прогон на 138 позициях, файл и звонок вместе. Цифра красивая, и ровно поэтому она пока выключена. В том же замере уверенный подбор с высоким счётом ставил на строку без указанного бренда гайку вполне конкретной марки: правдоподобно — и никем не проверено. Порог мы включим тогда, когда наберётся достаточно подтверждений менеджеров, чтобы проверить его на факте, а не на ощущении.

И сразу оговорка, без которой цифра выше врёт. Шестнадцать секунд машинного времени не заменяют двадцать минут работы менеджера — они лежат внутри них. Экономия не в том, что человек ушёл из процесса, а в том, что он перестал искать и начал проверять. Это разная работа: искать утомительно и медленно, проверять — быстро.

Что мерили и что откатили

Дальше самая полезная часть, потому что по ней видно, врём мы или нет.

Первый замер — сверка с заявкой, которую до этого менеджер собрал вручную. У нас есть эталон: 65 позиций, каждая выбрана человеком. Вопрос простой — оказался ли нужный товар среди тех вариантов, что система показала. За одну сессию доработок — таблица в нашем журнале так и подписана, «было утром / стало» — эта доля выросла с 60% до 80%, попадание в первые три варианта — с 52% до 69%. Позиции, которые не попали, не теряются: они уходят в очередь на ручной разбор со сроком в четыре часа.

Второй замер интереснее, потому что сравнивает не с ожиданием, а с фактом. Мы взяли заявку, по которой уже прошла отгрузка, и посмотрели, что система предлагала по каждой отгруженной позиции. Все десять оказались среди предложенных, все десять — в первой тройке, девять из десяти система подставила сама и верно. Выборка крошечная, выводов на ней не построишь. Но это единственный замер, где сравнение идёт с реальностью, а не с чужим мнением о ней. И сразу оговорка, без которой цифра льстит: в том файле была колонка с артикулом, то есть работал точный путь — а он почти безошибочен. Там, где артикулы зашиты в хвост названия, доля ниже, и это как раз те 80% выше.

Замер поймал и наши собственные ошибки. Девятнадцать строк из ста семи — восемнадцать процентов заявки — система подбирала по «ГАЗ-3102», приняв обозначение машины за артикул. Ни один из нас этого не заметил бы, читая выдачу глазами: результаты выглядели правдоподобно.

И симметричная история: за один день три правки, выглядевшие улучшением, результат ухудшили. Самая обидная — расширить окно кандидатов с пяти до двадцати. Логика железная: больше вариантов, выше шанс, что нужный среди них. По факту покрытие упало — нужный товар нашёлся у 49 позиций из 65 вместо прежних 52, — потому что вместе с нужным приехал шум, а пул кандидатов не резиновый. Эту правку откатили целиком, две другие переделали. Поймал их один и тот же эталон, прогнанный после каждой.

Собственно, это и есть весь секрет: не модель, не архитектура, а привычка после каждого изменения прогонять один и тот же эталон. Мы про это уже писали в статье про дообучение — экзамен важнее учебника, и здесь ровно то же самое.

Голос: что уже проверено, а что нет

Голосового канала в кабинете пока нет. В интерфейсе есть заготовка — тип источника и кнопка с микрофоном, — но приём звонков не включён, и обещать его как работающую функцию было бы враньём.

Что есть: рабочий прототип распознавания вне продукта, и он уже замерен на настоящем звонке. Разговор длиной 50 минут 45 секунд превратился в 34 строки, из которых 31 оказалась настоящей позицией заказа: три строки система отбросила как служебные: это были реплики по ходу разговора, а не позиции заказа. Дальше замер тот же прототипный, что дал 68% на потолке: 64% позиций подобрались уверенно, 22% ушли в список на выбор, 12% — на ручной разбор. Причём звонок был телефонного качества, то есть в худших возможных условиях.

Дальше эти строки должны пойти по тому же конвейеру, что файл или письмо, — так это спроектировано. Но честно: боевым конвейером голосовые строки мы ещё не прогоняли, замер сделан отдельной прототипной связкой. Непроверенных мест два — стыковка с кабинетом и поведение боевого подбора на тексте после распознавания.

Отдельно про железо, потому что это первый вопрос, который задают. Распознавание речи идёт примерно в двенадцать раз быстрее, чем длится разговор, на обычном процессоре — видеокарта для него не нужна. А вот подбор она ускоряет сильно, и здесь надо сказать прямо: те самые шестнадцать секунд на 107 позиций получены на видеокартах. На обычном процессоре второй проход по спорным строкам идёт примерно в одиннадцать раз медленнее. Без карты система работает, просто заявка разбирается заметно дольше — это развилка сметы, а не условие запуска. И всё это работает на своём железе: заявки и записи разговоров во внешние сервисы не передаются. Подробнее про то, когда локальная модель оправдана, а когда нет, — в отдельной статье.

Вопросы, которые задают первыми

А если у меня не 1С? Не важно. Нужен доступ к номенклатуре и к персональным ценам любым способом, который у вас есть, — выгрузка, база, обмен файлами. Приёмка живёт рядом с учётной системой и внутрь неё не лезет.

А если номенклатура грязная? Она у всех грязная, и система рассчитана именно на это — грязь приходит с обеих сторон, и из заявки клиента, и из справочника. Предварительно вычищать каталог не надо. Чужие артикулы, которых у вас нет, попадут в «не найдено», и этот список сам по себе полезен: видно, что у вас спрашивают и чего нет.

А если менеджеры не станут пользоваться? Приёмка встроена в тот же экран, где они уже работают, а не отдельная программа с новым паролем. Она отдаёт черновик заказа, который менеджер правит, а не приказ, который надо исполнить. И снимает самую нелюбимую часть работы — вбивание, а не разговор с клиентом. Начинать можно с одного менеджера и одного канала.

Что с заявками, которые не разобрались? Не теряются. Очередь со сроком в четыре часа, менеджер добирает руками, каждая правка запоминается: в следующий раз для этого клиента такая строка предложится сразу. Заявку нельзя удалить — только закрыть с указанием причины, чтобы история решений оставалась прослеживаемой.

Это переносится на другой бизнес

Задача универсальнее, чем кажется. Она звучит так: клиент присылает не то, что вы ждёте, а сотрудник руками сверяет присланное с вашей номенклатурой. Автозапчасти, метизы, электрика, стройматериалы, расходники, медизделия — везде, где у товара есть артикул и сорок способов его назвать, происходит одно и то же.

Честно про перенос. Скелет готов и обкатан: конвейер разбора, память подтверждений, журнал правок, очередь с корзинами — всё это переезжает. А вот отраслевые словари сокращений, правила «что за чем идёт в строке» и защиты вроде «не подставлять деталь от другой модели» пишутся заново под ваш каталог. У себя первая рабочая версия заняла неделю, но у себя мы знали номенклатуру наизусть; в чужом бизнесе дольше — уходит время на интеграцию и на первые недели подтверждений, когда система набирает память.

Поэтому мы не называем проценты заранее. Конвейер переносится, цифры — нет: они зависят от вашего каталога и от того, как пишут ваши клиенты. Первым шагом всегда идёт замер на ваших данных.

Когда вам это не нужно

• Клиенты присылают заявки в вашей форме и уже с артикулами — тогда хватит обычного импорта.
• В заявке пять-десять строк, и таких пара в день. Менеджер справится быстрее, чем вы окупите работу.
• Номенклатура небольшая и стабильная, все её помнят.
• Ассортимент почти не меняется, а покупатели постоянные — дешевле один раз свести таблицу соответствия их кодов вашим.
• Некому первые недели подтверждать спорные строки. Система разгоняется на решениях менеджеров: чем больше подтверждений, тем меньше вопросов она задаёт. Без живого человека в начале она так и останется на стартовом уровне — и это единственное, что вам придётся вложить обязательно.

Что пока не сделано

Голосовой канал в кабинете не включён. Фото и сканы не распознаём. Из мессенджеров напрямую не принимаем — список текстом надо вставить руками. Разбор идёт сразу, пока менеджер ждёт: очередь для фоновой обработки спроектирована, но не запущена. Список честный ровно потому, что по нему нас легко проверить: откройте кабинет и посмотрите.

От чего зависит объём работы

Цену такой системы нельзя назвать по телефону, и любой, кто называет, гадает. Вот развилки, каждую из которых вы можете прикинуть у себя сами:

• насколько чиста номенклатура и есть ли в ней артикулы и номера производителя;
• сколько каналов включаем: файл дешевле почты, почта дешевле голоса;
• есть ли история разобранных заявок — память может стартовать с накопленного, а может с нуля;
• нужна ли видеокарта или хватит обычного сервера;
• берём пилотом один канал и одного менеджера или сразу весь поток.

Точную цифру мы называем после того, как прогоним вашу заявку. До этого любая оценка — гадание, и мы предпочитаем не гадать.