Requests and offers

A booking request is a work-in-progress reservation — a quote you build and negotiate with a guest before it becomes a real booking. Requests hold the customer, dates, listing, and price while you send offers back and forth, then publish the accepted one. Find them under Requests in the sidebar.

Creating a request

The Requests list has two entry points, both opening the same wizard in a different mode:

New Request — the full 3-step wizard: Guest (link or create a customer), Wishes (the customer’s optional wishes — see Customer wishes), then Details & Pricing (listing, arrival/departure, guests, pets, and the price). Finish with Create Request.
Capture inquiry — a shorter Guest → Wishes intake for a call, email, or lead where there’s no listing or dates yet, just a customer and what they’re after. It ends in Create inquiry instead of a details step. If the conversation turns concrete mid-way, Add offer details reveals the Details & Pricing step without starting over — and if you still can’t complete it, Create inquiry stays available as a fallback there too.

There’s also a third way in:

From an inbox message — when a guest emails you an enquiry, open the conversation in the inbox and click Create booking request. It opens the same inquiry-capture flow: the guest’s name, email, and phone are pre-filled, their message becomes the customer’s wish text (see Customer wishes), and the conversation is linked to the request once it’s created.

Every request created in inquiry mode — from the list or the inbox — is marked Inquiry, the same origin badge storefront enquiries carry; requests created through the full wizard are marked Booking. Origin isn’t the same as status, though: a console- or inbox-captured inquiry still starts In Progress like any other console-created request — New Inquiry stays reserved for enquiries submitted through the storefront’s request-to-book form (see Request statuses).

A request created with no listing or dates at all is a listing-less inquiry — see below.

Storefront instant bookings also pass through the request list on their way to becoming bookings, but they’re published automatically and hidden from the list by default — flip Show auto-published on the Published or All views to audit them.

The request editor

A request’s detail page has Details, Conversation, and Activity tabs. On the Details tab you work with:

Active Offer — the current version of the deal: listing, period (travel and occupied), guests, pets, and the full price breakdown. A badge shows whether pricing is auto (recalculated from live listing data) or custom (line items you set by hand).
Customer Information — link, unlink, or create-and-link a saved customer, and edit contact details. A Matching customer found banner suggests an existing record when the details line up.
Customer wishes — the structured wishes captured for this request (see Customer wishes below); shown whenever any wishes are captured, and always for listing-less inquiries.
Payment — the payment mode this request will use once published. Leave it on the tenant default or pin a specific mode. (Shown only when more than one mode is available.)
Internal Notes — private notes, never shown to the guest.

Customer wishes

Every field is optional — wishes are a progressive capture, not a form you need to fill in fully before moving on:

Travel window — earliest arrival and latest departure.
Stay length — desired number of days.
Party — adults, children, pets.
Budget — a from/up-to range in the tenant currency.
Wished amenities — picked from the tenant’s amenity catalog.
Location wish — free text (“near the lake”, a region name, …).
The customer’s wish — their own words, verbatim from the call, email, or contact form.

Capture them in the wizard’s Wishes step, or edit them later on the request’s detail page via the Customer wishes card’s pencil — that card’s own save is independent of the rest of the request.

Wishes feed the offer you eventually build: entering the wizard’s Details & Pricing step, and opening Draft Offer on an inquiry (or New Offer on a request that already has one), fill in whichever of party size, pets, and travel period are still untouched — the travel period starts at the earliest arrival and runs for the wished number of nights, falling back to the full earliest–latest window when no stay length was captured. Anything you’ve already set yourself is never overwritten, and the prefill is only a starting point: creating the request with Create inquiry stores the wishes alone, not the prefilled dates. While you build the offer, a compact wishes summary strip stays visible at the top of the dialog, and the listing picker’s filters are pre-seeded from the same wishes — guest count, pets allowed, wished amenities, and the availability window.

Or skip building it by hand entirely — see Draft an offer with AI below.

Listing-less inquiries

A request captured via Capture inquiry can exist with no listing or dates at all — just the guest and their wishes. Until an offer gives it one:

The detail page shows an info banner, “Inquiry — no listing selected yet”, in place of the usual missing-information warning.
The context strip at the top of the page (visible on every tab) reads “Inquiry — no listing or dates yet” instead of listing/period/guest chips.
The Active Offer card shows an empty state pointing you at offer creation rather than blank fields, and the price summary stays hidden until there’s a real price to show.
The Offer History panel reads “No offer drafted yet” with a Draft Offer button, and the page header shows Draft Offer in place of New Offer — both open the same offer editor, prefilled from the wishes. The inquiry’s not-yet-drafted offer never appears as an offer of its own, so there’s nothing to accidentally duplicate.

Building an offer is how an inquiry gets a listing and travel dates. Sending that offer to the guest, or publishing it into a booking, needs a listing and dates exactly like any other request (see Offers) — only the intake step is listing-less.

Offers

An offer is a versioned snapshot of the negotiated deal (listing, dates, guests, pets, price), numbered like BD1001-2. You renegotiate by creating new offers — once an offer is sent it’s locked and can’t be edited. The Offer History panel lists them.

