A customer portal is a secure, signed-in website where customers serve themselves: they view their account, place orders, submit applications or raise requests, using data held in your ERP, CRM, billing or case system. A good build starts by choosing the portal type, deciding which system owns each piece of data, designing access per customer account and meeting OWASP and WCAG 2.2 baselines.
This checklist is for teams scoping a portal, whether it replaces emailed statements and phone orders or opens a public service online. It is vendor-agnostic and applies to custom builds and to portal modules bought with an existing system.
What types of customer portals are there?
Most portals fall into four types. Many real portals combine two, such as ordering plus support, but one type usually drives the design.
| Portal type | Who uses it | Typical jobs | Usual source systems |
|---|---|---|---|
| Self-service account | Consumers or small business customers | View bills, pay, update details, download statements | Billing, CRM |
| B2B ordering | Dealers, distributors, trade customers | Reorder, see contract prices and stock, track orders, download invoices | ERP, warehouse system |
| Applicant or case | Citizens, businesses, students, patients | Apply for a permit, licence or service, upload documents, track status, answer requests for information | Case management system |
| Support | Any customer | Raise and track tickets, warranty and returns, search help articles | Helpdesk, CRM |
Which features does each portal type need?
Build the jobs that generate the most phone calls and emails today first. The table shows which features are core, common or rare by portal type.
| Feature | Self-service account | B2B ordering | Applicant or case | Support |
|---|---|---|---|---|
| Sign-in and profile management | Core | Core | Core | Core |
| Several users per customer account | Common | Core | Rare | Common |
| Invoices and statements | Core | Core | Rare | Rare |
| Online payment | Core | Common | Common (fees) | Rare |
| Customer-specific prices and catalogue | Rare | Core | Rare | Rare |
| Quick order, reorder or file upload of orders | Rare | Core | Rare | Rare |
| Order and delivery tracking | Common | Core | Rare | Common |
| Multi-step forms with save and resume | Rare | Rare | Core | Common |
| Document upload | Common | Common | Core | Common |
| Status timeline | Common | Core | Core | Core |
| Secure messaging with staff | Common | Common | Core | Core |
| Help articles and search | Common | Common | Common | Core |
| Several languages, including right-to-left | Depends on market | Depends on market | Often required in public services | Depends on market |
To find the first release, read a month of your support inbox and call logs and count the requests. "Where is my order?", "Can you resend the invoice?" and "What is the status of my application?" usually top the list, and each one is a portal feature.
How should identity and access work in a customer portal?
Model people and customer accounts separately: a person signs in, belongs to one or more customer accounts, and has a role in each. Then choose sign-in methods to suit each audience.
- Consumers and applicants. Email and password with optional multi-factor authentication, or one-time codes sent by email or phone. Keep it simple; many will sign in a few times a year.
- Business customers. The same options, plus single sign-on through SAML 2.0 or OpenID Connect for larger customers who want staff to use their company identity provider.
- Roles per customer account. For a B2B portal, typical roles are account administrator, buyer, approver and finance viewer. Roles belong to the person within a specific account, not to the person globally.
- Delegated administration. The customer's own administrator invites and removes users, assigns roles and sets order limits. Your team stops handling every staff change at every customer, and access is removed faster when someone leaves.
- Proving account membership. Decide how a new user proves they belong to customer account X: an invitation from that account's administrator, a check against details only the customer holds (such as an account number plus a recent invoice number), or approval by your staff. This step is a common weak point.
- Staff access. If staff can view the portal as a customer to help them, log every session.
WCAG 2.2 added a criterion for this area: 3.3.8 Accessible Authentication (Minimum) asks that sign-in does not depend on a cognitive function test, such as remembering or transcribing a password, unless an alternative or assistance is available. In practice, allow password managers and pasting, and offer email codes or links.
What security basics does a customer portal need?
Assume every request might come from a different customer trying to see data that is not theirs. The most serious portal flaw is one customer viewing another's invoices or applications by changing a number in the address bar.
Two OWASP lists name this risk first. The OWASP Top 10:2025 puts Broken Access Control at A01:2025, and the OWASP API Security Top 10 (2023 edition) puts Broken Object Level Authorization at API1:2023. Portals are mostly APIs behind a web interface, so both apply. For a testable set of requirements, use the OWASP Application Security Verification Standard (ASVS 5.0), which defines three levels of verification; agree the target level with whoever owns security risk.
Security checklist:
- Server-side authorisation on every record, scoped to the signed-in user's customer account and role
- Identifiers that are hard to guess, as an extra layer (never as the only control)
- Multi-factor authentication available, and required for administrator roles
- Rate limits on sign-in, one-time codes and password reset
- Sign-in and reset messages that do not reveal whether an email address has an account
- Secure, expiring sessions
- File uploads checked for type and size, scanned for malware, stored privately and served only to authorised users
- Parameterised queries and input validation (Injection is A05:2025)
- Dependencies kept current and scanned (Software Supply Chain Failures is A03:2025)
- Logs for sign-ins, permission changes, exports and failed access attempts, with alerts (Security Logging and Alerting Failures is A09:2025)
- A penetration test before launch and after major changes
- Only the data customers need, shown to the people who need it
Our security and data protection page describes how we apply these controls in the systems we build.
How should the portal integrate with ERP, CRM and billing?
For every data item the portal shows or changes, decide which system is the master. The portal should rarely be the master of business data; it reads from the systems of record and sends new transactions back to them.
| Data item | Usual master | Portal access | Sync approach |
|---|---|---|---|
| Customer account, credit status | ERP | Read | On sign-in or near real time |
| Contacts | CRM | Read, limited edit | Changes sent back to CRM with rules |
| Products, prices, contract pricing | ERP | Read | Cached, refreshed when changed |
| Stock availability | ERP or warehouse system | Read | Live lookup or frequent refresh, showing the "as of" time |
| Orders | ERP once submitted | Create | Draft in portal, posted to ERP through an API; confirmation comes from the ERP |
| Invoices and statements | ERP or billing | Read | Documents generated by the master system |
| Payments | Payment provider, then ERP | Create | Provider webhook posts the receipt to the ERP |
| Applications and cases | Case management system | Create, read status, upload | API or shared database with clear ownership |
| Support tickets | Helpdesk | Create, read | Helpdesk API |
| Portal users, roles, preferences | Portal or identity provider | Full | Master in the portal |
Three integration rules prevent most production problems:
- Idempotency. Each order or payment carries a unique key, so a retry after a timeout cannot create a duplicate.
- Graceful downtime. When the ERP is unavailable, queue submissions and tell the customer clearly, rather than failing silently.
- Reconciliation. A daily report compares what the portal sent with what the master system recorded.
Our systems and API integration service covers this layer, and our guide to system integration approaches compares APIs, events, batch files and middleware.
Which notifications should a portal send?
Send notifications when something changes that the customer must act on or is waiting for, and let users choose channels where possible.
- Order confirmed, shipped, delayed or delivered
- Invoice issued, payment received, payment overdue
- Application received, information requested, decision made
- Ticket updated or resolved
- Account security events: new sign-in, password changed, new user added
Keep sensitive details out of email and text messages. "A new document is available in your portal" with a sign-in link is safer than attaching a statement.
What accessibility standard should a customer portal meet?
Aim for WCAG 2.2 Level AA. WCAG 2.2 is a W3C Recommendation, and the current version is dated 12 December 2024. Several criteria added in 2.2 matter directly for portals:
- 2.4.11 Focus Not Obscured (Minimum), AA: sticky headers and chat widgets must not hide the field a keyboard user is on
- 2.5.7 Dragging Movements, AA: drag-and-drop uploads need a button alternative
- 2.5.8 Target Size (Minimum), AA: buttons and links large enough to use
- 3.3.8 Accessible Authentication (Minimum), AA: covered above
- 3.2.6 Consistent Help and 3.3.7 Redundant Entry, both Level A: help in the same place on every page, and no re-entering information already given in the same process
Long application forms are where most portals fail users: labels, clear error messages, save and resume, and a summary page before submission. Legal accessibility obligations vary by country and sector, and public bodies often have specific requirements, so confirm yours with advisers.
How do you measure portal use without collecting personal data?
Measure tasks, not people. Count events such as "order submitted", "invoice downloaded" or "application step 3 completed", and keep names, email addresses, account numbers and free-text fields out of analytics tools. Respect the consent rules that apply to you for any analytics cookies, and use server logs for operational measures.
Useful measures:
- Share of orders, payments or applications that arrive through the portal rather than by email or phone
- Completion rate and the step where people abandon multi-step forms
- Support contacts about tasks the portal already handles
- Time from submission to decision, for case portals
Our guide to designing business dashboards with clear KPI definitions covers how to turn these into a dashboard people use.
What does a sensible rollout plan look like?
Roll out in waves, starting with a few customers who will tell you what is wrong.
- Discovery. Count requests by type, decide the master system for each data item, agree roles.
- Pilot. A handful of friendly customers use the first release for real work. Fix what confuses them.
- First wave. Invite customers in batches with a short guide; create administrator accounts in advance for B2B customers.
- Main rollout. Bulk invitations, help articles, staff trained to point callers to the portal.
- Channel shift. Gradually stop the manual alternative, for example emailing statements, once the portal is proven.
For a public-sector example, our Qatar government digital platform case study describes a bilingual platform with an applicant portal, case management, role-based access and audit.
What mistakes should you avoid?
- Building every feature for launch instead of the few jobs that drive most contacts
- Letting the portal become a second master for customer or price data
- Checking access only in the user interface, not on the server
- No clear process for proving a new user belongs to a customer account
- Showing stock or prices without saying when they were last updated
- Forms that lose work on timeout
- No owner for portal messages, so customers get faster answers by phone
- Launching without telling the staff who answer the phone
When is a custom portal not the right approach?
- Your system already includes a portal that fits. Many ERP, CRM and helpdesk products ship portal modules. Configure and test those first; build custom when the jobs, branding or combined data across systems need it.
- Very few customers would use it. Email and a shared document area may be enough.
- The source data is unreliable. A portal exposes wrong prices and balances directly to customers. Fix the data first.
- Nobody can answer portal messages. An unanswered portal does more harm than no portal.
How Timeline Digital helps
We design and build portals connected to the systems you already run. Our customer portal development service covers ordering, account, applicant and support portals, and our wider web application development work covers the back-office screens behind them. We start with a free pilot of 2 to 3 key modules before the full project, for example sign-in with account roles and order tracking, so your team can test real software with real data first.