CATAPULTAI WORK
Start a project

CRM, ERP & Operations

Customer Portal Features Checklist

A role-based customer portal checklist covering useful self-service, data boundaries, authentication, accessibility, integrations, and operations.

A portal is useful when it lets a customer finish something without another email exchange. Choose a few common requests and design the complete path, including what happens when information is missing or the customer needs help.

Choose features from customer journeys and support volume, then define permissions, source systems, accessibility, failure states, and ownership. A long feature list without these controls produces a fragile portal.

Related service: CRM, ERP & Web Application development
AT-A-GLANCE FLOWA safe portal request flow
  1. 01Authenticate the person at an appropriate assurance level.
  2. 02Resolve account membership and role.
  3. 03Authorize the requested action and record.
  4. 04Read or write through an approved system boundary.
  5. 05Confirm the result in plain language.
  6. 06Record security and business events.
  7. 07Provide recovery and human support when the task cannot finish.

SECTION 01

Choose features by customer job

Interview customers and support staff around the moments that create calls, emails, and uncertainty. Group requests into status, action, exchange, payment, administration, and help. Verify that the underlying system can supply accurate data before promising self-service.

The first release should complete a small number of journeys end to end. A customer who can start but not correct or track a request may create more support work than before.

Customer portal feature priority map
Customer jobFeatureRequired control
Know what is happeningOrder, project, case, or service statusVerified source and last-updated time
Ask for workStructured request and attachmentsValidation, confirmation, ownership, tracking
Exchange recordsDocuments, invoices, statementsAccount-level authorization and retention
Take actionApprove, reschedule, reorder, or payConsequential-action confirmation and audit
Manage accessInvite, role, remove userAuthorized account administrator and review
Get helpContextual knowledge and escalationConsistent support path and case handoff
Only include a feature when its data owner and operational response are defined.

SECTION 02

Identity, account, and permission checklist

Choose identity proofing and authentication from risk. A portal showing low-sensitivity status may differ from one exposing financial, health, or contractual records. Document enrollment, invitation, authenticator setup, recovery, reauthentication, account suspension, and deletion.

Account membership is separate from authentication. A valid user must still be authorized for the organization, location, project, invoice, or document requested. Test object-level and function-level permissions, including former employees and users with multiple accounts.

Identity lifecycle
Authorization

SECTION 03

Accessible forms, feedback, and recovery

Follow WCAG 2.2 across the complete process, not only individual screens. Use semantic controls, keyboard access, visible focus, labels and instructions, error identification, status messages, consistent help, and authentication that works with password managers and assistive technology.

Every action needs a clear pending, success, empty, validation, unavailable, and unexpected-error state. Preserve safe user input after a recoverable failure. Give confirmation references and next steps; never leave a spinner as the only evidence that a request may have completed.

SECTION 04

Connect without turning the portal into a shadow system

For each displayed or editable field, name the system of record, refresh target, validation, and write path. Some portal records may be native—such as preferences or draft requests—but operational status should come from the accountable system.

Use scoped service credentials, idempotent writes, correlation identifiers, retries, reconciliation, and an exception queue. Cache only when the freshness tradeoff is visible and acceptable. Do not report generated or inferred status as an operational fact.

Read boundary

Return only the fields the account and role may see.

Write boundary

Validate business rules again in the authoritative service.

Failure boundary

Distinguish rejected, pending, unavailable, and unknown outcomes.

Audit boundary

Connect customer action, integration work, and final system result.

SECTION 05

Launch and operate the portal

Test supported browsers and devices, assistive technology, realistic roles, concurrent use, uploads, rate limits, integration outages, recovery, and support handoff. Run a pilot with representative customers and support agents before wide access.

Monitor authentication failures, task completion, errors, queue age, search gaps, abandoned flows, support escalation, and permission incidents. Use findings to improve a defined journey rather than continuously adding modules.

Launch evidence
Ongoing ownership

SECTION 06

Frequently asked questions

What should a customer portal include first?

Start with one or two high-volume customer tasks that the underlying systems can support accurately, plus secure access, confirmation, recovery, and human escalation.

Is login enough to secure customer data?

No. Authentication identifies a user; the server must also authorize every requested organization, record, field, file, and action.

Should a portal copy CRM or ERP data?

Only with a documented reason. Prefer an explicit read or synchronization boundary with freshness, ownership, validation, reconciliation, and failure behavior.

How do you measure a customer portal?

Track completion and failure by journey, support escalation, queue age, search gaps, accessibility defects, permission incidents, and customer feedback—not logins alone.

PRIMARY REFERENCES

Sources and further reading

These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.

ABOUT THE AUTHOR

Catapult AI Work Technical Team

Catapult AI Work builds websites, business software, AI automations, and mobile apps. We write these guides to help business owners compare options and prepare project requirements.

EDITORIAL METHOD

About this guide

We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.

Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.

Read the editorial policy

DESIGN SAFE SELF-SERVICE

Choose the first complete customer journey.

Show us the customer task, source systems, roles, and support handoff. We can scope a portal around verified data and explicit controls.

Contact us for pricing