Subaccounts and purchase lists: access for client managers

Once the head of the supply department of a machine-building plant called me and said: “Listen, I have twelve people in my department. Everyone buys their own area - some fasteners, some electricians, some consumables for machine tools. And they all log into the supplier’s online store under one login. Everyone knows the password. It is unclear who ordered what. Who exceeded the budget cannot be tracked. One manager quit, everyone had to change their password. This is a complete mess, can’t it be done properly?” I thought about it then, because the situation was painfully familiar. This is not the first time I’ve heard something like this, and every time I’m surprised: how is it that in 2026, large companies with a turnover of hundreds of millions of rubles manage purchases through one common account in an online store? It’s as if the entire accounting department worked under one 1C account - an absurdity that for some reason is considered the norm in e-commerce.

And here's the thing - the problem is not that store owners don't want to give their customers a convenient tool. The problem is that standard WooCommerce (and most e-commerce platforms) simply are not designed for corporate buyers. One account - one user - one cart. Dot. But the real B2B world works completely differently. There is a hierarchy, budgets, areas of responsibility, approval procedures. And if your online store doesn’t understand this, you’re losing customers. Not because your prices are bad or the range is weak, but because it’s inconvenient to work with you. The buyer will spend an extra half hour placing an order through your website - and next time he will simply call a competitor who has a normal personal account.

I've been developing B2B solutions for WooCommerce for several years now, and the topic of corporate accounts is one of the most popular and at the same time the most underrated. When we started designing the subaccounts module for our COS WP Woo plugin, we didn't start from abstract "best practices" but from actual requests from real companies. And I want to tell you how we did it, what rakes we picked up along the way, and why properly organized corporate access can increase the average bill of a B2B client by 20-30 percent. Not because you are pushing something, but because it becomes more convenient for buyers to buy from you.

Why one account per company is never enough

Let's look at how procurement works in a typical medium or large company. There is a head of the procurement department - he is responsible for the overall budget and procurement strategy. Managers work under him, each of whom oversees his own area. Some purchase raw materials, some components, some consumables, some tools. Each manager has his own budget for a month or quarter, his own suppliers, his own usual positions. Sometimes there are also regional representatives - at production sites in different cities, who also order something, but within certain limits.

And just imagine: all this variety of roles and powers needs to be packaged into one online store account. What happens? A complete mess. The head of the department does not see who exactly made the order. Manager Ivanov ordered for 500 thousand, although his limit is 200. Manager Petrova accidentally ordered the same thing that Sidorov ordered yesterday, because they do not see each other’s orders. And when the time comes to deal with duplicates, returns and budget overruns, endless correspondence in instant messengers begins, calls and finding out “who ordered this and why.” Is this a familiar picture? I see this in literally every second company that comes to us for a B2B solution.

The problem is exacerbated by the fact that large organizations have internal procurement regulations. Orders over a certain amount must be approved by the manager. Purchasing a certain category of goods requires a CFO visa. Some items are generally purchased only through a tender procedure. And this entire corporate process needs to be somehow superimposed on the interface of an online store, which was originally designed for a retail buyer - an individual who selects a product, puts it in a cart and pays with a card. Between “add to cart” in B2C and “generate purchase requisition” in B2B is a gap that most WooCommerce plugins don’t even try to bridge.

I remember one of our clients, an industrial lubricants distributor, telling me that before implementing subaccounts, his sales managers spent about two hours a day processing orders that came in by phone and email. Why over the phone? Because buyers on the client side did not want to deal with an inconvenient personal account. It’s easier to call and dictate: “It’s like last time, but instead of a 200-liter barrel, take two 60-liter barrels.” Two hours a day, five days a week, fifty weeks a year - that's five hundred hours of manual work for a manager. With the average salary of a manager including taxes and deductions, this is approximately 350-400 thousand rubles per year, which could be saved by simply giving clients a normal tool for ordering independently. But not just a “store with a catalogue” - but a tool that takes into account corporate specifics.

This is why we designed the subaccount system as an integral part of the B2B module. Not as a separate add-on plugin that you need to screw on the side and pray that it doesn’t conflict with the rest of the functionality, but as an integrated component that works in conjunction with B2B groups, pricing, quotas and the rest of the ecosystem. And this is a fundamentally important point - subaccounts without connection to business logic do not make much sense. Just giving several people different logins is half the battle. Real value begins when each login has its own set of rights, its own limits, its own available categories and its own role in the purchasing process.

How subaccounts are structured from the inside

