Build a client portal your customers will actually use

A client asks which document you need, another replies to an old email, and a colleague promises to send an update after lunch. A useful client portal gives these conversations a shared place: what is happening, what is needed and who will act next.

For a consultancy or professional-services firm, start with one recurring customer task. The workflow below is a proposed approach to test with your own team. It is not a claim about results from a BrandFlame client.

Start with the questions your clients already ask

Review recent project emails and list the questions that required someone to look up an answer. Keep the wording customers use: “Have you received the files?”, “Which version should I review?” and “What happens after this meeting?” are useful starting points.

Choose one service with a reasonably consistent process. Write its stages in plain language, such as information requested, review in progress, feedback needed and work complete. Explain what each stage means to the client. A label such as “in progress” needs a next step and an update date beside it.

Give every active project a named contact. Agree who covers that person’s absence before putting their name in the portal. The interface should reflect a working responsibility, including how an urgent question reaches someone.

Define a small first version

A first version can contain four useful areas:

• Your next action: the document, answer or decision currently needed, with an agreed date where appropriate.
• Project progress: the current stage, a short explanation and when it was last updated.
• Documents: the current files, their purpose and whether they are ready for review.
• Contact: a named person and a clear way to ask a question about this project.

Keep internal working notes separate from information intended for the client. A staff checklist may contain unfinished judgements or commercial details that should never appear in the customer view. Test that separation with an external account, including direct document links.

Decide what happens after completion. Customers may still need the final deliverable, a record of their approval or a route for a new request. Define access and retention with the people responsible for your information policies rather than leaving projects open indefinitely by accident.

Check whether your existing tools can do the job

You may already have enough software for a pilot. Microsoft documents an upload-only file-request feature in OneDrive and SharePoint, subject to administrator settings. Uploaders cannot browse the destination folder. An unsigned uploader’s entered name is not verified identity, so an upload link alone should not be treated as a private client workspace. Microsoft’s file-request guidance explains the distinction.

For sharing documents back, Microsoft describes links restricted to named recipients and options for removing access. The experience depends on account and sharing settings. Review its external-sharing guidance before choosing an approach.

Use this as a practical buying question: can your existing system show the right information to the right customer and keep it current? Consider a dedicated portal or business application when your workflow requires permissions, approvals or connections that the existing setup cannot support reliably.

Connect updates to a clear source

Choose where each piece of information is maintained. The project system might own progress, the document store might own files, and the customer record might own contact details. Record those decisions before connecting them.

For every automated update, specify what happens if it fails. Show when information last refreshed, send an internal exception to a named person and provide a manual recovery step. A failed connection should never silently change “waiting for a document” into “ready for review”.

AI can help draft a plain-language update from approved project notes, with a person checking it before it reaches the customer. Keep dates, commitments and completion decisions tied to the actual project record. Test with fictional project information before considering access to customer material.

A worked example: collecting information for a consultancy review

Suppose an independent consultancy needs a process summary, an organisation chart and answers to three questions before a workshop. This is an illustrative scenario.

The portal lists each request separately and explains the format expected. When the client uploads a file, its label changes to “received, awaiting review”. The consultant checks it and either accepts it or asks a specific follow-up question. Only accepted material counts towards readiness for the workshop.

If the organisation chart is outdated, the client sees which item needs attention and why. The other accepted items stay complete. A colleague covering the project can see the same status without reading the entire email history.

The benefit to test is straightforward: can both parties identify the next action without asking for another update? Measure that in your pilot instead of assuming the portal will save a particular number of hours.

Test the awkward cases before rollout

Run the workflow with fictional clients and deliberately test a wrong file, a replaced document, an expired invitation, a missed update and a departing staff member. Confirm that one client cannot open another client’s project by changing a URL or following an old link.

Then invite a small, agreed pilot group and observe where people stop. Record repeated status questions, requests needing clarification, staff time spent maintaining the portal and tasks completed without assistance. Look for a simpler workflow before adding more features.

Our professional-services overview connects this work with the wider customer journey. Start with one handover that currently causes confusion, give it an owner and make its next action visible.