ServiceNow HR Knowledge Management Requirements Workshop Questions

This page helps a project lead decide which HR knowledge topics to write first, who owns them, how often they are reviewed and which need restricted access. It sets out the questions to put to HR staff, managers and policy owners in a requirements workshop, grouped by the design decision each answer settles.

Discovering Knowledge Gaps and High-Value Topics

In workshop, ask HR staff and managers: what questions do employees ask repeatedly? What topics cause the most confusion? Where do people find answers (HR website, email, colleagues, nothing)? Common topics: how to request time off, what is my benefits, how is my pay calculated, how do performance reviews work, what is the vacation policy, can I work from home. High-volume topics should become your first knowledge articles.

Content Strategy and Format Selection

Determine content needs by type. Policies work as step-by-step text guides. Benefits information works as structured FAQs with definitions. Processes work as flowcharts or video walkthroughs. Compliance training requires interactive content. Decide what content to create, which formats to use, who will create and maintain. Start with high-value, high-frequency topics that drive the most inquiries.

Ownership Model and Responsibility Assignment

Define who owns each content area. HR policy owner maintains all policy articles and updates them when policies change. Benefits team owns benefits content and updates during enrollment periods. HR manager for each area owns content relevant to their function. Document this ownership in writing and make people accountable. If content is everyone’s responsibility, it becomes no one’s.

Governance and Review Cycles

Establish when knowledge must be reviewed. Annual review is common for evergreen content (company policies, benefits overview). Quarterly review for changing content (leave policies, enrollment periods). Monthly review for content affected by business changes. Define what “current” means: articles must reflect current policy, have correct contact information, links must work. Old knowledge is worse than no knowledge because it misleads people.

Integration and Discoverability

Knowledge must be discoverable where employees need it. Integrate into HR portal so employees find articles when browsing. Link from request forms: if an employee asks for time off, show time-off policy article. Include in onboarding materials for new hires. Search must work well so employees find articles by keyword. Test search to ensure people find what they need.

Success Metrics and Continuous Optimization

Track knowledge program success: article usage (which articles are read, how often), user feedback (was this helpful), and HR team feedback (did knowledge reduce inquiries). Use metrics to decide what to improve. If an article is read 100 times a week, it is valuable; invest in keeping it excellent. If an article is never read, either it is not needed or people cannot find it.

Data Handling and Privacy in Knowledge

Knowledge articles may contain employee names, organizational structures, or sensitive policies. Questions to explore: should knowledge be visible to all employees or restricted by role, how should personal data be handled in examples, and what privacy considerations apply to the knowledge base itself?

Establish data classification: what information is public (anyone can see), what is restricted (only certain roles can see), and what is confidential (never publish externally). HR knowledge typically has mixed classifications: vacation policies are public, payroll tax withholding forms may be restricted, and individual salary information is confidential.

Implement access controls in the knowledge base so restricted articles are only visible to authorized users. This prevents accidental disclosure of sensitive information while maximizing knowledge availability for intended audiences.

Questions about content format and presentation also matter. Should articles include links to related articles, video demonstrations, or downloadable templates? Should there be a glossary of terms for employees unfamiliar with HR terminology? Questions about accessibility ensure knowledge reaches all employees: is the interface accessible for vision-impaired users, is content available in multiple languages if your workforce is multilingual, and can employees access knowledge on mobile devices?

Finally, consider how to measure success of the knowledge program. Are employees using it, is support volume declining, and are user satisfaction scores improving? Use these metrics to justify ongoing investment in knowledge management. Topics include structure, search, data privacy, and feedback mechanisms.

Selecting the attendee mix and the reason for each seat

A requirements workshop for HR knowledge fails in two opposite ways. Too few people in the room, and the answers describe one team’s view of a shared problem. Too many, and the session turns into a debate about wording that never reaches a decision. A useful group has one person who owns the policy content, one who runs the HR service channels that generate questions, one who represents the employee population most likely to search, and one from IT or the platform team who can say what the system will and will not do. Legal or compliance should attend the part of the session that covers restricted content, rather than the whole session, so their time goes to the decisions that need them.

Ask attendees to bring two things: the last three months of the most common HR questions, however they were received, and a list of the policy documents they consider authoritative. The second list often contains more than one version of the same policy, and finding that out in the room is cheaper than finding it during build.

Organizing the questions by the decision each one settles

A flat list of questions produces flat answers. A better approach groups the questions by the design decision they unblock, so that each answer leads directly to a configuration choice or a content rule. The table below shows how this works in practice. The middle column is the answer that lets the design move forward. The right-hand column is the answer that should stop the session and send someone away to find out more.

Write every answer into a decision log, beside the name of whoever gave it. A decision made in a workshop and never written down tends to be reopened during build, often by someone who was absent.

A running order for the session

Workshops overrun when the agenda puts the hardest topic last. Starting with governance and ownership clears the way for content questions, because many content disagreements are really ownership disagreements in disguise.

1. Agree the authoritative policy source for each topic area, and the owner for each source.
2. Review the common-question list and group it by life event, not by team.
3. Decide which topics need restricted visibility, and who must be able to see them.
4. Choose the content formats for the top topics, such as written steps, an eligibility checklist or a short video.
5. Close by listing the questions still open, each with an accountable person and a deadline for its answer.

Failure patterns in the answers themselves

Some answers look complete but hide a problem that will surface during build. A common one is “employees will find it through search” with no one checking which search terms employees use. Another is an accessibility answer deferred to testing, when the content formats chosen in the workshop already determine whether a screen reader can navigate a procedure. The implementation roadmap covers how these decisions are sequenced across a project. A third is a privacy answer that treats all HR content the same, when a vacation policy and an individual pay record carry completely different exposure. When you hear an answer that ends in “we will see”, ask what the first test of that answer will be and who will run it.

Questions teams ask before running the workshop

How many sessions does this often need?

A common split is one session on governance and one or two on content, with a short follow-up to close the open questions. A single long session tends to exhaust the policy owners before the restricted-content discussion starts.

Should employees attend?

Not in the decision sessions. Employee input is valuable for finding the questions and testing the wording, so run a separate short session or a question survey with a small sample, and bring the results into the workshop as evidence. Access questions raised by the restricted-content discussion are worked through in the security and access design guide.

What if two HR policy documents contradict each other?

Record the contradiction in the decision log as an open item with its owner. Do not let the knowledge team pick the winning version, because the article will then state a rule the policy owner never agreed to.

Which questions should go to legal?

Anything about who may see personal or disciplinary content, anything that describes an entitlement in wording an employee could rely on, and anything that says what happens during a dispute. Legal input on the rest can wait until review.

Can we skip the privacy questions for an internal-only pilot?

A pilot still exposes real content to real employees, so the restricted-content questions still apply. Limit the pilot to low-sensitivity topics if that makes the questions simpler, but keep the questions on the list.