When we started designing the subaccount module, the first thing we needed to decide was the data model. It would seem that what is so difficult here? There is a main account, there are child ones, linking via foreign key - and off you go. But the devil, as always, is in the details. We discussed at length what level of nesting to maintain. If a company has branches, each branch has its own purchasing department, each department has its own managers - these are already three levels of hierarchy. And if we add here also project groups that are formed for specific tasks - four. And each level has its own rights and limits.

As a result, we made a decision that may seem controversial to some, but in practice turned out to be absolutely correct: a two-level hierarchy. Main account (company owner or purchasing manager) and subaccounts (managers). No intermediate levels. Why? Because in real life, more complex hierarchies create more problems than they solve. Each additional level means a new layer of rights, new inheritance conflicts, new scenarios that need to be tested, and new bugs that are sure to pop up at the most inopportune moment. And ninety-five percent of B2B clients fit perfectly into the “one manager - several managers” model. For the remaining five percent, you can create several main accounts - one per branch, for example.

Each subaccount in our system is a full-fledged WordPress user with a separate login and password, but linked to the main account through an entry in the tablewpaic_b2b_subaccounts. The main account creates a subaccount directly from your personal account - specifies email, name, position and, most importantly, a set of restrictions. What are these restrictions? The maximum amount of one order - for example, a manager can order for an amount of no more than 150 thousand rubles. Available product categories - the consumables manager sees only consumables, and not the entire catalog. Approval Required - Sub-account orders may require approval from the main account before being submitted for processing. And finally, access to history - whether the subaccount sees only its orders or all the company’s orders.

Here's the thing - these restrictions are not hard-coded into the code, but are configured by the main account independently, without the participation of the store administrator. This is critical for scaling. Imagine that you have fifty B2B clients, each with five to ten managers, and each client wants to set up rights differently. If you need to write to technical support for this, your technical support will drown. And if the client can log into his personal account, create a sub-account and set limits - this is self-service in the best sense of the word.

Technically the implementation works like this: when creating a subaccount, a new WordPress user is generated with the rolecustomer, it is assigned a meta field_wpaic_parent_accountwith the main account ID, and an entry is created in our table with a set of rights and restrictions. When a subaccount logs in and enters the store, our plugin intercepts requests to the catalog and filters the available categories. When a subaccount adds an item to the cart, the amount limit is checked. When placing an order, a check is triggered: is confirmation of the main account required? If yes, the order is created with the status “Awaiting confirmation”, and the main account receives a notification by email. He logs into his personal account, sees the order, checks the items and amount, and clicks “Confirm” or “Reject.” Only after confirmation the order is processed.

I came across a situation where a client asked to add another level of confirmation - when an order over a certain amount must be confirmed not only by the head of the purchasing department, but also by the CFO. We implemented this through a threshold value mechanism: if the order amount exceeds the established limit, the order is sent for additional approval. This is not a classic approval chain like in BPM systems, but rather a two-stage filter, but for most scenarios it is more than enough. And you know what - the client was delighted. Because before that, he controlled large purchases through a WhatsApp group, where managers posted screenshots of orders. I'm not kidding - WhatsApp is a system for coordinating purchases at an enterprise with a turnover of half a billion rubles a year.

I would also like to highlight how subaccounts integrate with B2B groups. In our module, a B2B group is a set of pricing rules, discounts and conditions that apply to a certain category of clients. For example, the “Dealers” group receives a wholesale price minus ten percent, and the “VIP” group receives special fixed prices for key items. When a primary account belongs to a specific B2B group, all of its subaccounts automatically inherit that group's pricing. The purchasing manager sees the same prices that the manager would see if he ordered it himself. This is logical and natural - the price is determined not by the person, but by the purchasing company. But at the same time, each subaccount can have its own restrictions on categories and amounts that are set by the main account. The result is a flexible system: pricing is determined by the B2B group, access restrictions are determined by the main account.

There was an interesting case with a plant for the production of metal structures. They have twelve managers in the procurement department - the same call that I started the article with. We set up a structure for them like this: the main account is the head of the department, twelve subaccounts are managers. Three managers purchase fasteners (they see only the “Fasteners” category), two - electricians (the “Electrical Equipment” category), four - consumables for machines, one - tools, and two “generalists” who see the entire catalog, but with an order limit of 100 thousand rubles. Orders up to 50 thousand are processed automatically, from 50 to 200 - require confirmation from the boss, over 200 - additional approval from the finder. Setup took about an hour, and the factory has been ordering through the website ever since. In the first three months, the average bill increased by 27 percent - not because prices were raised, but because managers stopped forgetting items that they had previously “reordered” with separate calls.

