Wholesale portal on WooCommerce: groups, hidden catalogs and multi-level prices

Last week the owner of an industrial lubricants company wrote to me. The situation is painfully familiar: he has an online store on WooCommerce, retail works fine, but he wants to launch a wholesale business through the same site. And then the classic story begins - he went looking for solutions, found a dozen B2B plugins, each costing from two hundred to four hundred dollars a year, and none of them completely covered all the needs. One makes groups of clients, another makes wholesale prices, the third makes a hidden catalogue, the fourth makes requests for commercial proposals. And in order to put together a full-fledged wholesale portal, you need to buy three or four plugins, which are not always friendly with each other, are updated at different times, and support for each is a separate correspondence with a separate team of developers from different time zones.

I hear this story every two to three weeks. And every time I think about how fragmented and inconvenient the market for B2B solutions for WooCommerce is. Not because the developers are bad - they, as a rule, do their narrow task well. But because business does not need a set of separate tools, but a unified system that understands the logic of wholesale trade in its entirety. From the moment when a potential dealer visits the website and sees the “Become a wholesale customer” button, until the moment when the accounting department uploads his order into 1C and generates an invoice. This is one continuous process and should not depend on four independent plugins agreeing with each other.

That's why we made the B2B module part of COS WP Woo - not as a separate plugin, but as an integrated subsystem that knows everything about its environment. She knows about 1C integration, about search, about the catalog, about users. And when you set up the “Dealers” group with special pricing and limited catalog visibility, you don’t need to think about how to “make friends” with the rest of the store - it’s already connected, because it’s one product.

But let me tell you in order how it works in practice. Not in theory, not in marketing promises, but in real scenarios that we encounter with clients every day.

Anatomy of a wholesale client: why groups are not just a “discount for the elite”

When people think about B2B online shopping, the first thought is usually, “Well, we should just give the wholesalers a bigger discount.” And this is the most dangerous simplification that one can afford. Because the difference between a retail and wholesale client is not the size of the discount. This is a fundamentally different model of interaction.

A retail buyer came in, chose, paid by card, received the parcel. All. A wholesale client is a company with a legal entity, with several employees who can place orders, with an agreement, with deferred payment, with individual prices that depend on the volume of purchases for the last quarter, on the category of goods, on the region of delivery. A wholesale client may have a credit limit, a prepaid balance, a history of price negotiations, and personal commercial offers. And all this should work simultaneously, without interfering with retail and without turning the administrative panel into chaos.

We started from the very foundation - customer groups. But not those primitive groups that are found in most B2B plugins, where the group is just a label with a percentage discount. Our groups are full-fledged entities with inheritance of properties, priorities and flexible configuration for each parameter separately. What does this mean in practice? Let's say you have three levels of wholesale customers: “Dealer”, “Distributor” and “VIP-partner”. The dealer receives a base five percent discount on the entire catalog, sees only eligible wholesale items, and can pay orders on invoice. The distributor inherits all the dealer’s settings, but receives an additional discount - a total of ten percent, sees an expanded catalog, including goods on order, and can use a payment deferment of up to thirty days. The VIP partner inherits from the distributor, receives fifteen percent and personal pricing for individual product groups.

Inheritance is the key word here. You don't set up every group from scratch. You build a hierarchy, and each subsequent level adds or overrides only what is different. We changed the basic discount for dealers - it will automatically be updated in a cascade for distributors and VIP partners if they have not explicitly redefined it. This saves hours of work when managing dozens of client groups, and some of our clients have just that many – separate groups by region, by product type, by sales channel.

And this is where the fun begins - linking users to groups. It would seem that what is so difficult here? I assigned a group to a user and forgot. But in reality, one client may have several contact persons, each with their own account. Buyer, manager, accountant, executive - and everyone needs a different level of access. The buyer can create a cart, but cannot confirm the order. The accountant can see the order history and download documents, but cannot change the composition of the order. The manager sees everything and manages all subordinate accounts. This is no longer about groups - this is about subaccounts, and I will tell you more about this a little later. But it’s important to understand that groups are the foundation on which all other B2B logic is built.

