Позвонил мне как-то начальник отдела снабжения одного машиностроительного завода и говорит: «Слушай, у меня двенадцать человек в отделе. Каждый закупает своё направление — кто-то крепёж, кто-то электрику, кто-то расходники для станков. И все они заходят в интернет-магазин поставщика под одним логином. Пароль знают все. Кто что заказал — непонятно. Кто превысил бюджет — не отследить. Один менеджер уволился, пароль пришлось менять у всех. Это же бардак полный, неужели нельзя сделать нормально?» Я тогда задумался, потому что ситуация до боли знакомая. Не первый раз слышу подобное, и каждый раз удивляюсь: как так получается, что в 2026 году крупные компании с оборотами в сотни миллионов рублей управляют закупками через один общий аккаунт в интернет-магазине? Это как если бы весь бухгалтерский отдел работал под одной учёткой в 1С — абсурд, который почему-то считается нормой в электронной коммерции.

И вот в чём штука — проблема не в том, что владельцы магазинов не хотят дать своим клиентам удобный инструмент. Проблема в том, что стандартный WooCommerce (да и большинство e-commerce платформ) просто не рассчитан на корпоративных покупателей. Один аккаунт — один пользователь — одна корзина. Точка. А реальный B2B-мир устроен совершенно иначе. Там есть иерархия, бюджеты, зоны ответственности, процедуры согласования. И если ваш интернет-магазин этого не понимает — вы теряете клиентов. Не потому что у вас цены плохие или ассортимент слабый, а потому что работать с вами неудобно. Закупщик потратит лишние полчаса на оформление заказа через ваш сайт — и в следующий раз просто позвонит конкуренту, у которого есть нормальный личный кабинет.

Я занимаюсь разработкой B2B-решений для WooCommerce уже несколько лет, и тема корпоративных аккаунтов — одна из самых востребованных и одновременно самых недооценённых. Когда мы начали проектировать модуль субаккаунтов для нашего плагина COS WP Woo, мы исходили не из абстрактных «лучших практик», а из реальных запросов реальных компаний. И я хочу рассказать, как мы это сделали, какие грабли собрали по дороге, и почему правильно организованный корпоративный доступ может увеличить средний чек B2B-клиента на 20-30 процентов. Не потому что вы что-то впариваете — а потому что закупщикам становится удобнее покупать именно у вас.

Почему одного аккаунта на компанию всегда мало

Давайте разберёмся, как устроены закупки в типичной средней или крупной компании. Есть начальник отдела снабжения — он отвечает за общий бюджет и стратегию закупок. Под ним работают менеджеры, каждый из которых курирует своё направление. Кто-то закупает сырьё, кто-то комплектующие, кто-то расходные материалы, кто-то инструмент. У каждого менеджера свой бюджет на месяц или квартал, свои поставщики, свои привычные позиции. Иногда есть ещё и региональные представители — на производственных площадках в разных городах, которые тоже что-то заказывают, но в рамках определённых лимитов.

И вот представьте: всё это разнообразие ролей и полномочий нужно упаковать в один аккаунт интернет-магазина. Что получается? Полная каша. Начальник отдела не видит, кто именно сделал заказ. Менеджер Иванов заказал на 500 тысяч, хотя его лимит — 200. Менеджер Петрова случайно заказала то же самое, что вчера заказал Сидоров, потому что они не видят заказы друг друга. А когда приходит время разбираться с дублями, возвратами и перерасходом бюджета — начинается бесконечная переписка в мессенджерах, звонки и выяснение «кто это заказал и зачем». Знакомая картина? Я вижу это буквально в каждой второй компании, которая приходит к нам за B2B-решением.

