A customer has sent in their equipment for servicing. The business has received it, assigned a technician and opened an internal job.
The customer sees “In progress.”
That may be technically accurate. It is also doing rather a lot of work for two words.
A useful customer portal translates the service into information the customer can understand and actions they can take. For a custom .NET application, the important design choice is how much of the internal workflow belongs in that view.
The equipment-service journey here is illustrative, not a claim about a particular client’s portal.
| What the portal does | Example | |
|---|---|---|
| The customer needs reassurance | Shows a status in the language of the service promise | “Received and awaiting assessment”, with the job reference |
| The customer needs to act | Connects the decision to the right document and checks access on the server | Approve, ask a question or decline version 2 of the estimate |
| Something needs attention | Explains what is needed and links the reply to the same job | A request for more information, not a status that says “Exception” |
When the customer needs reassurance, show a meaningful status
After equipment arrives, the customer wants to know whether it was received and what happens next. The portal can show receipt, the relevant job reference and the next stage in understandable language.
An internal task code or queue name may mean something to staff without helping the customer. The customer view should use labels that reflect the service promise.
That does not require exposing every internal step. A concise explanation such as “Received and awaiting assessment” can be useful if it matches the actual process.
Where timing is known, state it appropriately. Where it is uncertain, explain the next update or contact route. A status should not imply a confirmed completion date simply because the design left room for one.
When the customer needs to act, make the decision clear
Suppose the assessment produces a service estimate requiring approval. The portal now has a different job: help the customer understand the proposal and record a decision.
We design and build custom web portals and dashboards for exactly this kind of work.
Connect the action to the correct document
Show the relevant estimate, its version and the work it covers. The customer should know which proposal they are accepting and whether any conditions remain.
Make the available actions clear. An approval, a request for clarification and a decision to decline have different meanings. The wording should match what the business will actually do afterward.
If the estimate changes, preserve the earlier decision appropriately and establish whether renewed approval is required under the workflow. Quietly replacing a document beneath an old approval can create confusion for everyone involved.
Enforce access beyond the visible page
The server needs to check that the signed-in customer may view this job, download the document and perform the requested action.
Hiding a link in the interface does not protect a direct download or action endpoint. Staff permissions need their own scope as well.
In a .NET implementation, a focused request handler can keep the relevant validation, authorization and state change together. Jimmy Bogard’s vertical-slice approach provides useful architectural context for organizing around such complete actions.1
The point is the behavior: the correct person makes the correct decision on the current record, and the result is stored clearly.
When something needs attention, preserve the next step
A portal should also work when the ordinary route pauses. Perhaps an item needs additional information or the customer has a question about the estimate.
Explain what is needed and provide an appropriate response route. A status that says “Exception” mainly informs the customer that they have become one.
The staff view can contain more operational detail. It should connect the customer’s response to the same job so the next person handling it can continue without reconstructing the conversation.
Notifications can help bring people back when there is something to review. Keep them relevant and direct the customer to the appropriate protected view. Repeated reminders about a decision already made are a reliable way to make an otherwise helpful system feel slightly haunted.
Real-time updates may suit a workflow where immediate changes matter. In other cases, a normal refresh and an honest indication of current information are sufficient. SignalR is one available .NET tool, rather than a requirement for every portal.
I would review the journey from both sides: receipt, assessment, customer decision and the next operational step. Check what each role sees and whether the records agree after an action or correction.
A good portal makes the service feel organized and understandable. The customer can see where things stand and when their involvement is needed. The business can continue the work with the right information. “In progress” finally gets some useful company.