Turning Your Salesforce Customer Portal Into a 24/7 Knowledge Base Hub

Most knowledge base projects on Experience Cloud are run as a content problem. Somebody counts the top thirty case reasons, writes thirty articles, publishes them to the portal, and waits for case volume to drop.

Then it doesn't, and the conclusion drawn is that thirty articles weren't enough.

Gartner surveyed 5,728 customers and found that only 14% of customer service issues are fully resolved in self-service. For issues customers themselves described as very simple, the figure only reached 36%. Those numbers are not a verdict on how well the articles were written. They're a verdict on whether the right article reached the right person at the moment they were stuck, which is a retrieval problem and a permissions problem long before it is a writing problem.

What "24/7" actually has to survive

Availability is the easy half. Your Experience Cloud site is already up at two in the morning.

The hard half is that at two in the morning there is nobody to compensate for a bad result. Inside the org, when Knowledge search returns the wrong thing, an agent recognizes it, rephrases, remembers the article from last week, or asks a colleague. Every one of those recoveries is a person absorbing a defect in retrieval.

Put the same Knowledge base in front of a customer with no product vocabulary, no history of the article set, and no colleague, and each of those recoveries disappears at once. A 24/7 hub isn't your internal Knowledge base with a login page in front of it. It's your Knowledge base with all of the human error correction removed.

The structure your team uses doesn't cross the boundary

Here's the specific thing that catches teams out. Data Categories are how Salesforce Knowledge gets organized internally, and out of the box they don't come through to an Experience Cloud site as a browsing and filtering experience. Salesforce Knowledge doesn't provide article filtering on Experience Cloud sites natively.

So the taxonomy your content team spent weeks agreeing on, product line, then version, then issue type, is real in the org and largely invisible on the site. The customer gets a search box.

That gap is worth naming precisely because of what teams do next. They see a thin portal, decide the answer is more content, and publish another sixty articles into a structure the customer can't navigate. Search relevance gets worse, not better. Closing the gap means building the navigation yourself, whether by mapping categories onto topics, by driving a filtered article list from the customer's own record, or by a custom component. None of that is a writing task, and none of it appears on a content calendar.

Visibility is a permissions decision, not a publishing decision

The second trap is quieter, because a portal that shows too little looks exactly like a portal nobody uses.

Data category visibility is set through profiles, permission sets, and permission set groups, and it decides which categorized articles a given user can see at all. A profile with no category visibility assigned doesn't see a reduced set of articles. It sees only uncategorized ones.

Which produces a failure mode worth checking before anything else. An article can be published, in the right channel, correctly categorized, indexed, and still be absent for every customer on your portal, because a category visibility assignment on the community profile was never made. Nothing errors. The article simply isn't there.

Before commissioning more content, log in as a portal user and search for an article you know exists. If you can't find it, the problem was never the article count. It's also worth doing this per profile if you run more than one customer community profile, since visibility is assigned per profile and the profiles drift apart over time.

The article is right, the scope is wrong

Even with navigation solved and visibility correct, a general article often fails a specific customer.

A customer doesn't have a question about your product. They have a question about their installation of your product, at their version, under their contract. An article that covers all versions is technically correct and practically useless to somebody on the release where the setting moved.

This is the part of a knowledge hub that actually earns the word hub. The portal knows things the Knowledge base doesn't: which assets this contact's account owns, which entitlement they're covered by, which cases they've already opened. Feeding that context into what gets surfaced, so a customer sees the articles attached to their product and their version before anything else, changes the hit rate more than any amount of new writing.

That's also where the work gets genuinely custom, and where platforms in this category, CRMJetty among them, tend to compete: not on storing articles, which is solved, but on how tightly article surfacing binds to the customer's own records.

Why deflection rate is the wrong number

Now the uncomfortable part, and it cuts against how my own category sells.

Deflection is the standard metric. Articles viewed before a case was submitted, cases avoided, tickets deflected. Every vendor in this market reports it, including us, and it's a bad primary measure because it can't tell the difference between two opposite outcomes.

A customer who reads an article and solves their problem is deflected. A customer who searches twice, finds nothing useful, gives up, and doesn't file a case is also deflected. The second one looks better in the dashboard. They churn quietly.

Set against Gartner's 14%, a rising deflection rate should provoke a question rather than a celebration. If deflection climbed and full resolution didn't, the portal didn't answer more questions. It absorbed more attempts.

Better instruments exist, and they're all unglamorous. Searches that returned no result the customer clicked. Article views immediately followed by a case on the same topic. Repeat searches within a session, which usually means the first answer was wrong. Cases whose resolution cites an article the customer had already opened, which is the clearest sign the article was found and not understood.

What to build instead of more articles

Assume the content is adequate and spend the next quarter on retrieval.

Give the customer a way to browse that matches how they think about your product rather than how your content team files it. Confirm visibility per profile rather than assuming it. Surface articles against the customer's own assets and entitlements. Instrument failed searches and read them weekly, because they are the only unfiltered list of what your customers wanted and didn't get.

Then, and only then, write. The list of failed searches is a far better content brief than a list of top case reasons, because it comes from customers already in the portal trying to help themselves.

Where this stops working

Some of this won't apply to you.

If your product is genuinely simple and your customer base small, the whole apparatus is overhead, and a well-maintained FAQ page beats a knowledge hub on both cost and outcome. If your support volume is dominated by problems that require account-specific action, a password reset that only your team can perform, a billing correction, a shipment that has to be rerouted, no article resolves those and knowledge is the wrong investment. Case management and better in-portal actions are.

And if nobody owns article maintenance after launch, none of the above matters. Knowledge decays. Products change, screenshots go stale, and a portal full of confidently wrong articles generates more contacts than an empty one, because now the customer has to check whether what they read is still true.

A 24/7 knowledge hub isn't a content library with a login. It's a retrieval system that happens to contain articles, and it's owned continuously or not at all.