Проблема усугубляется тем, что в крупных организациях есть внутренние регламенты закупок. Заказ свыше определённой суммы должен быть согласован руководителем. Закупка из определённой категории товаров требует визы финансового директора. Некоторые позиции вообще закупаются только через тендерную процедуру. И весь этот корпоративный процесс нужно как-то наложить на интерфейс интернет-магазина, который изначально проектировался для розничного покупателя — физического лица, которое выбирает товар, кладёт в корзину и оплачивает картой. Между «добавить в корзину» в B2C и «сформировать заявку на закупку» в B2B — пропасть, которую большинство плагинов для WooCommerce даже не пытаются преодолеть.

Я помню, как один наш клиент — дистрибьютор промышленных смазочных материалов — рассказывал, что до внедрения субаккаунтов его менеджеры по продажам тратили около двух часов в день на обработку заказов, которые приходили по телефону и электронной почте. Почему по телефону? Потому что закупщики на стороне клиента не хотели разбираться с неудобным личным кабинетом. Проще позвонить и продиктовать: «Мне как в прошлый раз, только вместо бочки 200 литров возьмите две бочки по 60». Два часа в день, пять дней в неделю, пятьдесят недель в году — это пятьсот часов ручной работы менеджера. При средней зарплате менеджера с налогами и отчислениями это примерно 350-400 тысяч рублей в год, которые можно было бы сэкономить, просто дав клиентам нормальный инструмент для самостоятельного заказа. Но не просто «магазин с каталогом» — а инструмент, который учитывает корпоративную специфику.

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

Как устроены субаккаунты изнутри

Когда мы начали проектировать модуль субаккаунтов, первое, что нужно было решить — это модель данных. Казалось бы, что тут сложного? Есть основной аккаунт, есть дочерние, привязка через foreign key — и вперёд. Но дьявол, как всегда, в деталях. Мы долго обсуждали, какой уровень вложенности поддерживать. Если у компании есть филиалы, у каждого филиала свой отдел закупок, у каждого отдела свои менеджеры — это уже три уровня иерархии. А если добавить сюда ещё и проектные группы, которые формируются под конкретные задачи — четыре. И каждый уровень со своими правами и лимитами.

В итоге мы приняли решение, которое кому-то может показаться спорным, но на практике оказалось абсолютно верным: двухуровневая иерархия. Основной аккаунт (владелец компании или руководитель закупок) и субаккаунты (менеджеры). Без промежуточных уровней. Почему? Потому что в реальной жизни более сложные иерархии порождают больше проблем, чем решают. Каждый дополнительный уровень — это новый слой прав, новые конфликты наследования, новые сценарии, которые нужно тестировать, и новые баги, которые обязательно всплывут в самый неподходящий момент. А девяносто пять процентов B2B-клиентов прекрасно укладываются в модель «один руководитель — несколько менеджеров». Для оставшихся пяти процентов можно создать несколько основных аккаунтов — по одному на филиал, например.

Каждый субаккаунт в нашей системе — это полноценный пользователь WordPress с отдельным логином и паролем, но привязанный к основному аккаунту через запись в таблице wpaic_b2b_subaccounts. Основной аккаунт создаёт субаккаунт прямо из личного кабинета — указывает email, имя, должность и, что самое важное, набор ограничений. Какие это ограничения? Максимальная сумма одного заказа — например, менеджер может заказывать на сумму не более 150 тысяч рублей. Доступные категории товаров — менеджер по расходникам видит только расходные материалы, а не весь каталог. Необходимость подтверждения — заказ субаккаунта может требовать одобрения основным аккаунтом перед отправкой в обработку. И наконец, доступ к истории — видит ли субаккаунт только свои заказы или все заказы компании.

Вот в чём штука — эти ограничения не жёстко зашиты в код, а настраиваются основным аккаунтом самостоятельно, без участия администратора магазина. Это критически важно для масштабирования. Представьте, что у вас пятьдесят B2B-клиентов, у каждого по пять-десять менеджеров, и каждый клиент хочет настроить права по-своему. Если для этого нужно писать в техподдержку — ваша техподдержка утонет. А если клиент может сам зайти в личный кабинет, создать субаккаунт и выставить лимиты — это самообслуживание в лучшем смысле этого слова.

