ServiceNow Employee Center Optimisation

Optimising an Employee Center that is already live starts with evidence rather than redesign: the search log, the dead ends that look like low adoption, and the requests employees still route around the portal. This page covers navigation and findability, content audit and refresh, request availability and workflow completion, mobile and personalisation, adoption measurement, a two-week tuning cycle that keeps every change testable, and when optimisation is the wrong move.

Navigation Architecture and Information Findability

Employee Center serves diverse employee populations: new hires, managers, remote workers, contractors. Navigation must work for all. We audit current navigation: what categories exist, are they logical, can employees find what they need. Common issues: navigation is too technical (IT-centric naming rather than employee-friendly), search doesn’t work well (employees can’t find answers via search), categories have similar names (employees don’t know which to click). We optimize: reorganizing categories by employee need rather than system structure, improving search to handle varied terminology (employee searches for ‘internet’ and finds networking article), adding related links so browsing is easier. We test navigation with real employees: task-based testing (can you find how to request leave, can you find office locations) reveals navigation pain points.

Content Audit and Refresh Strategy

Employee Center content goes stale: policies change, processes evolve, systems are updated. We audit: what content exists, when was it last updated, is it accurate, is it being used. Common findings: documentation reflects old processes (employees follow old steps, result is confusion), critical information is missing (employees don’t know how to do common tasks), content is scattered across portals (information about leave is in HRSD, leave policy is in HR portal, nobody knows which to check). We develop refresh strategy: retire outdated content, create missing documentation, consolidate scattered information. We also establish ownership: who is responsible for keeping content current as processes change.

Self-Service Request Availability and Workflow Completion

Employee Center should enable common requests: submit leave request, request equipment, update profile, track request status. We audit: what requests are available, how many employees use self-service versus contacting helpdesk, what requests are missing. Common issues: employees don’t know certain requests are available self-service, workflow requires information employees don’t have (approvers approve leave but workflow requires department code which employees don’t provide), requests get stuck (no status update so employee doesn’t know progress). We expand self-service: publishing available requests clearly, improving workflow to collect sufficient information without burden, automating status updates so employees see progress. Expanded self-service typically reduces helpdesk volume 15-25: requests that would have needed human processing now complete via self-service.

Mobile Experience and Responsive Design

Many employees access systems from phones and tablets. Employee Center should work on mobile. We audit: is portal mobile-optimized (responsive design), can employees complete requests on mobile, is important information accessible on small screens. Common issues: desktop portal doesn’t work on mobile (requires horizontal scrolling, buttons are too small), workflows have steps that don’t translate to mobile. We optimize: implementing responsive design so Employee Center adapts to screen size, optimizing workflows for mobile (reducing steps, simplifying input), testing on real devices. Mobile optimization typically increases Employee Center usage 10-20: employees use it when convenient rather than waiting to return to desk.

Personalization and Relevant Content Delivery

Generic Employee Center showing same content to everyone is less useful than personalized experience. We implement personalization: show content relevant to employee’s role (managers see manager workflows, new hires see onboarding information), show content relevant to employee’s location (employees in different offices have different office information needs), surface frequently-used content prominently. We also implement context-aware help: if employee is viewing leave policy, surface link to request leave; if employee is viewing desk phone policy, surface link to request phone replacement. Personalization makes Employee Center more useful and increases usage.

User Feedback Collection and Continuous Improvement

We establish feedback mechanisms: surveys asking what content is missing, what workflows are frustrating, what improvements would help; ratings on articles so popular content is identified and problematic content is flagged; support ticket analysis showing what employees ask helpdesk (are these questions that Employee Center should answer). We analyze feedback regularly: common themes emerge (many employees searching for same missing content), new requests become visible (new employee segment needs specific content). We prioritize improvements: high-frequency issues affecting many employees, requests from large employee segments, quick wins (easy improvements with high impact). Continuous improvement based on feedback keeps Employee Center relevant as employee needs evolve.

Adoption Measurement and Engagement Tracking

We measure adoption: what percentage of employees use Employee Center, which features are used most, how has usage grown over time. Low adoption indicates: employees don’t know it exists, navigation is poor, content doesn’t meet needs. We also measure engagement: how frequently do employees return, what is session duration, do employees complete actions they started. We track: helpdesk volume to confirm Employee Center reduction is occurring, employee satisfaction with Employee Center. We communicate results: showing adoption trends, recognizing improved areas, committing to address top complaints. Transparency builds adoption: employees see the system improving based on feedback.

Integration with HR Systems and Single Sign-On

Employee Center should integrate with HR systems so employees see current information. We assess: does Employee Center pull current employee data (department, manager, leave balance), can employees see status of HR requests they’ve submitted, does single sign-on work (employees can access without additional login). Common issues: employee information is out of date, integration broke during system upgrades, single sign-on doesn’t work consistently. We maintain integrations: monitoring data freshness, verifying integration works regularly, testing single sign-on. Integration health ensures Employee Center provides current information employees trust.

