Which handoffs missed the four-hour rule?
A shared acceptance rule applies to both teams. Use each receiving team’s supplied business window.
The question
Alder Relay is a fictional B2B subscription-software company with Boston and London teams. This is an interview case, using an authored packet rather than a real CRM export.
| Assigned UTC | Accepted UTC | Team | |
|---|---|---|---|
| UK A | 2026-11-02T15:00:00Z | 2026-11-03T11:00:00Z | London |
| UK B | 2026-11-06T16:00:00Z | 2026-11-09T12:00:00Z | London |
| US C | 2026-11-06T21:00:00Z | 2026-11-09T18:00:00Z | Boston |
| US D | 2026-11-02T14:00:00Z | 2026-11-02T19:00:00Z | Boston |
Fictional rule: accept within 4 receiving-team business hours, including exactly 4. Monday–Friday, no holidays. Supplied windows for these dates: London 09:00–17:00 UTC; Boston 14:00–22:00 UTC. The clock starts on assignment and does not restart on reassignment.
“State the measure, the evidence and the next owner.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Separate sending from acceptance
What would you do here? Open the move you’d make.
Use receiver acceptance timestamps
The strong move. Measure the event the policy names.
Treat a notification as acceptance
Tempting, but it misses something. A delivered alert does not prove that the receiver accepted the work.
See how a strong candidate says it
“The clock starts on assignment. A notification or an owner field alone is not an acceptance event.”
Why it works: Measure the event the policy names.
Step 2: Use the receiving clock
What would you do here? Open the move you’d make.
Apply the receiving team’s window
The strong move. These supplied windows avoid guessing at elapsed wall-clock time.
Use one global elapsed-hour clock
Tempting, but it misses something. A weekend or overnight gap is not four hours of working time.
See how a strong candidate says it
“London counts 09:00–17:00 UTC and Boston 14:00–22:00 UTC on weekdays for this packet. Nights and the weekend do not count.”
Why it works: These supplied windows avoid guessing at elapsed wall-clock time.
Step 3: Test the boundary
What would you do here? Open the move you’d make.
Keep the inclusive boundary
The strong move. Exactly four hours passes; greater than four breaches.
Mark exactly four hours late
Tempting, but it misses something. The fictional policy explicitly includes exactly four hours.
See how a strong candidate says it
“UK A and UK B each took 4 business hours, within the inclusive rule. US C and US D each took 5, so they breached.”
Why it works: Exactly four hours passes; greater than four breaches.
Step 4: Assign the repair
What would you do here? Open the move you’d make.
Fix the late records and review pending ones
The strong move. An average alone can hide which records need repair.
Reset the timestamp when the lead is reassigned
Tempting, but it misses something. Resetting the clock would conceal the original delay.
See how a strong candidate says it
“Two of four accepted handoffs breached, or 50%. I would inspect the two late records and assign a receiving owner plus a next action.”
Why it works: An average alone can hide which records need repair.
The answer, in short
- Decision
- UK A and UK B pass; US C and US D breach.
- Because
- The receiving-team business durations are 4, 4, 5 and 5 hours.
- What would change it
- A different documented work calendar or corrected timestamp would change the result.
Common traps
- A delivered alert does not prove that the receiver accepted the work.
Check your answer
- I used assignment and acceptance events.
- I used each region’s window.
- I applied the inclusive boundary.
- I kept pending work visible.
Last reviewed Nov 10, 2026