An HCM platform changes service delivery whether you plan for it or not. Once employees can update data, request leave, and view pay statements in self-service, the “old” model—emailing HR and waiting for manual fixes—starts to break. The choice is to redesign service delivery intentionally or to drift into a messy hybrid where the system exists, but work still happens through side channels. The former creates scale, transparency, and lower cost. The latter creates confusion, inconsistent answers, and persistent payroll risk.
This chapter focuses on four practical building blocks: a shared services model that complements self-service instead of competing with it; a case management approach that creates clean handoffs and traceability; service levels that reinforce cutoffs and accountability; and a workforce plan that ensures HR teams have the capacity and skills to run digital operations after the project ends.
14.1 HR Shared Services Design and Optimization
Shared services is not a call center; it is an operations hub. In a modern HCM environment, the hub exists to resolve exceptions, guide users through standard workflows, and steadily reduce avoidable contact. It delivers value only when it is designed around two principles: standardization and deflection. Standardization means there is one best way to execute common requests, with clear ownership and controls. Deflection means the organization prevents avoidable contact by making the self-service path clear, guided, and trustworthy.
Start with a service delivery tier model and make the boundaries explicit.
Tier 0: Self-service and knowledge. Guided journeys, embedded help, and knowledge articles that enable employees and managers to complete work without contacting HR.
Tier 1: Shared services resolution. High-volume inquiries and standard exceptions handled through scripts, knowledge, and defined escalation rules. Tier 1 should help users complete the correct path—not recreate a backdoor processing team.
Tier 2: Specialist handling. Complex leave, benefits, payroll, and policy cases that require deeper expertise and tighter controls.
Tier 3: Governance and design authority. Owners who adjust standards, approve variances, improve knowledge, and maintain the configuration “rules of the road.”
With tiers defined, build an HR service catalog. Keep it short and written in user intent language (“I need to change my address,” “I have a question about my payslip,” “I need help requesting parental leave”). For each service, specify: the primary channel (workflow, knowledge, case), the owning tier, and any required evidence (documentation, approvals, effective-date rules). The catalog is how you route work consistently and how you prevent shared services from becoming an intake box for everything.
Channel design is part of shared services design, not a communications afterthought. If your default channel remains email, you get unstructured requests, unclear priorities, and poor traceability. If your default channel is a portal entry point with guided journeys and a clear case intake, you can route work, measure it, and improve it. For frontline populations, that may mean QR codes, kiosks, or mobile access plus supervisor reinforcement. The rule is consistency: one front door, one set of status signals, one support path.
Operationalize knowledge and scripts like you would in finance operations. Give Tier 1 agents decision trees that lead to three outcomes: Deflect to the correct self-service journey, Resolve with a standard response and documented steps, or Escalate with a complete handoff package to Tier 2. Then sample closed cases weekly to spot misclassification, missing evidence, and premature closures, and feed fixes into scripts, training, and workflow guidance. This is how you reduce repeat contacts without creating backdoor data changes.
Optimization begins by separating demand into three types. Type 1 demand: legitimate requests the business will always have (for example, leave questions). Type 2 demand: avoidable questions caused by unclear guidance or poor experience (for example, “where do I find my pay statement?”). Type 3 demand: failure demand caused by defects, missing data, late approvals, or broken integrations (for example, “I wasn’t paid correctly because my time wasn’t approved”). Shared services becomes more efficient over time only when Type 2 and Type 3 demand shrink. If they do not, you are paying to absorb problems instead of eliminating them.
Design shared services to complement HCM workflows. The service center should not bypass platform validations “to be helpful,” because that undermines data quality and manager accountability. Where Tier 1 or Tier 2 must execute transactions (data corrections, exception processing, populations without self-service access), require the same workflow, approvals, and audit trail the business would use. Treat broad backdoor update access as a defect in the operating model, not a convenience.
Define what “case-worthy” means. If employees can open cases for routine transactions that the system supports, volume grows and self-service adoption stalls. Use guided intake that does two things: it routes true exceptions to cases, and it redirects routine intents to the correct journey with just-in-time knowledge. Good intake design is a deflection tool, not merely a form.
Shared services must also be aligned tightly with payroll. Define pay-impacting case rules: which issues qualify for expedited handling, what evidence is required, and who can approve exceptions such as off-cycle payments. Track pay-impacting cases and root causes weekly. If one unit repeatedly generates late approvals or missing bank data, address it through leadership escalation and policy enforcement, not through more service effort.
Finally, institutionalize a continuous improvement loop. The service center should own a small backlog of fixes—knowledge updates, routing refinements, workflow simplifications, and error-message improvements—reviewed monthly with HR operations and design authorities. The goal is steady reduction in repeat contacts and failure demand, not a permanent “hypercare” posture.
- Shared services design checklist: Tier boundaries defined; service catalog published; case-worthy rules enforced through intake; pay-impacting escalation aligned to payroll calendars; knowledge ownership assigned with a publishing cadence; failure demand measured and reduced through a monthly improvement backlog.
14.2 Case Management and Ticketing Integration Strategy
Case management turns “help” into accountable work: requests are logged, categorized, routed, tracked, resolved, and learnable. The integration strategy matters because employees should not need to know which system owns which step, and operations teams should not reconcile multiple queues. A good strategy provides a single entry experience, preserves the HCM platform as the system of record for workforce data, and creates a reliable control plane for service performance.
Begin by deciding where cases will live and where work will be executed. Most organizations land on one of three patterns.
Pattern A: HCM-native cases. Cases are created and worked inside the HCM platform. This can simplify user navigation and worker context, but some enterprise service capabilities (advanced routing, omnichannel, workforce management) may be limited.
Pattern B: Enterprise service platform front door. Cases are created and worked in a dedicated service tool, while the HCM platform remains authoritative for people data and controlled HR transactions. This pattern is common when the enterprise already runs a mature service platform and wants HR to operate with the same discipline.
Pattern C: Hybrid orchestration. Intake and routing happen in the service tool, while pay- or eligibility-impacting actions trigger controlled workflows in the HCM platform; the case captures status and evidence.
Whichever pattern you choose, design integration around four essentials: identity and context, lifecycle status, controlled actions, and measurement.
Do not underestimate “case-to-transaction” design. Many HR questions end with an action in HCM: a data correction, a leave status update, or a controlled pay request. If agents must swivel-chair and email for approvals, you have built latency and error into the model. Design structured handoffs so the case captures intent and evidence, triggers the correct workflow, and pulls the outcome back into the case with a reference number.
Decide where sensitive documents belong and how knowledge will be used. Store evidence once, apply retention rules, and reference it securely from other tools. Integrate knowledge into intake and agent handling so employees see suggested articles before they submit a case and agents see the same guidance while resolving it. Any change to a high-volume journey should include a knowledge update as part of release work.
Identity and context: Enable single sign-on and pass a stable worker identifier plus routing attributes (country, business unit, legal entity). This enables correct routing and supports population-scoped agent access so privacy is protected by design.
Lifecycle status: Ensure users can see case status from the front door. Creation, assignment, status changes, and closure reasons must be consistent so cases do not appear “closed” in one place and “open” in another.
Controlled actions: Many cases require actions in HCM—data correction, workflow initiation, or approval routing. Use a clear rule: if an action affects pay, eligibility, or access, it must follow HCM validations and approvals, and the case must record the transaction reference and outcome.
Measurement: Build a taxonomy that distinguishes how-to questions, true exceptions, and system or process failures. Without this, you cannot reduce failure demand; you can only handle it faster.
Taxonomy design is where many service models stumble. A workable structure is: Category (Pay, Time, Leave, Benefits, Personal Data, Talent), Subcategory (for example, Pay Statement, Missing Pay), and Reason (for example, “New hire first pay,” “Retro question,” “Time not approved”). Keep it small and review classification accuracy after go-live. Excessive granularity increases misrouting; excessive simplicity blocks root-cause insight.
Routing rules should be explicit and tied to both topic and urgency. Use population attributes and severity to route pay-impacting cases to specialized queues with tight SLAs and clear escalation. Use knowledge-first routing for low-risk informational intents. Good routing protects payroll windows and prevents specialists from being flooded with avoidable questions.
Design case content and attachments with privacy and auditability in mind. Define what information is allowed in notes, how sensitive attachments are stored, and how long cases are retained. Ensure agent access is population-scoped and role-based. For audits, make the chain traceable: the case should show why a change was needed, who approved it (if required), and what transaction was executed.
If you need a minimum viable starting point, do not compromise on: a single entry path, a routing taxonomy, SLA rules that distinguish pay-impacting cases, secure attachments with retention, and audit-ready traceability for actions that change pay, eligibility, or access. More advanced automation can be phased.
Finally, treat integrations as operational products. Prefer stable API-based integration with retries, acknowledgments, and monitoring. Define an interface contract (owner, failure alerts, runbook) and include critical case flows in every release regression cycle so platform updates do not silently break routing or status synchronization.
- Case integration checklist: Single entry point for users; SSO with worker context; population-scoped agent access; status synchronization; pay-impacting actions routed through HCM workflow; taxonomy small and accurate; integration monitoring alerts before users do.
14.3 Service Level Definition and Performance Governance
Service levels are an operational control. They define what employees can expect, how shared services prioritizes work, and how the organization enforces behaviors that protect payroll and compliance. Without clear service levels, “urgent” becomes subjective, escalations become political, and the service center is pulled in multiple directions at once.
Start by separating three concepts. SLAs: commitments to employees and managers about response and resolution times. OLAs: internal commitments between teams (shared services, payroll, benefits, IT) that make SLAs achievable. Cutoffs: hard deadlines driven by payroll calendars, statutory timelines, and business cycles. You cannot set meaningful SLAs without respecting cutoffs, and you cannot enforce cutoffs without visible SLAs and escalation.
Define service levels by journey and severity. A pay-impacting issue before payroll close is not the same as a general question about benefits. Create a shared severity model that is understood across HR and payroll: Severity 1: pay at risk for a population or statutory deadline at risk; Severity 2: pay at risk for an individual or high-visibility case; Severity 3: delay with a safe workaround; Severity 4: informational request. Tie each level to response and resolution targets and to escalation rules.
Set targets using baseline data and business rhythm. If you have no measured SLAs today, establish a baseline during stabilization and then tighten targets in steps rather than announcing aggressive commitments you cannot staff. Publish SLAs where users can see them, and train agents to communicate them consistently; unpublished SLAs do not shape expectations.
Build a balanced performance scorecard. Speed without quality creates repeat contacts; quality without speed creates backlog and forces off-cycle fixes. A practical scorecard includes: volume (cases per 1,000 employees), timeliness (SLA attainment by severity), quality (first-contact resolution, reopen rate), experience (satisfaction by journey), and preventability (share of avoidable cases). Add payroll-critical measures such as time-to-resolve pay-impacting cases and the share of issues caused by late approvals or missing data.
Standardize metric definitions to prevent gaming. “Response time” should mean time to first meaningful action, not an auto-acknowledgment. “Resolution” should be tied to a defined outcome and evidence step. Make these definitions part of the operating model, not an analytics footnote.
Governance is how service levels drive improvement. Run a weekly service performance forum chaired by HR operations with payroll and domain leads present. Review SLA performance, top contact drivers, repeat issues, and the improvement actions agreed for the next two weeks. Provide a monthly executive view focused on decisions: where to enforce manager compliance, where to simplify workflows, and where to invest in Tier 0 deflection. If governance only explains variance, it will not change outcomes.
Use OLAs to make upstream dependencies visible. Many service failures are not “service problems”; they are upstream behaviors. For example, payroll can meet its close window only if time approvals occur by cutoff. Shared services can resolve a leave case only if required documentation is provided. OLAs make these dependencies explicit and enable leadership intervention at the correct point in the chain.
Finally, design escalation to be predictable and calm. Escalation should not require knowing the “right person.” Use time-triggered rules (for example, if a Severity 1 case is not assigned within an hour, it escalates to a named payroll lead). Define who can approve exceptions such as off-cycle payments or late pay-affecting changes, and standardize communications templates for pay-impacting incidents so employees receive consistent updates.
- Service governance checklist: SLAs defined by severity and journey; OLAs defined for cross-team dependencies; metric definitions standardized; weekly performance forum drives actions; escalation is time-triggered and role-based; pay-impacting cases have tighter targets and evidence requirements.
14.4 Workforce Capacity and Skill Planning for HR Teams
Shared services and digital HR models fail when capacity planning is treated as “automation will reduce work.” Automation reduces some work, but it also creates new work: maintaining knowledge, monitoring workflow health, managing vendor feeds, governing data quality, and running release regression tests. Capacity planning must model both sides so the run organization can sustain the platform without constant escalation back to the project team or the system integrator.
Start with a demand model built from the service catalog and whatever volume data you have: case volumes by category, average handle times, peak periods (open enrollment, year-end forms, merit), and channel mix. If you lack formal case data, use proxies such as HR email volume, payroll inquiry counts, and time correction volume, then refine with real data after go-live. The model must be transparent: leaders should see assumptions and understand which levers will change demand.
Convert demand into capacity using three levers: deflection, productivity, and tiering. Deflection is the share of demand eliminated through Tier 0 journeys and knowledge. Productivity is handle time improvement through better routing, scripts, and system context. Tiering is how work is split across Tier 1 and Tier 2. Be conservative in early months; contact volume often spikes immediately after go-live and declines as knowledge and adoption stabilize. Plan explicitly for a short-term surge rather than treating it as a surprise.
Use a two-horizon staffing model. Horizon 1: go-live and stabilization (first 6–12 weeks), staffed for higher volume and higher escalation. Horizon 2: steady state (months 3–12), staffed for lower volume with dedicated time for continuous improvement and release readiness. This creates a glide path instead of a staffing cliff.
Build basic workforce management discipline even if you do not buy a dedicated tool. Define peak windows by pay cycle and region, schedule coverage accordingly, and include “shrinkage” for coaching, training, and meetings. Protect capacity for non-case work such as knowledge updates, quality reviews, and release testing; otherwise it will never happen and demand will not decline.
Plan a deliberate transition from project support to run support. Use shadowing during testing and the first pay cycles so run teams execute playbooks with experts observing, then reverse roles as confidence grows. Treat the handover of runbooks, knowledge, and escalation paths as a readiness gate.
Define skills by tier and build a capability plan.
Tier 0 skills: content design, journey thinking, and knowledge governance.
Tier 1 skills: troubleshooting, empathy, script discipline, and enough HCM fluency to guide users without taking work back from them.
Tier 2 skills: deep domain expertise, effective-dated thinking, and control awareness for pay- and eligibility-impacting actions.
Tier 3 skills: product management mindset—backlog prioritization, change control, regression testing, and data governance.
Role profiles should reflect these skills and should be tied to performance measures. For example, Tier 1 leaders should own knowledge quality and deflection outcomes, not just “tickets closed.” Payroll operations roles should own variance checks and reconciliation evidence, not just processing. Data stewards should own data quality thresholds and controlled structural changes. When measures align to outcomes, the operating model sustains itself.
Plan for reskilling and redeployment. If automation reduces manual processing, decide how the freed capacity will be used: improved service quality, better data stewardship, expanded analytics support, or actual headcount reduction. Ambiguity results in work expanding to fill capacity and benefits not being realized. Where workforce transitions are real, engage finance and labor relations early and follow lawful processes; uncertainty here is a major driver of resistance and shadow processes.
Global models also require explicit coverage decisions. Determine which interactions can be handled globally and which require local language or statutory interpretation (for example, leave entitlements, tax form questions, union premiums). A common scalable pattern is: Tier 1 provides global coverage for standard navigation and common questions using multilingual scripts and translation support; Tier 2 provides smaller specialist pools aligned to country clusters, with on-call coverage around payroll close; and local HRBPs focus on leadership support rather than case processing. Whatever pattern you choose, encode it in routing rules and SLAs so employees do not bounce between teams. Also define vendor coordination capacity: someone must own carrier and payroll provider escalations, file rejects, and evidence requests. If you do not staff this explicitly, it becomes invisible work done by your best specialists, and everything else slows down. For countries with works councils or strict privacy rules, reflect data residency and access constraints in staffing and tooling. Plan for peak events—open enrollment and year-end tax statements—by temporarily increasing local-language coverage and launching preemptive knowledge campaigns that answer the predictable questions.
Finally, fund continuous change. Every release and every policy update creates work: regression testing, knowledge updates, agent briefings, and post-release monitoring. Allocate explicit capacity for these activities. A sustainable HCM environment assumes frequent change; capacity planning must assume it too.
- Capacity model template: Demand (cases/month by category) × handle time (minutes) × productivity factor × (1 − deflection factor) = Tier 1 workload, then convert to FTE using available minutes per agent and a shrinkage factor for training, meetings, and peak coverage.
- Skill plan essentials: knowledge ownership with cadence; effective-dated stewardship; payroll control literacy for service leaders; analytics capability to turn contact drivers into improvements; release readiness embedded in run roles.
When HR service delivery is staffed and skilled for the digital model, employees feel the platform’s value where it matters: faster answers, fewer errors, and clearer accountability. When it is not, shared services become a permanent buffer that rebuilds manual workarounds—and the organization slowly recreates the complexity the HCM program was meant to remove.
