# 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](/general/agreements/triggered-policies.md) 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.octoo.com/general/requests/requested-timestamp.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.