Understanding the "Requested At" timestamp and how it affects triggered policies and acknowledgement deadlines.
The Requested At timestamp is a critical value that determines when a request is considered to have been officially submitted. This timestamp drives two important calculations:
Short Notice Policy - Whether the request qualifies for short notice fees
Acknowledgement Due At - The deadline for partner to communicate with the customer about the request's status
How Requested At Works
Standard Workflow (Customer or Auto-Approved Requests)
When a customer creates and submits a request (or when an partner creates a request that is automatically approved) the Requested At timestamp is set to the moment of submission or approval.
Request Created (Draft) → Submitted/Approved → Requested At = Now
Example:
Partner creates a draft request on Monday at 9:00 AM
Partner submits the request on Monday at 2:00 PM
Requested At is set to Monday 2:00 PM
All policy calculations use Monday 2:00 PM as the reference point
Partner Backdating Workflow
Partners sometimes receive requests via email, phone, or other channels before they can enter them into the system. In these cases, an partner can manually set the Requested At to reflect when the request was actually received.
Email Received (Friday 3pm) → Admin Creates Request (Monday 9am) → Requested At = Friday 3pm
Example:
Customer emails a request on Friday at 3:00 PM
Admin enters the request into the system on Monday at 9:00 AM
Admin sets Requested At to Friday 3:00 PM
All policy calculations use Friday 3:00 PM as the reference point
When an admin manually sets the Requested At timestamp, that value is preserved throughout the request lifecycle. The system will not overwrite it when the request is submitted or approved.
Impact on Short Notice Policy
Short notice policies determine whether additional fees apply based on how much lead time exists between the request and the scheduled service. The Requested At timestamp is the starting point for this calculation.
In the backdated example, even though the admin entered the request on Monday, the short notice policy correctly applies because the Requested At reflects Friday 3:00 PM (the actual time the customer made the request).
Impact on Acknowledgement Due At
The Acknowledgement Due At is calculated based on the Requested At timestamp and determines when partners must acknowledge the request.
Calculation Logic
The acknowledgement deadline is calculated as:
Start with the Requested At timestamp
Add the configured lead time (e.g., 48 hours)
Round up to the next cutoff time (e.g., 4:00 PM)
If the result exceeds the service start time, use half the remaining lead time instead
Example with 48-hour lead time and 4:00 PM cutoff:
Requested At
Service Starts
Initial Calculation
Final Acknowledgement Due
Monday 9:00 AM
Friday 2:00 PM
Wednesday 4:00 PM
Wednesday 4:00 PM
Monday 9:00 AM
Tuesday 10:00 AM
Wednesday 4:00 PM (exceeds start)
Monday 9:30 PM*
Friday 3:00 PM
Monday 10:00 AM
Sunday 4:00 PM (exceeds start)
Saturday 12:30 AM*
*When the calculated deadline exceeds the service start time, the system uses half the available lead time instead.
If an admin backdates the Requested At timestamp, the acknowledgement deadline will also be calculated from that earlier time. This may result in acknowledgement deadlines that have already passed.
Technical Details
For each service on a request, the system stores:
Requested At - When the request was officially submitted (drives policy calculations)
Acknowledgement Due At - Calculated deadline for provider acknowledgement
Created At - When the record was created in the database (for auditing)
When a request is submitted or approved:
If Requested At was manually modified by an admin, it is preserved
If Requested At was not modified, it is updated to the submission/approval time
Acknowledgement Due At is recalculated based on the final Requested At value