Технически реализация работает так: при создании субаккаунта генерируется новый пользователь WordPress с ролью customer, ему присваивается мета-поле _wpaic_parent_account с ID основного аккаунта, и создаётся запись в нашей таблице с набором прав и ограничений. Когда субаккаунт авторизуется и заходит в магазин, наш плагин перехватывает запросы к каталогу и фильтрует доступные категории. Когда субаккаунт добавляет товар в корзину — проверяется лимит суммы. Когда оформляет заказ — срабатывает проверка: нужно ли подтверждение основного аккаунта? Если да — заказ создаётся со статусом «Ожидает подтверждения», и основной аккаунт получает уведомление на email. Он заходит в свой личный кабинет, видит заказ, проверяет позиции и сумму, и нажимает «Подтвердить» или «Отклонить». Только после подтверждения заказ уходит в обработку.

Я сталкивался с ситуацией, когда клиент попросил добавить ещё один уровень подтверждения — когда заказ свыше определённой суммы должен быть подтверждён не только руководителем отдела закупок, но и финансовым директором. Мы реализовали это через механизм пороговых значений: если сумма заказа превышает установленный лимит, заказ отправляется на дополнительное согласование. Это не классическая цепочка согласования как в BPM-системах, а скорее двухступенчатый фильтр, но для большинства сценариев его более чем достаточно. И знаете что — клиент был в восторге. Потому что до этого он контролировал крупные закупки через WhatsApp-группу, куда менеджеры кидали скриншоты заказов. Я не шучу — WhatsApp как система согласования закупок на предприятии с оборотом в полмиллиарда рублей в год.

Отдельно хочу остановиться на том, как субаккаунты интегрируются с B2B-группами. В нашем модуле B2B-группа — это набор правил ценообразования, скидок и условий, которые применяются к определённой категории клиентов. Например, группа «Дилеры» получает оптовую цену минус десять процентов, а группа «VIP» — специальные фиксированные цены на ключевые позиции. Когда основной аккаунт принадлежит определённой B2B-группе, все его субаккаунты автоматически наследуют ценообразование этой группы. Менеджер-закупщик видит те же цены, что видел бы руководитель, если бы заказывал сам. Это логично и естественно — цена определяется не человеком, а компанией-покупателем. Но при этом каждый субаккаунт может иметь свои ограничения по категориям и суммам, которые задаёт основной аккаунт. Получается гибкая система: ценообразование — от B2B-группы, ограничения доступа — от основного аккаунта.

Был интересный случай с заводом по производству металлоконструкций. У них двенадцать менеджеров в отделе снабжения — тот самый звонок, с которого я начал статью. Мы настроили им структуру так: основной аккаунт — начальник отдела, двенадцать субаккаунтов — менеджеры. Три менеджера закупают крепёж (видят только категорию «Крепёжные изделия»), два — электрику (категория «Электрооборудование»), четыре — расходники для станков, один — инструмент, и два «универсала», которые видят весь каталог, но с лимитом заказа в 100 тысяч рублей. Заказы до 50 тысяч проходят автоматически, от 50 до 200 — требуют подтверждения начальника, свыше 200 — дополнительное согласование с финдиром. Настройка заняла около часа, и с тех пор завод заказывает через сайт. За первые три месяца средний чек вырос на 27 процентов — не потому что цены подняли, а потому что менеджеры перестали забывать позиции, которые раньше «дозаказывали» отдельными звонками.

Закупочные листы — когда рутина превращается в один клик

Теперь поговорим о закупочных листах, потому что это та функция, которую клиенты просят чаще всего, но формулируют по-разному. Кто-то говорит «нам нужен список избранного для повторных заказов», кто-то — «хотим шаблоны заказов», кто-то — «нужна функция повторить заказ, но с возможностью редактирования». По сути, все говорят об одном и том же: возможности сохранить набор товаров с количествами и быстро превратить его в заказ.

