ServiceNow Customer Self-Service Portal Best Practices

4. Write content for different literacy and technical levels. Some customers are technical; others aren’t. Provide both overview (plain language, no jargon) and details (for technical audience). Screenshots and step-by-step guides help non-technical users.

Knowledge and Content Best Practices

5. Publish frequently-asked questions with real questions from support tickets. When your support team answers the same question 10 times, write an article. Article should match the language customers use, not internal terminology.

6. Keep articles short: one task per article. “How to reset your password” is one article. Don’t mix it with “How to change your email” or “How to your account”. Users should be able to find exactly what they need without reading unrelated information.

7. Update articles after major product changes or support process changes. Outdated articles frustrate customers more than no article. Schedule quarterly content reviews; flag and retire articles that have gone a long time without a review.

8. Include visual aids where helpful: screenshots, video, diagram. Text alone is often insufficient. A short video of the steps can help more than a paragraph of instructions. Screenshots should highlight the relevant buttons or fields.

Self-Service Request Process

9. Make service catalog clear and appealing. Service catalog items should have: clear title, one-sentence description, and expected timeline. Avoid technical jargon. Use icons or images to make items visually distinct.

10. Minimize required fields in requests. Every required field is friction. Ask only what you truly need at submission. Ask follow-up questions via email after request is created if needed.

11. Provide immediate confirmation and status visibility. After submitting a request, customers should see: confirmation number, what was requested, next steps, and expected resolution time. Email confirmation should include a link to check status.

12. Use smart request defaults to pre-fill information. If requesting a password reset, your system should know the customer’s account and department. Minimize what the customer needs to type.

Mobile and Accessibility

13. Optimize the portal for mobile devices. Many customers will use phones. Portal should be responsive, buttons should be large, search should work well on mobile. Test on actual mobile devices, not just desktop.

14. Make the portal accessible to all users. Color contrast should be sufficient for low-vision users. Forms should work with screen readers. Avoid relying only on colors to convey information (status should be shown with text and icon, not colour alone).

Adoption and Promotion

15. Promote the portal in every support interaction. When support staff answer a question, include a link to the knowledge article. When customers call, staff should mention the portal and walk them to it. Promotion drives usage.

16. Make using the portal convenient for repeat customers. Allow saved preferences, bookmarks, and history. Returning customers should be able to quickly access common tasks.

17. Measure and track portal adoption by task type. Which requests do customers self-serve? Which do they still call for? Focus content and improvements on the tasks where self-service is lowest.

18. Plan for feedback and iteration. Portal success is not one-time. Gather customer feedback regularly: are they finding what they need, are there confusing elements, what would make the portal better? Use feedback to guide improvements. Iterate quarterly: add missing content, improve navigation, optimize slow searches. A maturing portal becomes more valuable over time as teams refine it based on real usage patterns.

Common Pitfalls to Avoid

Avoid building a portal nobody uses. Poor search, unclear navigation, or outdated content will drive customers to call instead. Avoid copying support team documentation into the portal; customer-facing writing is different. Avoid requiring login for browsing knowledge; gate only the submit/status features. Avoid surprise costs or hidden processes; if a request has prerequisites (like needing a manager’s approval), state it upfront.

Ranking practice gaps by what your queue shows

Published lists of portal practices can read as if their items were equal, but a live portal rarely has equal problems. A customer who cannot find the password reset article behaves differently from one who finds it and still cannot finish the form. For a support operations lead, the useful question is which gap is generating the most avoidable contacts this month. Start from the queue rather than from a checklist, because the queue records the points where customers gave up and picked up the phone.

Pull the cases opened by phone or chat on a topic the portal already covers. Agent notes may show whether the caller had tried the portal first. Those notes are patchy, but they can be enough to point at the likely failure: search results that bury the answer, article wording that uses internal names, a form that asks for too much, or a confirmation screen that leaves the customer guessing what happens next.

A practice audit in five steps

An audit does not need a new tool. It needs a fixed set of tasks, a way to score them and one owner who can make the changes. Work through the sequence below before proposing any redesign, because a redesign built on guesses can move the problem somewhere else instead of removing it.

