A first customer portal should support recurring tasks that customers can complete confidently and that your team can maintain reliably. Start with one bounded journey, such as viewing request status or supplying a requested document. Avoid moving every support interaction behind a login simply because a portal can contain many features.
The planning question is practical: what can the customer accomplish, what happens afterward, and where can they get help? Feature names such as “dashboard” or “self-service” are too broad to answer those questions.
Compare tasks before designing screens
Use this original matrix to assess candidate tasks. Frequency and effort are qualitative observations to verify with your own support records. The examples below are fictional and do not represent measured customer behaviour.
| Candidate task | Frequency and support effort | First-release decision |
|---|---|---|
| Check an open request's status | Recurring; staff repeat information | Consider if the source is current and understandable |
| Supply a requested file | Occasional; missing context causes rework | Consider with receipt and review states |
| Change a complex service scope | Variable; usually needs discussion | Offer a request route with human review |
| Browse general guidance | Recurring; low individual support effort | Keep public where no account is needed |
Add three questions for each row: who maintains the underlying information, what happens when it is wrong, and whether the customer needs an account for the task. A high-frequency task with unreliable source data is not automatically ready for self-service.
Work through one fictional journey
Imagine a small packaging-design business whose customers regularly ask which artwork version is under review. Its first portal journey lets a customer open a project, see the current review stage and submit a requested replacement file.
The screen should identify the project and file version in plain language. A successful upload changes the status to “File received, awaiting review.” It should not announce “Artwork approved,” because uploading and approving are separate actions.
If the file cannot be processed, the customer sees a clear explanation and a route to help. If staff request another version, the previous history remains understandable. The team agrees who updates the review stage so the customer is not left looking at a stale status.
Turn the journey into acceptance criteria
Write criteria as observable outcomes rather than visual preferences. For the fictional example, a reviewable first-release specification could say:
- A customer can identify the project and the currently requested file without contacting support
- After a successful upload, the customer sees the filename, receipt status and the next review step
- A failed upload does not appear as received; the customer can understand how to recover
- The customer can distinguish the latest submission from older versions
- A help route is available when the customer cannot complete the task
Test with synthetic projects and files. Ask someone who did not help design the screen to explain what they believe has happened. If their interpretation differs from the intended state, improve the wording before adding features.
Keep the forms understandable
W3C's forms guidance covers clear labels, instructions and feedback. Apply those principles to the portal's task screens: explain what is required, label controls meaningfully and make errors useful enough to correct.
For example, “Upload failed” does not tell a customer whether to choose another file or contact the team. The implementation should provide an appropriate explanation based on the actual failure. Do not invent a cause when the system cannot determine one.
Plan the work behind the screen
Self-service changes where work begins, but staff may still need to review submissions, resolve exceptions and maintain status information. Name those responsibilities before promising a faster process.
Decide what happens if a connected system stops updating. A visible “last updated” detail or temporary unavailable message may be more honest than showing old information as current. Define an alternative contact route for tasks that cannot wait.
Keep a short release boundary: the first customer group, task, records and outcomes covered. New audiences and unusual cases can be reviewed separately. For a scoped discussion, bring your matrix and acceptance criteria to Tralionex's web portal service.
Give every customer task a completion contract
A completion contract is a short description of what the customer can expect when a task succeeds. For the fictional file-submission journey, it says which file was received, which project it belongs to and what review happens next. It also states what has not happened yet, such as staff approval of the file's contents.
Write an equivalent description for each candidate task. A request for a change may be successfully submitted while the change itself is still awaiting review. A displayed status may be current only as of the last source update. These details belong in the journey specification before interface design, because they determine the words and evidence shown to customers.
Design for the customer who returns later
People may leave a task halfway through, switch devices or return after receiving an email. Decide what they should see when they come back. Can they tell whether their last action was completed? Is an unfinished draft distinguishable from a submitted request? Does the project still show the latest staff question?
In the fictional packaging example, a customer uploads a replacement file and returns the next morning. The project should make the latest submission and its review state recognisable. If the customer cannot distinguish that version from yesterday's file, they may upload it again or contact support to check. Record that scenario as a test case rather than treating it as a cosmetic detail.
Plan help at the point of confusion
A general contact page is useful, but task-specific help can explain the next step more clearly. Near the file submission area, explain which requested document belongs there and how to ask a question if the customer is unsure. Do not encourage uploading unrelated confidential material simply because an attachment field exists.
Keep public guidance accessible without an unnecessary account where appropriate. During website development planning, identify which instructions belong on public pages and which depend on a signed-in customer's records. This helps avoid copying the same guidance into several places that later drift apart.
Review support impact with actual observations
A self-service task can shift questions rather than remove them. Customers may stop asking for status but begin asking what a new status label means. Record the nature of support contacts during the pilot and compare them with the tasks the portal was intended to support. Avoid declaring success solely because people signed in.
For a small review, ask whether customers reached the correct task, understood its state and knew what to do if blocked. Ask staff whether the submitted information was sufficient and whether exceptions reached the right person. These are useful operational questions even before a larger measurement plan exists.
Common scope mistakes to catch early
Do not bundle viewing, requesting and approving into one vague “manage project” feature. They have different outcomes and may need different review steps. Avoid making customers responsible for correcting internal record problems they cannot understand. If the source is wrong, route that issue to a staff owner.
Finally, name a person who maintains help text and status definitions after launch. A portal is easier to operate when customers and staff continue using the same terms as the workflow evolves.
Frequently asked questions
Should every customer task require a login?
No. General guidance can often remain public. Use an account where the task genuinely involves customer-specific records or actions.
What is a sensible first portal feature?
A recurring, well-defined task with a reliable information source and a clear completion state. Status viewing is one possibility, not a universal answer.
Can a portal remove the need for support?
It still needs a help route and staff ownership of exceptions. Evaluate which routine questions it supports without promising support will disappear.
How do we know the first release is ready?
Test the agreed journeys, failure states and customer understanding. Completion requires the intended task to work, not merely the screens to look finished.
Plan your next project with Tralionex
Bring the customer-task matrix, a sample journey and your proposed completion criteria. Discuss a focused portal release with Tralionex, including the staff responsibilities and recovery routes that support the customer-facing screens.
