A Customer Self-Service Portal on Experience Cloud That Customers Actually Use

#The situation this design answers

Most service teams spend a surprising share of their day on requests customers could handle themselves. Where is my request? Can you send me that document again? Can you update our billing contact? Each one is quick to answer, and together they crowd out the work that actually needs an expert.

Our team has built customer and partner portals on Salesforce Experience Cloud across several earlier projects. This study brings that experience together around a common situation: a business-to-business service company whose customers phone and email for routine things, whose service team works in Service Cloud, and who wants a portal that customers will actually prefer to the phone.

The aim is not to push customers away. It is to make the easy things instant, so the service team has time for the hard ones.

#What we design

01 A portal built around customer tasks

We start by listing the tasks customers contact the service team about, and design the portal around the most frequent ones: submitting a request, checking its status, finding an answer, updating details and downloading documents. Each task gets a clear, direct path from the home page.

02 Request submission and tracking

Customers submit requests through guided forms that ask for the right information up front, so the service team does not have to come back with questions. Each request becomes a case in Service Cloud, and the customer can see its status and updates in the portal at any time.

03 Knowledge articles

Knowledge articles answer common questions before a request is created. Articles are suggested as a customer describes their issue, which turns many would-be cases into resolved questions.

04 Account details and documents

Customers can update their own contact details and download the documents relevant to their account, such as agreements, reports or certificates, without asking.

05 Guided flows and components

Screen flows and Lightning Web Components shape each task, validate what the customer enters and make the experience feel like an application, not a database form.

06 Sharing designed for the outside world

Sharing sets, profiles and permissions decide precisely what each customer user can see, normally the cases, documents and contacts of their own account. This is designed and tested deliberately, because a portal exposes the org beyond the company's walls.

07 A clear route to a person

Every page offers an obvious way to reach the service team. Self-service works best when customers know a human is there if they need one.

#A customer visit, end to end

The operations manager at a customer company needs a copy of last quarter's service report and wants to check on an open request. Instead of emailing, they sign in to the portal. The home page shows their open requests with current status; the one they care about was updated this morning. They open the documents area, download the report and update the phone number for their accounts contact while they are there.

Later, a new issue comes up. They start a request, and as they describe it, the portal suggests a knowledge article that answers the question. They read it and do not need to submit the request at all. The service team never sees any of this, because none of it needed them.

#Why sharing deserves the most design time

The visible parts of a portal, the pages and forms, are the easy part. The hard part is invisible: making sure every customer user sees exactly what they should and nothing else.

Internal sharing settings are usually not designed with external users in mind. A rule that is harmless for employees can expose another customer's cases or documents if it is inherited by the portal. That is why we design portal sharing from first principles, scoped to the customer's account, and test it with realistic customer users across several accounts before launch. We test what each user can see, what they cannot, and what happens at the edges, such as contacts who work for more than one customer.

#Why knowledge comes first

The cheapest support interaction is the one that never becomes a case. Knowledge articles, written in customers' language and surfaced at the moment they describe their problem, deflect routine questions more effectively than any form.

That means the knowledge base needs to be ready when the portal launches, not added later. We help service teams identify the questions they answer most often and turn the best answers into articles, so the portal is useful from day one.

#Making the portal feel like part of the brand

Customers judge a portal in the first minute. If it looks like a generic system screen, they assume it will be hard to use and pick up the phone instead. Experience Cloud gives enough control over branding and layout to avoid that, and it is worth using.

Brand and tone. The site carries the company's own branding, and the wording on every page is written in the customer's language, not internal jargon. "Track my request" works better than "Case list".

Mobile first. Many customers check a request on their phone between other tasks. Layouts, forms and documents are designed to work on a small screen before they are refined for a desktop.

Fast paths for frequent tasks. The home page puts the most common tasks one click away, informed by the contact reasons gathered at the start.

Status in plain words. Request statuses shown to customers are written for them, so "Waiting on you" or "In progress with our team" replaces internal status names that mean nothing outside the company.

Accessibility. Forms, colors and navigation are designed to be usable by everyone, including people who rely on keyboards or screen readers.

These details decide whether customers choose the portal over the phone. A portal that is technically complete but feels foreign will be ignored, and the service team will keep answering the same questions.

#How we deliver a portal like this, end to end

Start with contact reasons. The most frequent reasons customers contact the team decide what the portal does first.

Design the access model early. Sharing and permissions are designed alongside the experience, not after it.

Prepare the knowledge. The top questions are written up as articles before launch.

Build guided tasks. Flows and components make each task simple and validated.

Test with real scenarios. Customer users from several accounts test the portal before it opens, with special attention to what they can see.

Launch and learn. After launch, contact patterns show which tasks need improving next.

#The decisions that matter

Tasks over pages. A portal organized around what customers come to do gets used; one organized around the org's structure does not.

Sharing from first principles. Designing external access deliberately prevents the most damaging portal mistakes.

People stay visible. A clear route to the service team keeps self-service from feeling like a wall.

#What a portal changes

#What we would tell a service team considering a portal

List the reasons your customers contact you and design for the most frequent ones first. Spend your hardest thinking on who can see what, prepare your knowledge before launch, and keep your people easy to reach. A portal built that way does not replace your service team; it gives them back the time to do what only they can do.