Reading the search log before changing any navigation

Much Employee Center tuning work starts with opinions about the menu. A better starting point is what employees already typed into the search box and got nothing back for. Each unanswered query marks a request the portal failed to meet in the words an employee would use, and those words are rarely the ones the IT or HR team uses in its own documentation. A query for a laptop bag may belong under asset accessories, a request for a rota may belong under shift scheduling, and a question about a payslip may belong under payroll correction. Pull the search terms with no results or with clicks that led nowhere, sort them by frequency, and group them by the outcome the employee wanted rather than by the department that owns the answer. That grouping becomes the content backlog.

Read each term against one question: is this a missing article, a missing catalog item, an existing article filed under a different title, or a request that belongs in another channel altogether? Those four answers call for four different fixes. A missing article needs writing. A missing catalog item needs a decision about whether self-service is appropriate at all. A mistitled article is usually the cheapest win, since the content already exists and only needs better headings and synonyms. The fourth case, where the honest answer is a conversation with a manager or a call to a named team, should be routed on purpose rather than forced into a form.

Dead ends that look like low adoption

Low use of a request type does not always mean employees ignore it. Sometimes they start it and stop. A leave request that asks for a cost center the employee has never seen, an equipment order that needs an asset tag held only by the facilities team, or a profile update that routes to an approver who has since left the company will all produce the same pattern as an unpopular feature: few completions and many sessions that never reach the end. The abandoned sessions are visible in the workflow records if you look for requests that were opened and never submitted, or submitted and never moved past the first step.

Treat each dead end as a defect in the request rather than a training gap. Check the three causes that most often stop an employee. The first is a required field that takes its value from a system the employee cannot see. The second is a branch of the flow that depends on an approver or group with no members. The third is a confirmation screen that gives no next action and no reference number. Fixing the field source or the empty group often moves completion rates further than an announcement email, at lower cost.

Choosing which requests to fix first

A portal with many request types cannot be optimized in one pass, and trying to do so spreads the team thin enough that no change gets tested with real employees. Rank the candidates on three axes: how many employees reach the request, how often they contact the helpdesk about it afterwards, and how much of the fix sits inside your own configuration rather than in another team’s process. The table shows how those axes usually reorder the work.

When optimization is the wrong move

Optimization assumes the process behind a request is settled. Where it is not, polishing the portal makes things worse, because employees get a smooth route to an outcome the business has not yet agreed. Typical cases include a leave policy under revision, a device refresh scheme that finance has not approved, or a relocation process where two HR teams each claim ownership. Before changing a flow, confirm that one named owner accepts the process as written. If nobody will accept it, the work belongs in process design, and a better form only hides the disagreement until the first contested case arrives.

A second case is a request that should not be self-service at all. Anything that needs judgment on a sensitive employee matter, or that depends on records the employee cannot see, is better served by a case routed to a person who acknowledges it. The warning sign is a free-text box where the employee writes a paragraph and the approver then rewrites it into a form the system could have asked for in the first place.

A two-week tuning cycle that keeps every change testable

A workable cycle separates discovery from change, so each change can be measured against the same search and abandonment data that prompted it. The steps below suit a service owner who signs off each stage, with the portal team doing the build rather than deciding priorities alone.

1. Export the unanswered searches and the abandoned requests for the same window, and agree what counts as a dead end before anyone reads the data.
2. Group the findings by employee outcome and tag each group with its owner in HR, IT or facilities.
3. Choose no more than three changes that touch different request types, so their effects can be read separately.
4. Make each change in a sandbox, then walk the request through as a new hire, a people manager and a remote contractor, noting every point where a choice is unclear.
5. Publish the changes, compare the same measures against the same window in the next period, and record what was learned in the governance log.

Keep the owner of each request type responsible for its completion rate, not the portal team. That split stops the team from chasing portal metrics that do not reflect what an employee actually got done.

Questions a service owner asks after the first cycle

How do we tell a navigation change from a seasonal shift?

Compare the same request type across comparable periods and look at which search terms disappeared, not only total visits. If unanswered queries for a topic fall while completions rise, the change is doing its job. If visits rise but abandonment stays flat, the change moved people around without solving the problem.

Should managers see a different portal from individual contributors?

Sometimes, but only for requests that genuinely differ. A separate tab for team approvals is reasonable. A parallel set of articles that repeats policy text creates two versions of the truth, and the version managers read is usually the one that goes stale first.

Who should write the revised article text?

The owner of the underlying process should write it, and someone who completed that request in the recent past should review it. Text written from the policy document alone is accurate but often impossible to follow at the point of use.

What do we do when the helpdesk resists sending users to self-service?

Agree a short list of requests where the helpdesk hands off with a link and a one-line explanation, then track whether those employees finish. Helpdesk staff often accept redirection more readily when they can see completion results for the tickets they redirected.

Related guides: ServiceNow Employee Knowledge Articles That Get Used and ServiceNow Employee Center and Self-Service.