ServiceNow Employee Journey Management Requirements Workshop Questions

Workshop Format and Stakeholders

Requirements workshop brings together HR leadership, employee experience teams, line managers, and IT to define Employee Journey Management strategy. Plan the workshop length around the agenda. Participants should represent different employee segments (new hires, high performers, departing employees) and geographies. Send background materials before the workshop so participants understand Employee Journey Management capabilities and can come prepared with specific requirements.

Lifecycle Stages and Journey Mapping

What employee lifecycle stages does your organization recognize? Typical stages include: recruitment, onboarding, development, transition (role change), succession planning, and offboarding. Design consideration: each stage may have distinct workflows and touchpoints. Ask: which stages are most critical to manage in the system? Are there unique stages for your organization (e.g., apprenticeship, internship)?

What touchpoints matter most in each stage? Touchpoints are specific interactions: first day orientation, 30-day check-in, annual performance review, promotion, exit interview. Design consideration: touchpoints drive workflow automation and task creation. Ask: do you want all touchpoints automated or only critical ones?

Stakeholder Engagement and Communication

Who is involved in employee journey milestones besides HR? Typical participants: hiring manager (recruitment), direct manager (onboarding and development), peers (mentoring), executive sponsor (succession planning), and payroll (offboarding). Design consideration: workflows should involve all stakeholders. Ask: should Employee Journey Management create tasks for managers or just notify them? Who makes decisions during the journey (e.g., who approves promotions)?

What communications should employees receive? Do you send milestone notifications, offer learning resources, or ask for feedback? Design consideration: Employee Journey Management can automate communications. Ask: what messages matter to employees and when should they receive them?

Onboarding and Offboarding Workflows

Onboarding: what must happen before an employee’s first day (IT provisioning, workspace setup, background checks)? What happens on day 1 (orientation, system access setup)? What follow-up occurs in weeks 1-4 (training, manager check-ins, peer introductions)? Design consideration: complex onboarding involves many departments. Ask: which onboarding tasks are currently manual and would benefit from automation?

Offboarding: what happens when an employee departs (knowledge transfer, access removal, final paycheck, exit interview)? How long does offboarding take? Design consideration: offboarding mistakes (retained access, lost knowledge) create risk. Ask: who is accountable for each offboarding step? What is the timeline?

Data and Integration Requirements

What employee data drives journey decisions? Common drivers: tenure, performance rating, role, location, department. Design consideration: Employee Journey Management needs accurate employee data. Ask: where does employee data come from (HR system, payroll, performance management)? Is it current? Do you need to integrate multiple systems?

What systems need to respond to journey milestones? IT provisioning (new accounts, equipment), payroll (raise processing), learning management (course enrollment), benefits (enrollment windows). Design consideration: each integration requires testing. Ask: which integrations are most critical?

Learning and Development Pathways

What learning do employees need at different career stages? New employees need foundational training, experienced employees need skill-building and leadership development. Design consideration: Employee Journey Management can link learning resources to career stages. Ask: do you have a learning curriculum mapped to roles and stages? Should the system automatically recommend learning based on employee profile?

Succession Planning and Career Development

How do you identify high-potential employees and develop them for leadership roles? Design consideration: this is often manual and inconsistent. Ask: do you have a succession planning process? Should Employee Journey Management track career development plans and progress?

Reporting and Analytics

What metrics matter for employee journey? Common metrics: time-to-productivity for new hires, retention rate by tenure, internal promotion rate, onboarding completion rate. Design consideration: identify metrics before design so you can capture required data. Ask: what reports does leadership review?

Warning Signs From Workshops

If participants describe very lengthy onboarding (e.g., 6-12 months) with many manual steps, Employee Journey Management can help but requires significant design work. If participants cannot agree on which lifecycle stages matter most, you need HR strategy alignment before system design. If participants describe no clear ownership of employee journey, you need to establish governance before implementing the system.

Turning workshop answers into a decision log

A requirements workshop produces opinions quickly and decisions slowly. The useful output is not the flip-chart photo but a decision log that records, for each topic, what was agreed, who agreed it, what remains open, and which later design session will close the gap. Without that log, the same argument returns in the build phase, usually from a manager who was not in the room.

Plan the log before the workshop starts. Each question you ask should have an owner for the answer and a status that can be one of four values: decided, decided with conditions, deferred, or rejected. Anything marked deferred needs a date for the session that will settle it, otherwise it becomes a silent scope change.

How to run the last hour of the workshop

Many workshops run long on the topics people enjoy and short on the ones that carry risk. Reserve the final hour for the items that touch money, access or personal data. Walk through them in the order that a real employee would experience them, because that order exposes gaps that a topic-by-topic discussion hides.

1. Read back every decision marked as decided, one at a time, and ask the room to object now rather than in the build.
2. Take each deferred item and assign it a closing session with a named chair.
3. Ask which departure or transfer would be the hardest case to handle today, and trace it through the proposed events.
4. Confirm which system holds each employee attribute the journey will read, and who is accountable when that attribute is wrong.
5. Agree how the log will be shared, and who may change a decided item after the workshop.

Where requirements quietly conflict

Two requirements that sound compatible in isolation often conflict once they meet a real calendar. A rule that every new hire completes role training within the first week sits badly with a rule that hires in regulated roles cannot access certain systems until a check clears. Neither rule is wrong. The workshop has to decide which one governs the overlap, and the decision belongs in the log with a short example attached.

Another common clash appears between an efficiency goal and a fairness goal. Automating the approval of a promotion step may speed the process for one department while leaving another department’s managers with a manual queue. Ask which group absorbs the extra work, and whether that group was consulted.

Questions that belong to a later session

Not every question should be settled in a workshop. Detailed field mappings, notification wording, and approval routing for rare cases are better handled in design sessions with the people who will maintain them. The workshop should name these as deferred items and state the question each one must answer, so the design session starts with a clear brief rather than a blank page.

Questions about running the workshop

Who should be left out of the room?

Keep the decision group small enough that one person can summarize it. Invite subject experts for the topics they own and release them afterwards. A room full of observers tends to produce long lists and few decisions.

What if a site or region needs a rule the rest of the business does not?

Record it as a conditional rule scoped to that site, with the reason written beside it. Do not let a single site’s preference become a global rule by default, and do not drop it silently either. Local legal or working-pattern differences are often better captured as exceptions than as separate journeys.

Should the workshop cover succession and career planning in full?

Only if the organization already has a succession process that the journey will read from. Where it does not, the workshop should decide whether the journey will touch career development at all. Leaving that question open invites a broad scope that the first release cannot carry.

How do we know the workshop was a success?

The test is whether the decision log can be handed to a design team who was not present and produce a first draft of the journey without calling the workshop chair. If they cannot, the log needs more detail on owners and triggers.

Next step

Once the session notes are typed up, check the decision log against the security and access design guide, plus the roles and RACI guide.