Another point that is often missed is moderation. In retail, registration is instant: enter your email, come up with a password, and you’re done. It doesn't work that way in B2B. When a company submits an application for wholesale cooperation, it fills out an extended form: TIN, KPP, legal name, actual and legal address, contact person, telephone number, desired conditions. This application goes into moderation - the manager checks the data, may request additional documents, and only after approval the client receives access to the wholesale catalog and prices. We have implemented custom registration fields that are fully customizable from the admin panel - you decide what data to request, which fields are required and which are optional. And this data is then linked to the client’s account, available to managers and can be automatically included in documents - invoices, contracts, commercial proposals.

Honestly, when we first started designing this module, I thought customer groups were the easy part. It turned out that this is one of the most logic-laden components, because it is the group that determines what the customer sees, how much he pays, how he pays, and what he can do in the store. Everything else - pricing, visibility, restrictions - is built on top of groups.

Price is not a number, but a strategy: tiered pricing for wholesalers

One question I like to ask clients is, “How do you set your wholesale prices?” And nine times out of ten I get an answer that starts out simple and then becomes endlessly complicated. “Well, we give a discount based on volume. Ten pieces - five percent, one hundred pieces - fifteen, and if they take a thousand - then twenty-five. But this is not the same for all products. There is one mesh for oils, another for filters. And there are still separate conditions for dealers from Siberia, because logistics are more expensive. And there are also seasonal promotions, when we give an additional ten percent on certain groups of goods. And for the Gazpromneft client, we generally have an individual price list, which we recalculate every quarter.”

This is real B2B pricing. Not a “10% discount”, but a multidimensional matrix, where the price depends on the client, on the client group, on the product, on the product category, on the quantity in the order, on the total volume of purchases for the period, on the region and on a dozen more parameters that the business adds as it grows. And any tool that claims to work with wholesale prices must support this matrix - not in theory, but in a convenient interface where the manager can configure all this without a programmer.

In our module, pricing works on several levels, and this is not a metaphor - these are literally levels of priorities that the system checks from top to bottom until it finds a suitable rule.

The first level is group prices. For each customer group, you can set a fixed price or a percentage discount on a specific product. For example, the product “Hydraulic oil HLP-46” retails for 5,000 rubles per canister. For the “Dealers” group you set a price of 4,250 rubles, for “Distributors” - 3,800, for “VIP” - 3,500. These prices are set in the product card or en masse through the price table. When a client from the “Dealers” group goes to the product page, he sees his price - 4,250 rubles. A retail buyer sees 5,000. No magic, just pure substitution at the level of WooCommerce hooks, which works everywhere - in the catalog, in the product card, in the cart, in checkout, in letters.

The second level is tiered pricing. This is where the real fun begins. For each product (or product category), you can set a price grid depending on quantity. Ten canisters - five percent discount on the group price. Fifty cans - ten percent. One hundred - fifteen. Five hundred - twenty. And these grids are also tied to groups. Dealers have one network of volume discounts, distributors have another, more aggressive one. On the product page, the client sees a table with price thresholds - it is transparent, understandable, and encourages them to increase the order volume. In the cart, the price is automatically recalculated when the quantity changes.

The third level is individual prices. For individual clients, you can set personal prices for specific products that overlap group prices. This is for those very situations “we have a special agreement with them.” The manager goes to the client’s profile, sees all active prices - group and individual - and can add or change the price for any product. Individual prices have the highest priority and supersede everything else.