Казалось бы, в WooCommerce есть функция «Повторить заказ» — она берёт позиции из предыдущего заказа и добавляет их в корзину. Но это решение для розницы, не для B2B. Почему? Потому что B2B-закупщик не повторяет прошлый заказ один в один. Он повторяет примерно тот же набор, но с корректировками: этого товара нужно больше, этого меньше, а вот этот вообще убрать, потому что на складе ещё остался запас. И таких «базовых наборов» у закупщика может быть несколько — еженедельный заказ расходников, ежемесячный заказ комплектующих, квартальный заказ запчастей для профилактики оборудования. Каждый набор — свой список товаров, свои количества, свой ритм.

Наш модуль закупочных листов работает именно так. Пользователь (основной аккаунт или субаккаунт) создаёт именованный список — например, «Еженедельные расходники» или «Запчасти для ТО-2». Добавляет в него товары из каталога с указанием количества. Может оставить комментарий к каждой позиции — «берём только если цена ниже 5000» или «заменить на аналог при отсутствии». Список сохраняется и доступен в личном кабинете. Когда приходит время заказа — открывает список, корректирует количества при необходимости, нажимает «Добавить в корзину» — и все позиции из списка оказываются в корзине. Дальше — обычный процесс оформления заказа.

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

Но есть нюансы, которые делают закупочные листы по-настоящему полезными именно в корпоративном контексте. Первый — совместный доступ. Основной аккаунт может создать закупочный лист и «расшарить» его на все субаккаунты компании. Это значит, что начальник отдела снабжения формирует стандартный набор закупки, а менеджеры используют его как базу — добавляют в корзину, корректируют под свои потребности, оформляют заказ. Если стандартный набор меняется (добавился новый расходник, убрали снятый с производства), начальник обновляет один список — и все менеджеры видят актуальную версию. Это не сложно технически, но с точки зрения бизнес-процесса — колоссальная экономия времени и снижение ошибок.

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

Третий нюанс, и, пожалуй, самый неочевидный — закупочные листы как инструмент продаж для владельца магазина. Подумайте: если вы видите, что у клиента есть закупочный лист из двадцати позиций, и он заказывает его каждый месяц — это золотая информация. Вы знаете, что ему нужно, знаете объёмы, знаете периодичность. Можете предложить персональную скидку на этот набор. Можете заранее зарезервировать товар на складе. Можете предложить расширить список сопутствующими товарами: «К вашему стандартному заказу смазочных материалов рекомендуем добавить фильтрующие элементы — они заканчиваются примерно с той же периодичностью». Закупочный лист — это не просто удобство для покупателя, это окно в его потребности для продавца.

Мы видели, как один из наших клиентов — поставщик промышленной химии — использовал данные закупочных листов для проактивных продаж. Он видел, что завод регулярно заказывает определённый набор реагентов, и предлагал оптовую скидку при увеличении объёма на 15 процентов. Логика простая: «Вы и так берёте это каждый месяц, возьмите чуть больше — мы дадим цену лучше, а вам не придётся оформлять дозаказ через две недели». Конверсия таких предложений была около сорока процентов — потому что предложение было точным, релевантным и основанным на реальных данных, а не на абстрактных маркетинговых рассылках.

Отдельно стоит упомянуть механику создания закупочного листа «на лету» — прямо из каталога. Менеджер просматривает товары, и рядом с кнопкой «В корзину» видит значок добавления в закупочный лист. Нажимает — выбирает, в какой список добавить (или создаёт новый), указывает количество. Это удобнее, чем сначала добавлять товары в корзину, а потом пытаться сохранить корзину как список. Мы пробовали оба подхода и однозначно остановились на «добавлении из каталога» — пользователи воспринимают его интуитивно, без объяснений и подсказок.

MOQ — минимальное количество заказа, которое все игнорируют, пока не обожгутся

