What Your Customer Portal Should Show First

A customer portal should begin with the information and actions most relevant to the person using it. Displaying every internal capability can create a busy interface without helping customers achieve their purpose. The first view should clarify their current position, any action required, and how to continue or obtain assistance.

Prioritize the customer's reason for arriving

Use actual enquiries and observed tasks to identify common needs. A hypothetical commercial printing company may find that customers visit to check proof approval, delivery status, or outstanding payment. Those needs should shape the first view more directly than the company's internal department structure.

Distinguish frequent needs from important exceptions. A rarely used action, such as reporting an incorrect delivery address, may still deserve a clear route because its consequence is significant. Frequency alone should not determine what is visible.

The GOV.UK guidance on mapping a user's whole problem emphasizes understanding the wider journey. For a portal, this means asking what the customer is trying to achieve before and after visiting, rather than designing only around the records the business happens to store.

Make outstanding actions unmistakable

If the customer must approve a proof before production can begin, show the required action with enough context to make an informed decision. Include the relevant order, current version, and what approval means. A general notification count does not explain the commercial consequence.

Separate action required from information only. The customer should not have to inspect every item to discover whether they must respond. Equally, do not make every routine update appear urgent, because that can weaken the meaning of genuine requests.

Explain what follows completion. A customer approving a proof should understand whether production is now scheduled or whether another step remains. The portal and any confirmation message must reflect the same process.

Show status without exposing internal complexity

Use terms the customer understands and explain important qualifications. A status such as queued may be familiar to staff but unclear to the buyer. The relevant information may be that artwork is accepted and production is scheduled, with a date only where the business can support it.

Identify when information was updated if timing affects reliance. If delivery status comes from another provider and may be delayed, the company should understand that limitation and communicate it appropriately. A visible figure is not evidence that it is current.

Avoid presenting staff-only notes or functions merely because they are available. Customer access should reflect the information and authority appropriate to the role. A portal is a service boundary, not an unrestricted window into the company's internal system.

Keep the first view manageable

Group information around tasks and give less frequent functions a discoverable place. Do not require customers to understand several menus before finding an active order. Review wording, arrangement, and navigation with likely users rather than relying on an owner's familiarity with the business.

Test on relevant devices, including a phone where customers use one. Check whether the most important status and action remain understandable without excessive searching or horizontal scrolling. A design that works on a large office screen may not serve customers checking an order while travelling.

Consider the customer's history. A first-time user may need guidance to reach the first useful task, while a returning customer may need immediate access to current work. The starting experience should support both without forcing experienced users through a repeated tour.

Adapt the portal around business value with Holism

Holism combines AI-assisted development with a Software Product Line foundation and a human developer. Suitable reusable capabilities provide a starting point for records, actions, and access; AI supports implementation and iteration; the developer evaluates the business-specific journey and technical choices.

The owner contributes knowledge of customer priorities and the commercial meaning of statuses. This avoids making the owner an engineer while ensuring that the portal reflects the actual service promise. Reuse should support coherent behavior, not determine the first screen regardless of customer needs.

Evaluate the result through important task completion and support questions. A useful first view helps customers understand their situation and act confidently. The number of available functions matters less than whether the information shown first supports that outcome.