1. List the most frequent portal tasks by request volume, then add any low-volume task that generates repeat phone contact.
2. For each task, walk the journey yourself on a desktop and on a phone, and record every point where you would hesitate or need to search again.
3. Match each hesitation to a practice from the table above, and note whether the cause is content, search, form design or missing feedback.
4. Score each finding by the contacts it probably drives and by how cheap the fix is, then ship the cheap, high-contact items first.
5. Repeat the same walk-through after the change, and check whether phone contacts for that task actually fall in the weeks that follow. The portal metrics guide explains which contact measures to compare.

The last step matters most. Teams often declare a practice fixed because the article was rewritten, while the ticket volume for that topic has not moved. Treat a fix as proven only when the contact pattern changes, not when the content changes.

Where a standard practice does not fit your portal

Some widely repeated rules deserve a second look before anyone enforces them. The advice to keep navigation shallow suits a category-driven portal, but a search-first portal can work well with a deeper category tree if search returns the right article on the first attempt. The reverse holds too: a shallow menu paired with weak search sends customers to the phone faster than a deep menu does. Judge each rule by what it does to the customer’s path to an answer, not by whether it appears in a guide.

Gating is another place where practice and purpose diverge. Requiring a login to browse knowledge is often unnecessary, but a status page for a request has to be gated, because it shows a customer’s own record. If a practice would expose a record to someone who should not see it, the security requirement wins over the usability advice.

Questions portal owners raise after the first audit

Should every article be rewritten at once?

No. Rewrite the articles that the queue points to first, because those are the ones costing contacts. A portal with a handful of well-written articles on the top topics often does more for support load than one with a hundred lightly edited articles, and the effort stays manageable for the team that has to keep the content current afterwards. How article lifecycles are managed is worth reading before the rewrite starts, so that the new versions have owners.

How do we stop knowledge drifting back into internal language?

Give writers a short style guide with examples of the caller’s own words, and make the review step check the title and first paragraph against the terms customers actually type into search. Drift often comes from subject matter experts who write the fix and publish it unchanged, so the review should be a customer-language check rather than a technical one. A knowledge quality review routine can carry that check on a regular cycle.

Does a mobile test need real phones if the desktop build passes?

Yes, for the tasks that matter. Emulators catch layout breaks but miss touch behavior, keyboard overlap on forms and file pickers that behave differently on each operating system. A few real devices, used to complete the top tasks, will surface most of what customers would hit.

What if customers still phone after the fixes?

Then the fix addressed the wrong cause, or the callers form a segment with a different need. Ask the agents what the caller said in the first minute of the call. That answer often shows whether the portal failed on content, on trust or on a task it was never designed to handle. If the need is real but rare, the adoption and training plan is where to decide whether to teach the workaround or route it to a person.

Customer self-service portal defaults: tables, widgets and field names

A customer self-service portal built on ServiceNow Service Portal is a set of records: one portal, the pages inside it, and the widgets placed on those pages, each held in its own table. In practice, most best practices, such as search, navigation and form length, become edits to named records that can be reviewed and reversed.

These are common out-of-box table names. Check them on your own instance and release, because applications, releases and customisations change what a portal uses. Newer experiences built in UI Builder use different records.

Example (hypothetical): an owner decides that password reset is too hard to find. They open the page record for the portal homepage, check which widget instance shows the popular items, and change its options rather than altering the widget itself. Because the widget is shared across pages, changing its code would have altered every page that uses it.

Where is the portal address suffix set?

On the portal record in sp_portal, in the URL suffix field. The Service Portal default is often sp, and Customer Service installs commonly add a separate suffix. Check the record rather than assuming, because many organisations rename it.

Which field decides who can read an article?

Access is set mainly through user criteria on the knowledge base the article sits in, such as Can Read and Can Contribute. Review those criteria records, and any restriction set on the article itself in your release, before assuming a customer will see an article that staff can open.

Where do portal requests end up?

Catalog requests normally create a request (sc_request) with requested items (sc_req_item). Support questions go to a case record when CSM is in use. See the customer self-service portal guide, knowledge management and request fulfilment.