New Offer creates the next version, inheriting the current one’s details. If the guest has already accepted the current offer, the new one starts as an unsent draft instead of taking over — the accepted offer stays the active deal until you explicitly activate the new one (see below), so a guest’s acceptance is never silently lost to a new draft. A brand-new offer also pulls in whatever customer wishes haven’t been overtaken by your own edits yet.
Send to Customer locks the active offer, freezes its price, sends the guest a proposal email — with a link to their personal guest offer page — and moves the request to Proposal Sent. Sending needs the listing, period, and guests set, plus the guest’s email and first/last name (and, in custom pricing mode, at least one price line) — until then, Send to Customer and Resend Proposal render disabled with a tooltip listing what’s still missing. The send dialog has an optional message to the customer — free text that appears as a highlighted “Message” block in the email — and a Valid for (days) field (1–90, prefilled from the Default offer validity setting in Booking settings) that sets how long the offer stays open, with a preview of the resulting expiry date. If Auto-Publish on Guest Acceptance is on and the guest’s postal address is still incomplete, the dialog adds a hint that an accepted offer will wait for you to publish it by hand.
Set as Active brings an earlier sent offer back as the working version; Resend Proposal sends the active offer again (with a warning if it was already sent). If the current active offer has already been accepted by the guest, activating a different one instead asks you to confirm “Activate offer and revoke acceptance?” — confirming withdraws the guest’s acceptance and activates the other offer in one step, so an acceptance can never be silently orphaned by switching offers.
An offer’s own status runs Draft → Sent → Accepted / Declined, plus Withdrawn (you retracted it) and Expired. Expiry happens either because you mark it stale by hand, or automatically once its validity window passes — an hourly check flips the offer to Expired and returns the request to Offer Ready, and the guest’s offer page treats a past-due offer as expired immediately even before that check runs. A sent offer shows an Expires in N days hint that turns into an overdue warning if the deadline passes just ahead of the hourly sweep. Clicking the hint opens Extend Offer Validity — a “valid for N days from now” input that moves the deadline without resending: no email goes out, the guest’s existing link simply stays (or becomes) open until the new deadline.
In the Offer History panel, every draft-status offer has an edit pencil — not just the active one — while sent offers show a lock icon with a tooltip pointing you at New Offer to renegotiate instead. An unsent, auto-priced offer shows a live estimated total prefixed with ~ (the final price is only fixed once you send it), and the active offer carries its own Active badge alongside its status badge, whatever that status is.

Draft an offer with AI

Alongside building an offer by hand, Draft offer with AI — next to the Offer History panel’s header — turns a request’s customer wishes into a ready-to-review draft offer. It’s available whenever offers can still be created (hidden once the request is Declined or Published), though it needs at least some captured wishes or your own criteria to search from.

The dialog asks for:

Listings to include — how many options to propose, 1–5 (default 3).
Additional criteria — optional free text (e.g. “only apartments, prefer sea view, max 120 € per night”). Your criteria win over the customer’s wishes when the two conflict.

From there the AI searches your storefront-visible listings for matches on amenities, party size, pets, budget, and the wished travel window — including the individual free periods inside a flexible window when a stay length was given — checks real availability, and calculates real prices. It then creates a normal draft-status offer with up to the requested number of options, each with a short label and a one-sentence reason, using alternative options the same way a hand-built multi-option offer would. Nothing is ever sent to the guest automatically — you review, edit, and send the result like any other offer.

The result also includes a suggested customer message in the request’s communication language, with a copy button. It isn’t stored on the offer (the offer’s message field is only filled at send time), so paste it into the message to the customer field in the send dialog if you want to use it.

When nothing fits — budget too tight, nothing available in the window, no listing matching the wishes — no offer is created, and the dialog explains why instead.

A couple of things it won’t do: wished children aren’t added to the offer as guests automatically (their ages aren’t captured in the wishes, so add them yourself before sending), and only listings visible on your storefront are considered. Each run counts against your tenant’s AI usage like any other AI feature — see Cost and quotas.

You can also start the same flow from two other places:

The Wishes step of the Capture inquiry wizard has a Draft an offer with AI after creating checkbox (with the same option-count and criteria fields) — the run starts right after the inquiry is created and continues in the assistant’s Activity tab while you land on the new request.
Ask the AI assistant to draft an offer for a request (e.g. “draft an offer for BD1042”) and confirm the proposal card it shows you.

Alternative options (multi-option offers)

An offer can present the guest with up to 10 alternatives alongside the main option — useful when several listings or date ranges could all work. In the offer editor, Add Alternative adds one: each alternative has its own optional label (e.g. “Sea view, slightly smaller”), listing, travel dates, and price, calculated the same way as the main offer. Guests, pets, and the customer message are shared across every option — only the accommodation itself varies between them.

The proposal email lists every option, and the guest picks one on their offer page. Whichever one they choose becomes the deal: the console’s Offer History panel highlights it as Chosen by guest, and publishing uses that option’s listing, dates, and price — the options that weren’t chosen stay on record for reference. Availability for each option is checked live when the guest views and accepts the offer, so an option whose dates got booked elsewhere in the meantime shows to the guest as unavailable (they can still pick one of the others).