Purchasing sheets - when routine turns into one click

Now let's talk about purchasing sheets, because this is the feature that clients ask for most often, but are formulated in different ways. Someone says “we need a list of favorites for repeat orders”, someone says “we want order templates”, someone says “we need a repeat order function, but with the ability to edit”. Essentially, everyone is talking about the same thing: the ability to store a set of products with quantities and quickly turn it into an order.

It would seem that WooCommerce has a "Repeat Order" feature - it takes items from a previous order and adds them to the cart. But this is a solution for retail, not for B2B. Why? Because the B2B buyer does not repeat the previous order one to one. He repeats approximately the same set, but with adjustments: you need more of this product, less of this, but remove this one altogether, because there is still some stock left in the warehouse. And the buyer may have several such “basic sets” - a weekly order of consumables, a monthly order of components, a quarterly order of spare parts for equipment maintenance. Each set has its own list of goods, its own quantities, its own rhythm.

Our purchasing list module works exactly like this. The user (main account or subaccount) creates a named list - for example, “Weekly consumables” or “Spare parts for TO-2”. Adds products from the catalog to it indicating the quantity. Can leave a comment for each item - “take only if the price is below 5000” or “replace with an analogue if unavailable.” The list is saved and available in your personal account. When the time comes to order, he opens the list, adjusts the quantities if necessary, clicks “Add to cart” - and all items from the list end up in the cart. Next is the normal ordering process.

To be honest, when we first demoed this feature to clients, the response was unexpected. We expected something like “well, yes, it’s convenient.” And they got: “Wait, so my manager doesn’t have to spend forty minutes searching for and adding sixty positions every Monday? Does he just open a list and press one button?” That's right. Forty minutes of routine turns into thirty seconds. Multiply this by the number of managers, by the number of orders per month - and you will understand why purchasing lists have become one of the most popular functions of our B2B module.

But there are nuances that make buy sheets truly useful in a corporate context. The first is sharing. The main account can create a purchase list and “share” it to all subaccounts of the company. This means that the head of the supply department creates a standard purchase set, and managers use it as a base - add it to the cart, adjust it to their needs, and place an order. If the standard set changes (a new consumable is added, a discontinued one is removed), the boss updates one list - and all managers see the current version. This is not technically difficult, but from a business process point of view it saves enormous time and reduces errors.

The second nuance is integration with order history. The system analyzes which goods the buyer orders regularly and can automatically offer to create a purchasing list based on the last three to five orders. The algorithm is simple: if a product is present in more than half of the latest orders, it is a candidate for inclusion in the list. The quantity is taken as an average. The buyer sees the proposal, adjusts if necessary and saves. Thus, even if the manager has never heard of purchasing lists, the system itself will push him to use them.

The third nuance, and perhaps the most unobvious one, is purchasing sheets as a sales tool for the store owner. Think about it: if you see that a customer has a purchase list of twenty items and he orders it every month, that's golden information. You know what he needs, you know the volumes, you know the frequency. You can offer a personal discount on this set. You can reserve goods in the warehouse in advance. You can suggest expanding the list with related products: “We recommend adding filter elements to your standard order of lubricants - they run out at approximately the same frequency.” The purchase list is not just a convenience for the buyer, it is a window into his needs for the seller.

We saw one of our clients, an industrial chemicals supplier, use purchase slip data for proactive sales. He saw that the plant regularly orders a certain set of reagents, and offered a wholesale discount if the volume increased by 15 percent. The logic is simple: “You already take this every month, take a little more - we’ll give a better price, and you won’t have to place an additional order in two weeks.” The conversion rate of such offers was about forty percent - because the offer was accurate, relevant and based on real data, and not on abstract marketing emails.

Separately, it is worth mentioning the mechanics of creating a purchase list “on the fly” - directly from the catalog. The manager looks at the products and sees the add to purchase list icon next to the “Add to cart” button. Clicks - selects which list to add to (or creates a new one), indicates the quantity. This is more convenient than adding items to your cart first and then trying to save the cart as a list. We tried both approaches and definitely settled on “adding from the catalog” - users perceive it intuitively, without explanations or tips.

MOQ - the minimum order quantity that everyone ignores until they get burned

