Permissions Modelled Once
A coherent access model rather than checks scattered through the code as needs arise.
Portal Development
Portal Development That Reduces Support Load Instead of Adding To It
A portal is worth building when it removes work: customers checking their own status instead of calling, partners submitting data instead of emailing spreadsheets. Portal development fails when it becomes another system to maintain that nobody uses — which happens when the permissions are wrong or the data behind it is stale.
We Build Portals People Actually Use
Adoption is the measure. A portal with low usage has increased the work rather than reduced it.
Live Data
Connected to the systems of record, because a portal showing stale data is worse than none.
Built Around Real Tasks
What people currently phone or email about, which is what self-service has to cover.
Audit Trail
Who did what and when, which matters as soon as anything is disputed.
Honest Scope
Where an existing product would serve, we will say so.
Portals, Explained
What Kinds of Portal Are There?
Four common types with genuinely different requirements.
Discuss Your Portal →- 1
Customer Portals
Orders, invoices, status and documents — reducing inbound enquiries.
- 2
Partner Portals
Resellers or suppliers submitting and retrieving data without email.
- 3
Staff Portals
Internal tools consolidating systems people currently use separately.
- 4
Client Portals
Professional services sharing documents and progress securely.
What a Portal Build Covers
Access, the tasks it serves, and the integrations that make the data real.
Where the portal is the product rather than a support surface, see SaaS development.
How We Build Portals
Start from the support inbox. What people currently ask for is the specification.
Analyse Current Demand
What people phone and email about, by volume.
Design the Access Model
Users, organisations and roles as one coherent structure.
Prove the Integrations
Live data early, because stale data kills adoption.
Build the Tasks
Highest-volume requests first.
Measure Adoption
Usage and support volume, because reducing the latter was the point.
Adoption
Why Portals Go Unused
Almost always for one of two reasons, both decided before the build.
The data is not current
A portal showing yesterday's status teaches users to phone and check. Once they have learned that, they do not stop, and the portal becomes an additional system nobody trusts.
This usually happens because live integration was harder than expected, so a nightly export was accepted as a compromise. It is rarely a compromise — it is the difference between a portal that works and one that does not.
Where live integration is genuinely impossible, the honest response is to show the data's age prominently rather than present stale information as current.
It does not cover what people call about
Portals get specified from what is easy to expose rather than from what people ask for. The result covers the simple queries and misses the ones generating the calls.
The support inbox is the better specification. Categorising three months of enquiries by volume tells you exactly what self-service has to handle to make a difference.
It also tells you what not to build, which is usually most of the original feature list.
Questions,answered.
Portal development builds secure, access-controlled areas where customers, partners or staff complete tasks themselves — covering permissions, self-service functions and integration with the systems holding the data.
By looking at support volume. If a large share of enquiries are people asking for information you already hold, a portal removes real work. If they are mostly judgement-based conversations, it will not.
Almost always. A portal showing stale data trains users to phone and verify, and once they do that they stop using it. Where live integration is impossible, show the data age clearly.
Usually, through single sign-on where your organisation runs an identity provider. Worth establishing during scoping because it affects both the build and the security review.
Sometimes, particularly where the requirement is standard document sharing or ticketing. Custom becomes justified when the portal must reflect data from systems no product integrates with.
Still deciding if portal development is right for you?
Talk to UsThe Feature List Was Written by the Wrong People
Portal requirements usually come from a meeting between the people who own the systems and the people who commissioned the project. Both know the business well and neither handles the enquiries.
The resulting list reflects what is available to expose. It is coherent, defensible, and largely disconnected from why customers actually get in touch.
Three months of support tickets sorted by volume is a better specification than any workshop produces — and it usually shows that four functions would remove most of the calls.
Free Portal Review
Find Out What a Portal Would Actually Remove
Tell us what your support team spends time on. We will work out whether self-service would reduce it and what it would need to cover.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists