К содержанию
Артём Кадинproduct designer / builder
Территория масла Купец AmpliCore

CASE / B2B / PROCUREMENT

Купец: 7 дней → 2 дня

У первых пользователей пересобранный сценарий заявки проходил за 2 дня вместо 7. Проект превратил Excel и договорённости в личных сообщениях в единую B2B-платформу со сравнением поставщиков и цифровым ЭДО.

Интерфейсы заявок, аналитики и сравнения поставщиков в B2B-платформе «Купец» EARLY USERS / WORKING FLOW
Продукт
B2B-платформа закупок и ЭДО
Моя роль
Исследования, весь дизайн, frontend
Ответственность
Руководство разработкой и защита перед инвесторами
Статус
Рабочий ранний продукт, проверенный первыми пользователями
01 / КОНТЕКСТ

Закупка держалась на памяти людей

Разные роли видели только свой фрагмент процесса.

Excel показывал строки, но не показывал общую картину

Закупщики, поставщики, менеджеры и контрагенты работали через разрозненные таблицы и личные связи. У заявки не было единого маршрута: участникам приходилось вручную сверять условия, документы, сроки и договорённости.

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

О названии

«Купец» — публичный псевдоним проекта в сфере строительных материалов и металлопроката. Интерфейсы можно показывать, но название заказчика и внутренние данные не раскрываются.

02 / ИССЛЕДОВАНИЕ

Сначала — напряжение между ролями

Интервью помогли отделить реальные разрывы процесса от симптомов в интерфейсе.

01

Разобрал участников

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

02

Провёл интервью

Нашёл точки напряжения в создании заявки, согласовании условий и обмене документами.

03

Пересобрал маршрут

Связал заявку, предложения поставщиков, сравнение и документооборот в один последовательный flow.

04

Проверял в продукте

Первые пользователи проходили новый процесс; обратная связь возвращалась в дизайн и frontend без разрыва между макетом и реализацией.

03 / РЕШЕНИЕ

Одна система вместо цепочки ручных сверок

Интерфейс собран вокруг решения, а не вокруг хранения данных.

01

Единая заявка

Создание, редактирование и контроль заявки происходят в одном контексте, без дублирования по таблицам и перепискам.

02

Сравнение поставщиков

Предложения можно сопоставить по ключевым условиям и принять решение, не собирая картину вручную.

03

Цифровой ЭДО

Система поддерживает составление и правки документов, отправку на подписание и утверждение электронной подписью.

04

Прозрачный статус

Участники видят состояние процесса, сроки и следующий шаг — меньше зависимости от личной памяти менеджера.

От дизайна до реализации

Я отвечал за весь дизайн и frontend, руководил разработкой и защищал продукт перед инвесторами. Claude Code использовал для быстрых прототипов, документации и проверки гипотез; исследования и продуктовые решения оставались моей ответственностью.

04 / РЕЗУЛЬТАТ

Ранний сигнал, а не громкая статистика

Результат публикуется вместе с границами его доказательности.

7→2 дня
Цикл работы с заявкой у первых пользователей

Ориентир из раннего использования нового процесса. Это подтверждённый первыми пользователями эффект, но ещё не статистика на большой клиентской базе.

ЭДО
От заявки до подписанного документа

Создание заявки, сравнение поставщиков, правки, подписание и статус процесса связаны в одной системе.

Прогноз ≠ заработанные деньги

Независимый оценщик из бигтеха прогнозировал потенциальную прибыль проекта в 13 млн ₽. Это оценка потенциала, а не подтверждённая выручка или фактический финансовый результат.

05 / PROOF

Что здесь можно проверить

Интерфейс и роль доступны публично; коммерческий масштаб — нет.

Проект показывает продуктовую связку, а не только UI

В интерфейсах видны заявки, сравнение условий, фильтры, риски, сроки и аналитический контекст. Но сильная часть кейса — то, как исследование разных ролей превратилось в связанный рабочий процесс.

  • Публично показываются интерфейсы под условным названием «Купец».
  • Первые пользователи реально проходили пересобранный процесс.
  • Технологический стек и размер клиентской базы публично не зафиксированы — я их не додумываю.
  • Финансовая оценка остаётся отдельным прогнозом и не используется как бизнес-результат кейса.

Нужно распутать сложный B2B-процесс?

Разберу роли и реальные сценарии, соберу понятную систему и помогу довести её от продуктовой логики до рабочего frontend.

Написать в Telegram ↗