The ServiceNow Portal Playbook

Write down the problem the portal solves in one sentence — for example one front door for IT, HR and facilities requests.

Then pick three to five measures you can track from day one:

• Share of requests raised through the portal instead of email or phone
• Self-service rate (issues solved by an article, with no ticket)
• Time from request to fulfilment
• Satisfaction score after each request

List the groups who will use the portal — employees, managers, new joiners, customers — and what each needs most.

Don't guess the top tasks: pull them from data. Look at the most-requested catalog items, the most common incident categories, top knowledge searches and the reasons people call the service desk. Rank the top 20; they become your homepage and navigation.

Inventory current portals, catalog items, knowledge bases and intranet pages. For each, note whether it's used, who owns it and whether it's still accurate.

Also record your instance version, the applications and plugins you're licensed for, and any customisations that will need to move.

Run a short workshop with every department that will publish into the portal (IT, HR, facilities, communications). Agree what's in the first release, who owns each area, and who signs off.

Employee Center is ServiceNow's ready-made employee portal. It's built on Service Portal and brings topics, content publishing and a single experience across departments. Start here for an employee portal.

Service Portal gives you a blank framework of pages, widgets and themes — the right choice for highly custom or non-employee portals.

Customer Service Management includes its own customer portal; use it if you're serving external customers on CSM.

Whichever you pick, configure what's included before writing custom code.

Check which applications you're licensed for (for example ITSM, HR Service Delivery, CSM) and which portal features they unlock. Activate any plugins in a development instance first and review what they add.

Create a scoped application for your custom work, connect source control if you can, and agree how changes move from development to test to production. Agree naming conventions for pages, widgets and themes so the build stays tidy.

Choose the smallest release that covers the top tasks from discovery — often the homepage, search, 10–20 catalog items, key articles and My requests. Put everything else on a roadmap.

Group content into topics named the way users talk: Pay & benefits, Laptops & phones, Travel, rather than department names. Test your draft with a quick card sort or tree test with five to ten real users.

In Employee Center, topics are managed with the taxonomy tools; in Service Portal, they usually become categories and navigation menus.

Merge duplicate items, retire ones nobody uses, and rename the rest as tasks: Request a new laptop rather than Hardware – Laptop – Standard. Keep forms short and ask only what fulfilment really needs.

Decide on article templates, owners and review dates. Map your most-needed articles to topics so every topic page answers common questions before people raise a ticket.

Configure search sources (catalog, knowledge, other content), add synonyms for internal jargon, and promote the best result for your most common searches. Test with the real search terms you collected in discovery.

Sketch the header menu, homepage quick links and footer. Every top-20 task should be reachable in two clicks or one search.

Wireframe the homepage, a topic page, a catalog request, My requests, search results and a knowledge article. Keep them low-detail and test them with five users — you'll find most problems early.

Bring in brand colours, typography and logo, then define a small set of design tokens: colours, spacing, corner radius, shadows. In Service Portal these map to theme variables and shared CSS, so every widget looks consistent.

Define the building blocks once — cards, buttons, form fields, alerts, empty states — and reuse them across pages instead of styling each widget separately.

Aim for WCAG 2.1 AA: enough colour contrast, visible focus, labels on every field and full keyboard support. Design for phones first; many people will raise requests from one.

Agree a simple voice: short sentences, everyday words, no internal acronyms. Apply it to page titles, item names and help text.

Create (or configure) the portal record, its URL, theme, header and footer, homepage and login experience. For Employee Center, start from its configuration rather than building pages from scratch.

Lay out pages with containers, rows and columns in the page designer, and use included widgets wherever they fit. Every widget you don't write is one you don't maintain.

When you do need a custom widget, clone a similar included widget instead of editing the original, so upgrades don't overwrite your work.

• Keep server scripts lean: query only the fields and records you need
• Never hard-code record IDs; use widget options or system properties
• Put shared logic in script includes, not copied between widgets
• Expose options so content owners can reuse the widget

Create catalog items and record producers with clear variables and helpful descriptions, and automate fulfilment with Flow Designer. Send notifications at the moments users care about: submitted, approved, done.

Use user criteria to control who can see each item and article, and check role-based access. Impersonate different users — an employee, a manager, a contractor — to confirm each sees the right portal.

Use the Automated Test Framework to cover your most important catalog requests and flows, and run the suite before every release so upgrades and changes don't quietly break them.

Give real users the top tasks as scenarios and watch them work. Measure whether they succeed and how long it takes; fix what trips them up before launch.

Run an automated checker, then test by hand: complete key tasks with only a keyboard, and with a screen reader such as NVDA or VoiceOver.

Test page load times on a normal connection, look for slow widgets, and try the portal on phones, tablets and each supported browser.

Confirm access rules hold for every user group and that no widget exposes data its viewer shouldn't see.

Publish the key articles, announcements and quick links before launch. Brief the service desk and fulfilment teams, and plan how you'll point people to the portal — email signatures, auto-replies, intranet links.

Move changes to production the way you agreed, follow a cutover checklist, and smoke-test the top tasks in production straight away. Keep a short support period where the project team watches feedback closely.

Track the measures from discovery: portal share of requests, self-service rate, fulfilment time and satisfaction. Watch searches that return nothing and requests people start but abandon — they show you what to fix next.

Review feedback and data monthly, keep a prioritised backlog, and ship small improvements often. Set up light governance so new items and content follow the same standards as the launch.