Customer portal development for the work your customers keep asking you to do
Give customers and partners a clear way to find their orders, retrieve documents and follow requests, connected to the systems your business already runs.
01
Your team should not have to relay every account update
Better Software helps scope and build customer-facing web applications and the internal tools needed to operate them. Start with one useful workflow, clear account permissions and a way to handle the exceptions.
An order status lives in the ERP. An invoice lives in accounting. A quote needs an account manager's approval. The customer sees an email thread and asks your team to put the pieces together.
A portal can give that customer a controlled view of the information and actions they need. The difficult part is deciding whose records they may see, which system owns each fact and what the portal should do when an update cannot be confirmed.
We would define those rules alongside the screens. A dashboard that looks complete but shows the wrong account, an old price or an unconfirmed order creates more operating work.
02
A focused portal engagement
The starting scope is one customer group, one end-to-end journey and the source systems required to support it. That could be finding an order and downloading its documents, checking a quote and submitting a response, or following an account request through review.
| Workstream | What we would define and build |
|---|---|
| Customer journey | The screens and steps a customer needs to complete the chosen task |
| Identity and account access | Sign-in, account membership, roles and record-level access rules |
| Connected records | The agreed reads and updates, source ownership and freshness policy |
| Internal exception view | Requests that need attention, their context, status and accountable operator |
| Pilot and handover | Acceptance cases, rollout boundary, operating notes and maintenance responsibilities |
A quote response is different from a CPQ engine. Displaying an invoice is different from taking payments. These are separate scope decisions, with their own rules and dependencies. We would establish those boundaries before estimating the build.
03
Configure, buy or build around the actual workflow
Start by testing the portal your ERP, CRM or service platform already provides. If it supports the required account relationships and customer actions, configuring it may be the better investment.
A packaged portal is worth evaluating when its supported records, permission model and operating process fit. Check subscription costs at your expected user count, integration limits, export options and who maintains changes. A short setup can still leave significant ongoing work.
A custom portal becomes a candidate when customers need a journey the existing tools cannot express, or a consistent view across systems with different responsibilities. It also means owning another application. Include identity, hosting, monitoring, support and source-system changes in the decision.
Permissions are concrete platform behavior, not a feature label. For example, Microsoft's Power Pages documentation distinguishes account, contact and other scopes for Dataverse table permissions. That is a mechanism to evaluate where Dataverse is involved, not a reason to move every business onto that platform. Microsoft table permissions
04
Example: an order page with an honest exception path
Illustrative design. Fictional data, not a customer deployment or a working integration.
A distributor gives Account A access to its orders and related documents. Account B has separate records. An internal operator handles requests that cannot be completed through self-service.
The customer opens Order A-104. The page shows the last known status, the last successful source check and the documents the account is allowed to retrieve. If the ERP is unavailable, the page follows an agreed freshness rule. It does not turn an old snapshot into a current shipping promise.
A request that needs review appears in the operator's queue with the order reference and a customer-visible status. The customer can follow that request without restarting the conversation. The operator can see what failed and what needs a decision.
One customer journey, with an operator path when it needs attention
Illustrative design. Fictional data; no live connection.
Customer account A
- Order A-104
- Last known status: Processing
- Last source check: 10:00
- Document: Invoice A-104
- Request status: Awaiting review
Account and record checks
- Verify user membership
- Authorize this record and action
- Apply source freshness rule
ERP / CRM / document source
- Authoritative business records
- Defined reads and updates
Internal exception queue
- Order A-104
- Source refresh unavailable
- Owner: Operations queue
- Customer reference: Request A-12
- Authorized request
- Customer account A to Account and record checks
- Read or confirmed update
- Account and record checks to ERP / CRM / document source
- Needs review
- Account and record checks to Internal exception queue
- Visible request status
- Internal exception queue to Customer account A
What this example needs to prove
| Scenario | Expected behavior |
|---|---|
| Account A opens its order | Return only records and actions authorized for that user |
| Account B requests the same order or document | Refuse access at the server boundary |
| Source data cannot be refreshed | Explain the limitation and apply the agreed display/action rule |
| A change request has an uncertain outcome | Keep the outcome unresolved until authoritative evidence settles it |
| A customer loses account access | Enforce the defined revocation policy, including document delivery |
OWASP recommends object-level authorization for API operations on identified objects. Hiding another account's link in the interface does not replace that check. These example cases are a starting acceptance contract, not a security certification. OWASP object authorization
Our supporting guide explains the freshness decision in more detail: What should a customer portal show when ERP data is stale?
05
From a workflow review to a bounded pilot
We would first map the customer journey, users, account relationships and records involved. You bring the operating context and a source-system owner. We identify the access and platform constraints that can change the scope.
Next, we would compare configuration, packaged software and a custom build. The output should make the recommendation inspectable: what the first release covers, which systems it touches, what remains manual and what acceptance evidence it needs.
If custom development is the right route, the first working slice should connect the customer journey to the required source records early. We would test successful use, forbidden access and failure behavior before expanding the feature list.
Pilot rollout and continuing maintenance belong in the proposal. Agree who handles account setup, support, failed updates, source API changes and releases. Repository access, documentation and handover expectations should be explicit before work begins.
06
What changes scope and cost
The number of screens is only part of the estimate. Source API access, account hierarchies, document permissions, write approvals and the quality of existing records can change the work materially.
Read-only order visibility is a different commitment from accepting an order with customer-specific pricing and inventory reservations. Payments, CPQ, regulated data and changes inside a specialist ERP need separate technical assessment and the appropriate implementation owner.
We do not assume that a platform name on a requirements list establishes access or delivery scope. We would confirm those dependencies before committing to an implementation plan. The estimate follows that review; this page does not promise a fixed price or launch date.
07
Bring one workflow to the discussion
This is a useful starting point if you have recurring customer or partner activity, a source system holding the relevant records and someone who owns the operating process. A named owner and a pilot customer group make the first scope easier to test.
If an existing portal already solves the problem, the work may be configuration or process improvement. If the source records or access rights are unresolved, those become the first discovery questions.
Bring a description of one task customers repeat, the systems it touches and where your team currently intervenes. Use anonymized examples. We can discuss a scoped next step, whether that is improving the existing setup or building a focused portal.