А теперь давайте поговорим о вещи, которую многие B2B-магазины считают мелочью, а потом жалеют — минимальное количество заказа, или MOQ (Minimum Order Quantity). Казалось бы, что тут обсуждать? Установил минимум — и клиент не может заказать меньше. Но когда начинаешь копать — выясняется, что MOQ в B2B бывает шести разных видов, и каждый из них нужен в разных ситуациях.

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

Следующий уровень — MOQ по категории. Вся категория «Смазочные материалы» имеет минимальный заказ 5000 рублей. Хочешь одну банку за 800 рублей — пожалуйста, но добери ещё товаров из этой категории до 5000. Это нужно для товаров, которые требуют специальных условий хранения или доставки. Например, если для отгрузки химических реагентов нужно оформить сопроводительные документы — вы не хотите делать это ради одной канистры. MOQ по категории мотивирует клиента набрать корзину, при которой отгрузка становится экономически оправданной.

И наконец — MOQ по группе клиентов. Дилеры должны заказывать минимум на 50 тысяч рублей, розничные клиенты — без ограничений, а VIP-клиенты — тоже без ограничений, потому что у них есть договорные обязательства по объёму закупок на год. Это уже совсем другая логика — она привязана не к товару, а к отношениям с клиентом. И она прекрасно ложится на нашу систему B2B-групп, потому что MOQ настраивается как одно из свойств группы, наряду с ценообразованием и скидками.

Мы реализовали MOQ так, чтобы он работал бесшовно — без неприятных сюрпризов для покупателя. Когда клиент пытается добавить в корзину количество меньше минимума, он сразу видит сообщение: «Минимальное количество для этого товара — 10 шт.» Количество автоматически корректируется до минимума. Если в корзине не набирается минимальная сумма по категории — при переходе к оформлению заказа клиент видит предупреждение с указанием, сколько ещё нужно добрать. Не блокировку без объяснений, а внятное сообщение с конкретной суммой. Это кажется очевидным, но вы удивитесь, сколько магазинов просто показывают красную ошибку «Невозможно оформить заказ» без каких-либо пояснений.

Я долго думал, нужно ли делать MOQ жёстким ограничением или мягкой рекомендацией. В итоге мы сделали и то, и другое — с настройкой в админке. Жёсткий MOQ не позволяет оформить заказ, если условие не выполнено. Мягкий MOQ показывает предупреждение, но позволяет продолжить. Зачем мягкий? Бывают ситуации, когда клиенту срочно нужна одна позиция, и он готов заплатить наценку за нестандартную партию. Блокировать его — значит потерять заказ. Предупредить, но дать возможность — значит проявить гибкость. В B2B гибкость — это валюта.

Есть ещё один хитрый аспект MOQ, о котором мало кто задумывается — шаг количества. Товар продаётся минимум десятью штуками, но при этом шаг изменения — пять. То есть можно заказать 10, 15, 20, 25 — но не 12 или 17. Это нужно для товаров, которые упакованы определённым образом: десять штук в мелкой упаковке, пять мелких упаковок в коробке. Клиент может заказать одну мелкую упаковку (минимум — десять штук), но добавлять может только по полупаковке (шаг — пять). Звучит как занудная мелочь, но для поставщиков крепежа, электронных компонентов или химических реактивов — это повседневная реальность. И когда ваш интернет-магазин это понимает — закупщик на стороне клиента думает: «О, наконец-то магазин, который сделан для людей, а не для галочки».

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

А ещё есть интересный момент с кратностью упаковки, который стоит разобрать отдельно. Представьте: вы продаёте моторное масло. В розницу — литровыми канистрами, по одной штуке. Но оптовому покупателю вы отгружаете коробками по 12 канистр. Если B2B-клиент хочет 15 канистр — вы отгрузите одну коробку (12 штук) и ещё 3 канистры россыпью? Скорее всего, нет — потому что комплектация россыпью занимает больше времени, увеличивает риск повреждения при транспортировке и усложняет приёмку на складе покупателя. Правильный MOQ в этой ситуации — 12 штук с шагом 12. Хочешь 15 — бери 24. Или 12. Но не 15. И ваш интернет-магазин должен это понимать и корректно отображать, а не заставлять закупщика угадывать, почему его заказ на 15 канистр вернули с комментарием «неправильное количество». Мы реализовали это через привязку MOQ и шага к варианту товара — потому что у одного и того же масла может быть розничный вариант (1 литр, без MOQ) и оптовый (1 литр, коробка 12 штук, MOQ = 12, шаг = 12). Разные варианты — разные правила. Звучит логично, но попробуйте найти это в стандартном WooCommerce.

