By 
An invoice download and a disputed charge might start from the same account screen. One calls for a document, the other for a review of what happened.
A customer self-service portal lets customers find information, manage account details and submit requests independently. The planning challenge is deciding which tasks they can finish themselves and where staff should take over.
Choose tasks using four practical checks
Review recent enquiries and group them by purpose: retrieving documents, checking progress, changing bookings. Use that list to shape the development brief. For the platform and integration work described on Unbranded’s website development manchester page, specify which records each task retrieves or changes and when staff take over.
Assess each task against four checks:
- Demand: Does it recur often enough to justify building and maintaining an online route?
- Clear rules: Can the next step be determined consistently, or does it depend on negotiation and judgement?
- Reliable data: Will the portal draw current information from the system holding the definitive record?
- Control and consequences: Who should be allowed to perform the action, and what happens if it goes wrong?
Frequency is only part of the decision. Changing payment details needs different safeguards from viewing opening hours.
Authentication establishes who someone is; authorisation determines what they may access or change. On a business account, one employee might need invoices while another manages service bookings. Define those permissions before designing the dashboard.
Match each task to the right level of self-service
The same portal can offer immediate completion, requests for approval and staff-led resolution.
Downloading an invoice suits immediate completion when the document exists and the customer has permission to access it. Provide a clear route to the correct billing period, with a way to report a missing document.
Changing an appointment depends on availability and booking rules. Where the booking system supports an immediate change, the portal can confirm it. If staff approval is required, label the action as a request. Use “Request received” for submission and “Appointment changed” for a confirmed update.
Disputing a charge can begin online, with the decision left to staff. Collect the invoice reference, explanation and relevant documents, then send them to the responsible team. Give the customer a reference and explain the next step.
Specify what success and failure look like
Write acceptance criteria before development: observable results that show whether each task works as intended, including its failure route.
For an appointment change, a requirement could be: an authorised customer selects an available slot, the booking system records the change, and the portal displays the confirmed date and time. If confirmation is unavailable, show that the outcome needs checking and provide a route to do so. Reserve success messages for confirmed changes, so customers avoid repeatedly submitting the same update.
Test the complete journey, including unavailable records, expired sessions and rejected updates. Status messages should distinguish between received, awaiting review, completed and unsuccessful.
Keep help close to the task. When a customer needs staff assistance, pass along the request reference and information already supplied. That gives the team context and saves the customer repeating their explanation. Assign responsibility for the support queue.
Include keyboard operation, understandable error messages and mobile use in testing. Retain an alternative contact route for customers who need help completing the process.
Measure outcomes task by task
Define success around the customer’s purpose. For invoice retrieval, measure access to the required document rather than a visit to the invoice page. For a dispute, track submission and resolution as separate stages.
Monitor completion and abandonment for each task, alongside subsequent contact about the same issue. If customers download invoices but still telephone to understand them, clearer billing information could be more useful than another portal function.
Investigate where people stop. An exit might reflect confusion, a technical problem or a customer who no longer needs to continue. Read falling call volumes alongside these findings to distinguish useful self-service from people giving up.
Start with a few well-understood tasks, test them from beginning to end and review the results before expanding. Give someone ownership of unresolved requests as well as the portal itself. A small service that reliably completes useful work provides a firmer foundation than a dashboard full of partially supported tasks.
Comments