Why do buyers get different answers from our website and sales team?

A complex portfolio does not need one undifferentiated journey for every visitor. Technical specialists and business decision-makers often need different levels of detail, language and framing before they can understand the same offering. Siemens Digital Industries Software faced this challenge with a broad, technically advanced portfolio: detailed documents could overwhelm non-technical readers, while simplified messaging risked understating the technology.

A layered content structure can provide accessible entry points around relevant challenges or themes, then let people choose between deeper technical material and executive-level summaries. This gives visitors control over the depth they need without forcing technical and commercial audiences through identical navigation. It also makes the relationship between portfolio areas clearer, because each route starts with relevance rather than an internal product structure.

Different answers from the website and sales team often begin with fragmented source material. Information may be written for a particular page, campaign or internal team rather than as a clear account of what the business does, how its offers relate and why they matter. A stronger content model treats each important idea as a distinct, evidenced unit connected through meaning, relationship and relevance.

That approach gives web, sales, product and technical teams a common basis for describing the portfolio. In its work with G42, messaging was harmonised across all ten companies in the group into one unified voice, while the experience connected technology enablers to industry contexts, solutions and outcomes. Consistency does not require removing depth. It requires shared concepts that can be expressed appropriately for different audiences and formats.

A portfolio structure should be judged by whether people can locate and understand the information they need, not only by whether the menu appears logical internally. Set realistic tasks for distinct audiences, such as finding a relevant business area, locating technical information, understanding a solution's relevance or reaching supporting documentation. Observe the first route people choose, where they hesitate and whether they complete the task.

Run the same task tests before and after a structural change so that results can be compared. Review outcomes by audience type rather than treating all visitors as one group. This is particularly important where a site serves technical specialists, commercial decision-makers, partners, investors and employees. Testing can reveal whether visitors are being sent through a route built around internal terminology instead of their own questions.

Portfolio clarity also depends on whether people can access the information once they find it. Inclusion should be addressed during design and development, rather than treated as a final compliance step. Designers and developers can identify issues early, including text contrast, behaviour across devices and support for different input methods such as mouse, touch and keyboard.

This matters for complex websites because the portfolio may extend beyond standard web pages into technical documents, investor material and interactive tools. A redesign that improves navigation on primary pages can still leave barriers elsewhere if accessibility is not considered across the wider content system. Involving development from the start helps identify what is practical to implement and reduces the risk of trying to retrofit inclusive design under deadline pressure.