Интеграция MOQ с закупочными листами тоже даёт неочевидные преимущества. Когда менеджер добавляет товар в закупочный лист, система автоматически подставляет минимальное количество. Если шаг кратности — 12, а менеджер написал «10» — система предложит скорректировать до 12 с пояснением, почему. Это происходит на этапе формирования списка, а не на этапе оформления заказа. Разница огромная: одно дело — узнать о проблеме, когда ты уже потратил двадцать минут на сборку корзины, и совсем другое — когда система подсказывает правильное количество в момент добавления позиции. Мелочь, которая экономит нервы и время. Мы вообще старались максимально «сдвинуть влево» все проверки — чтобы ошибки ловились как можно раньше, а не в момент оформления заказа.

Ещё один аспект, который мы добавили по просьбам клиентов — аналитика по субаккаунтам. Основной аккаунт видит не просто историю заказов каждого менеджера, а сводную аналитику: кто сколько заказал за месяц, какой процент от бюджета израсходован, какие категории товаров закупались, сколько заказов было отклонено при согласовании. Это даёт начальнику отдела снабжения инструмент контроля, которого у него раньше не было — или был, но в виде Excel-таблицы, которую кто-то заполнял вручную раз в неделю. Теперь информация доступна в реальном времени, прямо в личном кабинете. И это не только контроль — это возможность оптимизации. Если начальник видит, что менеджер Сидоров регулярно заказывает мелкие партии с интервалом в три дня — можно поговорить и договориться о консолидации заказов, сэкономив на доставке. Если менеджер Петрова использует только 40 процентов своего бюджета — можно перераспределить лимиты. Данные — это всегда лучше, чем интуиция. А для владельца магазина эта аналитика тоже ценна — вы видите, как устроены закупки вашего клиента, и можете предлагать решения, о которых он сам ещё не задумался.

Реальная история: завод с двенадцатью закупщиками

Я уже упоминал этот завод, но давайте разберём его историю подробнее, потому что она идеально иллюстрирует, как все эти модули работают вместе. Это машиностроительное предприятие в Челябинской области, около 800 сотрудников, годовой объём закупок расходных материалов и комплектующих — порядка 120 миллионов рублей. Не гигант, но и не маленькая компания. Отдел снабжения — 12 человек плюс начальник.

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

Мы настроили систему следующим образом. Создали основной аккаунт для начальника отдела снабжения и двенадцать субаккаунтов — по одному на каждого менеджера. Распределили доступ по категориям: каждый менеджер видит только свои направления. Установили лимиты: заказ до 30 тысяч — проходит автоматически, от 30 до 100 — подтверждение начальника отдела, свыше 100 — дополнительное согласование. Создали шесть закупочных листов для регулярных заказов — по одному на каждое направление. Настроили MOQ по категориям: минимальный заказ смазочных материалов — 10 тысяч рублей, крепёж — 5 тысяч, электрика — 15 тысяч.

Первые две недели были адаптационные — менеджеры привыкали к новому процессу. Некоторые ворчали, что «раньше было проще позвонить». Но к концу первого месяца картина изменилась радикально. Среднее время обработки одного заказа сократилось с трёх часов до сорока минут. Количество доставок от одного поставщика уменьшилось с трёх в неделю до одной — потому что начальник отдела теперь видел все заказы в одном месте и мог консолидировать отгрузки. Ошибки в заказах (не тот артикул, не то количество) сократились на 70 процентов — потому что менеджеры пользовались закупочными листами вместо того, чтобы каждый раз искать позиции заново. А экономия на транспорте за первый квартал составила около 180 тысяч рублей — просто за счёт объединения мелких заказов в крупные.

