Sector · Industry & technical trade

Industry and technical trade — shops and websites for products that need explaining

Industrial valves, irrigation technology, rubber and plastic parts, shelving systems, glass cut to size: in these companies the order is not won by the product photo. It is won when a buyer can find the right component again without any doubt and order it at their own agreed terms. We build the shops, websites and interfaces for that — new builds on Shopware 6, TYPO3 or WordPress, configurators as custom development; existing Magento installations we continue to maintain instead of replacing them without reason. Six companies from industry and technical trade use these systems in daily business, and the connection to external procurement systems via OCI is running in a seventh project.

What sets this market apart technically

The part number is the most important search route

Anyone who buys in technical trade knows their component. They type a part number, a short designation or a combination of nominal diameter and pressure rating — not a product name. A search that cannot cope with hyphens, spaces and typing errors in part numbers is worthless in daily use, even if the menu looks tidy. At M&S Armaturen the search therefore uses an index that also matches part numbers and short designations correctly. In technical trade the search is the primary navigation and the menu is the second route. Compared with consumer business this order is reversed — and with it the question of where the work in a project actually sits.

Attributes belong in the data model, not in the product text

Material, standard, nominal diameter, pressure rating, hardness, approval: these values decide whether a part fits. If they sit as running text in the product description, they are readable for a person and invisible to the filter. At M&S Armaturen nominal diameter, pressure rating and material are modelled as filterable attributes, although the range also differs in connection type and sealing — which attributes belong in the filter and which in the product description is a decision made for each range. At Manotura the attribute model of the Magento shop covers the technical characteristics that decide the selection: nominal diameters, connection threads, pressure ratings, flow rates and sprinkler ranges. The difference only becomes visible when the range grows: a clean attribute structure carries over to new product groups, while a text-based solution has to be tidied up every time.

OCI is a condition of the order, not an extra feature

When a major customer runs procurement through SAP, Onventis, Ariba or Coupa, a punch-out connection is often the precondition for being listed at all. That requirement does not appear in the specification for the shop, but in the tender. The buyer jumps from their procurement system into your shop, assembles the basket and transfers it back in a structured format; the order is placed in the customer's system, with the customer's approval process. We implemented this in the Shopware shop of Lijnco (bank-formular.de), where buyers from the banking sector order directly out of their procurement system through an OCI plugin. The effort there lies less in the jump out than in the transfer back and in the sign-off by the e-procurement team on the other side. Anyone who discovers this only after promising a delivery date has a scheduling problem.

Not every range belongs in a shopping basket

Shelving systems are selected by load capacity, height, stored goods and available floor space — that is a consultation, not a checkout. Seals and moulded parts are quoted by material, dimension and quantity. Glass is made to measure and has no price before it is configured. In these cases the product is not the basket but the enquiry flow or the configurator. At FRANKSA the flow asks for material, dimensions, version and quantity and assigns the enquiry to the product group instead of offering a general contact form. Sales then receive enquiries they can work with immediately.

B2B is not D2C with a login

The sentence sounds like an agency formula, but it has very concrete consequences. In technical trade the price is not a property of the article but a property of the business relationship: customer-specific terms, tiered prices, framework agreements, net prices, ordering on account. A shop that shows a list price while sales have agreed a different price produces exactly the result that makes it redundant: the buyer calls, clarifies the price and then orders by email again. That is why pricing logic in these projects is not a configuration step at the end but one of the first questions in the concept.

The second difference concerns roles. The person who orders is often not the person who decides. There are head offices and branches under one customer account, several buyers per site, budget limits and approval processes in which an order only goes out after internal sign-off. Anyone who does not model this chain forces the customer into a detour — and detours in procurement end in the old process. One thing belongs before the quotation rather than in the middle of the project: customer groups, customer-specific prices and tiered prices come with Shopware 6 in the open core, while customer hierarchies with head office and branches, order approvals and budgets are delivered by Shopware as B2B Components in the paid plans, or we build them as our own plugin. Which route is cheaper, we calculate beforehand.

And third, the entry point is different. The buyer is not looking for inspiration, they are looking for a repeat purchase. They ordered the part three months ago and want to reorder it without searching. Order history, reordering from a past order, saved lists for recurring items: in B2B these are not convenience features but the actual value. At M&S Armaturen exactly this shift was the goal of the project — recurring procurement runs through the shop, while enquiries that need engineering support still go to the sales team.

