Как мы проверяли гипотезу с AI-сервисами и начали с определения кода ТН ВЭД (13 серия)
Когда INSAL расширял направление ВЭД, а мы в CompanionAI параллельно усиливали SEO-контент и экспертный контур услуг, довольно быстро проявилась одна из самых болезненных точек рынка — определение кода ТН ВЭД.
Это следующая статья из серии о том, как мы шаг за шагом развивали цифровой контур INSAL. Здесь — о том, почему первым открытым AI-сервисом стал именно подбор кода ТН ВЭД, как мы проверяли гипотезу спроса на прикладной AI-инструмент и почему после первых результатов сервис логично ушел из открытого доступа в CRM.
Сразу зафиксируем важную границу. Определить код ТН ВЭД со стопроцентным подтверждением и полной ответственностью может только опытный декларант. Иллюзий на этот счет не было. Мы не строили замену специалисту. Задача была другой: с помощью AI быстро дать направление, сократить время первичного подбора кода и помочь пользователю с предварительной unit-экономикой там, где ошибка в классификации обходится слишком дорого.
Почему гипотезу решили проверять не на всем сразу, а на одной задаче
Когда бизнес подходит к AI, почти всегда появляется соблазн сделать что-то “большое и умное”: универсального помощника, который разберется во всем. На практике это плохой старт.
Для проверки гипотезы нужен не красивый концепт, а узкий и понятный сценарий, на котором можно быстро проверить три вещи: есть ли реальный спрос, понимает ли пользователь ценность и готов ли он вообще взаимодействовать с AI в прикладной профессиональной задаче.
Поэтому начинать решили не с абстрактного “AI для импорта”, а с одной конкретной проблемы. Причем такой, где ошибка влияет не на удобство, а на деньги, сроки и риски.
Как при развитии ВЭД-направления и SEO проявилась главная боль рынка
Когда мы вместе с INSAL писали статьи и SEO-материалы по теме ТН ВЭД, сертификации, маркировки и услуг ВЭД, быстро стало видно повторяющееся узкое место. Импортеры, селлеры, предприниматели и менеджеры по закупке снова и снова упирались в один и тот же вопрос: какой код ТН ВЭД выбрать.
И это не формальная задача “для бумаги”. От кода зависят пошлины, ввозной НДС, маркировка, требования по сертификации, разрешительная документация, а в итоге — вся предварительная unit-экономика поставки.
Тот, кто работает с импортом, это хорошо знает: можно промахнуться в тексте, в карточке товара или в рекламном сообщении. Неприятно, но терпимо. Ошибиться в коде ТН ВЭД — уже совсем другая история. Здесь ошибка может потянуть за собой лишние расходы, неправильный расчет экономики и другой набор обязательств по товару.
Именно поэтому задача выделялась из общего потока. Она была частой, чувствительной и понятной рынку без дополнительных объяснений.
Почему первой точкой входа выбрали именно код ТН ВЭД
С точки зрения проверки гипотезы это была почти идеальная стартовая задача.
Во-первых, боль была реальной, а не придуманной.
Во-вторых, результат нужен быстро.
В-третьих, сам пользователь уже понимал ценность ответа — ему не нужно было объяснять, зачем вообще нужен код.
В-четвертых, у INSAL была предметная экспертиза, чтобы не строить сервис на пустом месте.
Нам был нужен не инструмент ради инструмента, а первый AI-сервис, который опирается на реальную рыночную проблему и дает человеку ощутимую пользу почти сразу.
Такой задачей и стало определение кода ТН ВЭД.
Какую задачу сервис реально должен был решать — и чего от него не ждали
Это ключевой блок всей истории.
Сервис не должен был “давать окончательный код вместо декларанта”. И точно не должен был обещать стопроцентную точность в любой ситуации. В реальной практике ВЭД один и тот же товар может классифицироваться по разным позициям в зависимости от состава, назначения, особенностей обработки и даже от того, как именно сформулировано описание в документах.
Поэтому задача формулировалась честно и прагматично.
Сервис должен был:
- быстро дать направление в определении кода;
- сократить время на первичный подбор;
- помочь специалисту ВЭД не начинать с нуля;
- дать импортеру или селлеру предварительную основу для расчета unit-экономики.
То есть это был инструмент первичного сужения поля поиска, а не машина, которая отменяет декларанта.
Именно такая постановка задачи и сделала сервис полезным. Он не обещал магию. Он экономил время и давал опору для следующего шага.
Почему MVP сделали в виде открытой формы
На стадии гипотезы MVP должен быть не сложным, а рабочим.
Поэтому интерфейс сделали в виде формы ввода. Это был самый простой и надежный путь. Пользователь заполнял понятные поля: ссылку на товар, наименование, материал, назначение, технологию обработки, физико-химические параметры, комплектацию, страну происхождения. Где-то можно было оставить минимум информации, где-то — добавить больше деталей.
Для проверки гипотезы такая форма была оптимальной. Она давала:
- понятный вход;
- контролируемый формат данных;
- минимум лишней оболочки;
- быстрый запуск без тяжелого интерфейса.
Нам нужно было проверить не красоту продукта, а реальное поведение пользователя. Пойдет ли он в такой сервис. Заполнит ли форму. Дождется ли результата. Увидит ли в нем ценность.
На этом этапе форма была самым здравым решением.
Как мы собрали логику результата
Ответ сервиса изначально проектировали не по схеме “один код и точка”.
Мы пришли к более взрослой логике: система должна показывать не один якобы безальтернативный вариант, а несколько наиболее релевантных кодов. Это и честнее, и полезнее. В реальной ВЭД-практике один и тот же товар действительно может классифицироваться по нескольким близким позициям.
Поэтому на выходе пользователь получал тройку наиболее подходящих вариантов. Дальше система показывала:
- код ТН ВЭД;
- категорию или тип;
- название товара;
- импортную пошлину;
- ввозной НДС;
- требования по сертификации;
- необходимость маркировки;
- оценку точности.
После этого выбирался основной кандидат и отдельно объяснялось, почему именно он выглядит наиболее сильным по введенным данным. То есть результат не просто выдавался, а аргументировался.
Дополнительно в логике сервиса была трехступенчатая проверка точности по независимым источникам и по реальным наименованиям, которые раньше уже декларировались по этому коду. Подробную техническую кухню в этой статье раскрывать не будем. Здесь важнее другое: ответ строился не на одном “мне так кажется”, а на проверяемой логике.
Что пользователь получал на выходе и почему это было полезно
Пользователь получал не абстрактную строку с кодом, а плотный прикладной результат.
Система показывала несколько релевантных кодов, сравнение по ставкам, НДС, сертификации и маркировке, затем объясняла, почему основной кандидат оказался первым, и добавляла примеры похожих наименований из практики декларирования.
Причем результат человек видел сразу на странице и мог сразу скопировать.
Это резко повышало ценность сервиса.
- Пользователь видел не просто “вот код”.
- Он видел направление.
- Понимал, какие платежи и требования могут стоять за этим кодом.
- Мог прикинуть предварительную unit-экономику.
- И, что не менее важно, получал язык для следующего разговора со специалистом.
Сервис не закрывал задачу до конца, но помогал перейти от хаоса к более предметному вопросу. Для такой темы это уже очень много.
Почему ограничение в 3 кода на пользователя было правильным
Форма была открыта всем желающим. Но без ограничений такой инструмент быстро превратился бы либо в бесплатный конвейер, либо в полигон для бесконечных проб и ошибок.
Поэтому ввели ограничение: не более трех кодов в одни руки.
Для проверки гипотезы это был разумный баланс. С одной стороны, человек мог попробовать сервис, понять пользу, протестировать реальный запрос. С другой — сервис не уходил в бесконтрольное использование и сохранял формат именно MVP, а не бесконечного публичного генератора.
Это ограничение сразу делало поведение пользователей более осмысленным. Люди не игрались с формой, а приходили с конкретной задачей.
Что показал первый запуск
На этом этапе стало понятно главное: гипотеза не пустая.
Когда использование сервиса дошло примерно до 70 уникальных пользователей в день, это уже выглядело как уверенный сигнал реального интереса. Для массового развлекательного инструмента такая цифра была бы скромной. Для нишевого B2B/ВЭД-сервиса — уже очень заметный результат.
Здесь не нужно рисовать “оглушительный успех”. Но и принижать цифру не стоит. Для такой темы она означала сразу несколько вещей:
- боль действительно существует;
- формат входа оказался понятным;
- люди готовы пробовать AI в прикладной профессиональной задаче;
- сервис не выглядел игрушкой.
То есть рынок не просто заметил инструмент. Он начал им пользоваться.
Почему после проверки гипотезы сервис перенесли в CRM
Когда стало ясно, что интерес реальный, открытый формат выполнил свою задачу.
MVP был нужен для проверки гипотезы. Он ее проверил. Дальше логично было забирать сервис в более управляемый контур.
Поэтому открытую форму потом закрыли и перенесли решение в CRM, где оно уже стало частью большего сервисного слоя. Там у инструмента появлялся другой контекст: не просто открытый тест, а полноценный маршрут внутри системы, связанный с услугами, пользователем, ограничениями доступа и всей дальнейшей AI-линейкой.
То есть перенос в CRM был не отказом от идеи, а следующим зрелым этапом. Сервис переставал быть публичным экспериментом и становился частью системного продукта.
Что этот этап дал INSAL
На этом этапе INSAL получил не просто несколько AI-инструментов внутри кабинета.
Компания получила первую рабочую модель того, как экспертность превращается в отдельный цифровой продукт внутри CRM. Появился бесплатный входной слой. Появились более серьезные флагманские сервисы. Появились пакеты, ограничения, логика регистрации и первые правила монетизации.
Параллельно AI начал работать и внутри команды: появился закрытый сервис для сотрудников, который помогал менеджерам отвечать клиентам быстрее, точнее и аккуратнее.
То есть AI начал жить уже не как набор идей, а как часть управляемой сервисной системы — и для клиентов, и для сотрудников.
Вывод
История с определением кода ТН ВЭД важна не потому, что INSAL “сделал AI-сервис”.
Она важна потому, что это был правильный способ проверять гипотезу.
Не с универсального помощника.
Не с расплывчатой идеи “давайте прикрутим нейросеть”.
А с одной конкретной, дорогой и часто повторяющейся задачи, которую рынок действительно хотел решать быстрее.
Мы в CompanionAI вместе с INSAL взяли реальную боль аудитории, упаковали ее в простой MVP, честно ограничили ожидания от результата и получили рабочий сигнал спроса.
Именно этот первый сервис показал главное: AI имеет смысл только там, где он экономит время на реальной дорогой задаче. Не на красивой демо-сцене, а в живом процессе, где ошибка дорого стоит и где рынок уже готов платить вниманием за полезный результат.
