Common ServiceNow Employee Center Mistakes and How to Avoid Them

This guide sets out eight common Employee Center mistakes. Many of them start with navigation built around HR's internal structure rather than employee tasks. For each mistake the page explains the problem and the fix, from stale policy content to launching without change management.

Mistake: Over-Complicated Information Architecture

Many organisations launch Employee Center with a hierarchy that mirrors HR’s internal structure: separate sections for compensation, benefits, payroll, leave, personnel records. This makes sense to HR, but employees search for “pay stub” and expect to find payroll information without knowing it is labelled “compensation.” When the navigation does not match how employees think, they give up.

The fix: base information architecture on employee tasks and questions, not HR structure. Organise by “what do I need to do” (update my direct deposit, enrol in benefits, request leave) rather than “which HR team handles this” (compensation, benefits, payroll). Validate the structure by asking employees and managers to find common tasks; if they guess wrong, reorganise.

Mistake: Stale or Incorrect Policy Information

Employee Center often hosts policy documents, benefit guides, and FAQs. These need regular updates, but ownership is unclear. A policy changes; HR updates the system of record but forgets to update the Employee Center copy. Six months later, employees are reading outdated information and making decisions based on wrong data.

The fix: assign an owner to each content item and set a review date. Employee Center should show when content was last updated, and if it has not been reviewed within the period you set, flag it for review. Integrate content management into HR’s change processes: when a policy is updated, automatically flag the Employee Center equivalent for review. Use workflows to ensure policy updates in the core system trigger content reviews.

Mistake: Hidden Features Employees Do Not Know Exist

A well-designed Employee Center has many helpful features: view leave balance, submit leave requests, download tax documents, update emergency contacts, view benefits coverage. But if these are buried in nested menus, employees do not find them. They continue using workarounds (emailing HR for leave forms, calling payroll for pay stubs) even though the portal has the tools they need.

The fix: use analytics to track what employees do in the portal. If nobody is using a feature, make it more prominent. Add a dashboard with quick links to the top 10 tasks. Promote new features via email: “did you know you can now view your benefits coverage in the portal?” Push feature adoption actively; do not assume employees will explore and find things.

Mistake: Poor Search and Navigation

Employees approach the portal with a specific need: “I need to update my address” or “how much leave do I have left?” If the portal forces them to browse menus instead of searching, they get frustrated. A search that returns irrelevant results (searching “leave” returns benefit updates that mention “leave of absence”) is worse than no search.

The fix: invest in search quality. Tag content with keywords employees use. Test search with real employee questions. If common searches return no results or irrelevant results, add content to address that gap. Consider a chatbot for top 10 questions: “did you mean to request leave?” with a shortcut to the leave form. This catches employees who could not find the feature through browsing or search.

Mistake: No Support for Edge Cases

Employee Center works great for common scenarios: a regular employee requesting leave, updating contact info, viewing pay stubs. But what about edge cases? An employee on unpaid leave, a contractor, someone with multiple employment agreements, a departing employee, or a manager acting on behalf of an employee. These scenarios often break portals because the design assumes one employment type per person.

The fix: user-test with employees in different situations, not just the majority case. Ask: can a manager request a leave exception for their team? Can a departing employee access reference letters? Can a contractor view their assignment dates? Build these scenarios into acceptance criteria before launch, and test regularly as employment models evolve.

Mistake: Disconnected Systems and Data Inconsistency

Employee Center might pull leave balance from one system and leave policies from another. If these do not stay in sync, employees see conflicting information: the portal shows one leave balance, while their manager’s system shows another that reflects days already taken. This erodes trust quickly.

The fix: understand all data sources and ensure they are synchronised regularly. Document which system is the system of record for each data type. If systems sync nightly, tell employees data might be up to 24 hours old. Better: integrate in real-time where possible, or clearly label stale data (“leave balance was last updated at 6 PM”). Resolve discrepancies as part of your data governance.

Mistake: No Feedback or Support Channel

