# Requested Timestamps

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:

1. **Short Notice Policy** - Whether the request qualifies for short notice fees
2. **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

{% hint style="info" %}
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.
{% endhint %}

## 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.

**See:** [Triggered Policies](https://docs.octoo.com/general/agreements/triggered-policies) for details on time calculation methods.

### Example: 48 Business Hours Short Notice Policy

| Scenario            | Requested At   | Service Starts    | Lead Time           | Short Notice? |
| ------------------- | -------------- | ----------------- | ------------------- | ------------- |
| Normal request      | Monday 9:00 AM | Wednesday 2:00 PM | \~53 business hours | No            |
| Last-minute request | Monday 9:00 AM | Monday 4:00 PM    | \~7 business hours  | Yes           |
| Backdated request   | Friday 3:00 PM | Monday 10:00 AM   | \~11 business hours | Yes           |

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:

1. Start with the **Requested At** timestamp
2. Add the configured lead time (e.g., 48 hours)
3. Round up to the next cutoff time (e.g., 4:00 PM)
4. 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.

{% hint style="warning" %}
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.
{% endhint %}

## 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