Illustrative concept / Customer portal
A clearer way for customers to manage service requests
A service portal concept showing how customers could submit requests, share documents and follow progress without relying on email updates.
This is an illustrative product concept, not a client case study. It does not represent a live engagement, customer result or measured outcome.
The challenge
Requests disappear across inboxes and tools.
Service businesses often manage requests across email, forms, shared inboxes and internal systems. Customers cannot easily see what has been received, who owns the next step or when they need to respond.
- Map the customer request from first contact through resolution.
- Give each request a clear status, owner and next action.
- Keep messages, files and decisions attached to the request they belong to.
- Design an internal view that uses the same record as the customer-facing portal.
Product views
A guided request form that changes based on the service selected.
A request detail view with status history, messages and documents in one place.
An internal list for sorting requests, assigning owners and handling unusual cases.
Start with one shared service record
The concept centres each service request on a single record. The customer and service team see different views of the same underlying information, which reduces the need to copy updates between tools.
The record holds the request details, current status, assigned team, messages, documents and a dated activity history. It also makes the next action explicit, including who needs to complete it.
Make progress understandable
Generic labels such as open or pending rarely tell a customer what is happening. The proposed statuses use plain stages that reflect the service process, then pair each stage with a short explanation.
A visible timeline records completed steps without exposing internal notes. When the business needs information from the customer, the request changes from passive tracking to a clear task with a due date and a direct action.
- Received and ready for review
- More information needed
- In progress with the service team
- Ready for customer approval
- Completed with a retained history
Design the internal operation at the same time
A customer portal only works when the internal workflow behind it is clear. The internal view groups requests by urgency, service type, owner and time in stage. Staff can see the same customer-facing status while keeping internal notes and controls separate.
Rules can direct routine requests, but unusual cases remain visible for human review. Every automated action should leave an activity record so the team can understand what happened and recover when a connected system fails.
Build around real access needs
The concept allows an organisation to invite more than one user and assign access by account, location or request type. This matters when a customer has an operational contact, an approver and a finance contact who need different information.
Logins, file permissions, a record of who did what, and how long information is kept would all be settled before any build. Accessibility checks would cover the complete request journey, including keyboard use, status announcements, form errors and document handling.
What would be validated first
Before a full build, a working prototype would test whether customers understand the status language, whether the request form asks for the right information and whether staff can process a request without maintaining a second record.
The first release could focus on one common request type and one internal team. Evidence from that release would guide which services, integrations and self-service actions should come next.
Start a project