Employees run into issues: a feature does not work, something is confusing, or they need help. If there is no obvious way to get support, they either suffer in silence or email HR, which creates tickets that could have been resolved with better guidance or a quick chat.

The fix: add a support link or chat widget to the portal. Make it easy for employees to report issues and ask questions. Monitor feedback closely: frequent questions signal that your content or design needs improvement. Common complaints (slow performance, confusing navigation) should trigger action, not just logging.

Mistake: Launching Without Change Management

A new Employee Center is a change to how employees interact with HR. If you launch it quietly, expecting employees to discover it, adoption will be slow. Some employees will never use it and continue emailing HR with questions the portal could answer. Others will use it incorrectly and cause issues (e.g., submitting leave requests twice because they did not believe the first one worked).

The fix: plan a communication and training campaign. Send email to all employees with top tasks and how to do them in the portal. Hold training sessions. Tie messaging to employee pain points: “tired of emailing HR for leave forms? Use the portal.” Make the business case clear. For the first month, monitor closely and provide extra support; most questions and issues surface early.

Problems that only appear after the first month

Launch week gets the attention, so most of the early problems are visible and get fixed. The mistakes that do lasting damage tend to surface later, once the initial enthusiasm has faded and the portal has become routine. They are harder to spot because nobody is watching for them. This section covers the problems that typically emerge in the second and third months, after the launch checklist has been closed.

A short post-launch review that finds these early

1. Export the list of open approvals and sort by age, then check each approver against the current staff directory.
2. Pick five recent submissions from different departments and compare every field the employee typed with what the profile already held.
3. Count the notifications sent to one representative employee over a normal week, and remove any that nobody acts on.
4. Ask two service desk agents which requests they still receive outside the portal, and trace one of them to its source.

The review is small enough to run on a regular cycle and produces a short list of defects. Its value is that it is repeatable, so the second review shows whether the first fixes held. The testing and acceptance checklist is a useful companion for the retest.

Why alerts and notifications need a sunset rule

Notifications are added one at a time. Each one seems reasonable when it is requested, and the cumulative effect is a stream of messages that employees learn to skip. A simple rule helps: every notification must name the action the employee should take, and a notification that never leads to an action is a candidate for removal. Review the list whenever a new one is requested, not only when complaints appear. Feedback from staff is the other source of evidence, and the employee feedback loop article covers how feedback becomes action.

Protecting the catalog from silent expansion

Catalog items tend to multiply because each team wants its own form. Over time the portal contains several forms for the same thing, each with slightly different fields, and employees choose the wrong one. Before adding an item, check whether an existing item can be extended. If a new item is necessary, retire the one it replaces in the same change, and record the decision.

Questions to ask at the three-month review

• Which request types have grown in volume since launch, and does any of that growth look like a process problem rather than demand?
• Has anyone added a notification, form or approval rule without a named owner?
• Are knowledge articles still matching the forms they point to, or have the forms changed under them?
• What did employees say in the feedback channel that the team has not yet acted on?

Why do employees keep emailing HR even though the portal exists?

Usually because the portal does not handle their situation well, or because the email route is faster for a reason the team has not examined. Ask a sample of people who emailed in the past week what they tried first. The answer tells you whether the gap is in the design or the awareness.

Is it a mistake to let managers approve on behalf of their team?

It is not a mistake in itself, but delegation needs a visible record. An approval made under a delegation should show who acted and who delegated, so that an audit can follow the decision. Delegations held by leavers are a gap to check, and the employee offboarding controls article covers the handover side of leaving.

What is a common reason an automated step stops working?

A dependency changed without anyone telling the portal team. A renamed group, a retired field or a new approval policy can break a rule silently. Keep a list of the automated steps and the systems they depend on, and check it whenever a dependency changes.

How should we respond to a complaint that the portal is slow?

Separate the complaint into the page, the form and the submission step, and time each one for the same user. Slowness at the submission step usually points to a downstream call, not to the portal interface.

Should the team wait for complaints before reviewing the portal?

No. Complaints tend to come from the most frustrated employees, and they miss the quieter group who simply stopped using the portal. A scheduled review finds that group before they leave.