A customer portal earns its place when it helps somebody complete a useful job without waiting for your team to move information between inboxes, folders and internal systems.
01
A login is not the customer outcome
That sounds obvious. It is still easy to commission a polished login area that shows a few documents and a vague status, while the customer continues to email for answers and staff continue to update the real process somewhere else.
Bespoke customer portal development should start with the service your customers are trying to use. The screens, integrations and technology come after that.
Imagine an established service business. A customer sends a request by email, attaches two documents and asks when the work will be finished. A member of staff checks the information, creates a record in the internal system and replies to ask for one missing file. Another colleague completes a review. The customer emails again because they cannot see whether anything has changed.
The proposed portal includes secure sign-in, a dashboard, document uploads and a status. It sounds complete when described as a feature list.
Now follow the same case from the customer's point of view. Can they tell which document is missing? Is the status written in language they understand? Can they correct the information without starting again? Will the portal explain what happens next? Can they still get help when their situation does not fit the normal route?
If those answers are unclear, the portal may move the waiting online without removing it.
GOV.UK service guidance recommends starting with what people are trying to achieve, how they currently do it and where they experience difficulty. That principle applies to commercial customer portals too. Customers do not wake up wanting to use a portal. They want to register a product, submit evidence, approve a quote, find a document, pay an invoice or understand what is happening.
The first development question is therefore not, "What should go on the dashboard?" It is, "Which complete customer job should become easier?"
02
Define customer jobs before portal features
A useful discovery phase should look at real customer enquiries, support calls, forms, documents and cases. It should also involve the staff who resolve problems when the ordinary route breaks.
For each important customer job, establish:
- what starts it
- what information the customer already has
- what they need to provide or decide
- which person or system acts next
- what a successful outcome looks like
- which exceptions still need human help
This keeps the project grounded. "Customers need document management" is broad. "A policyholder needs to retrieve the current policy document without asking the office to resend it" is something a team can design, build and test.
It also exposes internal work that the customer should never have to understand. They may not care which department owns the case or which system generates the document. They do care that the information is current, the next action is clear and somebody takes responsibility when it is not.
03
What can a bespoke customer portal include?
The right capabilities depend on the service. A portal for installers, policyholders or trade customers will not need the same journeys. The following table is a useful starting point, not a shopping list.
| Customer need | Useful portal behaviour | Question to settle before development |
|---|---|---|
| Access an account | Secure sign-in and recovery, with access to the correct organisation, sites or services | Can one person belong to several organisations, and who can invite or remove other users? |
| Submit a request | A guided form that validates the information and stores it against the right record | What makes a submission complete, and which exceptions need review? |
| Supply evidence | Uploads with clear file requirements, progress and confirmation | Who can view, replace, approve or delete each document? |
| Check progress | A current status, outstanding actions and an understandable next step | Which internal statuses are safe and useful to expose to customers? |
| Retrieve documents | Access to the correct version of approved files | What happens when a document is replaced, withdrawn or expires? |
| Approve or pay | A recorded decision or payment connected to the relevant case | Which system owns the amount, approval state and receipt? |
| Ask for help | A support route that carries the account and case context | Which conversations belong in the portal, and when should a person take over? |
| Receive updates | Relevant notifications triggered by meaningful events | How will users control noise without missing an important action? |
Adding every row to the first release would usually be a mistake. Start with the smallest complete journey that removes a recognised piece of customer and staff effort.
For the service business in our example, that might be one request type. The customer creates it, supplies the required evidence, sees what is outstanding and receives the approved result. Staff review the same case, ask for missing information and record the decision. That is a narrow scope, but it crosses the whole service and can prove whether the portal is useful.
04
Customer accounts need an organisation model, not just user records
Business portals often become awkward because the account structure is treated as a simple sign-in problem.
One customer organisation may have several users. One user may manage several branches or sites. A finance contact may need invoices but not case evidence. An external adviser may have temporary access to one record. A colleague may leave and need access removed without affecting the organisation's history.
Those relationships belong in the data and permission model from the start. Hiding a navigation link is not enough. The application must check whether the signed-in person is allowed to read or change the underlying account, case, document and action.
Authentication should follow the risk and audience. The National Cyber Security Centre describes several stronger options beyond passwords, including multi-factor authentication, federated sign-in, passkeys and one-time links. The right choice balances protection, usability, recovery and the devices customers can actually use. A high-friction login that drives people back to email is not a successful control.
Administrative access needs particular care. Staff who can impersonate users, change permissions or retrieve private files should have controlled access and meaningful activity records. The business also needs a dependable way to review access, handle leavers and recover essential accounts.
05
The portal must agree with the systems behind it
A customer portal is often the visible layer over a CRM, finance package, document store, booking platform or bespoke operational application. It does not need to replace those systems, but it does need clear boundaries with them.
Decide which system owns each important fact. If the CRM owns the customer address, the portal should not quietly create a second version with no reconciliation rule. If the finance package owns invoice status, the portal needs a safe way to retrieve and present it. If a document is generated after approval, the customer should not see it until the correct process has completed.
Every integration also needs a failure path. An API request may time out. A notification may bounce. A payment may be accepted while the callback is delayed. A document job may fail halfway through.
Useful integration design makes those states visible. It records what was attempted, prevents unsafe duplication, retries where appropriate and gives somebody a route to resolve the exception. Otherwise, the portal can show a reassuring message while the work has stopped behind it.
The customer experience and the internal operation are therefore one design problem. A clear portal status is only trustworthy when it reflects a dependable source and a process with ownership.
06
Privacy, accessibility and mobile use are part of the service
Customer portals often contain personal, financial or commercially sensitive information. Privacy cannot be added after the workflows are settled.
The Information Commissioner's Office says data protection should be integrated through the design, development, launch and live life of a product. In practice, that means collecting only the information required for a defined purpose, limiting access, setting retention rules and understanding which suppliers or integrations process the data.
The design also needs to work for the people who will actually use it. W3C guidance makes clear that mobile accessibility is covered by the same web accessibility standards rather than being a separate concern. Forms, errors, focus states, labels, contrast and touch targets all affect whether somebody can finish a task on a phone, with assistive technology or under ordinary time pressure.
Mobile friendly does not mean squeezing a wide dashboard onto a small screen. It means prioritising the action, information and feedback needed for that moment. A customer photographing evidence on site needs a different flow from an administrator reviewing twenty cases at a desk.
Testing with representative users should begin while the portal is still cheap to change. A prototype can reveal whether people understand the statuses, find the next action and recover from a mistake before the business funds every integration and report.
07
Notifications should support the portal, not recreate the inbox
A portal does not remove email simply by adding an inbox icon.
Customers need to know when something important changes, but they should not receive a notification for every internal action. Decide which events require attention, what the message should reveal and where the authoritative detail lives.
A useful notification might say that more information is required and take the customer to the exact case and action. A poor notification says there has been an update, then opens a generic dashboard where the user has to search for it.
The same discipline applies internally. Staff should be alerted to exceptions, overdue actions and work that needs a decision. They do not need another stream of messages that duplicates a properly designed task list.
Keep communication history where it supports the case, but do not force every human conversation into software. A complicated or sensitive situation may still need a call. The portal should help the staff member see the context before they make it and record the agreed outcome afterwards.
08
Bespoke or off the shelf?
Standard portal software is often the right starting point when the need is mainly support tickets, file sharing, invoices, bookings or account details. A product that already fits the job can be configured faster and carries less development responsibility.
Bespoke customer portal development becomes more defensible when the customer experience is part of a distinctive service, portal actions must drive an internal workflow, several systems need to work together or the organisation and permission model is too specific for a standard product.
Compare the full operating fit rather than the feature checklist. Consider integration limits, data ownership, licence costs, accessibility, support, export routes and the workarounds the team would still need. A custom build has an upfront and ongoing cost. A poor-fit subscription has a quieter cost in repeated admin and constrained service design.
Sometimes the best answer is mixed. A standard identity provider, payment service or document platform can sit behind a bespoke journey. Custom does not have to mean rebuilding solved technology.
09
Develop the portal in complete, reviewable phases
A portal project should not disappear into development for six months and return as a finished answer.
Begin with discovery. Map the current customer and staff journey, account structure, data, systems, exceptions and success measures. Prototype the risky parts, especially complex forms, permissions and the wording customers use to understand progress.
Then choose one production slice that can operate safely. Include the customer task, the internal response and the support needed when something fails. Agree acceptance criteria that describe observable behaviour, not just finished screens.
Later phases can add more request types, account services, integrations and reporting after the first journey is being used. Analytics, support questions and real cases should influence that roadmap. GOV.UK guidance recommends continuing user research through development and live operation because needs and assumptions become clearer when people use the service.
Launch is also the start of operational ownership. Hosting, monitoring, backups, security updates, access reviews, user support and a controlled release process need named responsibility. A portal that customers rely on has become a business service, not a completed website project.
10
Experience that connects the portal to the operation
I am a Business Software Consultant and Developer based in Greater Manchester, working with organisations across the UK. I have spent 17 years in commercial web and software work, including seven years as a hands-on Technical Director at Jarpa.
My portal experience includes a Qualitymark system that received data through an API, generated and securely hosted policy documents, and emailed customers so they could access them online. I also worked on an installer portal for Flexi-Orb that supported job registration, review collection and DNO-related forms. The value of those projects came from connecting the customer-facing journey to the operation, documents, data and people behind it.
That is how I approach bespoke customer portal development. I start with the job customers need to complete, understand how staff deliver the service and define the smallest production phase that can improve both sides without hiding new manual work behind a login.
If customers are repeatedly asking for updates, documents or help completing the same process, bring me one complete example. I can help decide whether a standard product will do the job or whether a bespoke portal is justified, then shape the discovery, prototype and build around a useful outcome.
Useful questions
Before commissioning a bespoke customer portal, confirm:
- The first complete customer job is defined in the customer's language.
- The internal workflow and exception route are understood.
- Organisation, account and permission relationships are explicit.
- Each important item of data has an agreed source of truth.
- Integration failures create visible states and recovery actions.
- Privacy, retention, accessibility and mobile use are included from the start.
- Notifications lead people to a clear action rather than creating more noise.
- The first release is small enough to test with real customers and staff.
- Hosting, monitoring, backups, security and support have named owners.
- Success is measured through completed customer jobs and reduced operational work, not portal logins alone.