I came across a situation where a client asked to set up pricing, where the final price was calculated through five levels of rules: the base price from 1C, minus the group discount, minus the volume discount, plus a markup for the urgency of delivery, minus the cumulative discount for the volume of purchases in the current quarter. And all this had to be displayed correctly at every stage - from the catalog to the final invoice. We managed, but then I realized that pricing in B2B is not a feature, it is a separate discipline that requires an architectural approach. You can’t just attach a filter to the price of a product - you need to rebuild the entire price calculation pipeline so that it takes into account all levels and at the same time remains fast. Because if a catalog page with three hundred products takes ten seconds to load while the system calculates an individual price for each, no discounts will save you.

A separate topic is synchronizing prices with 1C. Many of our clients set prices in 1C: Trade Management, and the website must reflect current prices from the accounting system. The 1C integration module knows about B2B groups and can compare price types in 1C with customer groups in WooCommerce. When the “Dealer price” for a product changes in 1C, these changes are automatically sent to the site through OData synchronization. The manager does not need to manually update prices in two places - just do it in 1C, and in a few minutes the site will show the current data.

Do you know what irritates me about most B2B plugins? They show the wholesale price only after authorization. That is, a potential dealer goes to the website, sees retail prices and thinks: “Expensive, I’ll go somewhere else.” He won’t even know that the conditions for wholesalers are completely different, because he first needs to register, wait for moderation, log in - and only then see his prices. We solved this problem differently: for unauthorized users, you can show a hint “Wholesale price is available after registration” or even a range - “from 3,500 rubles. when purchasing from 100 pcs." This acts as a lead magnet and significantly increases conversion rates for wholesale customer registrations.

Hidden directory and visibility rules: who sees what and why it's more important than it seems

Here's a typical situation: a company sells industrial equipment. The catalog has standard positions that are visible to everyone - they are indexed by search engines, attract organic traffic, and work on brand recognition. But there are also specialized products - say, components for the oil and gas industry or chemical reagents with limited circulation. These products should not be visible to the general public. They are intended only for certified dealers who have been verified and signed the appropriate documents. Showing them to retail customers is not only pointless, but sometimes even contrary to regulatory requirements.

A hidden directory is not just a matter of “removing it from the search results.” This is a whole system of visibility rules that determines who sees what products, who sees prices, who can add to cart, and who can only look. And this system must be flexible enough to cover all scenarios that occur in real business.

Let me describe a few real-life configurations that we configured for clients. The first option is a classic hidden catalog: some products are completely invisible to unauthorized users and retail clients. They are not displayed in searches, are not shown in categories, and are not indexed by search engines. Only customers from certain groups see these products after logging into their account. The second option is that the product is visible to everyone, but the price is hidden. Instead of the price, the “Request Price” button or the text “Price on request” is displayed. This is often used for high value items or with a price that depends on configuration. The third option is that the product is visible, the price is visible, but the “Buy” button is available only to authorized wholesale customers. Retail buyers can view the range and characteristics, but to purchase they need to apply for wholesale cooperation. The fourth option is a full store behind the login. The entire catalog is closed to unauthorized users. When you go to the site, you see a landing page with an offer to become a client, and only after authorization does a catalog with prices open. This is suitable for companies that operate exclusively in B2B and do not engage in retail.

Visibility rules can be combined at different levels: for an individual product, for a category, for a tag, for a group of customers. And they work cascading - if you hide an entire category for retail customers, all products in it automatically become invisible, even if no rules have been set for individual products. But you can explicitly override the rule for a specific product - for example, make one product from a hidden category visible to everyone if it is a demo.

I've been thinking a lot about why so many B2B stores do such a bad job with visibility. And I came to the conclusion that the problem is not in technical complexity, but in the approach. Most solutions make visibility binary: a product is either visible or not. But in reality, this is a spectrum: is the product visible, is the price visible, is the purchase button visible, is the “Request Price” button visible, is the quantity in stock visible. Each of these elements can be managed separately for each client group. And when you can fine-tune this granularly, you get a tool that accurately reflects your business model, rather than forcing the business to adapt to the limitations of the software.

