Relocation Service Design

Relocating an installed product is not one service. It is a removal at one address and an installation at another, separated by time, and often by a different crew. The design existed to make that dependency explicit in the system rather than in somebody's memory.

Treated as a single job, a relocation loses its second half. Treated as two unrelated orders, the assembly can be scheduled before the origin site is clear, and disputes about the condition of the product have no record from the first visit to refer back to. Both failure modes produce the same customer experience: a crew arriving to a situation nobody prepared for.

• Model the move as two orders with an enforced sequence. The second becomes actionable only when the first is verified complete.
• Make completion a gate, not a status. Verification at the origin site is what unlocks scheduling at the destination.
• Capture condition at disassembly. Without a record from the first visit, every later damage conversation becomes a matter of opinion.
• Train the sequence, not just the steps. The operational risk lives in the link, so that is what the training material should emphasize.
• Keep the customer informed at the gate. The wait between the two visits is where confidence is lost.

1. 01

   A two-order model

   Disassembly and assembly created as linked records with a defined dependency, so neither can drift into an unrelated job.

2. 02

   A completion gate

   A verification step at the origin site that must close before the destination work becomes schedulable.

3. 03

   A condition record standard

   Documented state and evidence captured at removal, carried forward to the installation as the reference point.

4. 04

   An internal training outline

   A short walkthrough of the sequence, the dependency, and the three ways it typically breaks.

1. 01

   Refuse to model it as one job

   A single order is simpler to create and impossible to schedule honestly, because the two halves have different sites, different crews, and different timing.

2. 02

   Gate on verification rather than on elapsed time

   Time-based sequencing assumes the first visit went as planned. Verification-based sequencing assumes nothing and is right more often.

• Reinforced the exception taxonomy with a dependency failure category.
• Fed the sequencing logic later reused in multi-visit service work.

This is a small artifact with a disproportionate lesson: most service failures in physical operations are not failures of execution, they are failures of linkage. When I look at a new workflow now, the first question I ask is which two steps are assumed to remember each other.

• Customer Operations
  Order Operations Architecture →

  An operating model for orders: one rule that settles ownership, a split-intake work design, and a decision tree an associate can run in the moment.

• Customer Operations
  Order Lifecycle Failure Map →

  Nine lifecycle stages drawn alongside the specific failure that occurs at each one, with the current state and the intended state stated side by side.