One Org or Three? Consolidating a Multi-Unit Service Estate

Recommendation: one org for consumer support and warranty/field dispatch; a separate EU-resident instance (or a residency-compliant configuration, confirmed contractually) for any workload touching EU personal data; a decision gate on the IT helpdesk rather than a commitment now.

Reasoning:

• Shared customer and asset data is the strongest single-org argument. Dealers, installed equipment, and consumer owners overlap, and a warranty claim is only resolvable when an agent can see the asset and the prior consumer contact. Duplicating that master data across orgs costs more, permanently, than any admin savings.
• Data residency is a constraint, not a preference. A works council requirement is not beatable with a business case. Either the platform can contractually keep EU personal data in region for all processing (including AI features, backups, and integrations), or the workload lives in its own org. Get that in writing in the order form; do not accept a verbal assurance, and do not let the residency question be answered by the architect alone.
• Release cadence divergence is a real tax, not a blocker. 12 vs 4 vs 30 deployments a year is survivable in one org with sandboxes, a pipeline, and release trains; it is not free. Weigh it against the integration spend the CIO wants to remove.
• IT helpdesk is a different domain (approval-driven, CMDB-centric, ITIL-shaped). Its renewal date is a natural evaluation gate, not a reason to pre-commit two years early.

Decision gates for the committee: written residency opinion; quantified decommission savings vs. added DevOps cost; and a fit test of the ITSM process against the platform.

Use three orthogonal levers, not one picklist.

• Case record types plus support processes, one per unit (Consumer, Warranty/Field, IT). Record types drive layouts, required fields, and which support process applies; support processes are the true boundary for assignment, escalation, and entitlement behaviour. Keep the number small, because every process multiplies test surface and every new one is a permanent maintenance cost.
• Queues per unit and region, with assignment rules keyed on record type plus product/asset attributes. Omni-Channel routes on queues, so a consumer chat can never land in a field dispatch queue. Skills for routing should be derived from the same taxonomy, not maintained in parallel.
• Sharing: set Case OWD to Private. Share Account, Asset, and Contact broadly (dealers and assets must be visible across units), but not cases. Agents see cases through queue membership and role hierarchy. Add criteria-based sharing only for the genuine cross-unit exception - e.g. a warranty claim raised through consumer support on an installed asset - and use case teams for individual collaborators rather than widening the model.
• SLA separation: separate entitlement processes per unit with region-specific business hours. Document the precedence rule when a case matches more than one entitlement, and test it; ambiguous precedence is the most common source of 'the clock is wrong' complaints.

Explicitly reject a single record type with a Business Unit picklist: you lose per-unit layouts, per-unit automation, and clean queue visibility, and you gain nothing.

Sequence by risk and dependency, not by unit size.

1. Foundation (weeks 0-8): identity and SSO, sharing model, record types, queues, sandbox strategy, deployment pipeline. Nothing user-visible breaks if this slips, which is exactly why it must not be compressed.
2. Warranty and field dispatch first. It already lives in the Sales org, so its Accounts and Assets are every other unit's dependency; its user base is moderate and tolerates a phased cutover; and moving it first proves the sharing model under real dealer data.
3. Consumer support second, one channel at a time - email before chat, chat before messaging. Messaging cutover is the least reversible and depends on routing and knowledge behaviour already being stable in production.
4. IT helpdesk last, after the renewal decision, as its own wave with its own record type and approval integration.

Gates between phases (each must be objectively passed, not 'feeling good'):

• Error rate and reopen rate on migrated or newly routed cases below an agreed threshold;
• Milestone accuracy validated against the source system for two consecutive weeks;
• Supervisor sign-off that queue and skill routing matches reality;
• A documented rollback that keeps the source system readable for at least a month.

Adoption risk sits with the unit whose daily process changes most - that is consumer support moving from a single channel to Omni-Channel, not the unit that moves last. Put floor support and hypercare there, and resist the temptation to spend the change budget on the pilot where people are already motivated.