The Problem That Routing Solves

Every HR Shared Service Center has experienced some version of this: a payroll query lands with the onboarding team. An employee relations case sits unassigned for three days because nobody was sure who owned it. A manager's request for a headcount report gets routed to the HR generalist helpdesk, which has no authority to respond.

Manual case assignment, someone reading each incoming request and deciding where to send it, does not scale. It is slow, inconsistent, and dependent on individuals who may be absent. It creates bottlenecks, delays, and frustrated employees.

Routing in SAP ESM solves this by making case assignment automatic, consistent, and driven by logic rather than by whoever happens to be checking the queue. When it is designed well, every case lands with the right team, at the right priority, within seconds of being created, regardless of which channel it came from and regardless of the time of day.

This post explains how to design routing and SLA logic that works cleanly from go-live and stays maintainable as your SSC evolves.

How Routing Works in SAP ESM: The Two Dimensions

Automatic routing in SAP ESM operates on two dimensions simultaneously. Understanding both is essential before you start designing routing rules.

Dimension 1: Case Category

The service catalog you designed in Blog 4 is the primary routing driver. When a case is created, via the self-service portal, email, Joule, or phone, it is assigned a category (L1 and L2). The routing engine uses that category to determine which Agent Group (team) should receive it.

This is the most direct and controllable routing dimension. A payroll query goes to the payroll team. An onboarding request goes to the onboarding team. The category is either selected by the employee during self-service intake, inferred from the email content, or guided by the Joule conversation.

Dimension 2: Employee Data from SuccessFactors

The second routing dimension uses employee master data pulled directly from SAP SuccessFactors Employee Central. For multinational organisations, this is what makes routing intelligent rather than just categorical.

Two employees submitting the same type of request, for example, a leave enquiry, may need to be routed to different teams based on their country, company code, or organisational unit. An employee in France requires an agent who knows French employment law; an employee in Singapore requires an agent who knows Singapore's MOM regulations. ESM routes based on the SuccessFactors org-unit hierarchy, ensuring employees are served by the right regional or country-specific HR team without the employee needing to know which team that is.

The combination of these two dimensions — what the case is about + who the employee is — is what makes ESM routing powerful. The design challenge is building rules that cover both accurately without creating an unmaintainable tangle of logic.

Agent Groups: The Structural Unit of Routing

Before writing a single routing rule, you need to understand Agent Groups, the unit of organisation that routing rules point to.

An Agent Group in SAP ESM is the equivalent of an HR team in your SSC. Every case ultimately gets assigned to an Agent Group (and then to an individual agent within that group). The Agent Group determines:

• Which agents can see and work on a case
• Which SLA rules apply (groups can have different SLA profiles)
• Which escalation path is triggered if the case is not resolved within the target time

The best practice established in Blog 3 applies directly here: map ESM Agent Groups 1:1 to your SSC teams. One HR team = one ESM Agent Group. If your SSC has an HR Operations team, a Payroll team, a Talent team, and an Employee Relations team, you will have four Agent Groups in ESM.

Resist the temptation to create sub-groups within teams (e.g., HR Operations – EMEA, HR Operations – APAC) unless the routing logic genuinely requires them and you have confirmed that agents in each sub-group only work that region. Overly granular Agent Groups create routing complexity that is difficult to maintain and leads to cases falling through the cracks when team membership changes.

Designing Routing Rules: The Principles That Keep It Maintainable

The most common routing design failure I see is what I call the “snowflake problem”: an ever-growing list of highly specific rules, each created to handle a particular edge case, that collectively become impossible to understand, test, or maintain. When the HR SSC reorganises (and it will), nobody knows which rules to change.

Here are five design principles that prevent this:

Principle 1: Start with the simplest rule that works
A routing rule that says “all Payroll cases go to the Payroll Agent Group” is better than ten rules each covering a specific payroll sub-category. Start broad and add specificity only when operational experience shows it is needed.

Principle 2: Use SuccessFactors org-unit data for geography, not custom fields**
Route by country or company code using the data that already exists in SuccessFactors Employee Central; do not create custom fields to replicate data that is already there. This keeps your routing in sync with your SuccessFactors org model automatically.