There is another aspect that is rarely talked about: performance. When you have sixteen thousand products and twenty customer groups with different visibility rules, checking “if this user has the right to see this product” should be lightning fast. You cannot make a separate database query for each product in the catalog. We solved this through preliminary caching of visibility rules - when a client logs into his account, the system calculates the full set of his rights once and stores them in the session. All subsequent checks work in microseconds. When the rules change, the cache is invalidated automatically. It sounds simple, but in a business with two thousand visitors a day, this is critically important - every extra millisecond spent checking multiplies by thousands of products and thousands of requests.

From cart to invoice: quotation request workflow

Now let's talk about what distinguishes a real B2B portal from a “discount store for wholesalers.” This is the procurement process. In retail, everything is simple: add to cart, pay, wait for delivery. In B2B, buying is a negotiation. The client creates a request, the manager reviews it, can offer an alternative, adjust prices taking into account the volume, offer an additional discount for urgency or for prepayment. Then the client confirms, an invoice is generated, payment is made by bank transfer, and only then the shipment begins. Try to put this into a standard WooCommerce checkout - nothing will work.

We have implemented a full workflow for requesting a commercial proposal, which in English is called Request for Quote - RFQ. How it works from the client's point of view: he goes to the site, selects products, and adds them to the cart. But instead of the “Place an order” button, he sees the “Request a quotation” button. He clicks, adds a comment - “delivery to a warehouse in Chelyabinsk is needed, if possible within a week, we are ready to consider analogues if there is a delay for some items” - and sends the request. The manager receives a notification, opens a request in the WooCommerce admin and sees everything: list of products, quantities, current prices for this client, history of previous orders, credit limit balance, client comment.

Then the fun part begins - the dialogues. We made a conversation system that is tied to each request. The manager can write to the client: “For item 3 (HLP-46 oil) - there are currently 80 canisters in the warehouse, the remaining 20 will be in 5 days. I can reserve the entire batch now with delivery in two stages, or wait for the complete set. In terms of price, if you order the entire batch at once, I can give you an additional 3%.” The client receives this message in his personal account on the website and by email, responds, and the manager adjusts the offer. All correspondence is saved in the request history - after six months you can pick it up and see what was agreed upon.

When the parties have reached an agreement, the manager creates a final proposal - with confirmed prices, quantities, delivery and payment terms. The system automatically generates a PDF commercial proposal - with the company logo, details, list of products, prices, total amount, conditions. The client can download this PDF from his personal account, forward it to management for approval, and attach it to the tender documentation. And when the offer is approved, it is converted into a WooCommerce order with one button - all positions, prices, addresses are automatically updated, nothing needs to be entered again.

You know what I love most about this process? It digitizes what previously happened in email, WhatsApp, and phone calls. The manager receives a request in the messenger, forwards it to a colleague in the purchasing department, he checks the balances, responds to the manager, the manager forms the CP in Excel, sends it to the client by email, the client edits it, sends it back... By the end of this chain, no one remembers which version is current, and half of the information was lost between transfers. With our workflow, everything is in one place: request, discussion, proposal, document, order. One click and the whole story is before your eyes.

It’s worth mentioning separately about PDF auto-generation. We spent a lot of time making these documents not just functional, but professional looking. Company logo, header with details, neat table of goods with articles and units of measurement, total amount with and without VAT, block with terms of payment and delivery, place for signature and seal. This is not a “printout from an online store” - this is a full-fledged business document that is not embarrassing to send to a large customer. The PDF template is customizable from the admin panel, and you can adapt it to suit your corporate style.

By the way, one of our clients - a manufacturer of hydraulic oils - told me how the RFQ module changed the work of his sales department. Previously, a manager spent an average of forty minutes processing one wholesale request: accept the application, check balances, calculate the price taking into account discounts, create a commercial proposal, send, wait for a response, adjust, send again. Now - fifteen minutes. Moreover, most of this time is not routine operations, but live communication with the client through a system of dialogues, discussion of specific positions, and selection of analogues. The system took over the routine: calculating prices, checking balances, generating documents.

