01 / PORTAL PLANNING
Decide what
belongs together.
Define the purpose, participants, and boundaries of a shared client space before choosing its features.
Start with one recurring exchange
A useful portal begins with a recognizable reason to return. That might be checking a service request, reviewing a document, or supplying information that a team needs to continue. “Give clients an account” is not yet a purpose; it describes a mechanism without the task.
Planning identifies the recurring exchange, the people involved, and the point at which a shared screen would be more useful than another email. The result should make it possible to explain the portal in ordinary language, with a clear reason for each proposed area.
Map the experience on both sides
A client sees a request to provide something. A coordinator sees an item that needs a response. Those views concern the same exchange, but they need different context. Mapping both sides helps reveal missing ownership, ambiguous wording, and actions that create work without a receiving team.
An initial map can cover entry, orientation, action, acknowledgement, and return. It should also include an ordinary failure: a missing attachment, an expired invitation, or a request that cannot be completed online. Each exception needs a recoverable path.
Set the boundary with existing systems
Some information belongs in a billing system, some in a document store, and some in the portal itself. Planning establishes the source for each important fact and how changes move between systems. A duplicate field is a future reconciliation problem unless there is a reason to keep it.
Integration scope should distinguish live connections from scheduled imports and manual updates. That distinction affects what the interface can honestly say about freshness. A portal should not imply that a status is immediate when it is updated only after staff review.
Turn the map into a release brief
A planning deliverable can include a journey map, a screen inventory, an information ownership table, and a list of decisions that require confirmation. The release brief then describes a small complete journey, the conditions for accepting it, and the person responsible for operating it.
This stage does not require pretending that every future requirement is known. It does require a shared understanding of what the first release will do, what it depends on, and which situations should route to a person instead of an automated step.