Customer Portal Planning: Features, Roles and Integration

Find the right use cases

• Review a sample of inbound emails and calls and group them by reason.
• Look for high-volume, repetitive requests and status questions such as "Where is my order?" or "Has my request been scheduled?"
• List documents customers ask for: invoices, statements, reports and certificates.
• Note service requests and bookings that need structured information to process.

Core features

Organizations, roles and permissions

• Separate the customer organization from its users.
• Define customer roles such as administrator, requester, viewer and billing contact.
• Decide whether users at multi-site customers see every site or only their own.
• Define internal roles for agents, supervisors and administrators.
• Check authorization on the server for every record. Broken object level authorization, where one customer can reach another customer's data by changing an identifier, tops the OWASP API Security Top 10.

Integration with back-office systems

• Identify systems of record: CRM for accounts and contacts, service management for requests, ERP for orders and invoices, and document storage.
• Decide which system owns each field and in which direction data flows.
• Choose real-time APIs where customers expect immediate status, and scheduled synchronization elsewhere.
• Build in retries, error alerts and reconciliation reports.
• Avoid staff re-typing portal requests into internal systems.

Authentication and security

• Offer single sign-on for enterprise customers where it makes sense.
• Follow NIST SP 800-63B guidance on passwords: allow long passphrases, screen against compromised passwords and avoid arbitrary forced changes.
• Offer MFA to everyone and require it for customer administrators and billing roles.
• Limit sign-in attempts, manage sessions securely and protect against cross-site request forgery.
• Validate uploaded files by type and content, and scan them for malware.
• Use the OWASP Application Security Verification Standard as the security checklist, and test before launch.
• Log access to sensitive records and administrative actions.

Privacy

• Collect only the information each request needs.
• Publish a clear privacy notice and set retention periods.
• Make it possible to respond to access and correction requests.
• Put data processing agreements in place with hosting and software providers.

Accessibility and usability

• Design to WCAG 2.2 level AA.
• Make every task work well on a mobile phone.
• Use plain language and specific error messages.
• Test with real customers before launch.

Phased launch

1. Build the top two or three use cases for a group of pilot customers.
2. Measure adoption, request completeness and follow-up calls.
3. Fix what the pilot reveals.
4. Onboard more customers with short guides.
5. Add features based on demand.

Measures of success

• Share of requests submitted through the portal.
• Time to resolution and repeat status inquiries.
• Active customer users and customer satisfaction.
• Support workload per customer.