The attributes people actually search by

A filter that cannot handle material, nominal diameter and pressure rating is not a filter in technical trade. The attributes have to sit in the data model as separate fields, with defined values and units, not as a sentence in the description text. This sounds obvious and is not: data taken over from legacy systems regularly delivers these values as a block of text, because they were never needed in any other form there. Modelling these attributes is a separate work step in projects of this kind, and often the one that decides the quality of the result — not the frontend design.

Then there is the search. It has to match part numbers with special characters, know short designations and cope with incomplete input. In the Magento shop of Manotura the product search therefore runs through Elasticsearch and not through a database query. At M&S Armaturen the search likewise uses an index that includes part numbers and short designations. The difference is measurable in operation by one simple figure: how often a search ends without a result although the article is in the catalogue.

The documents are part of the data model as well. Data sheets, dimensional drawings, material specifications, standards and approvals belong to the article, not in a folder next to the catalogue. Anyone looking for an approval is looking for it in relation to a component. And they rarely arrive through the home page: industrial procurement enters directly on the product or material page from a search engine. At FRANKSA the site is designed for exactly that — individually addressable product and material pages with a flat click structure, instead of a range hidden behind a layer of generic terms. How closely document and article need to be linked depends on the case: in a shop catalogue the data sheet belongs to the article record; on a website such as the one for Manotura, download areas at product group level are the more pragmatic form, because there the editorial team maintains the content and not the interface.

The ERP leads, the shop follows

Inventory, prices and customer terms sit in the ERP. The shop is a display and ordering channel, not the owner of the data. This division of roles sounds trivial but is frequently broken — usually because in the early phase a price list is quicker to maintain in the shop than in the ERP. After that there are two versions of the truth, and the difference between them creates rework for the sales team. At M&S Armaturen and at Manotura it therefore runs in both directions in a defined way: product master data, prices and availability come from the leading system into the shop, and orders go back the other way in a structured form instead of landing as an email in an inbox.

The quality of such an integration is not decided by the data format but by the behaviour when something fails. A synchronisation will break at some point — because of a network outage, a locked record, a field that is suddenly empty in the ERP. We therefore build the transfers as repeatable jobs with a log for each run and with retry logic, so that an interrupted synchronisation restarts without damaging data and a single failure does not block the whole synchronisation. How that looks in detail is described on our page about interface and API development.

The reverse also applies: not everything belongs in the ERP. Marketing texts, images in several resolutions, translations, accessory and alternative references are usually out of place there. Either a PIM or the shop itself is responsible for those. Drawing this line early is cheaper than correcting it later — otherwise the ERP becomes an editorial system and every text change needs an ERP account. Where the line runs depends on the company, and it is a question we clarify before the quotation, not after.

When the customer's procurement department dictates the ordering system

OCI stands for Open Catalog Interface, a standard for electronic procurement established by SAP. Systems such as Ariba or Coupa work with cXML PunchOut instead — technically different, in principle the same. In both cases the sequence is: jump out of the procurement system into your shop, assemble the basket at the customer's terms, transfer it back in a structured format. The advantage over a static catalogue file is that prices and range are maintained in one place: in your shop. No catalogue export, no version that goes out of date at the customer's end.

The Shopware shop of Lijnco for forms and print solutions in the banking sector shows what this looks like in practice. The buyer starts in their procurement system, is logged in to the shop by punch-out with the credentials passed across, and sees the range released for them at the prices that apply to them. The completed basket does not trigger an order but goes back in the OCI field format to the hook URL of the procurement system — with part number, description, quantity, price and unit. The punch-out standard OCI 4.0 is supported there. Every integration is tested against the specific customer system, because field usage, character sets and return methods differ in practice.

So the actual work lies in the transfer back and in the coordination. Every procurement system expects the basket in a particular structure — material numbers, product groups, units of measure, sometimes classifications such as eCl@ss. The integration is only finished when your customer's e-procurement team has signed it off. For practice this means two things: an existing shop is made punch-out capable, and no second shop is needed for procurement. And one shop can serve many major customers — with a clean implementation the second customer is configuration, not a new project. Details on this on our service page about OCI and punch-out.

Shop, website and enquiry flow are three different tasks

