Custom client portals: when to build one

A custom client portal is worth building when clients repeatedly need the same project updates, documents or decisions, and your existing software cannot give them useful access without exposing internal information. The first version should answer one recurring question using records your team already maintains, with clear limits on what clients can see, change and request.

For a service business, the buying decision starts with the coordination work. A portal can reduce avoidable status chasing only if clients trust what it shows and staff do not have to maintain a second set of records.

Start with the question clients keep asking

“Which drawing is approved?” “What happens next?” “Are you waiting for anything from us?” Each question interrupts someone who must check a schedule, open a folder or ask accounts before replying. Different people may then send different answers to the same client.

Before scoping a portal, review a representative week of these requests. Record the question, who answers it, where they find the answer and roughly how long the reply takes. Include time spent correcting an earlier answer or resending a document.

This gives you a practical starting point: perhaps project status and current drawings cause most interruptions, while invoices rarely generate questions. Build around the first journey. Do not add a payments section simply because other portals have one.

Also check whether clients would use a portal. A clear update email may be enough for a short engagement with few documents. A longer project with several client-side stakeholders is more likely to benefit from a shared view.

Use an existing portal or commission a custom one?

First test the guest access or client portal in the software you already use. It may cover document sharing, project milestones and simple approvals adequately. Configuration is usually the sensible starting point when the process fits and permissions can be restricted properly.

A custom client portal becomes more useful when:

• The client journey crosses several systems, such as a project schedule, document store and accounting package.
• Different client contacts need different views or approval rights.
• Requests must follow your own review process before internal records change.
• Existing portals require staff to copy information or expose details clients should not receive.

Compare the whole operating cost: setup, integrations, hosting, support, access administration and changes when the underlying tools change. If the source records are unreliable, address that first. An attractive portal will still publish an outdated date.

Define three permission boundaries

What clients can see

List the information clients need and its authoritative source. A typical first version might show the current stage, next milestones, issued documents and decisions waiting on the client.

Be explicit about exclusions: internal margins, supplier costs, draft documents and internal notes. Permissions must apply to the underlying records and downloads, not just to buttons hidden on the screen. Test that a contact from one client cannot open another client's project or file.

What clients can change directly

Keep this list short. Updating an allowed contact field and uploading a document into a named request are straightforward examples.

Approving a variation needs more care. Show the exact scope, amount and revision being approved. Limit approval to an authorised client contact, record the identity and time, and define what happens if that variation changes afterwards. A click should not accidentally approve a later revision.

What clients can request

Changes to scope, milestone dates or site visits can create a request for the responsible team member. The client should see that it was received and whether it is awaiting review, accepted or declined.

Define who handles each request and how an overdue response is escalated. A portal that accepts requests without an internal owner creates another inbox to overlook.

A hypothetical fit-out contractor in Dubai

Consider a hypothetical contractor managing eight to ten office projects. Drawings live in a shared document store, variations in a tracker and invoices in the accounting system. The initial portal answers: “What is happening on my project, and which documents should I use?”

The client sees the project stage, the next three milestones and drawings marked “Issued for construction”, each with its revision number. If invoices are included, amounts appear in AED with their payment status from accounts and a visible refresh time.

A named approver can respond to a specific variation. Other contacts can upload a requested landlord no-objection letter or ask for a site visit. A requested date change becomes a task for the project manager; the published schedule changes only after the internal review.

Now consider a difficult case: a client asks why last week's drawing disappeared. Revision C has replaced revision B. The portal clearly identifies C as current and keeps B in a labelled superseded history, with the old download carrying the same warning. Nobody needs to guess which file is safe to use.

Keep the underlying systems authoritative

For every field, write down the source system, record identifier, update frequency and person responsible for accuracy. Milestones might belong to the project schedule, documents to the document store and invoice status to accounts.

A portal may hold a cached copy for performance, but it should not become a competing source of truth. Show when information was last refreshed. If an accounting connection fails, retain a clear “last updated” warning rather than silently presenting old payment information as current.

Write-back actions need an explicit result too. If an upload or approval fails to reach the source system, show that it is pending or failed and alert its owner. Do not show a successful approval just because the browser accepted a click.

What to ask a client portal development provider

Before approving a scope, ask the provider to demonstrate:

1. One complete journey: a client finds the latest document, submits a request and sees the resulting status.
2. Access boundaries: each client and role can reach only its permitted records, including direct file links.
3. Revision handling: an old document or changed approval cannot be mistaken for the current version.
4. Failure handling: an unavailable source system, duplicate submission or failed write has a visible recovery path.
5. Ongoing ownership: someone manages invitations, departing contacts, unanswered requests and support.

Pilot with a small group of real users. Compare repeat questions, time spent maintaining the portal and outstanding client decisions with your starting position. Expand when the first journey is useful and maintained reliably.

Scope the journey before the interface

SolvTree builds client portals as part of its custom systems work. Its integration and delivery approach starts by checking how the existing tools can connect and what the scoped work requires.

If you are weighing a custom portal, discuss your most repeated client question with SolvTree. Start with the information clients need, its current source and the actions they should be able to take. Those decisions make a first-build scope concrete.