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

# Read a reservation

> The reservation record decoded: status lifecycle, the guest behind it, the channel it came from, and what your PMS owns

## What this helps you do

Answer "which reservation?" — the first question behind almost any guest
issue — and read the record correctly once you have it.

## The status lifecycle

A reservation moves through a small set of statuses:

| Status | Meaning |
| - | - |
| **Inquiry** | A guest asked about a stay; nothing is committed |
| **Confirmed** | The booking is real and upcoming |
| **Checked In** / **In Stay** | The guest is currently at the property |
| **Checked Out** | The stay ended normally |
| **Canceled** | The booking ended before or during the stay |

Status answers most timing questions on its own: a "late checkout" request
against a **Checked Out** reservation and one against an **In Stay**
reservation are different conversations.

## What hangs off the record

* **The guest contact.** The person behind the stay, with their conversation
  history. One contact can hold many reservations across properties and years.
* **The property.** The stay links to exactly one property, which is where
  cleaning, maintenance, and house details live.
* **The channel.** Where the booking originated — a listing channel or a
  direct booking. Channel determines how guest messages travel and which
  policies came with the booking.
* **Connected work.** Tasks and conversations created for this stay reference
  it, so the reservation is the hub for tracing what happened around a stay.

## What your PMS owns versus Trellis

When a property management system is connected, it is the source of truth for
the booking itself — dates, status, guest identity, and money sync from the
PMS into Trellis. Work that happens around the stay — conversations, tasks,
notes, AI activity — lives in Trellis.

The practical rule: to change booking facts, change them in the PMS and let
the sync carry them over; correcting them only in Trellis will not hold. For
tracing and fixing wrong information wherever it lives, see
[Fix wrong AI information](/guides/fix-wrong-ai-information).

## Block dates on connected booking channels

Administrators and managers can block and unblock dates by default. A custom
role or workspace override can restrict this through reservation edit and
delete permissions.

For properties whose availability is managed through Trellis's channel
connection, ask the AI Agent to block dates and name the property. Include the
year and departure date: "Block November 10–13, 2026 for Apartment 4 for
maintenance" closes the nights of November 10, 11, and 12. November 13 remains
outside that block. If the start date has already passed, only current and
future nights can be updated.

Trellis saves the block and checks that the connected calendar reflects it.
When Airbnb is connected, it also checks the mapped listing. A saved local
block alone is not confirmation that Airbnb has closed the dates. If the
connection is inactive, restore it in **Settings > Integrations**. If
confirmation is pending, retry the same property and dates to check delivery;
this does not create a second block.

Ask the AI Agent to unblock the same property and date range to remove a
Trellis block. Existing reservations, other overlapping blocks, and separately
closed availability remain in place. The property must have an active
connection that allows updates and a complete room mapping.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.