Subaccounts, wallets and purchase lists: when B2B is not one person, but an entire company

There is one thing that online retailers generally do not understand, but B2B portals must take into account: a customer is not a person, it is an organization. The organization has several employees, and each needs a different level of access to the store. The buyer forms applications, the manager approves them, the accountant downloads documents and monitors payments, the logistician tracks delivery. If everyone has the same login, it means chaos and security problems. If each has a separate registration, then they are not related to each other, and the manager does not understand that Ivanov, Petrov and Sidorov are one company “HydroTech”.

Subaccounts solve this problem elegantly. The company's main account—usually the manager or purchasing officer—creates subaccounts for its employees. Each subaccount is assigned rights: can it create orders, can it confirm orders above a certain amount, can it see orders from other company employees, can it manage purchase lists. All subaccounts inherit the group, prices and visibility rules from the main account. Orders placed by subaccounts are visible in the overall company history. It's like a corporate account - one company, several users, transparent history.

I remember one client telling me about his headache before introducing subaccounts. He had a large dealer with five buyers in different cities. Each buyer was registered separately, each was manually assigned a “Dealer” group, and each was given individual prices. When one buyer left and a new one arrived, a commotion began with transferring the account, changing passwords, checking whether all the settings were in place. And then the manager of this dealer asked: “Show me the entire purchase history of our company for this year,” and the manager began to collect information from five separate accounts manually. With subaccounts, all this disappeared - the dealer manager manages his employees himself, sees general statistics, and if someone quits, he simply deactivates his subaccount. Three seconds instead of an hour of correspondence.

Now about the B2B wallet. This feature appeared at the request of customers who work with regular wholesalers on an advance payment basis. The logic is simple: the dealer deposits a certain amount on the balance sheet - say, five hundred thousand rubles - and then writes off orders from it. There is no need to create a separate invoice each time, wait for payment, or check receipts. The money is already on the balance sheet - I placed an order, the amount was written off, and the goods were sent for shipment. This is convenient for the client and speeds up the procurement process. For the seller - a guarantee of payment and predictable cash flow. In the personal account, the client sees the current balance, the history of deposits and debits, and can download a statement for the period. The manager can replenish the balance manually or set up automatic replenishment upon receipt of payment.

Buying slips are another feature that seems like a small thing until you work with B2B clients who place regular orders. Let's say a car service orderes the same consumables every month: ten canisters of 5W-30 motor oil, five canisters of transmission oil, twenty oil filters, ten air filters. Each time, searching for these products in the catalog again, adding them to the cart, entering quantities is five to ten minutes of manual work. With a purchase list - one click of a button. The client creates a “Monthly consumables” list once, adds all the necessary products with quantities there, and then sends the entire list to the cart with one click. You can create several lists - “For the service station on Lenin”, “For the branch in Kopeysk”, “Emergency stock” - and use them as needed.

But what makes buy sheets truly useful is the integration with the rest of the system. The prices in the purchase list are always up to date - if the group price has changed, the list will show the new price. If an item is out of stock, the list will show this. If a seasonal discount appears, the price in the list will be updated automatically. A purchasing list is not a static set of products, but a living tool that always reflects the current state of the catalog.

And since we’re talking about payment, let’s talk about B2B payment methods. In retail everything is simple: card, electronic wallet, cash on delivery possible. In B2B, the main payment method is issuing an invoice to a legal entity. The client places an order, the system automatically generates an invoice with the details of both parties - the seller and the buyer. The invoice is available in your personal account and sent by email. The client pays by bank transfer, the manager confirms receipt - the order is processed. The second method is Purchase Order, when the client indicates the number of his internal work order, and payment occurs according to the terms of the contract - with a delay of thirty, sixty or ninety days. The third is payment from a B2B wallet, which I already talked about. All three methods work in the standard WooCommerce checkout - the client selects the appropriate one when placing an order, and the system automatically applies the appropriate logic.