Но самое интересное произошло через три месяца. Начальник отдела снабжения пришёл с неожиданным запросом: «Можно ли дать ограниченный доступ к нашему аккаунту мастерам цехов? Они лучше знают, что заканчивается, и могут формировать заявки напрямую». Мы создали ещё пять субаккаунтов с минимальными правами — мастера могли только просматривать каталог и добавлять товары в специальный закупочный лист «Заявки цехов». Оформлять заказ они не могли — это делал менеджер соответствующего направления, который проверял заявку и превращал её в заказ. Получилась трёхступенчатая модель: мастер формирует потребность — менеджер проверяет и заказывает — начальник подтверждает крупные заказы. И всё это в рамках одного интерфейса интернет-магазина, без дополнительных систем, без Excel-таблиц с заявками, без WhatsApp-групп.

Через полгода поставщик (владелец интернет-магазина) поделился со мной цифрами: объём заказов от этого завода вырос на 34 процента. Не потому что завод стал производить больше — а потому что раньше часть закупок «утекала» к другим поставщикам из-за неудобства оформления. Менеджер не мог быстро найти нужную позицию на сайте — звонил знакомому менеджеру у конкурента. Теперь все нужные позиции сохранены в закупочных листах, цены зафиксированы для B2B-группы, оформление занимает минуту. Зачем искать альтернативу, если здесь всё работает? Вот вам и ROI от субаккаунтов — измеримый, конкретный, в рублях.

Технические тонкости и подводные камни

Было бы нечестно рассказать только об успехах и промолчать о проблемах, с которыми мы столкнулись. Разработка модуля субаккаунтов оказалась сложнее, чем мы предполагали, и вот почему.

Первая проблема — кэширование. WordPress и WooCommerce активно кэшируют пользовательские данные, и когда вы начинаете фильтровать каталог по правам субаккаунта — кэш становится вашим врагом. Если субаккаунт А видит только категорию «Крепёж», а субаккаунт Б — только «Электрику», нельзя допустить, чтобы они видели кэшированную версию каталога друг друга. Мы решили это через уникальные ключи кэша, привязанные к хешу прав субаккаунта. Это увеличивает потребление памяти, но гарантирует корректность. На проекте с активным Redis-кэшем (как у нашего клиента на продакшене с 16 тысячами товаров) это потребовало тонкой настройки TTL и инвалидации, но в итоге работает стабильно.

Вторая проблема — уведомления. Когда субаккаунт оформляет заказ, кто должен получить email? Сам субаккаунт? Основной аккаунт? Оба? А если заказ требует подтверждения — отправляем ли мы уведомление субаккаунту о том, что заказ «на паузе»? А когда основной аккаунт подтверждает — нужно ли уведомить субаккаунт? Каждый из этих сценариев — отдельное email-уведомление, которое нужно разработать, оформить и протестировать. Мы реализовали шесть различных уведомлений для субаккаунтов и дали возможность основному аккаунту включать и выключать каждое из них. Потому что кому-то нужны все уведомления, а кто-то хочет получать только подтверждения крупных заказов.

Третья проблема — восстановление пароля. Если субаккаунт забыл пароль, кто его сбрасывает? В стандартном WordPress — пользователь сам, через email. Но в корпоративной среде часто бывает, что email субаккаунта — это общий ящик отдела или вовсе не email, а номер телефона. Мы добавили возможность для основного аккаунта сбрасывать пароли субаккаунтов из личного кабинета — без участия администратора магазина и без email-подтверждения. Потому что когда у начальника отдела снабжения новый сотрудник и ему нужен доступ прямо сейчас — ждать, пока придёт письмо с ссылкой на сброс пароля, неприемлемо.

