One platform, three completely different buyers.
Most ecommerce stories start with a shopper browsing a catalogue. V-ZUG's doesn't. Behind the brand sit three very different people placing orders, and none of them buys the way a normal customer does.
Three buyers who don't buy the same way
The first is an internal technician fixing an appliance under warranty. They know the exact part, and they don't pay for it. The order is a stock transfer inside SAP, not a sale.
The second is an external agent - an independent technician or retailer who buys parts at trade pricing and then invoices the end customer. Their order is a sales order, priced and routed differently from the technician's.
The third is V-ZUG's own service team, placing orders on behalf of walk-in and phone customers. They look the customer up in SAP, create the record if it is new, take card payment, and ship direct.
This is B2B and B2C running on one system. Same products, often the same screen, but three different ways of buying, each with its own customer-group pricing, payment rules and permissions. The usual way to handle that is to stand up three systems, or bend one system until it cracks. V-ZUG runs all three on one.
One system that models the operation
On Core dna, the login decides everything that follows. Which checkout a person sees, which price list applies, which payment options appear and which products are visible all key off the user group.
Internal technicians see stock transfers. External agents see trade pricing and pay on account. The service team sees retail pricing, card payment, and a customer lookup step the others never touch.
Group-based pricing means the same part can carry a trade price for an agent and a retail price for a service order, with no second store and no duplicated catalogue. Products a given group should not see are simply hidden from that group.
This is what it looks like when a platform models the business instead of forcing the business into pages, posts and products. V-ZUG's operation has technicians, agents and a service desk, so the platform has technicians, agents and a service desk.
The hard part happens in SAP, under control
The reason this is difficult has nothing to do with the storefront. It is what has to happen behind it, in the ERP.
When the service team places an order, Core dna queries SAP to find the customer by email or phone, creates the record if they are new, builds the sales order with the correct state-based routing, reserves inventory, and hands the order off to third-party logistics. That is a multi-step SAP workflow. To the person placing the order, it is a short checkout.
The result V-ZUG reports: a sales order that used to take around 15 minutes to raise by hand now takes a couple of minutes. The platform does the heavy lifting, and the team does the order.
None of that automation runs unsupervised. A back-order example shows the shape of it. Specific agents carry an ignore-stock permission that lets them check out parts that are out of stock. The system creates the sales order, but holds release until the stock checks actually pass. The order moves on its own up to the point where a control says wait.
Receiving a container, without a day of data entry
The clearest before-and-after is not on the storefront at all. It is in the warehouse.
When a shipment of appliances arrives, every unit carries a unique serial number, delivered as a spreadsheet. Matching each serial to the right line on a purchase order - dishwashers to dishwashers, dryers to dryers - used to be a long stretch of manual entry.
Core dna takes a paste of that spreadsheet, writes each serial where it belongs, builds the invoice, and links it line by line back to the purchase order in SAP. Hours of entry become a paste and a click. The data still lands exactly where the ERP expects it. A person just stops being the one keying it in.
What the V-ZUG story actually shows
It is tempting to read this as an ecommerce build. It is not. V-ZUG's portal is an operations system that happens to have a checkout on the front of it.
Three buyer types, three pricing models, three payment paths, one deep SAP integration doing the work underneath, and a small team running all of it. That pattern shows up wherever B2B and B2C, customer-specific pricing and ERP-deep order flows meet on one system: the complexity is not in selling, it is in everything that has to be true in the systems of record before and after the sale.
Put that on one governed platform, and a lean team can run what used to need more people and more systems than anyone wanted to maintain.
