> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mosaqo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Request lifecycle

> Every status a booking request can be in, who moves it forward, and what each button actually does.

Every guest booking moves through a fixed set of statuses. This page is the reference for what each one means and exactly how it changes.

## The statuses at a glance

```
UNASSIGNED → ASSIGNED → ACCEPTED → IN PROGRESS → COMPLETED
                  ↘  NEEDS ATTENTION  ↗
        (any non-in-progress status) → CANCELLED
```

| Status              | What it means                                                    |
| ------------------- | ---------------------------------------------------------------- |
| **Unassigned**      | New request, no provider picked yet                              |
| **Assigned**        | You've picked one or more providers; waiting on their acceptance |
| **Accepted**        | All assigned providers have accepted                             |
| **In progress**     | A provider marked the service as started                         |
| **Needs attention** | A provider flagged a problem while working the request           |
| **Completed**       | The service was delivered                                        |
| **Cancelled**       | You cancelled it                                                 |

<Frame caption="Request detail pane — status badge and available actions">
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/mosaqo/images/requests/request-detail-pane.png" alt="Request detail pane" />
</Frame>

## Unassigned → Assigned

You assign a request to one or more providers from the Requests page. See [Assigning a request](/requests/assigning-a-request) for the full walkthrough.

<Note>
  There's no auto-assign. Every request starts Unassigned and stays that way until a PM picks a provider — even if you've set up a "default" provider concept elsewhere, it isn't wired up to auto-assign requests today.
</Note>

## Assigned → Accepted

Each assigned provider gets an **Accept** / **Decline** choice.

* **If you assigned multiple providers**, the request only becomes Accepted once *all* of them accept. Until then, you'll see "X of Y accepted" in the detail pane.
* **If a provider declines**, they give a reason (schedule conflict, service not available, unable to reach the guest, or other). The request drops back to Unassigned only if everyone else has also declined or was never assigned — otherwise it just waits on the remaining providers. There's no auto-reassignment; you'll need to assign someone new yourself.
* **15-second undo window**: right after accepting, a provider (or you, while others are still pending) can undo the acceptance. The guest's "your request was accepted" email is deliberately held back for those 15 seconds too, so an accidental tap doesn't notify the guest prematurely.

## Accepted → In progress

Normally the provider taps **Start** when they begin the job. If they can't (no phone access, forgot, etc.) and you know the work has started, you can click **Mark started** yourself — you'll be asked to confirm, since this updates the record on their behalf.

## In progress → Completed

Same pattern: the provider taps **Complete**, or you use **Mark completed** if they can't do it themselves.

## Needs attention

A provider raises this — it's the only way a request gets here, and it can only happen **while the request is In progress**. They pick a reason (guest not available, unable to reach the guest, guest requested to cancel, service can't be completed as booked, safety/access issue, equipment/supply problem, or other) via **Report an issue**.

You'll see an orange banner with their reason. From there you choose how to resolve it:

<Frame caption="Needs attention banner with resolution options">
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/mosaqo/images/requests/needs-attention-banner.png" alt="Needs attention banner" />
</Frame>

<Steps>
  <Step title="Reassign">
    Resets acceptance for the currently assigned providers — they'll need to accept again — and puts the request back in Assigned.
  </Step>

  <Step title="Mark completed">
    If the issue turned out not to block finishing the job.
  </Step>

  <Step title="Cancel">
    If the request can't be salvaged. Same Cancel flow as below.
  </Step>
</Steps>

## Cancelling

Only you (the PM) can cancel a request — providers can decline before accepting or report an issue while in progress, but they can't cancel outright. See [Cancelling a request](/requests/cancelling-a-request) for the full flow and what it does (and doesn't) do about refunds.

## Reminders

If a provider is sitting on a **Pending** assignment and hasn't responded, click **Remind provider** (visible while the request is Assigned) to re-send them the assignment notification. There's a 4-hour cooldown between reminders for the same provider so you can't spam them.

## Duplicating (rebooking)

Once a request is **Completed** or **Cancelled**, a **Duplicate** button lets you create a fresh booking with the same details — property, service, guest info, add-ons, pricing — but:

* A new reference number
* Status reset to Unassigned (you'll need to assign it again)
* Assignment/activity/message history is **not** copied
* Payment is reset to Cash / Pending regardless of how the original was paid

Handy for a returning guest or a recurring booking, without retyping everything.

## Editing a request

<Warning>
  There's no edit feature yet. You'll see a disabled **Edit request** button in the detail pane — it's coming, but isn't built. Until then, the way to change a request's details is: cancel it and create a new one, or use **Duplicate** on a finished one and adjust the date/time.
</Warning>

## Where to see what happened

Every request has an **Activity** feed in the detail pane — a plain-language history ("You assigned the request to Jane Doe," "Provider accepted the request") with timestamps. This is separate from the org-wide **Audit Log** page, which tracks account/catalog changes (properties, services, staff) but not request status history — for a specific request's story, the Activity feed on that request is the only place to look.