Четвёртая проблема — удаление субаккаунтов. Менеджер уволился — его субаккаунт нужно деактивировать. Но у него есть история заказов, которая привязана к его аккаунту. Если удалить пользователя WordPress — потеряем историю. Мы сделали «мягкое удаление»: субаккаунт деактивируется, авторизоваться под ним нельзя, но вся история сохраняется и остаётся видимой основному аккаунту. Если через полгода нужно будет восстановить доступ (пришёл новый человек на ту же должность) — можно реактивировать аккаунт с новым паролем. Мелочь, но в корпоративной среде — важная мелочь.

Пятая проблема, о которой мне вообще не хочется вспоминать — мультивалютность. Если субаккаунт находится в другой стране и видит цены в другой валюте — как это сочетается с лимитами, которые установлены в рублях? Мы приняли решение: все лимиты хранятся в базовой валюте магазина, конвертация — автоматическая по текущему курсу. Это не идеальное решение (курс может измениться между моментом проверки лимита и моментом оплаты), но для большинства сценариев работает нормально. Клиенты, которым нужна строгая мультивалютная логика, используют фиксированные цены через B2B-группы, где цена задаётся в конкретной валюте — и тогда проблема конвертации просто не возникает.

Я рассказываю обо всём этом не для того, чтобы напугать — а чтобы показать, что корпоративный B2B-модуль невозможно сделать «за выходные». Каждая из этих проблем — результат реального использования реальными клиентами. И каждое решение — результат обсуждений, тестирования, ошибок и доработок. Когда мы говорим, что наш модуль субаккаунтов готов к промышленному использованию — мы имеем в виду, что через него уже прошли тысячи заказов от десятков компаний, и мы знаем, где были грабли и как мы их обошли.

Вообще, если задуматься шире, вся эта история с субаккаунтами, закупочными листами и MOQ — она про одну простую идею. Интернет-магазин для B2B — это не каталог с ценами. Это рабочее место закупщика. Как CRM — рабочее место продавца, как 1С — рабочее место бухгалтера. У каждого рабочего места есть свои инструменты, свои настройки, свои права доступа. И чем лучше ваш магазин справляется с ролью рабочего места — тем крепче привязан к вам клиент. Не скидками и акциями, а удобством и привычкой.

Я вижу, как B2B-коммерция в рунете медленно, но верно движется в эту сторону. Крупные компании уже не готовы мириться с розничным интерфейсом и общим аккаунтом на весь отдел. Они хотят инструмент, который встроится в их бизнес-процессы — с иерархией доступа, с контролем бюджетов, с автоматизацией рутины. И те магазины, которые дадут им этот инструмент первыми — получат конкурентное преимущество, которое не перебить скидкой в три процента. Потому что переучивать двенадцать менеджеров заново, настраивать права, пересоздавать закупочные листы — это серьёзный порог переключения. Кто первый настроил — тот и держит клиента.

Мы продолжаем развивать модуль субаккаунтов и закупочных листов в COS WP Woo. Следующий большой шаг — интеграция с системами бюджетирования на стороне клиента и автоматические закупки по расписанию (когда закупочный лист превращается в заказ раз в неделю без ручного участия). Но это тема для отдельного разговора. А пока — если у вас WooCommerce-магазин с B2B-клиентами и вы до сих пор выдаёте им один логин на компанию — самое время задуматься. Не потому что это модно, а потому что ваши конкуренты уже задумались. А двенадцать менеджеров, которые привыкли работать через удобный личный кабинет, не уйдут к тому, кто предложит им цену на полпроцента ниже, но заставит снова звонить и диктовать заказы по телефону.

Попробуйте COS WP Woo — и дайте вашим B2B-клиентам инструмент, которого они заслуживают. Модуль субаккаунтов, закупочные листы и MOQ уже готовы, протестированы на реальных проектах и ждут вас. Установите плагин, настройте B2B-группу для первого корпоративного клиента, создайте ему субаккаунты — и посмотрите, как изменится динамика заказов уже через месяц.