Many companies in this sector run their shop and their corporate website separately, and that is usually a correct decision, not accumulated disorder. M&S Armaturen runs a B2B shop on Shopware 6 and the corporate website on TYPO3. Manotura operates the Magento shop and the trade website on TYPO3 as two systems. The reasons are practical: different audiences, different maintenance rhythms, different release cycles. A Shopware update should not touch the careers page, and an editorial team that maintains sustainability and careers content should not have to work in a shop backend to do so. Editorially the two sites refer to each other; technically they stay decoupled.

Where no basket makes sense at all, the project shifts to opening up the range and to the enquiry. At Wehry Regale — WordPress with a custom theme instead of a page builder — the selection depends on load capacity, height, stored goods and floor space; people who search usually know what they want to store, but not what the suitable design is called. The task of the site is then to sort the variants understandably and to keep the path to the enquiry short. At Littwin Systemtechnik, also WordPress with a lean theme instead of a stack of plugins, the point is to explain the range of services and the reference projects with technical depth, because enquiries only start when a prospect sees that someone knows their sector.

Between catalogue and enquiry sit the made-to-measure products. At Max Glas the price only comes into being once dimensions, glass type, thickness, edge finishing and fittings are defined — before that there is at best a range. The configurator there is a custom development and takes on the task that a sales conversation would have in a shop: guiding the user, limiting the permitted combinations, catching impossible input. The rule and price calculation runs on the server so that it cannot be manipulated in the browser, and the shipping logic distinguishes parcel from freight, because a large-format pane is not a parcel. With cut glass, errors that only show up in production cannot be corrected.

What applies to all three cases: which one fits you, we say before the quotation. If a shop does not justify the effort in your case — because the range needs too much consultation, or because the data in the ERP is not yet good enough — we say so and propose the smaller step.

Frequently asked questions

Why is a B2B shop more work than a shop for consumers?

Not because of the number of articles, but because of the logic behind them. In B2B the price is a property of the customer relationship: individual terms, tiered prices, framework agreements, net prices, purchase on account. On top of that come customer hierarchies with head office and branches, several buyers per account, budget limits and approval processes. And the data for all of this sits in the ERP, not in the shop. Volume is the smaller factor: the catalogue at M&S Armaturen holds more than 10,000 article and variant combinations, and Manotura has more than 12,000 synchronised articles — the work still lies in pricing logic, attribute model and interface.

Does the search have to find our part numbers?

Yes, and in technical trade that is the single most important requirement for the frontend. Buyers search with part numbers, short designations or attribute combinations such as nominal diameter and pressure rating. The search has to cope with hyphens, spaces and shortened input. We implement this with a search index instead of a database query — at M&S Armaturen with an index that includes part numbers and short designations, in the Magento shop of Manotura with Elasticsearch. You can check it against one simple figure in operation: how often a search ends without a result although the article is in the catalogue.

Shopware or Magento for technical trade?

For a new build, Shopware 6 is our main system. It is built on Symfony, is widely used in German-speaking B2B and brings part of the pricing logic in the open core with customer groups, customer-specific prices, tiered prices and the rule builder; that is the basis in the shop of M&S Armaturen. We look after Magento where it is running for historical reasons and doing its job — for example in the shop of Manotura. In that case we do not recommend a migration just because another system sounds more modern: a stable, well-maintained Magento shop with a lot of custom logic is no reason for a rebuild project. As soon as running costs and benefit drift apart, we say so and calculate the change before you place the order.

Do we need a PIM or is the ERP enough?

That depends on how many channels you serve and how much maintenance work is attached to the product data. Inventory, prices and customer terms belong in the ERP — that is where they are managed. Description texts, images in several resolutions, translations, accessory and alternative references usually do not belong there. With one shop and a manageable amount of text, the shop can take on that role as well. If shop, website, catalogue and punch-out access all need the same data, there is a strong case for a PIM — whether it pays off depends on the number of channels and on the maintenance effort, and it is a calculation we make before the quotation, not during the project.

Our major customer requires an OCI integration. What does that mean for us?

Your customer no longer wants to order in your shop, but out of their own procurement system. You need neither a second shop nor a catalogue file for that — your existing shop is made punch-out capable. The buyer jumps from SAP, Onventis, Ariba or Coupa into your shop, sees their terms and transfers the basket back in a structured format; the order is placed in the customer's system. This is implemented at Lijnco, where the basket goes back in the OCI field format to the hook URL of the procurement system. We clarify the field specification directly with your customer's IT department and run test transfers through to sign-off. Call us before you promise a date: the sign-off on the customer side determines the schedule, not the development.

