Customer portal development: define a useful first version

Start with a repeated customer task

Choose a real workflow rather than a long wish list. Our example lets a customer see an approved project status and download the current document. Record how that works today and where clarification is needed. Check whether a portal is genuinely necessary or a better existing process would be enough.

• ›Which information is requested repeatedly?
• ›Who needs it and when?
• ›Who creates and updates it?
• ›What should the customer do independently?
• ›How will completion be visible?

Describe a small but complete first version

Our proposal covers one complete journey: receive access, find your own work, understand the information and take the next action. A few reliably maintained functions are easier to review than many unfinished menu items. Explicitly exclude later features such as invoice payments, live chat or additional user administration.

For each function, our brief records its trigger, displayed data, permitted action and outcome. For a document, ask who uploads it, how the current version is identified and who may download it. Those questions support scope estimation better than the general phrase document area.

Plan identity and access separately

OWASP distinguishes authentication from authorization. Successful sign-in does not mean someone can access every record. Permissions should be checked on every request and allow only the access required.

Our business test uses two separate customer accounts. Account A can see its own documents, not B's. Also check direct document addresses and the state after access is removed. The visible menu alone does not establish that data is correctly separated.

Name the maintenance owner and source of data

A status field needs a named source and owner. For manual updates, agree when the value changes. For information from another system, define delays and handling of failed transfers. Do not present apparently current information when the actual data state is unknown.

Accept the workflow with customers and staff

Test invitation, sign-in, own records, permitted actions, missing documents and revoked access. Have a future user complete the task without an explanation. The internal team then checks outcomes and ownership. Separate blocking defects from functions intentionally scheduled for later.

Observe operation and value after launch

Name owners for user questions, data maintenance and technical failures. Our measurement proposal tracks completed customer tasks and remaining clarification work. Fewer emails alone are incomplete evidence: check whether customers are instead stuck in a confusing portal. Use repeated questions to identify the next specific improvement.