Portal Development
Customer and partner portals succeed or fail on three decisions made before any interface is designed: which roles exist, what each may see and do, and where each field’s system of record lives. Every portal we have been called in to rescue had a screen design and no agreed answer to those questions.
Permissions before screens
A portal is a permission model with an interface attached. That ordering is not rhetorical: the questions of which roles exist, what each may see, and which system owns each field determine what can be built at all, and they are expensive to answer late.
Portals that fail typically had an attractive design approved early and a permission model discovered during build. The rework is not cosmetic — it reaches into data access, integration and audit, and it is why portal projects acquire their reputation for overrunning.
The commercial objective is usually deflection: work customers or partners currently do by emailing your team, they do themselves. That means the measure of success is inbound volume reduced, and it should be baselined before the build starts.
What a portal engagement covers
Six workstreams. The first two are signed off before design begins.
Role and permission matrix
Every role enumerated with what it may see, create, change and approve — signed off before design, because permission models discovered late are rewrites rather than changes.
Data ownership map
The system of record for every field, and whether the portal reads live, reads a cache, or owns the data. Ambiguity here surfaces as data that disagrees with itself.
Authentication and audit
Login, SSO where required, session handling, and audit logging of who saw and changed what — which is a statutory requirement in some sectors and a dispute-resolution tool in all of them.
Self-service journeys
The specific tasks users will complete unaided, chosen from your actual inbound volume so that the build targets deflection rather than plausible-sounding features.
Integration
Connections to the systems behind the portal, with failure behaviour designed rather than assumed — a portal that shows stale data confidently is worse than one that says it cannot reach the system.
Admin tooling
The screens your own team needs to manage users, resolve problems and answer questions, which is routinely omitted and immediately missed.
How a portal engagement runs
Define roles
Role and permission matrix enumerated and signed off, with the awkward cases resolved rather than deferred.
Map the data
System of record per field established, and the portal’s read or own position decided for each one.
Baseline the volume
Current inbound support volume measured by task type, so deflection can be judged against a real number after launch.
Build journeys
The highest-volume self-service task built first, end to end including integration and admin tooling, and put in front of real users.
Extend and hand over
Remaining journeys delivered, then documentation and admin training so your team can operate it.
Data strategies for a portal
How the portal relates to the systems behind it.
| Dimension | Read live | Read a cache | Portal owns the data |
|---|---|---|---|
| Freshness | Always current | Lags by design | Authoritative |
| Backend load | High | Low | None |
| Behaviour when backend is down | Portal degrades | Portal serves stale | Unaffected |
| Complexity | Low | Moderate | Reconciliation needed |
| Right for | Balances, order status | Catalogues, documents | Portal-only records |
| Wrong for | High-traffic reads | Anything financial | Data another system owns |
What we will stop and ask about
We will not build screens against an unresolved permission model. Where two departments disagree about what a partner may see, that is a business decision and encoding a guess produces either a data exposure or a rework. We will stop and ask for the decision, which occasionally makes us the reason a timeline pauses.
A portal also cannot reduce inbound volume for tasks that require judgement. Where customers email because their situation is genuinely non-standard, self-service returns them to email with an extra step first. We identify those from your ticket data and leave them out of scope deliberately.
- Roles and permissions are signed off before design, not discovered during build.
- Decide per field whether the portal reads live, reads a cache, or owns the data.
- Baseline inbound support volume so deflection can be measured.
- Admin tooling is not optional; your team needs it on day one.
Questions buyers ask about this
Why start with roles rather than screens?
Because a permission model discovered late is a rewrite, not a change. It reaches into data access, integration and audit. Every portal we have been asked to rescue had approved designs and no agreed answer to who may see what, and the cost of resolving it after build is several times the cost of resolving it before.
Can the portal read from SAP?
Yes, and we will specify per field whether it reads live, reads a cache, or owns the data — before anyone draws a screen. Live reads suit balances and order status. Cached reads suit catalogues and documents. Portal-owned data needs a reconciliation position, which is why it is a decision rather than a default.
How do you measure whether the portal worked?
Against a baseline of current inbound support volume by task type, taken before the build. If customers were sending four hundred order-status emails a month and now send eighty, that is the number. Login counts and page views do not tell you whether the portal removed work.
What about audit and compliance?
Audit logging of who viewed and changed what is built in rather than added later, because retrofitting it into an existing data-access layer is disproportionately expensive. In regulated sectors we scope the retention and access requirements explicitly during the permission workstream.
Should the portal be a separate application or part of our website?
Usually separate, sharing branding but not the same codebase or hosting model. An authenticated application and a public marketing site have different rendering, security and release requirements, and coupling them means every marketing change carries authentication risk.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.