Can we run shop and website in one system?

Technically yes, but often it does not make sense. At M&S Armaturen the B2B shop runs on Shopware 6 and the corporate website on TYPO3; at Manotura the shop runs on Magento and the trade website on TYPO3. The separation has practical reasons: different audiences, different maintenance rhythms, different release cycles. A shop update should not touch the careers page, and an editorial team that maintains corporate content should not have to work in the shop backend. Editorially both sites refer to each other. Where one system is enough — a small range, a small editorial team — we recommend that too.

How do prices and stock levels get into the shop?

Through an interface to the leading system, usually the ERP. Product master data, prices and availability run from there into the shop, and orders go back in a structured form. More important than the format is the behaviour when something fails: we build the transfers as repeatable jobs that log every run and have retry logic, so that an interrupted synchronisation restarts without damaging data and a single failure does not block the whole synchronisation. How often the data is synchronised depends on the business — more often with fast-moving inventory than with stable catalogues.

We sell through enquiries and consultation, not through a shopping basket. Is a website still worth it?

As a rule, more so than a shop. If the selection depends on load capacity, material or engineering design, the task of the site is to organise the range understandably and to qualify the enquiry. At FRANKSA the enquiry flow asks for material, dimensions, version and quantity and assigns the enquiry to the product group instead of offering a general contact form. That saves the sales team the chain of follow-up questions that precedes every quotation. At Wehry Regale the site organises shelving types and application areas as their own content structure, because prospects know what they want to store but not what the design is called.

Can you build configurators for made-to-measure products?

Yes. At Max Glas glass showers, glass doors and kitchen splashbacks are configured through dimensions, glass type, thickness, edge finishing and fittings; the price comes out of these parameters and not from a stored fixed price. Minimum and maximum dimensions as well as impermissible combinations are checked as the values are entered. The calculation runs on the server so that it cannot be manipulated in the browser, and the shipping logic distinguishes parcel from freight. The decisive point with made-to-measure products: an error that only shows up in production can no longer be corrected once the material is cut.

What happens to our data sheets, standards and approvals?

They belong to the article, not in a storage area next to the catalogue. Anyone looking for an approval or a dimensional drawing is looking for it in relation to a specific component, and they often arrive from a search engine directly on the product page rather than through the home page. In a shop we therefore model documents as part of the article record and deliver them on the detail page. For pure websites the smaller form is often enough: at Manotura, download areas for data sheets are a fixed content element at product group level, because the editorial team maintains them there. If data sheets sit in the ERP or in a file management system, transferring them becomes part of the interface — not a recurring manual step.

We already have a shop, built by another agency. Will you take it over?

Yes, that is the more common case. We start with a survey: version levels, custom developments, the plugins and extensions in place, changes to the core, how the interfaces to the ERP are built and how much of it is documented. From that comes an assessment of whether further development, an update or a rebuild is the cheaper route. You get that assessment before you place an order. If the existing system is sound and only needs maintenance, we say that too — a relaunch that does not pay off is a bad project for both sides.

What does a B2B shop for a technical range cost?

That depends on three things: the state of the data in the leading system, the number of different pricing and approval rules, and how many attributes have to be modelled properly. A large catalogue with one uniform pricing model can be cheaper than a small one with customer-specific tiered prices and several punch-out connections. After a first conversation and a look at your product data you receive an estimate with clearly separated items. We do not quote flat rates — in this sector they reliably hide the extra charges that follow.

How quickly do you respond when the shop is part of daily business?

With a service level agreement according to the level you book: BASIC 24 hours, STANDARD 8 hours, ADVANCED 4 hours, PREMIUM 2 hours response time, billed as a monthly flat fee, net, per project. For shops with ongoing order volume and connected systems, ADVANCED is usually the right level. Without an agreement we work in order of arrival within 48 hours during business hours, Monday to Friday, 9:00 to 16:00. Operation and development sit in the same team here — whoever looks for the fault knows the code.

Show us your product data, not your design wish list.

One look at your product master data, your pricing logic and your ERP integration says more about the effort involved than any specification document. Call us — Mon–Fri 9:00–16:00, 0441 21 21 63 0. If a shop does not justify the effort in your case, we will say so in the first conversation.

Start a project 0441 21 21 63 0
Call Start a project