Principle 3: Define a default rule for every category
Every category in your service catalog must have a default routing rule, a fallback that catches cases where the more specific rules do not match. A case with no matching routing rule sits unassigned. In production, that means an employee waiting with no acknowledgement. Default rules are your safety net.

Principle 4: Map routing rules to Agent Groups, not individuals
Never route directly to a named agent. Agent-level routing breaks the moment that person goes on leave, changes role, or leaves the organisation. Route to Agent Groups; let supervisors manage the assignment queue within the group.

Principle 5: Document every rule as you build it
Maintain a routing rule register, a simple table that lists every rule, what triggers it, which Agent Group it routes to, and when it was last reviewed. This document is invaluable during UAT, go-live troubleshooting, and any future restructure. It is also one of the outputs your project should produce before go-live.

Direct-to-Tier-2 Routing: When Not Everything Should Go to the Generalists

In Blog 3 we discussed the multi-tier model: Tier 0 (self-service), Tier 1 (HR generalists), and Tier 2 (HR specialists). The natural assumption is that all cases enter at Tier 1 and escalate upward only if the generalist cannot resolve them.

For most categories, that assumption is correct. But for certain high-sensitivity, high-complexity categories, sending cases to Tier 1 first creates unnecessary delay and, in some cases, risk.

Consider this: an employee raises a grievance about workplace harassment. Or a case arrives related to a formal disciplinary process. Routing these to an HR generalist who then has to escalate them is not just inefficient. It means a sensitive case has been seen by a wider audience than necessary.

Direct-to-Tier-2 routing is the solution. Specific service catalog categories, typically those in the Employee Relations, Legal, Payroll Corrections, and Executive HR domains, are configured to bypass Tier 1 and route straight to the specialist Agent Group.

Setting up direct-to-Tier-2 routing requires:
– A clear list of categories for which direct routing applies (agreed between HR leadership and SSC management before go-live)
– Dedicated Agent Groups or queues for those categories in ESM
– Clear documentation so HR agents understand why certain cases never appear in the Tier 1 queue

This is one of the design decisions that the Discovery Workshop (covered in your pre-implementation phase) should explicitly address. It should not be decided during configuration.

SLA Design: The Three Measurements That Matter

A Service Level Agreement in SAP ESM is not a single number. It is three distinct measurements, each with its own target and trigger:

Measurement 1: Acknowledgement Time
How long after a case is created does the employee receive confirmation that their request has been received?

For email-created cases, the auto-acknowledgement (covered in Blog 5) handles this instantly. For self-service cases, a confirmation message is shown in the portal as soon as the case is submitted. The SLA acknowledgement timer tracks whether the HR team has taken ownership of the case within the defined window; typically within 4 business hours for standard cases.

Measurement 2: First Response Time
How long until the HR agent sends the first substantive response, not just an acknowledgement, but actual progress on the case?

This is where SLA performance is most visible to employees. A case that sits acknowledged but untouched for two days creates exactly the frustration that ESM is meant to eliminate. Typical targets:

• High priority cases: 4 business hours
• Standard cases: 1 business day
• Low priority / informational cases: 2 business days

Measurement 3: Resolution Time
How long until the case is closed, the employee's query has been fully answered, the transaction has been completed, or the issue has been resolved?

Resolution targets vary significantly by category. A payslip query might have a target of 2 business days. A complex employee relations case might have a target of 10 business days. The variation is intentional; uniform resolution targets across all categories either set the bar too low for simple queries or create unrealistic pressure on complex ones.

Best practice for SLA target setting: Use 12 months of historical ECSC or legacy query data to set targets based on what your team actually achieves today, not aspirational benchmarks from a vendor brochure. Setting targets you cannot meet from day one erodes confidence in the SLA framework before it has had a chance to become established.

Business Hours, Time Zones, and Holiday Calendars

SLA timers in SAP ESM run against business hours, not wall-clock hours. This is a critical configuration detail. A case created at 4:55pm on a Friday should not be flagged as an SLA breach at 9:05am on Monday because it was not responded to over the weekend.

Business hours configuration in ESM requires:

• Working hours per Agent Group: define the hours during which each team operates (e.g. 08:00–18:00 CET for the EMEA HR team)
• Public holiday calendars per country: cases assigned to the UK HR team should not count Christmas Day as a working day
• Time zone alignment: for global SSCs serving multiple time zones, business hours must reflect the receiving team's timezone, not the submitting employee's timezone

SLA Escalation: What Happens When Targets Are Missed

Designing SLA targets is only half the work. The other half is defining what happens when a case is at risk of breaching, or has already breached, its target.

For your escalation design, answer these questions before configuration:

• Who receives the warning alert — the agent, the team supervisor, or both?
• What is the escalation path for a breached Tier 1 case — does it go automatically to Tier 2, or is it flagged for manual intervention?
• Are there categories where SLA breach should trigger immediate escalation to HR leadership (e.g., employment law queries, executive requests)?

Document these decisions in your routing rule register alongside the routing rules themselves.

The Dependency Triangle: Routing, Org Design, and Service Catalog

Routing design cannot be done in isolation. It is the third vertex of a triangle whose other two corners are the SSC org design (Blog 3) and the service catalog (Blog 4).

The dependency runs in both directions:

• Your service catalog categories determine what routing rules are needed. Adding a new L1 category after go-live without a routing rule leaves cases unassigned.
• Your Agent Groups must match your SSC team structure. Reorganising the SSC without updating Agent Groups and routing rules creates misrouted cases.
• Your SLA targets must be calibrated against the actual volume and complexity profile of each category, which is why baselining 12 months of historical query data before go-live is not optional.

When all three are designed together (org structure, catalog, routing) the system is coherent. When they are designed separately by different workstreams and stitched together late in the project, inconsistencies emerge that are expensive to fix post-go-live.

Common Routing Mistakes and How to Avoid Them

Mistake 1: Creating routing rules before the service catalog is finalised
Every routing rule references at least one category. If the catalog changes after rules are built, rules become orphaned or mismatched. Always finalise the L1/L2 catalog before building routing rules.

Mistake 2: Routing to individuals instead of Agent Groups
As noted above, this breaks whenever a person's availability, role, or employment status changes. Always route to groups.

Mistake 3: No default rule for unmatched cases
A case with no matching routing rule sits in an unassigned queue and generates no alerts. Build a catch-all default rule for every routing scenario, even if it just routes to a supervisory Agent Group for manual triage.

Mistake 4: Setting SLA targets without historical data
Aspirational SLA targets — “we want to resolve everything within 24 hours” — that the team cannot meet from day one destroy SLA credibility, and creates a reporting baseline that shows constant failure. Anchor targets to what the team actually achieves, then set improvement targets for months 3–6 post-go-live.

Mistake 5: Ignoring time zones in business hours configuration
A global SSC that uses a single business hours calendar, typically set to the HQ timezone, will show SLA breaches during public holidays and out-of-hours periods in other regions. Configure business hours per team, per country.

Routing and SLA Design Checklist

Before signing off on routing and SLA configuration for go-live, validate:

• [ ] Every Agent Group in ESM maps 1:1 to an SSC team documented in the org design
• [ ] Every L1/L2 service catalog category has at least one routing rule and one default fallback rule
• [ ] Direct-to-Tier-2 categories are identified, agreed with HR leadership, and configured
• [ ] No routing rules reference individual agents — all routing points to Agent Groups
• [ ] A routing rule register document is complete and signed off
• [ ] Business hours are configured per Agent Group with correct time zones
• [ ] Country-specific public holiday calendars are loaded for every country in Wave 1 scope
• [ ] SLA targets (acknowledgement, first response, resolution) are defined per category and validated against historical volume data
• [ ] End-to-end routing test cases are written covering every Agent Group and every direct-to-Tier-2 category
• [ ] Routing is validated in UAT by submitting cases across all channels and confirming correct Agent Group assignment

What Comes Next

With routing and SLAs designed, cases will flow to the right teams at the right times, but employees will also be receiving automated communications throughout that journey. Acknowledgements when a case is created. Updates when its status changes. Notifications when more information is needed. Confirmation when it is resolved.

None of those communications happens automatically unless they are configured. And how you configure them shapes whether employees feel informed and confident, or confused and uncertain.

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.

What is SAP ESM for HR? And Why Your HR Shared Service Center Needs It

Source link