Customer portals

Some industrial companies in the German Mittelstand are already very advanced with their customer portals. Their portals have long gone beyond order functions and invoice archives: machine-specific spare parts search, where customers find the right parts directly via factory number or serial number – including exploded-view diagrams, technical documentation and real-time availability. 
Integrated performance dashboards that monitor machine fleets, control maintenance intervals and reduce unplanned downtime. 
Automatic document libraries that provide instruction manuals, certificates and wiring diagrams with machine precision. 
And increasingly AI-supported pricing, which automatically generates quotes based on material costs, market prices and customer history. 

The interesting thing: these companies didn't start with the big board. They started with core functions – often the spare parts catalogue or order history – and then expanded step by step, sprint by sprint, based on what their customers actually needed. 

The following customers of ours run digital customer portals: Liebherr, Wacker, WESSLING, KTR.

In almost every one of our portal projects, we encounter the same insight, and it's surprising every time:

The requirements that make the biggest difference don't come from the requirements catalogue. 

At a mechanical engineering company we did qualitative UX research during the conception phase and spoke with real end customers in in-depth interviews. What came out of it wasn't on the internal project team's radar: customers didn't primarily need a nicer ordering process. They needed a way to identify a spare part at two in the morning when a system is down – without knowing the article number, only the machine designation and a rough description of the component. 

At another industrial company, we went into the factory halls and spoke with the people at the machines. We had them show us how they work with the equipment, what typical support cases look like, and where they get stuck in everyday work. The findings were concrete and surprising: the existing portal was used almost exclusively by the purchasing department – the maintenance staff, who actually needed access to spare parts and documentation most urgently, had no login at all. Or didn't even know the portal existed. 

In a current project, we're conceiving a customer portal based on workshops, design sprints and customer research. The approach: before a single line of code is written, we understand who will actually use the portal and in which situations. That sounds obvious, but in practice it's the exception. 

Typical portal project dynamic looks like this: IT defines the technology, sales describes the functions, management approves the budget. What results works for the buyer placing orders during business hours, but not for the rest – maintenance staff, plant management, field service technicians. 

The reason is structural: Whoever isn't at the table won't appear in the portal.
And the people who need a customer portal most urgently are almost never at the table. The maintenance technician is in the hall at night, the plant manager has twelve sites and no cross-site reporting, the service technician needs mobile documentation on site. 

These requirements can't be derived from internal workshops. They become visible when you go out and ask: in in-depth interviews, by shadowing everyday work, in usability tests with real users. In our experience, this investment in customer research is the biggest lever for a portal project's success – not the technology decision, not the design, not the feature list, but understanding which problems the portal is actually meant to solve.

A customer portal doesn't unfold its value as an isolated application, but as part of a connected digital architecture. What matters is that CMS, CRM, ERP, PIM, SAP and other specialist systems work together cleanly. This way, marketing and sales content can be delivered directly from the CMS in the portal too – such as campaign content, product information, downloads or service information – without content having to be maintained twice.

This turns the customer portal into part of a digital experience platform: campaigns lead into relevant portal areas, sales and service work with consistent data, and customers experience a seamless journey – from first contact through advice and ordering to self-service.

The economic situation makes it harder for many industrial companies to justify large digital projects. Budgets are tightening, investments are scrutinised more closely. At the same time, customers' own expectations aren't changing: self-service, real-time information and mobile availability are already standard among the industry's frontrunners. 

The good news: you don't have to start with the big leap. In our projects, we regularly see that a focused MVP – digital spare parts catalogue, order history, technical documentation – can go live within three to six months. However, the architecture must be right from the start: modular, API-based, extensible. Anyone building a monolithic system today forfeits the ability to add IoT data, analytics dashboards or AI-driven services tomorrow without rebuilding everything. 

The integration strategy is also decisive. Almost every portal project in industry faces the same challenge: the data sits in SAP, in a PIM system, in the CRM, sometimes in Excel lists. Anyone who doesn't connect these systems properly ends up building a portal with outdated prices, incorrect availability and duplicate data maintenance. In our projects, we integrate SAP processes, ERP systems and sales tools such as Salesforce to establish exactly this connection. 

What is emerging goes beyond the portal. Industrial companies that lay the infrastructure today – modular architecture, clean data integration, real understanding of their users – can in the coming years add functions that are only now becoming possible: machine data that flows directly into the portal and indicates maintenance needs before a failure occurs. Automatic reordering based on consumption data instead of a calendar. AI agents that increasingly carry out service processes independently. Whoever architecturally prepares their portal for this does not need to graft these functions on afterwards. 

Whoever today only keeps procurement at the desk in view is building for a world that's currently changing. The investment in customer research and a well-thought-out technical foundation pays off not only in the first release – it decides whether the portal is still relevant in three years' time. 

At synaigy (interactive tools) we work on strategy, user experience, creation and technical implementation of customer portals. We connect third-party systems or existing services and develop new services together with our clients. We integrate SAP processes, ERP systems and sales tools such as Salesforce to drive automation forward and create genuine interlinking. 

Our approach always starts with the users: in customer research and ideation workshops, we identify the actual requirements – the visible and the overlooked. This produces viable concepts, which we test as MVPs in a protected environment and develop further in agile sprints. 

If you're thinking about a customer portal or want to further develop an existing one, get in touch – we often start with an ideation workshop, where we jointly define goals and develop initial concept sketches. 

What does a customer portal actually bring my B2B customers? 
Self-service round the clock: find and order spare parts, track orders, access technical documentation, check availability in real time. This reduces wait times and dependency on inside sales – for your customers and for your team. 

How long does it take to build a customer portal? 
A focused MVP with core features – spare parts catalogue, order history, documentation – can go live in three to six months. It's then extended iteratively, based on real user feedback and business requirements. 

What does a B2B customer portal cost? 
That depends heavily on scope. The architecture is decisive: those who build modularly and API-based can extend step by step, without rebuilding everything. 

Why is customer research important before the portal launch? 
Because internal requirement lists systematically overlook users who aren't sitting in the planning room – maintenance staff, service technicians, plant management. Interviews and shadowing in daily work reveal needs no brainstorm delivers. 

How do you integrate a portal with SAP and existing systems? 
Via APIs and a modular architecture. We integrate SAP processes, ERP systems and sales tools such as Salesforce to reflect real-time prices, availability and order status in the portal – without duplicate data maintenance. 

What if we already have a portal that isn't being used? 
Usually it's not down to the technology, but to relevance for users. A usability audit and conversations with real portal users quickly reveal where the gaps lie. Often targeted adjustments suffice to significantly boost usage.