Reservation Cancel + Waitlist

ReservationsFree

Description

Reservation Cancel + Waitlist is a FORMLOVA official workflow that starts from a submitted form response and turns review, classification, notification, record keeping, and follow-up into one repeatable operating flow. Run the prompt in a connected AI chat to review the responses and carry out the supported actions.

3 steps

  1. 1

    Read the new response

    Review form capacity, registration rules, and operator-confirmed waitlist evidence. Do not treat waitlist rows as response records.

  2. 2

    Decide the next action

    Decide the next action from the response, score, date, or category.

  3. 3

    Apply to operations

    Confirm access, targets, and copy before execution. Keep results separate from schedules and append business tags or notes while preserving existing values.

Prompt Example

Goal: Contact waitlisted people in order when a reservation is canceled. Fields: Respondent email address, Response body, and Target date and time. Confirm canceled slot, requested slot, and waitlist priority from the response body. Rules: Pick the next waitlisted person matching the canceled slot, include a response deadline, and move to the next person if it expires. Actions: For the native waitlist, check the shared capacity of one form with get_form. Configure waitlist enablement and offer expiry through set_waitlist using operator-specified values, then verify the successful response. The native mechanism sends offers in queue order when space becomes available and expires offers; the AI must not infer sent or accepted results. Native waitlist rows have no response ID and cannot be read through get_responses; never call reply_to_respondent or update_response for them. For a separately supplied queue and vacancy list, use reply_to_respondent only for candidates whose existing response IDs the operator has verified. Ask instead of using that route for external candidates without response IDs. Confirm multi-slot or party-size allocation separately from native shared capacity. Execution: Run this reusable prompt in an AI chat connected to FORMLOVA. Pasting it does not start continuous monitoring or recurring execution. Only settings saved and verified through actual tools run automatically. Request missing targets, dates, or evidence instead of inventing them. Records: update_response accepts only new / in_progress / resolved / spam for status. Use status="in_progress" for new open work; do not reopen existing resolved/spam responses, and use resolved only when the work is verified complete. Immediately before changing business tags or notes, read their current values with search_responses. Pass the deduplicated full set of existing plus added tags (at most 20 tags, 50 characters each), or the full existing notes with the addition appended. If current values cannot be read or limits would be exceeded, ask instead of overwriting. Keep schedules and drafts separate from verified sends, writes, and attendance.

For you

steps
3 steps
Required plan
Free
Required integrations
FORMLOVA

What this workflow solves

Form responses arrive, but contacting waitlisted people when a reservation is canceled still depends on manual checking, causing delayed or missed follow-up.

Best for

  • reservation desks
  • paid application workflows

Expected outcome

When you run the prompt in chat, each reviewed response moves into a clear contacting waitlisted people when a reservation is canceled state, so the team can focus on the next required action.

Setup notes

  • Connect FORMLOVA MCP in your AI client and confirm permission to read and update responses for the target form.
  • Execution: Run this reusable prompt in an AI chat connected to FORMLOVA. Pasting it does not start continuous monitoring or recurring execution. Only settings saved and verified through actual tools run automatically. Request missing targets, dates, or evidence instead of inventing them.
  • Response review, organization, and ordinary individual replies are available on Free. Check AI client and external service terms separately.
  • Business labels are not response statuses. Read current tags/notes immediately before updating and preserve them when appending; tags allow at most 20 values of 50 characters each. Ask if values cannot be read or limits would be exceeded.
  • Native waitlist rows do not have response IDs. Distinguish native shared-capacity offers from ordinary replies to existing response IDs. Verify waitlist sends and acceptance from operator-confirmed records.

FAQ

Can this work with an existing form?

Yes. Map the existing response fields to the required slots and adjust the notification or record destination.

More in this category