> ## Documentation Index > Fetch the complete documentation index at: https://docs.riservahq.com/llms.txt > Use this file to discover all available pages before exploring further. # Customer emails Riserva sends a small set of emails a guest needs, and nothing that reads like marketing. This page lists each email, when it sends and who gets it. It also lists what Riserva doesn't send. Riserva delivers guest email for you, so there is no provider account to create. **Settings → Emails** is where you shape it: who it comes from, which moments send, the wording and the design. See [Email settings](/guest-experience/email-settings). **Log only** means delivery isn't configured. Every message is still built and recorded on the reservation's timeline; it just isn't delivered. Contact Riserva support. *** ## The emails Riserva sends | Email | When it sends | Goes to | | - | - | - | | **Reservation confirmed** | When an online order becomes a reservation, or when staff book one with an email address on it (details below) | Guest | | **Pre-visit reminder** | Once, in the 24 hours before the reservation, or when staff press **Send reminder email** | Guest | | **Reservation cancelled** | Whenever a reservation is cancelled: by the guest, by staff, or by cancelling the order in Shopify | Guest | | **Reservation rescheduled** | After a reservation's date or time changes, whether the guest moved it or you did (one exception below) | Guest | | **Payment failed** | When a scheduled charge is declined | Guest | | **Waitlist — table ready** | When a host presses **Notify** on a waitlist party | Guest | | **New reservation alert** | When a reservation is made online (not when your team books one) | Your team: the **Alert addresses** you enter in Settings → Emails | Confirmation and rescheduled emails carry an **add-to-calendar file** (`reservation.ics`). When a reservation moves, the new file updates the event already in the guest's calendar. It doesn't add a second one. ### When the Reservation confirmed email sends * The moment an online order becomes a reservation. This includes a charge-later order that collected \$0. * For an order still waiting on payment, when it's paid. * When staff book a **Phone** reservation in the admin, or book on the POS register, with an email address on it. * Never for an order paid after its visit had ended. The reservation is marked **Booked after its time** instead. ### When the Reservation rescheduled email doesn't send A host may move an early-arriving party to now at check-in. That move sends no rescheduled email, because the guest is already at the counter. ### Reservations your team makes A reservation booked by staff gets the confirmation **at once, when it has an email address**: * **Book reservation** in the admin sends it for a **Phone** reservation. A **Walk-in** gets none, because the guest is standing at the desk. * The **Book reservation** tile on the POS register sends it whenever an email is entered. The field reads "Email (for the confirmation)". * A party **seated from the waitlist** gets none. All of these follow the **Reservation confirmed** switch in Settings → Emails. A payment link paid later sends nothing extra. A guest without a confirmation still gets the reminder and the rescheduled and cancelled emails. If such a guest wants something in writing now, open the reservation and use **Send reminder email**. It sends the reminder immediately, and it counts as the reminder, so the automatic one won't follow. ### The saved-card line in charge-later emails On an experience that saves the card and charges later, the confirmation and the reschedule email each carry one extra line. It names the exact moment and amount: * A charge on a set date: *"Nothing was charged today. Your card is saved and will be charged \$119.99 on Sun, Sep 20 at 9:00 AM EDT."* * An "At check-in" experience: *"…when you check in"*. * An "At the visit" experience: *"…at the end of your visit, unless you settle it at the counter"*. On a reschedule it reads *"Your card is still saved and will now be charged…"* with the new moment, because the charge follows the visit. The line appears only while the card really is saved and unpaid. A reservation paid at checkout never sees it. ### The Payment failed email The **Payment failed** email is the only notice a guest gets about a declined saved card. Shopify sends none of its own for saved-card orders. Riserva sends it when the card genuinely failed. * It tells the guest their reservation is still held. * It states the amount owed. * When there is a payment link, it offers a **Pay now** button. * Without a link, it says *"We'll be in touch to arrange payment, or contact us by replying to this email."* Follow up with a payment link or a call. The reservation still becomes **Payment due** for you to collect, but the guest is told nothing. Telling someone their card failed when it may have worked is worse than saying nothing. ### The refund line in the cancellation email The refund line only appears when money is actually moving. A cancellation with nothing to refund says nothing about refunds at all. It never promises a guest money that isn't coming. ### The pre-visit reminder * It goes out once per reservation, in the 24-hour window before the slot. * It goes only to confirmed reservations that have an email address. * If a reservation is cancelled before the reminder is due, no reminder is sent. * Reminder timing is fixed at 24 hours; it can't be changed. > **Good to know** > Riserva runs a reminder check every hour on its own. It runs again whenever > your team is using the admin, at most every 15 minutes. A reservation booked > less than a day ahead gets its reminder at the next check. Staff can also > send it early from the reservation page with **Send reminder email**; it > then counts as the reminder. ### The waitlist email Only one send happens per party, even if a host presses **Notify** twice. A guest who gets told twice assumes they were double-booked. *** ## The alert to your team **New reservation alert** is the one email addressed to your staff, not the guest. It goes out when a reservation is made online, through the booking window and checkout. It names the guest, the party, the date and time, and the guest's email and phone. Reservations your team makes in the admin or on the register don't send it. Whoever booked it already knows. Set where it goes in **Settings → Emails → Notifications**, in the **Alert addresses** field under that email: * Enter up to five addresses, separated by commas (for example `tastingroom@yourwinery.com, manager@yourwinery.com`). * Each address gets its own copy. * Leave the field empty and no alert is sent. ## An email that exists but isn't switched on * **Payment due** — would email a guest their payment link when you create one on a reservation. Today you copy the link and send it yourself. It shows a **Not sending yet** badge under **Notifications** in Settings → Emails. *** ## What Riserva doesn't send * **A post-visit thank-you or review request.** If you want one, the [Klaviyo](/integrations/klaviyo) and [Shopify Flow](/integrations/shopify-flow) connections can start one from the guest's check-in. * **A no-show notice.** A guest marked a no-show gets no email from Riserva. * **Text messages (SMS).** Riserva sends email only. *** ## What the emails look like Riserva's emails are one narrow column on soft paper, with dark warm ink. A single accent colour is used on the button and the confirmation code. A heading carries the experience name; everything else is plain and readable. **Banner.** If the experience has a **photo**, it appears as a banner across the top of its emails automatically. Each experience's emails look like that experience, with no setup. You can switch this off, or set one banner for every email, in [Email settings](/guest-experience/email-settings). **Details card.** The body is a details card, with the **label on the left, value on the right**. It shows Date, Time, Party, Confirmation code and Location. Situational rows (Previously, Amount due, Refund) appear when they apply. **Extras.** Add-ons and special requests appear underneath only when there are any. So does the experience's **Good to know** note, if you've written one on the experience page (arrival details, parking, dress code). **Your words.** The opening and closing lines of each email are yours to rewrite, per touchpoint, from [Email settings](/guest-experience/email-settings). The greeting and the reservation facts always stay. Your words change the voice, never the details. **Dates.** Dates and times follow your **Regional formats** setting. Emails always spell the year out, because people open them months later. Every email also carries a plain-text version with the same facts in the same order. It reads correctly in text-only clients and scores well with spam filters. No. Anything a guest typed, such as their name or their special requests, is escaped before it's rendered. Links that aren't ordinary web or email links are refused rather than shown. A guest can't smuggle anything into an email you send. *** ## Naming and links in the emails Two things in the emails can't be changed: * **The winery name** in the eyebrow line and the footer comes from the reservation's location name. It falls back to a tidied version of your store domain. What guests see in the *From* line is separate, and you do control it. See [Email settings](/guest-experience/email-settings). * **The "Manage your reservation" link** goes to Riserva's built-in manage page on your storefront (`/apps/bookings/manage`). It is personalised per guest, so it opens their reservation directly, with no code or email to type. It can't be pointed at a different page from the admin. See [Let guests manage their own reservations](/guest-experience/guest-self-serve). Everything else is on the [Email settings](/guest-experience/email-settings) page. That covers who the email comes from, which emails send, their subject and opening/closing lines, the colours, the images and a footer line. *** ## Where to check whether an email went out Open the reservation and look at its **timeline**. Every attempt is recorded there, including failures. A message that couldn't be delivered shows as a failed notification rather than disappearing quietly. Emails never block anything. A delivery failure or a bad address can't roll back a reservation, a refund or an order. *** **What things mean on this screen:** [What things mean: What your guests see](/reference/guest-surfaces) ## Related * [Email settings](/guest-experience/email-settings) — who your email comes from, what it says, and how it looks * [What guests see, end to end](/guest-experience/what-guests-see) * [Guests managing their own reservations](/guest-experience/guest-self-serve) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.