A B2B customer portal specification should define what each user can do, which organization owns each record, and what happens in the business after a customer takes an action. A list of screens is not enough to estimate the complete workflow.
Use this checklist with your product lead, customer operations team, and the owners of the connected systems. Start with one customer journey, then add scope when its dependencies are understood.
Define the account structure before the screens
A customer account may represent a company with several users, locations, or departments. Decide whether those users share all records or only a subset. Describe who can invite another user, approve their access, and remove them.
Hypothetical example: a supplier gives customer employees access to service requests. A location manager can see requests for their site, while a purchasing lead can see the whole company. Calling both roles “customer” would hide a major requirement.
Write permission rules as actions on records. OWASP recommends enforcing permissions on each request and checking access to individual resources; a visible or hidden button is not the access boundary. OWASP authorization guidance.
Complete one journey from submission to resolution
For each proposed feature, answer these questions:
- What starts the journey, and what information is required?
- What record is created or changed?
- Which internal team receives the work?
- Which states can the customer see?
- Can the request be edited, cancelled, rejected, or reopened?
- How does the customer know that an action succeeded?
“Submit a request” is incomplete if nobody has defined where that request goes. Include the internal queue and the response path in the estimate, even when those steps use existing software.
Use a requirements worksheet
Copy this structure into your brief. The entries below illustrate a possible service-request portal; they are not a description of a delivered Yarify project.
| Area | Decision to record | Evidence for acceptance |
|---|---|---|
| Account access | Location managers see only their site’s requests | Test with users from two locations and two companies |
| Request submission | A valid request creates one internal work item | Repeating the submission does not create unintended duplicates |
| Documents | Files belong to a specific account and request | Another account cannot retrieve the file through its URL |
| Status | The operations system owns the status | A changed status appears within the agreed delay |
| Support | Failed transfers go to a named internal queue | Staff can find the failure and follow the recovery procedure |
Define the first release and its exclusions
Separate essentials from later options. A request portal may not initially need online payments, multilingual content, complex reporting, or customer-managed configuration. Record those exclusions explicitly so different suppliers estimate the same assignment.
Also assign responsibility for interface design, identity setup, system access, test data, and user acceptance. A backend estimate and an estimate for the entire portal are different scopes.
Prepare a brief that can be estimated
The useful first package is short: the selected journey, account model, worksheet, system list, and unresolved questions. Include representative non-sensitive records and identify who can answer questions about each system.
Use the custom software cost guide to review estimate assumptions. If connecting existing systems is the main uncertainty, work through the API integration checklist before adding more portal features.
Put it into practice.
Explore our customer portal development service or send us the problem you are working on.