Customer portal requirements: a worksheet for a B2B client or customer portal

What a customer portal requirements list has to answer

Specify who acts, what changes, which system is authoritative and what happens on failure. Use this worksheet to compare native configuration, packaged software and a custom build. A technical review must still establish feasibility before a firm quote.

Step 1: list every role that signs in

Define roles by access. Start with customer users, customer administrators, partners, approvers, exception handlers and access administrators. Record who may invite colleagues, how many people each role covers and where identities live.

Step 2: one line per action

Use the customer's wording and fill in each column.

Compare actual actions with the Experience Cloud versus custom portal worksheet.

Step 3: name the system of record for each field

Name the authority for orders, cases, invoices, documents and entitlements. Where two systems disagree, decide which wins. Where a value exists only in an inbox, assign an owner and a home.

Record each system's administrator, required API operation and confirmed access under your plan. The platform limits guide explains allowance questions; recheck its dated examples against current documentation and your account.

Step 4: write the permission rule for each action

Write a rule combining the person, role, account and action. Define sign-in, session expiry, account isolation, file access, audit records and hosting requirements. Have the responsible reviewer specify applicable data-handling controls and evidence.

OWASP's Authorization Cheat Sheet, checked October 7, 2026, recommends checking authorization on every request and enforcing it on the server. A hidden button is not an access rule.

Step 5: decide what happens when something fails

For each action, name who sees a decline, rejected update or unknown outcome; what the customer is told; and where work waits. Assign an exception owner with defined correction authority. Keep internal notes out of customer-facing errors.

Step 6: write down who owns it after launch

Name who handles sign-in problems, security updates, process changes and support. Record ownership of code, hosting and accounts, and what happens if the builder becomes unavailable. Mark undecided responsibilities explicitly.

A readiness scorecard for client portal development

Score each line yes, no or unknown; attach an owner and next check to every gap.

A critical access or isolation unknown remains a blocker regardless of how many other lines pass.

Completed example: a customer address-change request

Synthetic demonstration: invented records. Cedar Services, account A-101 and request R-014 form a proposed acceptance specification. No portal was implemented or tested for this example. No real client or measured outcome is shown, and no customer team has reviewed it.

The task changes the account's mailing address. It assumes an authorized CRM update operation and a way to detect a changed record version, both requiring verification. The CRM owns the current address; the request stores the proposal and approval history. Existing orders and invoices are excluded.

Roles, actions and authority

• Customer member: may view their account's confirmed address. Submission is denied, including direct requests.
• Customer administrator: may propose changes for A-101 with active membership and permission. Cannot approve or access A-102. Test by changing the requested account ID.
• Staff approver: may approve or decline assigned accounts' requests with a reason. Editing an approved proposal requires fresh approval.
• Integration worker: may apply approved fields through the authorized CRM operation. Pending and declined requests must produce no write.
• Operations owner: investigates uncertainty, reconciles completed writes or returns work for correction. Intervention must preserve the proposal and approval history.

One request from submission to confirmation

1. An administrator submits R-014 to change invented address "10 Orchard Way" to "22 Cedar Lane". Store account, fields, source version, submitter and time. Show awaiting approval; leave the CRM unchanged.
2. The approver approves the exact proposal. A decline instead records the reason, informs the customer and closes the request without writing.
3. Recheck approval, account scope and source version. If staff changed the address meanwhile, show needs review and preserve the newer value.
4. Apply the update using a stable operation key derived from R-014. Verify duplicate protection in the integration and destination; an ID alone does not make retries safe.
5. Confirm the stored CRM value before showing completed. A timeout leaves outcome unknown until reconciliation establishes what happened.

Acceptance checks to hand to the builder

Record expected behavior, actual output, evidence and reviewer for each case:

• Approved: A-101 changes once; request and audit agree; unrelated fields and historical invoices remain unchanged.
• Denied: a member cannot submit; an A-102 administrator cannot read, approve or alter R-014 through the UI or API.
• Declined: no source write; the customer sees a useful reason without internal notes.
• Repeated: the same operation key returns the same request; different proposed fields require a separate approval decision.
• Timeout after write: simulate a successful CRM update followed by a lost response. Reconcile before retrying; prevent duplicate side effects or invented success.
• Conflicting edit: change the CRM after submission. Expect a pause for review, preserving the newer value.
• Recovery: expire credentials or reject a field. Work remains visible with an owner; correction preserves the approval boundary.

Observed results: not run. These specify expected behavior, not completed connector or permission tests.

Copyable requirements record

Copy this into a document or spreadsheet per action, or print this page.

Action, account boundary, allowed and denied roles:
Source of truth, fields and verified API access:
Approval rule and approved proposal version:
Source version and conflict behavior:
Duplicate key and repeated-request behavior:
Success evidence and unknown-outcome behavior:
Exception owner and correction authority:
Test case / expected / actual / evidence:
Reviewer, date and unresolved issues:

Questions buyers ask about B2B customer portal development

What should be in a customer portal requirements document?

Roles, actions, authoritative systems, permissions, approvals, failures, ownership and acceptance checks. Include volumes and applicable data requirements.

How do we write requirements when our process is not documented?

Trace one request with its owners, including email and phone handoffs. Check the proposed flow against that trace.

Do we need every requirement before client portal development starts?

A pilot can cover one specified workflow. Record wider roles, data boundaries, dependencies and exclusions before implementing it.

Who should write the requirements, our team or the vendor?

Your team owns the business rules. A builder helps translate them into technical scope. Review the result together before agreeing it.

Using the worksheet with us, or without us

The portal development overview explains our discovery and pilot process. Bring system names and one desired action using invented or sanitized examples. Do not send credentials or customer records. We can complete the worksheet with you after a discovery call; you keep it whatever you decide.

Discuss a portal project