Rules and restrictions: make the system work according to your business processes

Do you know what is the fundamental difference between a retail and wholesale store in terms of business logic? In retail, the rules are simple and the same for everyone: minimum order - one product, payment - by any method, delivery - wherever you say. In B2B, rules are part of the business model, and they are different for different clients.

A dealer cannot order less than ten units of one product - otherwise the logistics will not pay off. The distributor can only order full pallets. A VIP client can order any quantity, but his minimum order amount is fifty thousand rubles. A new client who has not yet confirmed his status can only pay by prepayment. A customer with an overdue debt is temporarily limited - he can view the catalog, but cannot place orders. A customer from a certain region cannot order goods with limited turnover.

All these rules and restrictions should work automatically, without manual control by the manager. And they should be clear to the customer - if he tries to place an order for eight cans with a minimum of ten, he should see a clear message: “The minimum quantity for this product is 10 pieces.” And not the mysterious “unable to place an order” error.

We have implemented a rules system that covers basic B2B constraint scenarios. Minimum order quantity - by number of goods, by amount, by weight. Quantity Step - If an item is only sold in packs of six, the customer cannot order five or seven. Restrictions on payment methods - only certain payment methods are available for certain groups. Restrictions on delivery methods - large orders only by transport company, not by courier. Required fields - When ordering certain products, the customer must provide additional information, such as a license number or intended use.

These rules are associated with customer groups, product categories, or specific products. And they are checked at every stage: when adding to the cart, when going to checkout, when placing an order. If a rule is broken, the client receives a clear message and a hint on how to correct the situation.

I often hear the objection: “Why such complexity? Let the manager check each order manually.” And it works when you have five wholesale clients and ten orders a week. But when there are fifty clients and twenty orders a day, manual verification turns into a bottleneck. The manager spends time checking trivial rules instead of making sales. And if the manager is sick or on vacation, the rules simply stop working, and you risk shipping goods to a customer with an overdue debt or accepting an order below the minimum amount.

Rule automation is not about replacing a manager. This is about freeing the manager from routine and giving him the opportunity to do what really requires human participation: negotiations, selection of goods, building relationships with clients. Let the system check the minimum quantities and available payment methods - at this time the manager will discuss the conditions for the next quarter with the client.

Separately, I would like to say about the registration rules. I have already mentioned custom fields when registering a wholesaler - tax identification number, checkpoint, legal address. But it's not just about the fields. The whole process is important: the client fills out the form, the application goes into the queue for moderation, the manager receives a notification, checks the data - perhaps enters the TIN in the Federal Tax Service database, checks the company for debts and lawsuits - and makes a decision: approve, reject or request additional information. Upon approval, the client automatically receives an assigned group, sees his prices and catalog. If rejected, he receives an email explaining the reason. All this is customizable, letter templates can be edited, application statuses are visible in the general list.

Why is this important? Because the first impression of a B2B portal is formed precisely at the moment of registration. If a potential dealer filled out the form and did not receive a response for three days, he has already left for a competitor. If it's approved within two hours with a personal greeting and instructions for your first order, it's yours. The speed and quality of processing applications directly affect the conversion from “interested” to “became a client.”

Why one module is better than four plugins: economics and common sense

Let's do the math. Typical set of B2B plugins for WooCommerce: plugin for customer groups and roles - from $79 to $149 per year. Wholesale pricing plugin - $99 to $199. RFQ (Request for Quotation) plugin – $79 to $149. Plugin for restricting catalog visibility - from $49 to $99. Total for a minimum set of four plugins - from 306 to 596 dollars per year. And this is without subaccounts (79-149 more), without tiered pricing (99 more), without B2B registration with moderation (79 more). If you take everything you need for a full-fledged B2B portal, it easily comes out to $800 a year. Every year.