Now let's talk about something that many B2B stores consider a small thing and then regret - the minimum order quantity, or MOQ (Minimum Order Quantity). It would seem, what is there to discuss here? Set a minimum - and the client cannot order less. But when you start digging, it turns out that there are six different types of MOQ in B2B, and each of them is needed in different situations.

The simplest is MOQ by product. This product is sold in batches of ten. If you want three, sorry, at least ten. This is necessary for goods that are unprofitable to assemble individually: hardware, gaskets, filters, consumables. A warehouse picker won’t count out three bolts from a box of a thousand pieces—he ships in boxes. And this makes sense, because the cost of processing an order of three bolts can exceed the cost of the bolts themselves. Product MOQ solves this problem at the interface level - the customer simply cannot add less than the minimum to the cart.

The next level is MOQ by category. The entire “Lubricants” category has a minimum order of 5,000 rubles. If you want one jar for 800 rubles, please, but add more goods from this category up to 5000. This is necessary for goods that require special storage or delivery conditions. For example, if you need to prepare accompanying documents for the shipment of chemical reagents, you do not want to do this for the sake of one canister. The MOQ by category motivates the customer to fill the basket, at which point the shipment becomes economically justified.

And finally - MOQ by customer group. Dealers must order at least 50 thousand rubles, retail clients - without restrictions, and VIP clients - also without restrictions, because they have contractual obligations on the volume of purchases for the year. This is a completely different logic - it is tied not to the product, but to the relationship with the client. And it fits perfectly with our B2B group system, because MOQ is configured as one of the group properties, along with pricing and discounts.

We implemented MOQ so that it works seamlessly - without unpleasant surprises for the buyer. When a customer tries to add a quantity less than the minimum to the cart, he immediately sees a message: “The minimum quantity for this product is 10 pieces.” The quantity is automatically adjusted to the minimum. If the cart does not reach the minimum amount for a category, when proceeding to checkout, the client sees a warning indicating how much more needs to be added. Not a block without explanation, but a clear message with a specific amount. This seems obvious, but you'd be surprised how many stores simply show a red "Order Unable to Checkout" error without any explanation.

I've been thinking for a long time about whether MOQ should be a hard limit or a soft recommendation. In the end, we did both - with settings in the admin panel. A strict MOQ does not allow you to place an order if the condition is not met. Soft MOQ shows a warning but allows you to continue. Why soft? There are situations when a client urgently needs one item, and he is ready to pay a premium for a non-standard batch. Blocking it means losing the order. To warn but to give opportunity means to be flexible. In B2B, agility is the currency.

There is another tricky aspect of MOQ that few people think about - the quantity step. The product is sold in at least ten pieces, but the change step is five. That is, you can order 10, 15, 20, 25 - but not 12 or 17. This is necessary for goods that are packaged in a certain way: ten pieces in a small package, five small packages in a box. The client can order one small package (minimum ten pieces), but can only add half packages at a time (five steps). It sounds like nerdy stuff, but for suppliers of fasteners, electronic components, or chemicals, it's an everyday reality. And when your online store understands this, the buyer on the client’s side thinks: “Oh, finally a store that is made for people, and not for show.”

MOQ works well with subaccounts and creates interesting scenarios. For example, the main account can set not only the maximum order amount for the subaccount, but also the minimum. For what? So that managers do not place micro-orders for three items, when it is more economically profitable to accumulate needs and order once a week. This is the internal optimization of the customer's purchasing process that you help as a supplier. And the client appreciates this because his own costs for processing incoming deliveries are reduced.

There is also an interesting point with the multiplicity of packaging, which is worth examining separately. Imagine: you sell motor oil. Retail - in liter canisters, one piece at a time. But you ship to a wholesale buyer in boxes of 12 canisters. If a B2B client wants 15 canisters, will you ship one box (12 pieces) and 3 more canisters in bulk? Most likely not - because bulk packaging takes longer, increases the risk of damage during transportation and complicates acceptance at the buyer's warehouse. The correct MOQ in this situation is 12 pieces in increments of 12. If you want 15, take 24. Or 12. But not 15. And your online store should understand this and display it correctly, and not force the buyer to guess why his order for 15 cans was returned with the comment “wrong quantity.” We implemented this by linking the MOQ and step to the product option - because the same oil can have a retail option (1 liter, no MOQ) and a wholesale option (1 liter, box of 12 pieces, MOQ = 12, step = 12). Different options - different rules. Sounds logical, but try to find this in standard WooCommerce.

