Why This Is the Most Important Design Decision You Will Make
If you ask an experienced SAP ESM consultant which single design decision has the greatest impact on everything else in the implementation, the answer is almost always the same: the service catalog.
Get it right, and routing works cleanly, SLAs are meaningful, the self-service portal makes sense to employees, reports tell a coherent story, and your HR agents know exactly what they are responsible for.
Get it wrong, and you spend the next six months rebuilding it after go-live, while the system is live, under pressure, with frustrated agents and confused employees.
This post covers what an HR service catalog is, how SAP ESM structures it, and how to design yours in a way that will serve you well beyond Wave 1.
What an HR Service Catalog Actually Is
An HR service catalog is a structured classification of every type of HR request your Shared Service Center handles. It is the taxonomy that organises HR work.
- In SAP ESM, every case belongs to a category in the catalog. That category determines:
- Which HR team receives the case (Case routing)
- What SLA applies (response and resolution targets)
- What the employee sees when browsing the self-service portal
- What knowledge base articles are suggested to the employee before they submit
- How cases are counted and reported in analytics
Think of the service catalog as the skeleton of your ESM configuration. Everything else, routing, SLAs, knowledge base, portal layout, reporting, is built on top of it. This is why getting it right early matters so much. A poorly designed catalog is not just an inconvenience; it is structural debt that affects every other part of the system.
The Four-Level Taxonomy: L1 to L4
SAP ESM supports up to four levels of category classification. Understanding how these levels work, and how to use them wisely, is the key to a clean catalog design.
L1 — Service Domain
The broadest grouping. L1 represents the major functional areas of HR service delivery. Think of these as the doors employees walk through when they need HR help. A typical ESM for HR implementation has five to six L1 categories.
L2 — Service Area
A subdivision within an L1 domain. L2 narrows the request to a specific area within that domain. For example, within the L1 “Payroll & Compensation” domain, L2 categories might include Payslip & Earnings, Tax & Deductions, and Overtime & Allowances. L2 is where routing decisions are most commonly made.
L3 — Service Topic
A further subdivision of L2. L3 allows you to get more specific about the nature of the request within a service area. For example, within L2 “Leave & Absence,” L3 might distinguish between Annual Leave, Sick Leave, Parental Leave, and Unpaid Leave.
L4 — Service Sub-topic
The most granular level. L4 is typically used to capture very specific request types or to distinguish between sub-processes within a topic. For example, within L3 “Parental Leave,” L4 might separate Maternity Leave from Paternity Leave from Shared Parental Leave.
The Wave 1 Rule
Here is the most important piece of practical guidance in this post: at go-live, populate L1 and L2 only. Leave L3 and L4 for Phase 2.
This is a best practice that experienced implementers follow consistently, and it is worth understanding why. L3 and L4 add reporting granularity and routing precision — but they also multiply the complexity of every other configuration decision. More categories means more routing rules, more SLA definitions, more knowledge base articles to write, and more portal tiles to organise. For a first go-live, that complexity is unnecessary and often counterproductive.
Start with L1 and L2. Run the system for three to six months. Let the query volume data tell you where additional granularity is genuinely needed. Then add L3 and L4 in Phase 2, informed by real usage rather than assumptions.
The Six Core L1 Categories
Based on best practice across SAP ESM for HR implementations, the following six L1 categories provide a solid starting point for most organisations:
- Working Practices & Administration
The broadest day-to-day HR category. Covers the operational and administrative questions employees have about their employment.
Typical L2 areas: Employment Verification, Personal Data Changes, Work Documentation, Policies & Guidelines, Company Policies
- Payroll & Compensation
Everything related to pay, deductions, and financial entitlements. This is typically the highest-volume category in most SSCs.
Typical L2 areas: Payslip & Earnings, Tax & Deductions, Overtime & Allowances, Pay Corrections, Compensation Queries
- Leave & Absence
Absence management and leave entitlement queries. Often closely integrated with SuccessFactors Time & Attendance.
Typical L2 areas: Annual Leave, Sick Leave, Parental Leave, Unpaid Leave, Absence Reporting
- Benefits Administration
Queries related to employee benefits, enrollment, and entitlements.
Typical L2 areas: Benefits Enrollment, Pension & Retirement, Health & Wellbeing, Flexible Benefits, Benefits Statements
- Onboarding & Offboarding
The lifecycle events at the beginning and end of employment. These cases often involve SuccessFactors Onboarding and Offboarding module integration.
Typical L2 areas: New Joiner Support, Pre-boarding Queries, Leavers & Exit Process, Rehire Queries, Contractor Onboarding
- Talent & Learning
HR service requests related to performance, development, training, and career progression. Volume in this category grows significantly when SuccessFactors Talent modules are in scope.
Typical L2 areas: Performance Review Support, Learning & Development, Succession Planning Queries, Recruitment Support, Career Development
How the Catalog Connects to Everything Else
The service catalog is not a standalone configuration item. It is the connective tissue that links every other part of the ESM design. Here is how each major area depends on it:
Catalog → Routing
Every routing rule in ESM is built on a category. When a case is created in the “Tax & Deductions” L2 category under “Payroll & Compensation,” ESM knows exactly which Payroll team should receive it. The routing engine does not guess — it follows the rules you define per category. A well-structured catalog makes routing simple. A poorly structured catalog makes routing a maintenance nightmare.
Catalog → SLAs
SLA definitions in ESM are tied to categories and priority levels. A “Personal Data Change” case might have a 4-hour response SLA and a 2-business-day resolution SLA. An “Employee Relations” case might have a 1-hour response SLA and a 5-day resolution SLA due to its complexity. None of this is possible without a defined category structure.
Catalog → Self-Service Portal
The self-service portal is organised around your catalog. The tiles employees see when they log in, the forms they fill out when raising a request, and the knowledge base articles suggested to them — all of these are structured around your L1 and L2 categories. A logical catalog produces an intuitive portal. A messy catalog produces a confusing one.
Catalog → Knowledge Base
Knowledge base articles are tagged to categories. When an employee starts browsing in the “Leave & Absence” area of the portal, ESM surfaces knowledge base articles tagged to that category. This is how self-service deflection works in practice. Without a clean catalog, articles cannot be surfaced in context, and deflection rates suffer.
Catalog → Reporting
Every ESM report and dashboard is aggregated by category. Case volumes, SLA performance, deflection rates, and agent productivity are all reported at the category level. If your catalog is poorly designed, categories that are too broad, too narrow, or inconsistently named, your reporting will never tell a coherent operational story.
The Relationship Between the Catalog and Your SSC Org Design
Blog 3 covered the importance of designing your HR Shared Service Center structure before you configure anything. The service catalog is where that org design becomes concrete.
The relationship is direct: SSC Design Decision -> Catalog Implication
- You have a dedicated Payroll team -> Payroll & Compensation needs to be its own L1 category
- Your Employee Relations team handles complex people cases -> Employee Relations should be a separate L1 category, not buried under another domain
- Onboarding is handled by a specialist team -> Onboarding & Offboarding should route to that team, not to HR Generalists
- Your Tier 1 team handles all Benefits queries -> Benefits can remain at L2 within a broader L1; a dedicated L1 is not needed
- You support 8 languages -> Every L1 and L2 category label must be translated into all 8 languages before go-live
The rule is simple: every L2 category should map to exactly one HR team. If a category could reasonably be handled by two different teams, that is a signal that the category needs to be split, or that the org design needs to be clarified first.
The Mistake That Derails Most First Implementations
The most common service catalog mistake I see is what I call the completeness trap: teams that try to build the most exhaustive, comprehensive catalog possible before go-live.
They list every HR query type they can think of. They create L3 and L4 categories for every conceivable sub-topic. They build a catalog with 80, 100, sometimes 150+ categories before they have a single month of live data to validate any of it.
The result is always the same. Agents cannot find the right category quickly. Employees are confused by the portal. Routing rules become unmanageable. The knowledge base is impossible to maintain. And after six months, the team begins the exhausting process of rationalising the catalog reducing it to the 20 or 30 categories that actually carry meaningful volume.
The antidote is the volume baseline best practice: capture the last 12 months of HR query volume by type before you design the catalog. Use your existing HR ticketing data, your shared inbox, your Excel trackers, whatever you have. Even rough numbers are better than guessing. Let volume guide the catalog. If a query type accounts for less than 1% of annual volume, it does not need its own L2 category at go-live.
Start lean. Add granularity later. Your catalog can always grow, shrinking it after go-live is far more disruptive.
A Practical Catalog Design Checklist
Before signing off your service catalog design, work through this checklist:
- [ ] Have I baselined 12 months of historical query volume by type?
- [ ] Does each L1 category correspond to a recognisable HR functional area?
- [ ] Does each L2 category map to exactly one HR team or routing destination?
- [ ] Are L1 and L2 labels written in plain employee language (not HR jargon or system codes)?
- [ ] Have I limited go-live to L1 and L2 only, with L3/L4 reserved for Phase 2?
- [ ] Has the catalog been reviewed and approved by HR team leads — not just IT or the project team?
- [ ] Are all category labels translated into every language supported at go-live?
- [ ] Does every category have at least one knowledge base article planned, even if not yet written?
- [ ] Have I mapped each L2 category to an SLA definition?
- [ ] Does the catalog structure make sense to an employee who has never seen ESM before?
If you can answer yes to all ten, your catalog design is solid enough to build on.
What Comes Next
With your service catalog designed, you are ready to think about how cases will actually arrive in the system. The catalog tells ESM what a case is and where it goes, but the channel strategy determines how employees create that case in the first place.
Next post: Blog 5 — Omnichannel Strategy: How Employees Will Reach HR
Part of the series: “Implementing SAP ESM for HR — A Practitioner's Guide from Zero to Go-Live.” All content is based on hands-on implementation experience and SAP best practice materials.
Source link