A global mobility operating model is the design of how an organisation decides, delivers, pays for, controls and reports on cross-border employee moves. It defines who owns policy and approvals, where case management sits, which providers deliver which services, how data and technology connect them, how costs are controlled, how compliance is evidenced and how employees are supported. For a multi-country organisation, the operating model matters more than any single supplier: it determines whether moves are predictable, auditable and affordable as volume and complexity grow. Design it in layers — governance, delivery, providers, data, finance, compliance and experience — then choose who executes each layer.
Key takeaways
- An operating model has seven layers; ‘internal vs outsourced’ is only one decision within the delivery layer.
- Choose a structural pattern — centralised, decentralised or hybrid — based on where decisions and expertise must sit.
- Write a RACI for the moves you actually run, including project deployments and onward regional moves.
- Use a maturity model to set a realistic target state, then transition in waves.
- Measure the model through a small set of KPIs agreed by HR, finance and operations.
What is a global mobility operating model?
Think of it as the blueprint behind every move. A mobility policy says what employees are entitled to. An operating model says who makes which decision, who performs which task, in what sequence, with what data, under which controls and with what reporting. Two companies with identical policies can have very different results because one has clear ownership and the other relies on emails between HR, business units and a dozen suppliers.
| Layer | Key question | Typical design choices |
|---|---|---|
| Governance and ownership | Who sets policy, approves moves and accepts risk? | Mobility steering group, executive sponsor, exception authority |
| Service delivery | Who runs cases day to day? | Internal team, co-managed, outsourced managed mobility |
| Provider ecosystem | Who performs specialist work? | Preferred suppliers, open ecosystem, single provider |
| Technology and data | Where does the case record live? | Single case platform, integrations with HRIS and payroll |
| Finance and cost control | How are costs forecast, approved and reconciled? | Cost estimates, budget approvals, cost-centre reporting |
| Compliance chain | How are checks evidenced? | Pre-work readiness gates, advice records, renewal tracking |
| Employee experience | How are employees and families supported? | Single point of contact, communication standards, feedback |
Governance and ownership
Mobility often sits between HR, total rewards, finance, legal and the business. Without explicit ownership, decisions drift to whoever is most urgent. Name an accountable owner for the programme, a forum where HR, finance and business leaders review performance and exceptions, and an exception authority with documented limits.
Centralised, decentralised or hybrid?
| Pattern | How it works | Strengths | Risks |
|---|---|---|---|
| Centralised | One global team owns policy, approvals and case management | Consistency, data quality, negotiating leverage | Distance from local business needs; bottlenecks |
| Decentralised | Each country or business unit runs its own moves | Local responsiveness | Inconsistent policy, fragmented data and suppliers, hidden cost |
| Hybrid (hub-and-spoke) | Central governance and data; regional hubs coordinate delivery; local teams own business relationships | Balance of control and proximity | Requires precise role definitions to avoid duplication |
Many multi-country organisations settle on a hybrid pattern: global policy and reporting, regional coordination hubs (for example Dubai for the Middle East), and local HR owning the business relationship and employee contact.
The service delivery layer
This is where the internal, co-managed or outsourced decision belongs. The question is who runs cases day to day: intake, specialist coordination, dependency tracking, employee communication, cost reconciliation and reporting. We cover that decision in depth in a separate guide; within the operating model, the key point is that execution can move while accountability for policy and risk stays with the employer. Keep the strategy. Outsource the operation.
- Internal vs co-managed vs outsourced global mobility
- Global mobility outsourcing: operating-model guide
The provider ecosystem
Decide whether you want a closed network (one provider supplies everything), a preferred-supplier list managed internally, or an open ecosystem where a coordinator works with both its own services and the providers you already trust. The right answer depends on supplier performance, contractual commitments and how much variety your corridors require. Whatever you choose, define instruction rights, status reporting, advice storage and invoicing for every provider.
Technology and data
The case record should be the single source of truth: who is moving, where, why, under which arrangement, with what approvals, documents, milestones and costs. Technology should make the operating model visible — tasks, alerts, reports — but it does not replace the people accountable for the work. Decide which systems feed the case record (HRIS for employee data, payroll for compensation changes, finance for cost centres) and which reports each stakeholder receives.
Finance and cost control
Finance needs four numbers per move: the estimate at request, the approved budget, committed spend and final actuals. Define who approves estimates, how exceptions are approved and how third-party invoices are mapped to cases. Tax and payroll treatment of allowances should be confirmed with advisers before payment, not after.
The compliance chain
Compliance in mobility is a chain of checks, each owned by someone: confirming the work arrangement, obtaining work authorization before duties start, assessing tax and social-security questions, tracking renewals, recording business travel activity and closing the case properly. Build readiness gates into the workflow — for example, no start-date confirmation until work authorization status is confirmed by the responsible adviser — and keep evidence in the case record.
Employee experience
Employees judge the operating model by communication. Assign one point of contact, set response standards, explain what is happening and why, and support families separately from the employee's work authorization. Collect feedback at defined milestones and review it with service performance.
Reporting
Reporting closes the loop. Agree a small set of KPIs by stakeholder — cycle times, readiness on start date, exceptions, cost against budget, employee satisfaction, provider performance — and review them in the governance forum.
Example RACI for a cross-border move
R = responsible, A = accountable, C = consulted, I = informed. Adapt to your structure; this example assumes a co-managed or managed model.
| Activity | Business manager | HR / Mobility lead | Mobility partner | Specialist advisers | Finance | Employee |
|---|---|---|---|---|---|---|
| Request move and business case | R | A | I | — | C | I |
| Approve policy package and budget | C | A | C | — | R | I |
| Case intake and feasibility triage | C | A | R | C | I | C |
| Immigration / work authorization | I | A | R (coordinate) | R (advise/file) | I | C |
| Tax and social-security assessment | I | A | R (coordinate) | R (advise) | C | C |
| Relocation and settling-in | I | A | R | C | I | C |
| Start-date readiness confirmation | I | A | R | C | I | I |
| Cost reconciliation | I | C | R | — | A | — |
| Programme reporting | I | A | R | — | C | — |
Target operating model design steps
- Baseline: map current move types, volumes, corridors, roles, suppliers, systems and pain points.
- Trace three recent anonymised moves end to end, recording every handoff and delay.
- Define design principles with HR, finance and operations (for example: one case owner per move; no work before readiness confirmed).
- Choose the structural pattern: centralised, decentralised or hybrid.
- Decide the delivery model per move type — you may run executive moves internally and outsource project deployments.
- Design the provider ecosystem and contracts.
- Define the data model, systems and reports.
- Write the RACI, readiness gates and exception process.
- Agree KPIs and governance cadence.
- Plan transition in waves and communicate the change.
Global mobility maturity model
| Level | Description | Typical signals |
|---|---|---|
| 1. Reactive | Moves handled ad hoc by whoever receives the request | Email and spreadsheets; costs discovered after the fact |
| 2. Defined | Policy exists; preferred suppliers; basic tracking | Inconsistent ownership; reporting assembled manually |
| 3. Coordinated | One case owner per move; readiness gates; consolidated case record | Predictable timelines; cost estimates before approval |
| 4. Managed | Governed operating model with KPIs, provider oversight and finance integration | Regular governance reviews; exceptions trending down |
| 5. Strategic | Mobility data informs workforce planning and expansion decisions | Leadership uses mobility insight in project and market decisions |
Few organisations need to jump to level 5. Moving from level 2 to level 3 — one owner, one record, clear gates — usually delivers the biggest practical improvement.
Transition roadmap
| Phase | Focus | Outputs |
|---|---|---|
| Discover | Baseline, case tracing, stakeholder interviews | Current-state map and problem list |
| Design | Target model, RACI, providers, data, KPIs | Target operating model document |
| Prepare | Contracts, system configuration, communications | Go-live readiness checklist |
| Pilot | One move type or region | Lessons learned; adjusted processes |
| Scale | Remaining move types and regions in waves | Full programme coverage |
| Optimise | KPI reviews, provider performance, policy updates | Continuous improvement backlog |
Keep open cases with their existing owners unless a clean handover is possible; never force an employee's live application through a new process mid-flight.
Employer scenario: a hybrid model across three regions
Consider a company with headquarters in Europe, a regional office in Dubai and a growing US presence. Moves were handled by local HR in each country, with separate suppliers and no shared reporting. The redesigned model keeps policy and exceptions with a central mobility lead, uses Dubai as the Middle East coordination hub for UAE and GCC moves, delegates day-to-day case management to a managed mobility partner, retains a trusted immigration firm in one country inside an open ecosystem and gives finance a monthly cost report by cost centre. This is an illustrative design, not a client case.
Common mistakes
- Treating the operating model as a supplier decision rather than a design exercise.
- Designing for permanent transfers only and ignoring business travel, project deployments and remote-work requests.
- Writing a RACI that no one uses because it does not match real workflows.
- Implementing technology before defining ownership and data.
- Skipping finance in design, then struggling to report cost.
- Moving everything at once instead of piloting.
The minimum viable operating model document
A useful target-state document does not need to be a presentation full of abstract diagrams. It needs a scope statement, a move-type catalogue, decision rights, a named case owner at each step, the provider map, required case fields, approval gates, cost fields, a reporting calendar and an escalation path. Make the first version short enough that a regional HR partner can use it during a real request. Ask someone outside mobility to walk a live case through it; if they cannot identify the next owner, the design is not finished.
Version control matters. Country-specific steps change, and a global process should not silently overwrite local advice. Give every country appendix an owner, a date of review and a route for urgent corrections. Keep a decision log for policy exceptions: what was requested, who approved it, the rationale, the cost and whether it suggests a policy change. The model should improve from evidence rather than accumulate undocumented workarounds.
| Document | Owner | Update trigger |
|---|---|---|
| Move-type catalogue and intake | Mobility lead | New move type or new region |
| RACI and approval matrix | HR operations | Organisation or delegation change |
| Country appendices | Local HR and qualified advisers | Rule or process change |
| Provider map and escalation path | Vendor manager | Contract or service change |
| KPI definitions and cost codes | Mobility lead and finance | Reporting or policy change |
How to test a proposed design before rollout
Run three different cases through the future-state process: a permanent family transfer, a short project rotation and an urgent business trip whose activities may amount to work. Record who receives the request, which facts are missing, who decides the route, who asks advisers, who approves spend and who confirms readiness. The exercise exposes whether a single workflow can handle different populations or whether separate branches are needed. It also reveals where handoffs are duplicated or where nobody is accountable.
Then test failure, not just the happy path. What happens if a permit is delayed after flights are booked? Who tells the manager to change the start date? Who contacts the employee? Who approves extra temporary accommodation? What happens if a trusted local provider refuses to update the shared record? Document answers in the operating model and make them part of the pilot acceptance criteria. An elegant RACI that fails under pressure is not a working design.
Important: immigration, employment, tax, payroll and social-security outcomes depend on nationality, employing entity, activities, duration, location and the current rules of each jurisdiction. This article is general guidance, not legal or tax advice. Validate every case with qualified local advisers and the competent authorities before travel or work begins.
How xpath.global supports operating model design
xpath.global is a Global Mobility Management Company powered by technology. We help employers design the operating model, then run the delivery layer as a managed service where that is the right choice — immigration, tax coordination, relocation and settling-in under one accountable case owner, with case tracking and reporting on our platform. You keep policy, approvals and strategy; we manage the mobility operation.
- How to choose a global mobility management company
- Global mobility KPIs for HR, finance and leadership
- Global mobility management: the complete employer guide
- Managed mobility
Frequently asked questions
What is the difference between a mobility policy and an operating model?
A policy defines entitlements and eligibility. An operating model defines who decides, who delivers, with which providers, data, controls and reporting.
Which structure is best for a multi-country organisation?
Many use a hybrid model: central policy, governance and data; regional coordination hubs; local business ownership. The right answer depends on volume, corridors and where expertise sits.
Do we need new technology to change our operating model?
Not necessarily first. Define ownership, data and gates; then choose technology that supports them. A managed mobility partner may provide the platform as part of the service.
How long does an operating model redesign take?
It depends on scope, number of regions and contract changes. Plan discovery and design before committing to a go-live date, and pilot before scaling.
Can different move types use different delivery models?
Yes. Many employers keep executive moves close to HR while outsourcing project deployments or high-volume transfers.
Who should sponsor the redesign?
Usually the CHRO or HR operations lead, with finance as a co-sponsor because cost visibility is a core outcome.
Review governance, delivery, providers, data and reporting with a mobility consultant and get a practical target state.
Request a Global Mobility Operating Model Assessment
