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

> Customers emailed and phoned for things they could have done themselves: checking a request, updating details, downloading a document. Drawing on the customer and partner portals our team has built on Experience Cloud, this is how we design a self-service portal that takes routine work off the service team without hiding the people behind it.

- Source: https://synconai.com/case-studies/customer-self-service-portal-experience-cloud
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Organisation: A business-to-business service company whose customers contact the service team for routine requests, status updates and documents
- Industry: Commercial & Business Services
- Products: Experience Cloud, Service Cloud, Knowledge, Sharing Sets, Flow, Lightning Web Components
- Service: Salesforce Experience Cloud (https://synconai.com/salesforce-experience-cloud)
- Reading time: 6 minutes

## In short

A customer self-service portal on Experience Cloud works when it is designed around the tasks customers come to do: submitting and tracking requests, finding answers in knowledge articles, updating details and downloading documents. Guided flows make each task easy, sharing sets show customers only their own records, and Service Cloud keeps the portal and the service team on one set of data.

## Key points

- Design around tasks, not pages. Customers arrive to do something specific; the portal should make that one thing quick.
- Sharing is the hardest part. Deciding precisely what each customer may see is where portals succeed or leak.
- Knowledge first. Good articles answer questions before a case is ever created, which is the cheapest support there is.
- Never hide the people. A clear route to a human keeps trust when self-service is not enough.

## What sits behind a self-service portal

At the top is the customer experience: a branded Experience Cloud site where customers sign in, submit and track requests, search knowledge articles, update their details and download documents. Beneath it, guided flows and Lightning Web Components shape each task so customers can complete it without help. Below that, sharing sets and permissions decide exactly which records each customer can see, normally their own account’s cases, documents and contacts. At the base, Service Cloud holds the cases, knowledge and accounts that the service team works from, so the portal and the team always see the same information.

### 1. Experience

- Branded site
- Sign-in
- Requests
- Knowledge
- Documents

Designed around the tasks customers come to do.

### 2. Guided tasks

- Screen flows
- Lightning Web Components
- Validation

Each task can be finished without a phone call.

### 3. Access

- Sharing sets
- Profiles and permissions
- Account scope

Each customer sees only what is theirs.

### 4. Service data

- Cases
- Knowledge articles
- Accounts and contacts

One set of records for portal and team.

## 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

| Area | Without a portal | With a portal |
| --- | --- | --- |
| Request status | Customers phone or email to ask | Status visible in the portal at any time |
| Routine questions | Answered one by one by the team | Answered by knowledge articles |
| Documents | Resent on request | Downloaded by the customer |
| Contact details | Updated by the team | Updated by the customer |
| New requests | Incomplete emails needing follow-up | Guided forms that collect the right details |
| Service team time | Spent on routine contacts | Focused on issues that need expertise |

## 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.

## Questions

### Experience Cloud or a custom-built portal?

When the portal’s job is to give customers access to cases, knowledge, accounts and documents that already live in Salesforce, Experience Cloud is usually the better choice: the data, security and service processes are already there. A custom portal makes more sense when the experience is a product in its own right with needs far beyond Salesforce data.

### How do you make sure customers see only their own information?

Through sharing sets, profiles and permission design scoped to the customer’s account, tested with realistic customer users before launch. Sharing is designed deliberately rather than inherited from internal settings, because a portal exposes the org to the outside world.

### Will a portal reduce calls to the service team?

It reduces routine contacts when the portal makes routine tasks genuinely easier than calling. That depends on good knowledge content, simple guided tasks and clear status information. We design for that and measure contact patterns after launch rather than promising a number in advance.

---

SynconAI. https://synconai.com/case-studies/customer-self-service-portal-experience-cloud