Integrating MOQ with purchase lists also provides unobvious benefits. When a manager adds a product to a purchasing list, the system automatically enters the minimum quantity. If the multiplicity step is 12, and the manager wrote “10”, the system will offer to adjust to 12 with an explanation why. This happens at the list building stage, not at the checkout stage. The difference is huge: it’s one thing to find out about a problem when you’ve already spent twenty minutes assembling your cart, and quite another thing when the system prompts you for the correct quantity at the time you add an item. A little thing that saves nerves and time. In general, we tried to “shift to the left” all checks as much as possible - so that errors were caught as early as possible, and not at the time of placing the order.

Another aspect that we added at the request of clients is analytics for subaccounts. The main account sees not just the order history of each manager, but summary analytics: who ordered how much per month, what percentage of the budget was spent, what categories of goods were purchased, how many orders were rejected upon approval. This gives the head of the procurement department a control tool that he did not have before - or did, but in the form of an Excel spreadsheet that someone filled out manually once a week. Now information is available in real time, right in your personal account. And this is not only control - it is an opportunity for optimization. If the boss sees that manager Sidorov regularly orders small quantities with an interval of three days, you can talk and agree on consolidating orders, saving on delivery. If Petrov's manager uses only 40 percent of his budget, the limits can be redistributed. Data is always better than intuition. And for the store owner, this analytics is also valuable - you see how your client’s purchases are structured, and you can offer solutions that he himself has not yet thought about.

True story: a factory with twelve buyers

I've already mentioned this plant, but let's take a closer look at its history because it perfectly illustrates how all these modules work together. This is a machine-building enterprise in the Chelyabinsk region, about 800 employees, the annual volume of purchases of consumables and components is about 120 million rubles. Not a giant, but not a small company either. Supply department - 12 people plus the chief.

Before implementing our solution, the purchasing process looked like this: a manager receives a request from production, searches for goods on suppliers’ websites, calls or writes an email, agrees on a price, receives an invoice, brings the invoice for signature, sends payment, waits for delivery. One order – from two to four hours of manager’s work. However, six of the twelve managers regularly purchased industrial lubricants from the same supplier, but did so independently of each other. Result? Three deliveries a week from one supplier, each with its own transportation costs, its own set of documents, and its own acceptance at the warehouse. Because managers did not coordinate orders.

We have configured the system as follows. We created a main account for the head of the supply department and twelve subaccounts - one for each manager. We distributed access by category: each manager sees only his own areas. We set limits: an order up to 30 thousand is processed automatically, from 30 to 100 - confirmation by the head of the department, over 100 - additional approval. We created six purchasing sheets for regular orders - one for each direction. We set up the MOQ by category: minimum order of lubricants - 10 thousand rubles, fasteners - 5 thousand, electrics - 15 thousand.

The first two weeks were adaptation weeks - managers got used to the new process. Some grumbled that “it used to be easier to call.” But by the end of the first month the picture had changed radically. The average processing time for one order has been reduced from three hours to forty minutes. The number of deliveries from one supplier decreased from three per week to one - because the head of the department now saw all orders in one place and could consolidate shipments. Errors in orders (wrong item, wrong quantity) were reduced by 70 percent - because managers used purchasing sheets instead of searching for items again each time. And savings on transport in the first quarter amounted to about 180 thousand rubles - simply by combining small orders into large ones.

But the most interesting thing happened three months later. The head of the supply department came with an unexpected request: “Is it possible to give limited access to our account to the workshop foremen? They know better what is ending and can generate applications directly.” We created five more sub-accounts with minimal rights - craftsmen could only view the catalog and add products to a special purchasing list “Requests from workshops”. They could not place an order - this was done by the manager of the corresponding direction, who checked the application and turned it into an order. The result is a three-stage model: the master creates a need - the manager checks and orders - the boss confirms large orders. And all this within one online store interface, without additional systems, without Excel tables with applications, without WhatsApp groups.

Six months later, the supplier (owner of the online store) shared figures with me: the volume of orders from this plant increased by 34 percent. Not because the plant began to produce more, but because previously part of the purchases “flowed” to other suppliers due to the inconvenience of registration. The manager couldn’t quickly find the desired position on the website - he called a manager he knew at a competitor. Now all the necessary items are saved in the purchasing lists, prices are fixed for the B2B group, registration takes a minute. Why look for an alternative if everything works here? Here is the ROI from subaccounts - measurable, specific, in rubles.

Technical subtleties and pitfalls

It would be dishonest to talk only about the successes and remain silent about the problems we faced. Developing the subaccount module turned out to be more difficult than we expected, and here's why.