The guest offer link

Every sent proposal email includes a link to a personal, tokenized offer page where the guest can accept or decline the offer directly — no reply email required. The link belongs to the request, not to any one offer: renegotiate and send a new offer, and the same link stays valid, always showing the guest’s current active offer.

Once any offer has ever been sent, a Copy Guest Offer Link button appears next to the offer on the Details tab — it stays visible through renegotiation, even while you’re preparing a new unsent offer, so you can always share the link yourself (phone, chat, another channel) instead of relying on the guest finding it in their inbox. Next to it, a Guest link badge — open / accepted / declined / withdrawn / expired / booked / being revised — shows what the guest currently sees when they open that link; being revised means the active offer is back in draft while you renegotiate, so the guest’s page can’t show a concrete deal yet.

On the offer page, the guest sees the listing(s), dates, price, your personal message, and the validity deadline, and can:

Accept — choosing an alternative option first if the offer has more than one. Accepting moves the request to Customer Confirmed, sends you a notification email, and records which option was chosen.
Decline — with an optional message. Declining moves the request to Proposal Declined, sends you a notification email, and — when the guest left a message — drops it into the request’s inbox conversation as a new unread message, exactly as if they’d emailed you.

Every guest action appears in the request’s Activity tab with Guest as the actor, alongside your own actions.

If an acceptance was recorded in error (e.g. a phone booking the guest then also confirmed online), Revoke Acceptance on the Details tab undoes it — the offer returns to Sent and the request to Offer Ready — as long as the request hasn’t been published yet. Revoke Acceptance also works if the accepted offer is no longer the active one — for example, another offer was activated after the guest had already accepted. Reynt flags that state with a warning banner on the Details tab, since an orphaned accepted offer can’t be re-activated or published on its own; the banner’s own Revoke Acceptance button clears it so you can carry on negotiating.

No inventory is held while an offer is out: the dates stay bookable by anyone else until the guest accepts (or you publish manually), and availability is re-checked at both accept and publish.

Request statuses

A request progresses through these statuses (shown as the primary badge):

Status	Meaning
New Inquiry	A storefront enquiry awaiting triage.
In Progress	You’re actively working the request — the default for console-created requests, including wishes-only inquiries captured via Capture inquiry.
Offer Ready	An offer is prepared and ready to send.
Proposal Sent	The offer went to the guest; awaiting their reply.
Customer Confirmed	The guest accepted — online via their offer link, or you recorded a phone agreement. Ready to publish.
Proposal Declined	The guest declined — online, or you marked it declined yourself.
Declined	You declined the whole request (can be restored).
Published	Converted into a booking.

From Proposal Sent you can also Withdraw or Mark as Expired an offer yourself, and an unanswered offer expires automatically once its validity window passes — each returning the request to Offer Ready. Archive hides a request from the default list without affecting its status.

Publishing a request into a booking

Once the guest has agreed, publish the request:

Publish as Booking appears when the active offer is accepted and the request is complete. For deals agreed by phone, Confirm & Publish accepts the active offer and publishes in one step.
Publishing needs everything sending an offer needs (see Offers) plus the guest’s full postal address. Until that’s all in place, both buttons render disabled with a tooltip listing what’s missing, and a Missing information warning appears on the Details tab with the same list — its Complete customer info button opens the Customer Information edit dialog directly when a guest field (name, email, address) is the gap. Auto mode recomputes the price at publish; custom pricing mode still needs a non-empty price, which is already required to send.
A request never holds its dates — if they overlap another booking or blocked dates in the meantime, a conflict warning lists the blockers with links (the request list also flags conflicted rows). Publishing over a conflict is blocked: the publish re-checks availability and rejects with “These dates are no longer available” if the dates were taken.
The publish dialog shows the linked customer, the effective payment mode, and a toggle for whether to send the guest a confirmation email — with an optional personal message to the customer included in that email.

With Auto-publish on guest acceptance turned on (Settings → Booking settings — see Booking settings), a guest accepting online publishes the request automatically — no manual Publish as Booking click needed. Reynt re-checks availability first; if the dates were taken in the meantime, or the request is missing the guest details publishing requires (email, phone, full address — sparse, manually-created requests can fall short of this), the request stays Customer Confirmed for you to resolve and publish by hand. Turned off (the default), every acceptance — online or by phone — waits for you to publish.

On publish, Reynt creates the booking (pending or confirmed depending on your auto-confirm setting), blocks the dates, sets up payments and invoices, links any inbox conversation to the new booking, and keeps the request on record marked Published. The published request’s header links to the booking (Published as B-1001), and the booking links back with Created from request — the negotiation history is always one click away.

Activity and notifications

The request’s Activity tab logs every change — status transitions, offer actions, customer links, and emails — filtered by All / Emails / Events. The Notifications card offers manual sends where they make sense, such as a request confirmation acknowledgement or a decline notice. Sending a proposal and publishing send their emails automatically. Wherever a dialog sends the guest an email (send proposal, publish, decline), it includes an optional free-text message to the customer that is rendered inside the email.