A new portal needs an audience that can use it

A supplier can build a well-designed portal that its intended customer is not permitted or prepared to use. Before commissioning another account system, inspect the recipient’s accepted communication arrangement and the task the proposed portal is meant to improve.

The fictional case below concerns a supplier working with one institutional buyer. Its conclusion is specific to that relationship. It does not mean that customer workspaces are generally unnecessary or that a public link can replace controlled document exchange.

Establish the intended recipient’s constraints

The supplier proposes a portal for specification documents and project replies. The stated goal is to reduce confusion about which material the buyer has received and which question needs an answer. The team initially assumes that the buyer’s contact will create an account in the new portal.

The buyer’s approved procurement procedure requires these exchanges to remain in its existing procurement channel. Its designated recipient cannot create an external supplier-portal account for this work. The supplier confirms that this is an actual requirement for the relationship, not a guess about the recipient’s preferences.

The proposed portal therefore lacks a usable route to its intended audience. Improving its login screen or adding more notification emails would not change the buyer’s accepted process.

Inspect the channel already available

The team reviews the supported functions of the existing procurement channel in the agreed test arrangement. It permits the supplier to attach the relevant approved documents, identify the project reference and ask a clearly numbered question. The recipient can retrieve those materials and reply within the same authorised context.

The current confusion arises because the supplier’s messages use vague subjects and refer to “the attachment” when more than one document is present. The channel can carry clearer references; the team has not been using them consistently.

That evidence suggests a bounded improvement within the accepted route. It does not establish that the channel supports every future workflow, such as joint editing or an external system integration. Those needs remain separate questions.

Choose a structured exchange

The selected procedure identifies the project, the exact document reference and version, the question requiring a reply and the responsible recipient. The message distinguishes material supplied for information from a question requiring a decision.

In the fictional example, project P-72 sends approved specification S-21 version 2 and schedule C-14 version 1. Question Q-6 asks the recipient to confirm which of two permitted delivery windows should be considered next. It does not claim that a booking or commercial acceptance has already occurred.

The supplier uses the existing channel’s supported document and reply functions. It does not duplicate the buyer’s records into a separate portal solely to create another dashboard. The organisation also keeps its own appropriate record of the exchange under the agreed handling arrangements.

Verify the recipient’s task

In the controlled fixture, the designated recipient opens the project context, retrieves S-21 version 2 and C-14 version 1, and identifies Q-6 as the outstanding question. Their reply carries the project and question reference back to the supplier through the accepted channel.

The supplier can associate the reply with Q-6 without guessing from an email subject or a similarly named attachment. A reference to an older specification is recognised as older material rather than silently substituted for version 2. An unrelated project remains outside the recipient’s permitted context.

The completed comparison shows that the immediate exchange can be made usable within the approved route. It does not establish the final delivery decision or eliminate the need for the responsible person to review the reply.

Defer the portal for a stated reason

The selected decision is to improve the exchange procedure and defer the new portal. The reason is concrete: the intended recipient cannot use the proposed account channel, while the inspected existing channel can complete the immediate document-and-reply task.

The project note records what would justify reconsideration. A different customer group may accept external accounts, or the buyer may later approve another arrangement. A future requirement may also exceed the existing channel’s supported functions. Those changes would provide new evidence for a portal scope.

For now, commissioning the portal would create software without resolving its audience dependency. The workspace service can help evaluate that fit before building. Bring the recipient’s actual task, accepted channel and access constraints; a decision not to build is strongest when the alternative has been demonstrated rather than merely suggested.