The first problem is caching. WordPress and WooCommerce actively cache user data, and when you start filtering a directory by subaccount permissions, the cache becomes your enemy. If subaccount A only sees the Fasteners category, and subaccount B only sees Electrical, they cannot be allowed to see a cached version of each other's catalog. We solved this through unique cache keys tied to the subaccount rights hash. This increases memory consumption but guarantees correctness. On a project with an active Redis cache (like our client in production with 16 thousand products), this required fine-tuning TTL and invalidation, but in the end it works stably.

The second problem is notifications. When a subaccount places an order, who should receive the email? The subaccount itself? Main account? Both? And if the order requires confirmation, do we send a notification to the subaccount that the order is “on pause”? And when the main account confirms, does the subaccount need to be notified? Each of these scenarios is a separate email notification that needs to be developed, executed and tested. We implemented six different notifications for sub-accounts and gave the main account the ability to turn each of them on or off. Because some people need all notifications, while others want to receive only confirmations of large orders.

The third problem is password recovery. If a subaccount forgot its password, who resets it? In standard WordPress - the user himself, via email. But in a corporate environment, it often happens that the email of a subaccount is a general department mailbox or not an email at all, but a phone number. We have added the ability for the main account to reset passwords for subaccounts from your personal account - without the participation of the store administrator and without email confirmation. Because when the head of the supply department has a new employee and needs access right now, waiting for an email to arrive with a link to reset the password is unacceptable.

The fourth problem is deleting subaccounts. The manager quit - his subaccount needs to be deactivated. But he has an order history that is linked to his account. If you delete a WordPress user, you will lose your history. We made a “soft deletion”: the subaccount is deactivated, you cannot log in under it, but the entire history is saved and remains visible to the main account. If after six months you need to restore access (a new person has come to the same position), you can reactivate the account with a new password. It’s a small thing, but in a corporate environment it’s an important little thing.

The fifth problem that I don’t want to think about at all is multicurrency. If the subaccount is located in another country and sees prices in another currency, how does this fit in with the limits that are set in rubles? We made a decision: all limits are stored in the base currency of the store, conversion is automatic at the current rate. This is not a perfect solution (the rate may change between the time the limit is checked and the time of payment), but it works fine for most scenarios. Clients who need strict multi-currency logic use fixed prices through B2B groups, where the price is set in a specific currency - and then the conversion problem simply does not arise.

I’m telling you about all this not to scare, but to show that a corporate B2B module cannot be done “over the weekend.” Each of these problems is the result of real use by real customers. And every decision is the result of discussions, testing, errors and improvements. When we say that our subaccount module is ready for industrial use, we mean that thousands of orders from dozens of companies have already gone through it, and we know where the mistakes were and how we got around them.

In general, if you think more broadly, this whole story with subaccounts, purchasing lists and MOQs is about one simple idea. An online store for B2B is not a catalog with prices. This is the buyer's workplace. Like CRM is a seller’s workplace, like 1C is an accountant’s workplace. Each workplace has its own tools, its own settings, and its own access rights. And the better your store copes with the role of a workplace, the more closely the client is attached to you. Not with discounts and promotions, but with convenience and habit.

I see how B2B commerce in RuNet is slowly but surely moving in this direction. Large companies are no longer ready to put up with a retail interface and a common account for the entire department. They want a tool that will integrate into their business processes - with an access hierarchy, budget control, and routine automation. And those stores that give them this tool first will receive a competitive advantage that cannot be overcome by a three percent discount. Because retraining twelve managers anew, setting up rights, and re-creating purchasing lists is a serious switching threshold. The one who set it up first is the one who keeps the client.

We continue to develop the subaccounts and purchasing lists module in COS WP Woo. The next big step is integration with client-side budgeting systems and automatic scheduled purchases (when the purchase list turns into an order once a week without manual participation). But this is a topic for another discussion. In the meantime, if you have a WooCommerce store with B2B clients and you still give them one login per company, it’s time to think about it. Not because it’s fashionable, but because your competitors are already thinking about it. And twelve managers who are accustomed to working through a convenient personal account will not go to someone who offers them a price half a percent lower, but will force them to call again and dictate orders over the phone.

Try COS WP Woo - and give your B2B clients the tool they deserve. The subaccount module, purchase lists and MOQ are already ready, tested on real projects and are waiting for you. Install the plugin, set up a B2B group for your first corporate client, create subaccounts for him - and see how the order dynamics change in just a month.