Which rescheduling policy applies?
Read the policy date against the original purchase time.
The question
A customer asks to move a fictional coworking day pass because their plans changed. The visit is on 8 July.
| Hours | |
|---|---|
| Purchased before 1 July 00:00 UTC | 48 |
| Purchased from 1 July 00:00 UTC | 120 |
Both policies require a future visit. The current help article describes the 120-hour window.
- Purchase display1 July in UTC+02. The display omits the time.
- Request received4 July at 12:00 UTC.
Keep the original pass or show current rebooking options. If a customer reports a booking portal outage, a specialist can review it after you verify the incident reference.
“How do you decide what you can offer?”
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: Which record decides?
What would you do here? Open the move you’d make.
Get the UTC purchase event
The strong move. It tells you which policy was in force when the customer paid.
Use the current help article
Tempting, but it misses something. It describes newer purchases and cannot date this one.
Use the 1 July display as the cutoff
Tempting, but it misses something. The display is two hours ahead of UTC.
See how a strong candidate says it
“I’ll check the exact UTC purchase time in the ledger and match it to the start of the policy.”
Why it works: A local date without a time does not place the purchase on either side of a UTC cutoff.
Step 2: What can you offer now?
What would you do here? Open the move you’d make.
Keep the pass active and explain the check
The strong move. This protects the booking and avoids a premature decision.
Reschedule now under 120 hours
Tempting, but it misses something. The purchase may have happened before that rule began.
Escalate for an outage exception
Tempting, but it misses something. The customer reports a schedule change. The specialist needs an outage report and a reference.
See how a strong candidate says it
“I’ll keep your original pass active while I confirm which change window applies.”
Why it works: The customer can still use the existing booking while support verifies the missing fact.
Step 3: Does the pass qualify?
The purchase ledger shows 30 June at 23:40 UTC. That is 1 July at 01:40 in UTC+02.
What would you do here? Open the move you’d make.
Apply the 48-hour window
The strong move. The recorded purchase is before the UTC cutoff, and 84 hours and 20 minutes exceeds 48 hours.
Apply the 120-hour window
Tempting, but it misses something. The local date is 1 July, but the UTC purchase is still on 30 June.
Apply neither window
Tempting, but it misses something. The timestamp and the policy record are sufficient for the standard decision.
See how a strong candidate says it
“It was purchased 20 minutes before the policy changed. The request arrived 84 hours and 20 minutes later, outside the applicable 48-hour window.”
Why it works: The local date and UTC date refer to the same purchase. The UTC instant decides which window applies.
Step 4: How do you explain the decision?
What would you do here? Open the move you’d make.
Explain the window and offer the two available options
The strong move. The customer can keep the visit or choose whether to rebook.
Cancel the original pass
Tempting, but it misses something. The customer asked to move it. You do not have their approval to cancel.
Say support has no further options
Tempting, but it misses something. The policy gives two next steps even after the free window ends.
See how a strong candidate says it
“The free change window for your pass was 48 hours. Your request arrived after that window. I can keep your 8 July booking or show you the current options for a new date.”
Why it works: The reply explains the outcome in plain terms and gives the customer a choice.
The answer, in short
- Decision
- Keep the original pass active and explain the options after the 48-hour window.
- Because
- The recorded purchase precedes the policy change and the request arrived more than 48 hours later.
- What would change it
- A purchase from 1 July 00:00 UTC would use the 120-hour window.
Common traps
- Using the latest article for a purchase covered by an earlier policy.
- Treating a local date as UTC.
Check your answer
- What event starts the window?
- Which time zone applies to the cutoff?
- How much time elapsed?
- What option can the customer choose now?
Last reviewed Nov 11, 2026