But money is not so bad. The real problem is compatibility. Each of these plugins has its own pricing logic, its own way of checking access, its own hooks and filters. When you put four plugins next to each other, they start to conflict. The pricing plugin considers that the price for the dealer is 4,250 rubles, and the groups plugin imposes its own discount on top and the result is 3,825. The visibility plugin hides the product, but the RFQ plugin still shows it in the request. You spend time debugging conflicts, write support for each plugin, get the standard answer “this is not our bug, contact the developer of another plugin,” and end up hiring a freelancer for some money to write custom code that glues it all together.

And then one of the plugins is updated, and everything breaks again.

People may object to me: “But modularity is good! I only buy what I need." And I agree - modularity is good when the modules are designed to work together. Like construction kit parts that fit together perfectly. But when modules are independent products from different teams that don't even know each other exists, modularity becomes a headache.

In our approach, modules are parts of a single product. B2B groups, pricing, visibility, restrictions, RFQ, subaccounts, wallets - all this is one PHP namespace, one set of tables in the database, one API, one administrative panel. When you set up a group price, the pricing system knows about the groups. When you hide a product for retail customers, search does not show it either. When a client generates an RFQ, the system sets his group prices taking into account volume discounts. Everything works as a single mechanism, because it is a single mechanism.

And one more argument that is important for those who already work with 1C. Our B2B module was designed taking into account 1C integration from the very beginning. Customer groups are compared with price types in 1C. Wholesale prices are synchronized via OData. Orders are uploaded to 1C with the correct analytics - by customer group, by payment type, by order source. Try setting up this integration with four independent plugins - you will need not just one freelancer, but a whole team of developers. And every update to any of the plugins will potentially break the integration.

I'm not saying that our solution is the only correct one. There are excellent dedicated B2B plugins on the market that do their specific task better than anyone else. But if you need a full-fledged B2B portal - with groups, prices, visibility, requests for proposals, subaccounts, integration with 1C - assembling it from separate plug-ins means dooming yourself to an endless struggle with compatibility, updates and support.

You know, I sometimes compare this to renovating an apartment. You can buy separate tiles, separate grout, separate glue, separate tools - and figure out for yourself which grout fits which tiles, which glue holds on which base. Or you can take a ready-made kit from one manufacturer, where everything is selected and tested together. The first way is cheaper if you know what you are doing. But if you make a mistake, it’s more expensive to redo it than it would be to buy the kit outright.

Back to the person who called me last week - the owner of a lubricants company. We set up a complete B2B portal for him in two weeks. Three groups of clients with inheritance, multi-level pricing linked to 1C, a hidden catalog for specialized products, RFQ-workflow with the generation of PDF commercial proposals, sub-accounts for large dealers, a B2B wallet for regular customers with prepayment. One admin panel, one set of settings, one support channel. A month after the launch, its managers processed twice as many wholesale orders with the same staff - because the system took over the routine.

He then wrote to me: “I spent two years trying to put this together from separate plugins. I spent more than your solution cost, and never got it to work.” I hate to turn this into a sales pitch, but the fact remains that an integrated B2B solution is not just a convenience, it is an economic necessity for companies that are serious about the wholesale sales channel.

What if you're just starting to think about B2B and aren't sure you need the full feature set? Start small. Set up one group of wholesale customers with base prices. Enable registration moderation. See how it goes. As you grow, connect tiered pricing, RFQ, subaccounts - each module is enabled by a switch in the settings, without additional plugins, without additional payments. You grow - the system grows with you. And at some point you will look back and see a full-fledged wholesale portal that was built naturally, step by step, without stress and rework.

Try COS WP Woo - 14 days free.Install the plugin, activate the B2B module and set up your first group of wholesale clients in fifteen minutes. No card binding, no functionality restrictions. All the features we talked about - groups, prices, hidden catalogue, RFQ, subaccounts, integration with 1C - are available from day one. If you don’t see a difference in two weeks, just deactivate the plugin. But I'm sure you will.