This is the full developer documentation for Reynt Docs # Reynt Bedienerdokumentation > So verwaltest du Objekte, Buchungen, Preise, Verfügbarkeit, Rechnungen und deine Storefront in der Reynt-Admin-Konsole. Willkommen bei der Reynt-Bedienerdokumentation. Diese Seiten erklären, wie Property-Manager und Marktplatz-Betreiber die Reynt-Admin-Konsole im Alltag nutzen — von deinem ersten Objekt bis zu einer voll laufenden Storefront. ## Was ist Reynt? [Section titled “Was ist Reynt?”](#was-ist-reynt) Reynt ist eine Vermietungs- und Buchungsplattform. Du verwaltest alles über eine Admin-Konsole: deine Objekte, die Buchungen dazu, Preise und Verfügbarkeit, Zahlungen und Rechnungen, die Kommunikation mit Gästen und eine White-Label-Storefront für Kunden. Gäste sehen die Konsole nie — sie sehen deine Storefront. ## Neu hier? [Section titled “Neu hier?”](#neu-hier) Beginne mit [Willkommen](/de/docs/getting-started/welcome/) für eine kurze Orientierung, dann folge [Erste Schritte](/de/docs/getting-started/first-steps/), um einen frischen Mandanten live zu schalten. Die [Konsolentour](/de/docs/getting-started/console-tour/) erklärt das Dashboard, die Navigation und Shortcuts. Noch nicht bereit, etwas einzurichten? Der [Demo-Modus](/de/docs/getting-started/demo-mode/) spielt zuerst eine Buchung komplett auf Beispielinhalten durch. ## Orientierung [Section titled “Orientierung”](#orientierung) Nutze die Seitenleiste, um zu einem Thema zu springen: * **Objekte** — Objekte anlegen, Inhalte und Fotos hinzufügen, Ausstattung, Zusatzleistungen, Veröffentlichung und [Registrierung für Kurzzeitvermietung](/de/docs/listings/registration/). Siehe [Objektübersicht](/de/docs/listings/overview/). * **Katalog** — gemeinsame Bausteine: [Ausstattung, Attribute, Tags](/de/docs/catalog/overview/), [Reiseziele & Entfernungen](/de/docs/catalog/places-and-distances/) und [Objekttypen](/de/docs/catalog/property-types/). * **Preise** — Grund- und Saisonpreise, Aufenthaltsregeln, Rabatte, Gebühren und [Gutscheincodes](/de/docs/pricing/promo-codes/). * **Verfügbarkeit** — [Daten blockieren](/de/docs/availability/block-dates/), [iCal-Sync](/de/docs/availability/ical-sync/) und Kalenderansichten. * **Buchungen** — der [Buchungslebenszyklus](/de/docs/bookings/lifecycle/), Anfragen und Angebote, Änderungen, Stornierungen und Gästeregistrierung. * **Zahlungen & Rechnungen** — [Zahlungsanbieter](/de/docs/payments/providers/), Teilzahlungen, Rechnungserstellung und Steuern. * **Kunden & Eigentümer** — die Menschen auf beiden Seiten einer Buchung. * **Kommunikation** — der [Posteingang](/de/docs/communication/inbox/), Benachrichtigungen und die E-Mail-Bestätigungssperre. * **Storefront** — eigene Seiten, Blog, Navigation, Erscheinungsbild, Domains und Suche. * **Sprachen & KI** — mehrsprachige Inhalte und KI-gestützte Generierung. * **Konfiguration** — [Mandanteneinstellungen](/de/docs/configuration/tenant-settings/), [Mitglieder & Rollen](/de/docs/configuration/members-and-roles/) und [API-Schlüssel](/de/docs/configuration/api-keys/). ## Konventionen in dieser Dokumentation [Section titled “Konventionen in dieser Dokumentation”](#konventionen-in-dieser-dokumentation) * **Konsole** meint die Admin-Web-App, in die du dich einloggst. * **Storefront** meint die kundenseitige Buchungswebsite, die deine Gäste sehen. * Konsolenpfade sind mandantenbezogen: Die Seite **Eigentümer** liegt in der Konsole unter `//owners`. Wir verweisen auf Seiten anhand ihres Labels in der Seitenleiste, **fett** hervorgehoben. # Der KI-Assistent > Reynt fragen — ein angedockter Assistent, der Fragen aus deinen Live-Daten beantwortet und Änderungen vorschlägt, die du bestätigst. **Reynt fragen** ist der in die Konsole integrierte Assistent. Öffne ihn mit dem **Reynt fragen…**-Button in der oberen Leiste oder **Cmd/Ctrl + J** — er dockt als Panel rechts an, sodass du weiterarbeiten kannst, während du mit ihm sprichst. Er liest die live Daten deines Mandanten, um Fragen zu beantworten, und kann Änderungen für dich vorbereiten — aber er **ändert niemals etwas von sich aus**: Jede Änderung wird als Vorschlagskarte angezeigt, die du zuerst prüfst und bestätigst. ## Das Panel [Section titled “Das Panel”](#das-panel) Das Panel ist der Chat — und nur der Chat. Zwei verwandte Dinge sitzen daneben: * **KI-Aktivität** — das Symbol neben der Glocke in der oberen Leiste öffnet ein Fach mit laufenden und kürzlich abgeschlossenen KI-Workflows (Importe, Inhaltsgenerierung, Übersetzungen). Verfolge den Fortschritt und öffne Ergebnisse dort zur Prüfung, statt auf der Seite zu warten, die sie gestartet hat; ein Badge zeigt, wie viele Läufe aktiv sind oder auf Prüfung warten. Weil es ein eigenes Fach ist, kannst du einen Lauf im Blick behalten und gleichzeitig weiterchatten. * **Hilfe** — schriftliche Anleitung zur aktuellen Seite, geöffnet über den **Hilfe**-Button im Kopfbereich dieser Seite. Sie legt sich im selben Panel über den Chat und bleibt so neben dem Inhalt, den sie erklärt; **Zurück zum Chat** bringt dich wieder heraus. Der **KI fragen**-Eintrag oben in der Befehlspalette (**Cmd/Ctrl + K**) übergibt deine eingetippte Frage direkt an den Chat. ## Chat — und worüber er spricht [Section titled “Chat — und worüber er spricht”](#chat--und-worüber-er-spricht) Es gibt **ein Gespräch**, und es weiß immer, was du gerade ansiehst. Wenn du auf einem Datensatz bist — einer Buchung, einer Anfrage, einem Objekt, einer Rechnung, einem Gast, einem Eigentümer, einer Konversation im Posteingang oder einer Storefront-Seite — erscheint über dem Eingabefeld ein kleiner **Chip** mit dem Namen dieses Datensatzes. Alles, was du mit sichtbarem Chip sendest, darf „diese Buchung“ sagen und sich die Referenz sparen. Der Chip ist ein Hinweis, keine Schranke: * **Entferne ihn** mit dem `×`, wenn deine Frage nicht diesen Datensatz betrifft. Sonst ändert sich nichts — der Assistent kann so oder so genau gleich viel. * **Lass ihn stehen und frag trotzdem etwas anderes.** Eine mandantenweite Frage („Wie war der Umsatz letzten Monat?“) von einer Buchungsseite aus bleibt eine mandantenweite Frage und wird auch so beantwortet. * **Füge weitere hinzu** über **Kontext hinzufügen**, um dem Assistenten mehrere Datensätze gleichzeitig vorzulegen — etwa eine Buchung und das Objekt, auf das du sie verschieben willst. Gesendete Nachrichten behalten die Chips, mit denen sie gesendet wurden. Im Verlauf ist dadurch sichtbar, welche Fragen Kontext trugen und welche nicht. Die Aktion **Zu dieser Buchung / diesem Objekt / dieser Seite fragen** im Kopfbereich eines Datensatzes öffnet einfach den Chat — der Chip ist schon da. Der Gesprächsverlauf ist eine einzige Liste. Ist ein Chip angeheftet, bietet das Verlaufsmenü an, nur die Gespräche zu diesem Datensatz zu zeigen. ## Was er beantworten kann [Section titled “Was er beantworten kann”](#was-er-beantworten-kann) Der Chat liest deine echten Daten, sodass Antworten tatsächliche Datensätze zitieren statt allgemeiner Ratschläge. Er kann Folgendes nachschlagen und zusammenfassen: * Buchungen, Anfragen und Angebote sowie deren Aktivität * Objekte, Preise und Verfügbarkeit — inklusive „Ist das Objekt vom 3. bis 7. August frei?“, beantwortet mit den belegten und gesperrten Zeiträumen und den freien Lücken dazwischen * was ein bestimmtes Objekt tatsächlich hat — Ausstattung, Schlagwörter, Merkmale und Entfernungen, Zusatzleistungen und Rabatte, saisonale Aufenthaltsregeln sowie den Sync-Status importierter Kalender-Feeds * warum ein Objekt noch nicht veröffentlicht werden kann — Punkt für Punkt, mit dem Tab, auf dem du es behebst * Kunden und Eigentümer * Rechnungen und Zahlungen sowie die Steuerregeln dahinter — Kurtaxe und Mehrwertsteuersätze * Stornobedingungen und die Erstattung, die eine konkrete Stornierung auslösen würde * Posteingangs-Gespräche * Gutscheincodes und Storefront-Seiten * **Auswertungen** für einen von dir genannten Zeitraum — Umsatzübersicht, Umsatzverlauf, Auswertung nach Objekt und nach Buchung sowie die Provisionsprüfung. Sie stammen aus derselben Quelle wie die Seite „Auswertungen“ in der Konsole, die Zahlen stimmen also mit dem überein, was du dort siehst * Dashboard-Kennzahlen (gesamter Zeitraum) und **Belegungsberichte** für einen von dir genannten Zeitraum * Objekte über die **Smarte Suche** (“ein Objekt mit Meerblick, das Hunde erlaubt”) Bankverbindungen und Steuerdaten von Eigentümern werden nie mit der KI geteilt — diese Felder bleiben maskiert. ## Was er tun kann (mit deiner Bestätigung) [Section titled “Was er tun kann (mit deiner Bestätigung)”](#was-er-tun-kann-mit-deiner-bestätigung) Wenn du um eine Änderung bittest, bereitet der Assistent sie vor und zeigt eine **Vorschlagskarte**, die genau beschreibt, was passieren wird. Nichts läuft, bis du bestätigst, und bestätigte Aktionen landen in denselben Audit-Trails wie manuelle. Er kann unter anderem vorschlagen: * **Buchungen** — eine Buchung bestätigen, stornieren oder abschließen. Bei einer Stornierung nennt die Karte die zugrunde liegende Stornobedingung und zeigt sowohl den Anspruch laut Bedingung als auch die tatsächliche Erstattung an den Gast * **Anfragen & Angebote** — eine Anfrage erstellen, ein Angebot vorbereiten und senden, eine Anfrage veröffentlichen oder ablehnen, oder anhand der erfassten Wünsche der Anfrage ein ganzes [Mehrfachangebot mit KI entwerfen](/de/docs/bookings/booking-drafts-and-offers/#ein-angebot-mit-ki-entwerfen) * **Verfügbarkeit** — Termine sperren oder freigeben * **Objekte** — Objektdetails aktualisieren, Preise verwalten, einen Eigentümer zuweisen oder Objektinhalte mit KI generieren * **Rechnungen & Zahlungen** — eine Rechnung ausstellen, als bezahlt markieren, stornieren, eine Gutschrift erstellen oder eine Zahlungsüberweisung als bezahlt markieren * **Posteingang** — eine Antwort entwerfen, ein Gespräch zuweisen oder dessen Status ändern * **Personen** — Kunden und Eigentümer erstellen oder aktualisieren * **Aktionen** — einen Gutscheincode erstellen oder deaktivieren * **Kunden-Oberfläche** — einen neuen Seitenabschnitt generieren oder einen bestehenden bearbeiten ## Kosten [Section titled “Kosten”](#kosten) Auf dem Plattform-Schlüssel hat der Assistent sein eigenes großzügiges tägliches Token-Kontingent, getrennt von den in der [KI-Übersicht](/de/docs/ai/overview/) beschriebenen KI-Workflow-Limits. Wiederholter Kontext wird zwischengespeichert und günstig gewichtet, sodass normale, alltägliche Nutzung bequem innerhalb dieses Kontingents bleibt. Mit deinem eigenen verbundenen API-Schlüssel gibt es kein Plattform-Limit — die Nutzung wird direkt deinem Anbieterkonto in Rechnung gestellt. # Inhaltsgenerierung und Übersetzung > Objekt- und Website-Inhalte mit KI schreiben und übersetzen, jeden Vorschlag vor dem Speichern prüfen. Sobald KI verbunden ist (siehe [KI-Übersicht](/de/docs/ai/overview/)), erscheint die Inhaltsgenerierung genau dort, wo du schreibst — direkt an den Feldern und in ein paar geführten Dialogen. Alles, was KI erzeugt, wird dir zur Prüfung angezeigt, bevor es gespeichert wird. Du kannst die Generierung von Objektfeldern und Storefront-Seitenabschnitten (oder deren Bearbeitung) auch einfach starten, indem du den [KI-Assistenten](/de/docs/ai/assistant/) darum bittest. ## Ein einzelnes Feld generieren [Section titled “Ein einzelnes Feld generieren”](#ein-einzelnes-feld-generieren) Übersetzbare Felder — ein Objekttitel, eine Beschreibung, SEO-Text und so weiter — tragen einen kleinen **KI**-Button. Je nach deinen Sprachen bietet er: * **Inhalt generieren** — schreibe dieses Feld mit KI in allen Sprachen gleichzeitig. * **Fehlende Sprachen übersetzen** — übersetze den bereits geschriebenen Text in die noch leeren Sprachen. Nach der Generierung zeigt eine Vorschau das Ergebnis pro Sprache. **Übernehmen**, um die Werte in das Feld zu schreiben, oder **Verwerfen**, um sie zu verwerfen — nichts wird gespeichert, bevor du übernimmst. ### Tonalität und Länge [Section titled “Tonalität und Länge”](#tonalität-und-länge) Dasselbe **KI**-Menü trägt die Stil-Regler für den nächsten Lauf: * **Tonalität** — Warm, Sachlich oder Locker. Sie startet mit der Tonalität, die du unter **Einstellungen → KI** gesetzt hast; die Auswahl hier gilt nur für diese eine Generierung, nicht für die Einstellung. * **Länge** — Kurz, Standard oder Ausführlich, nur bei den Fließtexten (Beschreibung, Ausstattung, Gästeinfos, Preis- und Rabatttexte). Beide Regler erscheinen nur an den Feldern, die sie tatsächlich verändern. Ein **Titel**, ein **SEO-Titel** oder ein **Meta-Titel** eines Blogbeitrags zeigt keinen davon: Das sind kurze, keyword-getriebene Bezeichnungen mit fester Zeichenvorgabe — ein Objekttitel hat etwa eine Zeile auf der Karte, ein SEO-Titel 50-60 Zeichen bei Google — also bestimmen ihre eigenen Regeln die Formulierung, und eine Tonalität würde nur Füllwörter in eine Zeile drücken, die keinen Platz dafür hat. Teaser und Meta-Beschreibungen sind ganze Sätze und nehmen deshalb sehr wohl eine Tonalität an; ihre Zeichenvorgabe bleibt trotzdem bestehen. ### Schnellübersetzung bei Sprachfeldern [Section titled “Schnellübersetzung bei Sprachfeldern”](#schnellübersetzung-bei-sprachfeldern) Bei einem Feld mit sprachspezifischen Tabs nimmt die Aktion **Fehlende Sprachen übersetzen** eine bereits ausgefüllte Sprache als Quelle und übersetzt sie in die leeren Tabs, wobei die Formatierung in Rich-Text-Feldern erhalten bleibt. Es ist der schnellste Weg, eine Sprache auf die übrigen auszuweiten. ## Mehrere Felder gleichzeitig generieren [Section titled “Mehrere Felder gleichzeitig generieren”](#mehrere-felder-gleichzeitig-generieren) Für einen größeren Durchgang lässt dich der Dialog zur Objektfeld-Generierung auswählen, welche Felder wie generiert werden: * **Inhalte generieren in** — wähle die Sprachen. Deine Standardsprache wird immer generiert; die anderen werden daraus erzeugt. * **Modus**: * **Aus Standardsprache übersetzen** — einmal in der Standardsprache generieren, dann übersetzen. Günstiger. * **Nativ pro Sprache** — jede Sprache unabhängig für den besten Ton generieren, zu höheren Kosten. Der Lauf zeigt Fortschritt, und das Ergebnis öffnet sich mit einem **Tab pro Sprache**, damit du jede Sprache prüfen — und bearbeiten — kannst, bevor du sie übernimmst. Ausgewählte Felder werden in jeder generierten Sprache angewendet, prüfe also jeden Tab zuerst. ## Ganzseitige und kontoweite Generierung [Section titled “Ganzseitige und kontoweite Generierung”](#ganzseitige-und-kontoweite-generierung) Dasselbe Prüfen-vor-Speichern-Muster gilt für die größeren Workflows: * **Seiten und Blogbeiträge** — generiere einen vollständigen Satz an Inhaltsabschnitten und prüfe ihn, bevor du ihn anwendest. * **Katalog, Textbausteine, Optionen für die Herkunftsquelle** — generiere einen zugeschnittenen Ausgangssatz, den du bearbeiten kannst. * **Jede fehlende Übersetzung** — die [Übersetzungen-Seite](/de/docs/languages/translations-page/) füllt alle ausstehenden Übersetzungen in einem Durchgang, mit einem Prüfungsfenster, in dem du alles abwählst, was du nicht möchtest. ## Ein ganzes Objekt importieren [Section titled “Ein ganzes Objekt importieren”](#ein-ganzes-objekt-importieren) Um ein Objekt aus einer bestehenden Quelle statt Feld für Feld zu erstellen, nutze den KI-Import — füge eine URL, Text oder PDF ein, oder lade Fotos hoch, und KI entwirft das gesamte Objekt (in allen deinen Sprachen) zur Prüfung und Veröffentlichung. Siehe [Ein Objekt erstellen](/de/docs/listings/create-a-listing/). # KI-Antworten an Gäste > Lass KI Antworten auf eingehende Gastnachrichten entwerfen — oder senden — mit Prüffenster und einem Autopilot, der nur einfache Fragen beantwortet. Reynt kann eingehende Gastnachrichten in deinem [Posteingang](/de/docs/communication/inbox/) für dich beantworten. Du entscheidest, wie weit die KI dabei gehen darf: einen Entwurf vorbereiten, den du prüfst, nach einer Wartezeit senden, oder einfache Sachfragen sofort beantworten. Das ist **standardmäßig aus**. Es wird nichts entworfen oder gesendet, bevor du es einschaltest. ## Selbstständigkeit festlegen [Section titled “Selbstständigkeit festlegen”](#selbstständigkeit-festlegen) Gehe zu **Einstellungen → KI** und wähle unter **KI-Antworten an Gäste** einen Modus. | Modus | Was passiert, wenn ein Gast schreibt | | --------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **Aus** | Nichts. Die KI rührt eingehende Nachrichten nicht an. | | **Entwurf zum Prüfen** | Eine fertige Antwort wartet in der Unterhaltung. Ohne dich wird nichts gesendet. | | **Nach Prüffenster senden** | Eine Antwort wird vorbereitet und sendet sich nach Ablauf der Wartezeit selbst — außer du greifst vorher ein. | | **Autopilot für einfache Fragen** | Einfache Sachfragen werden sofort beantwortet; alles andere landet als Entwurf bei dir. | Fang für ein bis zwei Wochen mit **Entwurf zum Prüfen** an und lies, was dabei herauskommt. So findest du ehrlich heraus, ob die Antworten für deine Objekte gut genug sind, bevor sich etwas selbst versendet. ### Das Prüffenster [Section titled “Das Prüffenster”](#das-prüffenster) Im Modus **Nach Prüffenster senden** legst du fest, wie lange die Antwort wartet (1–120 Minuten, standardmäßig 10). In dieser Zeit zeigt die Unterhaltung einen Countdown, und die Antwort wird abgebrochen, wenn du: * **Im Editor bearbeitest** — übernimmt den Text als deinen eigenen in das Antwortfeld, * sie **verwirfst**, * oder einfach **selbst antwortest**. Eine interne Notiz bricht das geplante Senden ebenfalls ab, lässt den Entwurf aber verfügbar — eine Notiz heißt, dass du dir die Sache ansiehst, nicht dass der Gast eine Antwort hat. Wenn du nicht warten willst, sendet **Jetzt senden** die Antwort sofort. ### Was der Autopilot beantwortet — und was nicht [Section titled “Was der Autopilot beantwortet — und was nicht”](#was-der-autopilot-beantwortet--und-was-nicht) Der Autopilot sendet nur dann selbst, wenn die Nachricht des Gastes eine klare Sachfrage ist, die er überprüfen kann: * **Verfügbarkeit** — ob Termine frei sind, Mindestaufenthalte, was ein Aufenthalt zu deinen hinterlegten Preisen kostet * **Ausstattung** — Parkplatz, WLAN, Haustiere, Küche, Betten, was inbegriffen ist * **Check-in** — Check-in- und Check-out-Zeiten, Schlüsselübergabe * **Anfahrt** — wie man das Objekt findet, Entfernungen, was in der Nähe ist Alles andere wird stattdessen zu einem Entwurf für dich, insbesondere alles rund um **Geld** (Erstattungen, Rabatte, Zahlungsprobleme), **Buchungsänderungen** (Stornierungen, Termin- oder Personenänderungen, früher Check-in oder später Check-out), **Beschwerden, Schäden oder rechtliche Themen** — und jede Nachricht, bei der er sich nicht sicher ist. Eine Nachricht, die eine einfache Frage mit so einem Thema mischt, landet ebenfalls bei dir. Wenn er ablehnt, zeigt die Unterhaltung den Entwurf mit dem Hinweis **Deine Entscheidung nötig** — du bekommst den Vorsprung trotzdem, entscheidest aber selbst. ## Was der Gast sieht [Section titled “Was der Gast sieht”](#was-der-gast-sieht) Eine Antwort, die die KI selbst gesendet hat, trägt einen kurzen Hinweis, dass sie automatisch erstellt wurde und dass der Gast einfach auf die E-Mail antworten kann. Das ist beabsichtigt und lässt sich nicht abschalten: Wenn du ohne diesen Hinweis senden möchtest, nutze **Im Editor bearbeiten** und sende die Nachricht als du selbst. In der Unterhaltung ist alles, was die KI gesendet hat, mit **KI** gekennzeichnet — so erkennst du jederzeit den Unterschied zwischen den Antworten deines Teams und automatischen. ## Woher die Antworten kommen [Section titled “Woher die Antworten kommen”](#woher-die-antworten-kommen) Die KI liest die Unterhaltung und schlägt vor dem Schreiben deine echten Daten nach — die Buchung oder Anfrage, um die es geht, das Objekt, dessen Preise und Verfügbarkeit, Ausstattung und Entfernungen. Sie ist angewiesen, nie etwas zu behaupten, was sie nicht überprüfen konnte, und stattdessen einen Platzhalter für dich zu hinterlassen. Interne Notizen zitiert sie dem Gast gegenüber nie, und sie behandelt alles, was in der Unterhaltung steht, als Information und nicht als Anweisung — ein Gast kann sie also nicht dazu überreden, ihre Regeln zu ignorieren. ## Voraussetzungen und Grenzen [Section titled “Voraussetzungen und Grenzen”](#voraussetzungen-und-grenzen) * **KI muss verbunden sein.** Siehe [KI-Übersicht](/de/docs/ai/overview/). * **Automatisches Senden braucht eingehende Antworten.** Aktiviere **Eingehende E-Mail-Antworten** unter **Einstellungen → E-Mail-Zustellung**, damit die Antwort des Gastes wieder in der Unterhaltung landet — siehe [Eingehende Antworten](/de/docs/communication/inbox/#eingehende-antworten). Ohne das erstellt die KI nur Entwürfe, und die Einstellungsseite weist dich darauf hin. * **Tageslimit.** Eine Obergrenze, wie viele KI-Antworten pro Tag erzeugt werden (standardmäßig 100), schützt dich vor einer Nachrichtenflut. Sie gilt zusätzlich zu deinem [KI-Token-Budget](/de/docs/ai/overview/#kosten-und-kontingente). * **Nur E-Mail-Unterhaltungen** — Nachrichten, die per E-Mail oder über das Kontaktformular deiner Website eintreffen. * **Spam wird ignoriert**, und wenn vor dem Senden eine neuere Nachricht eintrifft, wird die überholte Antwort verworfen statt verspätet gesendet. ## Kosten [Section titled “Kosten”](#kosten) KI-Antworten an Gäste greifen auf dasselbe tägliche KI-Budget zu wie der Rest der Konsole — viel Posteingangsverkehr und viel Inhaltsgenerierung konkurrieren also um dieselbe Menge. Behalte das auf der [KI-Nutzungsseite](/de/docs/ai/overview/#nutzung-%C3%BCberwachen) im Auge und nutze das Tageslimit als Notbremse. # KI-Übersicht > Was Reynt KI kann, wie du sie verbindest und wie du Nutzung und Kosten überwachst. Reynt hat KI durchgängig in die Konsole eingewoben, um die repetitiven Teile deines Geschäfts zu beschleunigen — Objektinhalte schreiben, sie übersetzen, Objekte importieren und Website- und Support-Texte entwerfen. Diese Seite erklärt, was KI kann, wie du sie einschaltest, und wie du die Kosten im Blick behältst. ## Was KI kann [Section titled “Was KI kann”](#was-ki-kann) * **Ein Objekt importieren** — füge eine URL, Text oder PDF ein, oder lade Fotos hoch, und KI extrahiert die Details, schreibt den Inhalt in allen deinen Sprachen und ordnet Ausstattungsmerkmale zu. Siehe [Ein Objekt erstellen](/de/docs/listings/create-a-listing/). * **Objektinhalte generieren und übersetzen** — schreibe oder übersetze einzelne Felder (Titel, Beschreibung, SEO und mehr) über deine Sprachen hinweg. Siehe [Inhaltsgenerierung und Übersetzung](/de/docs/ai/content-generation-and-translation/). * **Objektbilder beschriften** — Bildanalyse erzeugt beschreibende Beschriftungen für Fotos. * **Website-Inhalte generieren** — entwirf Inhaltsabschnitte für CMS-Seiten und Blogbeiträge. * **Deinen Katalog aufbauen** — generiere Tags und Stornierungsrichtlinien, zugeschnitten auf dein Geschäft. * **Icons vorschlagen** — bei der Auswahl eines Icons für einen Katalogeintrag (Ausstattung, Attribut und Ähnliches) schlägt **Mit KI vorschlagen** passende Icons anhand des Namens des Eintrags vor. * **Support- und Checkout-Texte entwerfen** — wiederverwendbare Textbausteine für den Posteingang und Optionen für die Herkunftsquelle „Wie haben Sie von uns erfahren?“. * **Gästen antworten** — Antworten auf eingehende Gastnachrichten im Posteingang entwerfen oder automatisch senden. Standardmäßig aus. Siehe [KI-Antworten an Gäste](/de/docs/ai/guest-replies/). * **Ortskoordinaten ausfüllen** — finde Breiten-/Längengrad für Orte, denen sie fehlen. * **Alles übersetzen** — die [Übersetzungen-Seite](/de/docs/languages/translations-page/) kann jede fehlende Übersetzung mit KI ausfüllen. * **Smarte Suche** — beschreibe in natürlicher Sprache, was ein Gast sucht, und lass KI passende Objekte finden. * **Das Angebot einer Anfrage entwerfen** — finde anhand der erfassten Kundenwünsche einer Anfrage passende Objekte, prüfe Verfügbarkeit und Preise, und erstelle einen Angebotsentwurf mit mehreren Optionen und Nachrichtenvorschlag. Siehe [Ein Angebot mit KI entwerfen](/de/docs/bookings/booking-drafts-and-offers/#ein-angebot-mit-ki-entwerfen). Es gibt außerdem **Reynt fragen**, den in die Konsole integrierten Assistenten — einen vollwertigen Chat-Agenten, der die Daten deines Mandanten lesen kann (Buchungen, Objekte, Preise, Kunden, Rechnungen, Berichte und mehr), Fragen zur Konsole beantwortet und Änderungen vorschlägt, die du bestätigst. Siehe [Der KI-Assistent](/de/docs/ai/assistant/). ## KI verbinden [Section titled “KI verbinden”](#ki-verbinden) KI-Funktionen werden unter **Einstellungen → KI** konfiguriert. Ein Hilfe-Panel auf der Seite führt dich durch dieselben Schritte. * **Anbieter** — wähle, welcher Anbieter deinen Mandanten bedient: **Anthropic** (USA) oder **Mistral** (EU). Diese Wahl funktioniert **mit und ohne eigenen Schlüssel** — hält die Plattform für den gewählten Anbieter einen eigenen Zugang bereit, laufen deine Anfragen darüber, und unser Auftragsverarbeitungsvertrag deckt sie ab. Die Seite zeigt dir, welche Anbieter so verfügbar sind und wo deine Anfragen gerade tatsächlich verarbeitet werden. * **API-Schlüssel (optional)** — hinterlege einen eigenen Schlüssel, wenn stattdessen direkt über dein Anbieterkonto abgerechnet werden soll. Damit verlagern sich auch die datenschutzrechtlichen Pflichten zu dir — siehe [Datenschutz](#datenschutz) unten. Wählst du einen Anbieter, für den die Plattform keinen Zugang hat, ohne einen eigenen Schlüssel zu hinterlegen, bleibt KI für diesen Anbieter aus: Wir leiten deine Daten nicht stillschweigend an einen anderen Anbieter um. * **Modell** — belasse es auf der Standardeinstellung (**Claude Sonnet 5** für Anthropic) für eine gute Balance aus Qualität und Geschwindigkeit, oder wähle ein anderes Modell — Anthropic bietet Opus 4.8, Opus 4.7, Sonnet 5, Sonnet 4.6 und Haiku 4.5 (schneller, günstiger für kurze Texte); Mistral bietet Mistral Medium, Large, Small und Magistral Medium. Du kannst auch eine benutzerdefinierte Modell-ID eingeben. * **Eigene Anweisungen** — optionale Vorgaben, die auf generierte Inhalte angewendet werden (Ton, Stil, Hausregeln). Du kannst sogar einen Ausgangssatz aus deinen eigenen Objekten und Einstellungen generieren lassen. * **Smarte Suche** — ein separater Embedding-Anbieter (**OpenAI**, USA, oder **Mistral**, EU), ein optionaler Schlüssel und ein Modell treiben den Smarte-Suche-Index an. Es gilt dieselbe Regel: Der Anbieter ist auch über den Zugang der Plattform wählbar, ein eigener Schlüssel ist optional. Der Wechsel des Embedding-Anbieters oder -Modells indexiert alle deine Objekte neu. Sobald KI verfügbar ist — über den Zugang der Plattform oder deinen eigenen Schlüssel —, leuchten die KI-Buttons überall in der Konsole auf, am sichtbarsten auf Objekt-Detailseiten. ## Kosten und Kontingente [Section titled “Kosten und Kontingente”](#kosten-und-kontingente) Der verwendete Schlüssel bestimmt, wie die Ausgaben gesteuert werden: * **Eigener Schlüssel (BYOK)** — du zahlst direkt an deinen Anbieter, und es gibt keine Plattform-Limits. Damit ändert sich auch, wer die datenschutzrechtlichen Pflichten trägt — siehe [Datenschutz](#datenschutz) unten. * **Plattform-Schlüssel** — ist kein Schlüssel verbunden, läuft KI auf dem Plattform-Schlüssel, vorbehaltlich kontobezogener Limits (eine Obergrenze, wie viele Workflows gleichzeitig, pro Tag und pro Monat laufen). Der [KI-Assistent](/de/docs/ai/assistant/) hat sein eigenes tägliches Token-Kontingent auf dem Plattform-Schlüssel (großzügig genug für den normalen Gebrauch); das Verbinden deines eigenen Schlüssels hebt es vollständig auf. Jeder KI-Lauf zeichnet auf, welcher Schlüssel verwendet wurde, damit du immer sehen kannst, wo Kosten entstanden sind. ## Datenschutz [Section titled “Datenschutz”](#datenschutz) KI-Funktionen übermitteln Daten an einen Sprachmodell-Anbieter. Für die Daten deiner Gäste und Eigentümer bist du der Verantwortliche — deshalb lohnt es sich, das zu kennen, bevor du die Funktionen einschaltest. **Was die Plattform verlässt.** Nur das, was die jeweilige Anfrage braucht, und nur in dem Moment, in dem du sie auslöst. Je nach Funktion können das Stammdaten von Gästen und Eigentümern (Name, Anschrift), Kontaktdaten (E-Mail, Telefon), Buchungsdaten einschließlich Sonderwünschen sein und — nur wenn du KI-Antworten auf eingehende Gast-Nachrichten aktivierst — der Text dieser Nachrichten. **Meldeschein-Daten werden nie an ein Modell übermittelt.** Im Hintergrund passiert nichts: ohne deinen Aufruf oder eine von dir aktivierte Funktion gibt es keine Übermittlung. **Wer verarbeitet.** Der Anbieter, den du unter **Einstellungen → KI** ausgewählt hast. Beide sind als genehmigte Subunternehmer in [Anhang 3 des AVV](https://www.reynt.co/de/legal/avv) geführt: * **Anthropic (USA)** — die Voreinstellung. Jede Anfrage ist eine Übermittlung in ein Drittland, auf Grundlage der EU-Standardvertragsklauseln. * **Mistral (Frankreich, EU)** — über den Zugang der Plattform wählbar, ohne eigenen Schlüssel. Weil der Anbieter in der EU niedergelassen ist, ist deine Anfrage keine Drittlandübermittlung durch uns. Die Grenze dieser Aussage steht weiter unten. Deine Inhalte werden nicht zum Training von Modellen verwendet (AGB § 6 Abs. 3). Die Einstellungsseite zeigt an, welcher der beiden dich gerade bedient — du musst es nicht erschließen. **Informiere deine Gäste.** Deine eigene Datenschutzerklärung muss abbilden, dass KI-Funktionen ihre Daten verarbeiten — und, wenn du den US-Anbieter nutzt, dass dabei eine Übermittlung außerhalb der EU stattfindet. Diese Pflicht trifft dich als Verantwortlichen, nicht uns (AVV § 5 Abs. 3). **Wenn du einen eigenen Schlüssel hinterlegst**, ist der von dir gewählte Anbieter *dein* Auftragsverarbeiter, nicht unserer. Unsere Verträge und Garantien decken diesen Schlüssel nicht ab. Du brauchst dann einen eigenen Vertrag nach Art. 28 DSGVO mit diesem Anbieter, eine eigene Grundlage für die Übermittlung, falls er außerhalb der EU sitzt, und eine eigene Information der betroffenen Personen (AVV § 6 Abs. 6). BYOK ist also nicht automatisch sicherer — es verlagert diese Pflichten von uns zu dir. **Was die Wahl des EU-Anbieters klärt — und was nicht.** Sie beseitigt die Drittlandübermittlung *von uns zum Anbieter*: Mistral ist in Frankreich niedergelassen, dieser Schritt bleibt also in der EU — und er bleibt unter unserem Vertrag, statt auf dich verlagert zu werden. Sie ist aber **keine** Zusage einer Verarbeitung ausschließlich in der EU über die gesamte Kette. „EU-Unternehmen“ und „Verarbeitung ausschließlich in der EU“ sind nicht dasselbe: Anbieter dokumentieren Hosting-Regionen und Unterauftragsverarbeiter je Funktion, und das ändert sich. Unser Vertrag verweist für diese weiteren Schritte deshalb auf das Regime des Anbieters, statt eine Datenresidenz zuzusagen, die wir nicht geprüft haben. Wenn du eine harte Residenz-Zusage brauchst und nicht nur einen in der EU niedergelassenen Auftragsverarbeiter, sprich uns an, bevor du dich darauf verlässt. **Eine Ausnahme, an der keine Anbieterwahl etwas ändert:** die Suche in der eingebauten Hilfe-Wissensdatenbank. Dieser Index beschreibt Reynt selbst und wird zentral für alle Konten erzeugt; er nutzt daher immer den Embedding-Anbieter der Plattform — dein Suchtext geht unabhängig von deiner Anbieterwahl dorthin. Anhang 3 weist das deshalb gesondert aus. **Weniger nach außen geben.** Unter **Einstellungen → KI** gibt es die Option **Pseudonymisierung**: Namen, E-Mail-Adressen, Telefonnummern und Straßenangaben werden durch Platzhalter ersetzt, bevor etwas das Modell erreicht, und wieder aufgelöst, bevor du die Antwort siehst. Sie ist standardmäßig aus, weil sie den Assistenten etwas Fähigkeit kostet, ähnliche Namen zuzuordnen und deutsche Anreden korrekt zu beugen. Sie ist eine Schutzmaßnahme, keine Anonymisierung — die Daten bleiben personenbezogen, und der Anbieter bleibt Auftragsverarbeiter. Am meisten lohnt sie sich auf einem eigenen Schlüssel, weil unsere eigenen Garantien genau dort nicht greifen — und sie ist auch beim US-Anbieter eine Überlegung wert, wo jeder Aufruf eine Drittlandübermittlung ist. ## Nutzung überwachen [Section titled “Nutzung überwachen”](#nutzung-überwachen) Die Seite **Einstellungen → KI-Nutzung** gibt dir Einblick in den Verbrauch: * **Nutzung**-Tab — Karten für Workflows heute, diesen Monat und aktuell laufend; Gesamtwerte für einen gewählten Zeitraum (letzte 7 Tage, letzte 30 Tage oder dieser Monat), die Workflow-Anzahl, Tokens und **geschätzte Kosten** abdecken; sowie eine Aufschlüsselungstabelle nach Workflow-Typ mit Schlüsselquelle, Token-Anzahl und Kosten. * **Workflows**-Tab — eine Historie jedes KI-Laufs mit Typ, Status, zugehöriger Entität und Dauer. Öffne eine beliebige Zeile, um die Schritte des Laufs im Detail zu prüfen. # Daten sperren > Markiere ein Objekt manuell für einen Datumsbereich als nicht verfügbar, sodass Gäste es nicht buchen können. Das Sperren von Daten nimmt ein Objekt für einen Zeitraum vom Markt, ohne dass eine Buchung dahintersteht — nutze es für Wartung, Eigentümeraufenthalte, Renovierungen oder jegliche Daten, die du einfach nicht buchbar haben möchtest. Gesperrte Daten verschwinden aus der Storefront-Suche und werden im Kalender als nicht verfügbar angezeigt. ## Wo Sperrungen zu finden sind [Section titled “Wo Sperrungen zu finden sind”](#wo-sperrungen-zu-finden-sind) Öffne ein Objekt und gehe zu seinem Tab **Sperrzeiten** (**Objekte → \[Objekt] → Sperrzeiten**). Dies ist eine einfache Liste gesperrter Zeiträume — jede Zeile zeigt Start- und Enddatum, Anzahl der Tage und einen optionalen Grund. Es ist kein Drag-auf-einem-Kalender-Tool; du fügst jeden Zeitraum über ein kleines Formular hinzu. ## Eine Sperrung hinzufügen [Section titled “Eine Sperrung hinzufügen”](#eine-sperrung-hinzufügen) 1. Klicke im Tab **Sperrzeiten** auf **Erstellen**. 2. Wähle den **Zeitraum** — ein Start- und Enddatum. Jedes Feld öffnet einen Kalender, durch den du klicken kannst. 3. Gib optional einen **Grund** ein (z. B. „Wartung“, „Eigentümeraufenthalt“). Dies ist Freitext, keine feste Liste, und er erscheint im Kalender beim Hovern. 4. Klicke auf **Speichern**. Die Datumsauswahl hebt Daten hervor, die bereits durch eine bestehende Sperrung oder Buchung belegt sind, sodass du Überschneidungen erkennst, bevor du bestätigst. Die gesperrten Daten verschwinden aus der Storefront-Suche, sobald du speicherst. ## Eine Sperrung bearbeiten oder entfernen [Section titled “Eine Sperrung bearbeiten oder entfernen”](#eine-sperrung-bearbeiten-oder-entfernen) Klicke auf eine beliebige Zeile in der Liste, um sie erneut zu öffnen. Ändere die Daten oder den Grund und klicke auf **Speichern**, oder klicke auf **Löschen**, um die Sperrung zu entfernen und diese Daten wieder buchbar zu machen. ## Wie Sperrungen mit Buchungen zusammenhängen [Section titled “Wie Sperrungen mit Buchungen zusammenhängen”](#wie-sperrungen-mit-buchungen-zusammenhängen) Manuelle Sperrungen und bestätigte Buchungen machen beide ein Datum nicht verfügbar, werden aber getrennt erfasst und im [Kalender](/de/docs/availability/calendar-views/) in unterschiedlichen Farben angezeigt — eine manuelle Sperrung ist **Gesperrt** (rot), eine Buchung ist **Gebucht** (blau). So kannst du operative Ausfallzeiten auf einen Blick von echtem Umsatz unterscheiden. Aus einer externen Plattform importierte Sperrungen sind eine dritte, separate Ebene; siehe [iCal-Synchronisierung](/de/docs/availability/ical-sync/). ## Sperren vorgemerkte Buchungen ebenfalls Daten? [Section titled “Sperren vorgemerkte Buchungen ebenfalls Daten?”](#sperren-vorgemerkte-buchungen-ebenfalls-daten) Bestätigte Buchungen sperren Daten immer und überall. Vorgemerkte Buchungen (ein Checkout, der noch nicht bezahlt oder bestätigt wurde) werden durch eine Einstellung unter **Einstellungen → Buchungseinstellungen** gesteuert: **Vorgemerkte Buchungen blockieren Storefront**. * **An (hart):** Vorgemerkte Buchungen sperren den Storefront — die Suche blendet das Objekt für diese Daten aus, der öffentliche Kalender zeigt sie als nicht verfügbar an, und neue Checkouts mit überschneidenden Daten werden abgelehnt. * **Aus (weich):** Der Storefront ignoriert vorgemerkte Buchungen und nimmt an diesen Daten weiterhin neue Buchungen an. In beiden Fällen behandelt die Operator-Konsole vorgemerkte Buchungen immer als gesperrt, sodass dein Kalender und deine Verfügbarkeitsansichten sie unabhängig von dieser Einstellung anzeigen. # Kalenderansichten > Verfügbarkeit über alle Objekte hinweg oder für ein einzelnes Objekt lesen, mit einer Farblegende für jeden Status. Reynt hat zwei Kalender zum Lesen der Verfügbarkeit: ein globales Raster, das alle Objekte auf einmal abdeckt, und eine Monatsansicht pro Objekt. Beide sind schreibgeschützt — Änderungen nimmst du im Tab [Sperrzeiten](/de/docs/availability/block-dates/), bei [Buchungen](/de/docs/bookings/lifecycle/) oder über die [iCal-Synchronisierung](/de/docs/availability/ical-sync/) vor — und beide teilen sich dieselbe Farblegende. ## Der globale Kalender [Section titled “Der globale Kalender”](#der-globale-kalender) Öffne **Kalender** aus der Hauptnavigation. Er zeigt eine Zeile pro Objekt und eine Spalte pro Tag des gewählten Monats, sodass du dein gesamtes Portfolio nebeneinander überblicken kannst. Nutze die Pfeile, um zwischen Monaten zu wechseln. * **Nach Titel filtern** grenzt die Zeilen nach Objekttitel oder -schlüssel ein. Du kannst mehrere durch Komma getrennte Begriffe eingeben. * **Nach Tags filtern** beschränkt das Raster auf Objekte, die die von dir gewählten Tags tragen. Hover kurz über eine Zelle oder klicke sie an, um sie zu fixieren, und ein Panel zeigt den Status dieses Tages, einen etwaigen Sperrgrund und den Preis. Von dort kannst du direkt zu **Buchung #… öffnen** (wenn eine Buchung den Tag belegt) oder **Objektkalender öffnen** springen. ## Der Kalender pro Objekt [Section titled “Der Kalender pro Objekt”](#der-kalender-pro-objekt) Jedes Objekt hat seinen eigenen Tab **Kalender** (**Objekte → \[Objekt] → Kalender**), dargestellt als vertrautes Monatsraster. Jeder Tag zeigt sein Datum und, wenn ein Preis gilt, den Übernachtungspreis darunter. Nutze die Pfeile, um den Monat zu wechseln. ## Was die Farben bedeuten [Section titled “Was die Farben bedeuten”](#was-die-farben-bedeuten) Beide Kalender nutzen dieselbe Legende: * **Verfügbar** (grün) — buchbar, mit einem Preis. * **Gebucht** (blau) — eine bestätigte Buchung. * **Vorgemerkt** (pink) — eine noch nicht bestätigte Buchung. * **Gesperrt** (rot) — eine manuelle Sperrung aus dem Tab „Sperrzeiten“. * **Externer Kalender** (lila) — eine über iCal-Synchronisierung importierte Sperrung von einer anderen Plattform. * **Kein Preis** (bernstein) — keine Preisregel deckt den Tag ab, daher ist er erst buchbar, wenn du eine hinzufügst. Manche Zellen sind diagonal in zwei Farben geteilt. Dies sind **Übergangstage**: ein Abreisemorgen nach der letzten gebuchten Nacht oder ein Anreisenachmittag zu Beginn eines Aufenthalts. Die farbige Hälfte markiert den Teil des Tages, an dem das Objekt belegt ist, sodass aufeinanderfolgende Aufenthalte korrekt dargestellt werden, statt wie ein komplett gesperrter Tag auszusehen. ## Preise im Kalender [Section titled “Preise im Kalender”](#preise-im-kalender) Der Kalender pro Objekt druckt den Übernachtungspreis auf jeden Tag, und der globale Kalender zeigt ihn im Hover-Panel an. Ein mit **Kein Preis** markierter Tag hat keine Regel, die ihn bepreist — lege im Tab [Preise](/de/docs/pricing/base-and-seasonal/) des Objekts Basis- oder Saisonpreise fest, um ihn buchbar zu machen. # iCal-Synchronisierung > Synchronisiere die Verfügbarkeit mit Buchungsportalen und anderen Plattformen über iCal-Feeds. Wenn du dieselbe Unterkunft auf anderen Plattformen anbietest, hält die iCal-Synchronisierung deren Kalender und Reynt im Gleichschritt. Reynt kann die Verfügbarkeit eines Objekts als iCal-Feed **veröffentlichen** und Feeds von anderen Plattformen **abonnieren**, sodass deren Buchungen in Reynt Daten sperren. Beides findest du im Tab **Externe Kalender** eines Objekts (**Objekte → \[Objekt] → Externe Kalender**). ## Deinen Kalender veröffentlichen (ausgehend) [Section titled “Deinen Kalender veröffentlichen (ausgehend)”](#deinen-kalender-veröffentlichen-ausgehend) Der Bereich **iCal-Export** gibt jedem Objekt eine private Feed-URL, die du bei einem Buchungsportal, einem Channel-Manager oder jedem Kalender, der iCal liest, einfügst. 1. Klicke auf **Export-URL generieren**. Der Export ist ausgeschaltet, bis du das tust. 2. Klicke auf **URL kopieren** und füge sie in das „Kalender importieren“-Feld der anderen Plattform ein. Der Feed deckt die nächsten 365 Tage ab und enthält bestätigte Buchungen sowie jede manuelle Sperrung. **URL neu generieren** stellt einen neuen Link aus und macht den alten ungültig (nutze das, falls eine URL durchgesickert ist); **Export deaktivieren** schaltet den Feed komplett ab. ## Externe Kalender abonnieren (eingehend) [Section titled “Externe Kalender abonnieren (eingehend)”](#externe-kalender-abonnieren-eingehend) Der Bereich **Externe Kalender** zieht Verfügbarkeit *von* anderen Plattformen *herein*. Füge so viele Feeds hinzu, wie du möchtest: 1. Klicke auf **Kalender hinzufügen**. 2. Füge die iCal-URL ein, die dir die andere Plattform gibt. 3. Klicke auf **Speichern**. Jeder Feed erscheint in der Liste mit seiner URL, seinem Typ, dem Zeitpunkt der letzten Synchronisierung und einem Status-Badge. Reynt aktualisiert jeden Feed automatisch **einmal pro Stunde** — klicke auf **Alle synchronisieren**, um sofort zu ziehen. Importierte Buchungen erscheinen als gesperrte Daten im [Kalender](/de/docs/availability/calendar-views/) in der Farbe **Externer Kalender** (lila), beschriftet mit der Zusammenfassung des Ereignisses aus der Quelle. Reynt erfährt nur, dass ein Datum belegt ist — es erhält niemals Gastdetails aus einem externen Feed. ## Wenn ein Feed fehlschlägt [Section titled “Wenn ein Feed fehlschlägt”](#wenn-ein-feed-fehlschlägt) Feeds brechen — eine URL ändert sich, eine Plattform hat einen Ausfall. Reynt kümmert sich für dich darum: * Ein fehlschlagender Feed zeigt **Letzte Synchronisierung fehlgeschlagen** an und wird automatisch mit wachsender Verzögerung erneut versucht (beginnend bei ca. 15 Minuten und von dort ansteigend). * Wenn ein Feed weiterhin fehlschlägt, stoppt Reynt die erneuten Versuche und markiert ihn als **Pausiert**, um eine tote URL nicht weiter zu belasten. Eine eindeutig defekte URL wird nach wenigen Versuchen pausiert; sporadische Fehler werden zunächst deutlich länger erneut versucht. * Behebe die URL (nutze **URL bearbeiten**), öffne dann das Menü der Zeile und klicke auf **Jetzt erneut versuchen** — dies synchronisiert sofort erneut, löscht den Fehlerstatus und setzt einen pausierten Feed fort. Du kannst einen gesunden Feed auch selbst **pausieren** und **fortsetzen** oder ihn **löschen**. ## Sync-Probleme aufspüren [Section titled “Sync-Probleme aufspüren”](#sync-probleme-aufspüren) Du musst nicht jedes Objekt öffnen, um defekte Feeds zu finden: * Das **Dashboard** zeigt eine Warnung an, wenn Kalender fehlschlagen oder deaktiviert wurden, mit einem **Sync reparieren**/**Ansehen**-Link direkt zum betroffenen Objekt (oder zur gefilterten Liste). * Die Seite **Objekte** hat einen Filter **Kalender-Sync-Fehler**, der nur Objekte mit fehlschlagenden Feeds anzeigt. Dashboard-Links landen hier bereits vorgefiltert. ## Manuelle Sperrungen vs. synchronisierte Sperrungen [Section titled “Manuelle Sperrungen vs. synchronisierte Sperrungen”](#manuelle-sperrungen-vs-synchronisierte-sperrungen) Aus einem externen Feed importierte Sperrungen werden vollständig von der Synchronisierung verwaltet — sie werden bei jedem Lauf aktualisiert, sodass du sie in Reynt nicht bearbeiten oder entfernen kannst. Um eine zu entfernen, entferne sie auf der Quellplattform. Deine eigenen manuellen Sperrungen im Tab [Sperrzeiten](/de/docs/availability/block-dates/) sind unabhängig und jederzeit entfernbar. # Vor der Anreise > Die zwei E-Mails, die in den Tagen vor dem Check-in rausgehen — Anreiseinfos und die Erinnerung an den Meldeschein. Zwei E-Mails gehen in den Tagen vor der Anreise von selbst raus. Beide verschickt ein täglicher Lauf am Morgen, beide werden **einmal pro Buchung** verschickt, und für keine muss jemand einen Knopf drücken. ## Anreiseinfos [Section titled “Anreiseinfos”](#anreiseinfos) Schalte **Einstellungen → Buchungseinstellungen → Anreiseinfos vor dem Check-in senden** ein, und jeder bestätigte Gast bekommt ein paar Tage vor der Reise seine Anreiseinfos: Anfahrt, Übergabekontakt und Check-in-Zeit. * **Tage vor Anreise** legt fest, wie weit im Voraus. Voreingestellt sind drei. * Der Inhalt kommt aus dem **Objekt**, nicht aus der E-Mail — trag die Anreisehinweise also zuerst beim Objekt ein, sonst hat die E-Mail wenig zu sagen. Es sind dieselben Angaben wie in der Bestätigungsmail, damit beide nicht unterschiedliche Türcodes nennen. * Sie ist **standardmäßig aus**. Wer *innerhalb* dieses Zeitraums bucht, bekommt sie beim nächsten Tageslauf. Am Anreisetag selbst geht nichts mehr raus — dann ist der Gast bereits unterwegs und die E-Mail käme zu spät. Da sie nur einmal pro Buchung verschickt wird, führt ein späteres Verschieben der Termine nicht zu einem zweiten Versand. Ändern sich die Anreisedetails kurzfristig, nutze die Sende-Aktionen der Buchung, um den Gast zu informieren. ## Erinnerung an den Meldeschein [Section titled “Erinnerung an den Meldeschein”](#erinnerung-an-den-meldeschein) Wo die [Gästeregistrierung](/de/docs/bookings/guest-registration/) gilt, bekommt ein Gast, der das Formular noch nicht ausgefüllt hat, am **Tag vor der Anreise** eine Erinnerung mit dem Link dorthin. * Sie geht nur an Buchungen, für die die Meldepflicht **überhaupt gilt**, und nur solange der Eintrag leer ist. Wer schon ausgefüllt hat — oder wessen Formular du selbst aus der Buchung heraus erfasst hast — hört nichts. * Sie hat **keine eigene Einstellung**. Die Gästeregistrierung einzuschalten ist bereits eine bewusste Entscheidung; das hier gehört dazu. * Der Zeitpunkt am Vortag ist fest. Früher denkt der Gast noch nicht an die Reise, am Tag selbst ist er unterwegs. ## Abschalten und Wortlaut ändern [Section titled “Abschalten und Wortlaut ändern”](#abschalten-und-wortlaut-ändern) Beide sind ganz normale Benachrichtigungen: **Einstellungen → Benachrichtigungen** führt *Anreiseinfos senden* und *Erinnerung an den Meldeschein* neben allen anderen Gäste-E-Mails auf. Dort kannst du jede einzeln abschalten, den Wortlaut je Sprache anpassen und dir eine Testmail schicken. Schaltest du die Anreise-E-Mail in den **Buchungseinstellungen** aus, gilt das für alle; schaltest du sie unter **Benachrichtigungen** aus, passiert dasselbe von der anderen Seite. Nimm, was du zuerst findest — die Anreiseinfos selbst bleiben in beiden Fällen, wo sie sind. # Anfragen und Angebote > Erstelle ein Angebot, sende es an einen Gast, lass ihn online annehmen oder ablehnen, verhandle nach und veröffentliche die akzeptierte Anfrage als Buchung. Eine **Buchungsanfrage** ist eine noch in Arbeit befindliche Reservierung — ein Angebot, das du erstellst und mit einem Gast verhandelst, bevor daraus eine echte [Buchung](/de/docs/bookings/lifecycle/) wird. Anfragen halten Kunde, Daten, Objekt und Preis fest, während du **Angebote** hin- und hersendest, und veröffentlichen dann das akzeptierte. Du findest sie unter **Buchungsanfragen** in der Seitenleiste. ## Eine Anfrage erstellen [Section titled “Eine Anfrage erstellen”](#eine-anfrage-erstellen) Die Anfragenliste hat zwei Einstiegspunkte, die beide denselben Assistenten in unterschiedlichem Modus öffnen: * **Neue Anfrage** — der vollständige dreistufige Assistent: **Gast** (Kunde verknüpfen oder anlegen), **Wünsche** (die optionalen Wünsche des Kunden — siehe [Kundenwünsche](#kundenw%C3%BCnsche)), dann **Details & Preisgestaltung** (Objekt, An-/Abreise, Gäste, Haustiere und Preis). Schließe mit **Anfrage erstellen** ab. * **Interesse erfassen** — eine kürzere Erfassung **Gast → Wünsche** für einen Anruf, eine E-Mail oder einen Lead, bei dem es noch kein Objekt und keine Daten gibt, nur einen Kunden und seine Wünsche. Sie endet mit **Interesse anlegen** statt mit einem Details-Schritt. Wird das Gespräch im Verlauf konkreter, blendet **Angebotsdetails hinzufügen** den Schritt Details & Preisgestaltung ein, ohne von vorn zu beginnen — lässt er sich trotzdem nicht abschließen, bleibt **Interesse anlegen** dort weiterhin als Ausweg verfügbar. Es gibt noch einen dritten Weg: * **Aus einer Postfach-Nachricht** — wenn dir ein Gast eine Anfrage per E-Mail schickt, öffne die Konversation im [Postfach](/de/docs/communication/inbox/) und klicke auf **Buchungsanfrage erstellen**. Das öffnet denselben Interesse-erfassen-Ablauf: Name, E-Mail und Telefonnummer des Gastes werden vorausgefüllt, seine Nachricht wird zum Kundenwunsch-Text (siehe [Kundenwünsche](#kundenw%C3%BCnsche)), und die Konversation wird mit der Anfrage verknüpft, sobald sie erstellt ist. Jede im Interesse-Modus erstellte Anfrage — aus der Liste oder aus dem Postfach — wird als **Anfrage** markiert, demselben **Herkunft**-Badge, das auch Storefront-Anfragen tragen; über den vollständigen Assistenten erstellte Anfragen werden als **Buchung** markiert. Herkunft ist dabei nicht dasselbe wie Status: Eine in der Konsole oder im Postfach erfasste Anfrage startet weiterhin auf **In Bearbeitung**, wie jede andere in der Konsole erstellte Anfrage — **Neue Anfrage** bleibt Anfragen vorbehalten, die über das Buchungsanfrage-Formular des Storefronts eingehen (siehe [Anfrage-Status](#anfrage-status)). Eine ganz ohne Objekt oder Daten erstellte Anfrage ist eine **objektlose Anfrage** — siehe unten. Storefront-**Sofortbuchungen** laufen ebenfalls über die Anfragenliste auf dem Weg zur Buchung, werden aber automatisch veröffentlicht und standardmäßig aus der Liste ausgeblendet — aktiviere **Automatisch veröffentlichte anzeigen** in den Ansichten „Veröffentlicht“ oder „Alle“, um sie zu prüfen. ## Der Anfragen-Editor [Section titled “Der Anfragen-Editor”](#der-anfragen-editor) Die Detailseite einer Anfrage hat die Tabs **Details**, **Konversation** und **Aktivität**. Im Details-Tab arbeitest du mit: * **Aktives Angebot** — die aktuelle Version des Deals: Objekt, Zeitraum (Reise- und Belegungszeitraum), Gäste, Haustiere und die vollständige Preisaufschlüsselung. Ein Badge zeigt, ob die Preisgestaltung **automatisch** (aus aktuellen Objektdaten neu berechnet) oder **benutzerdefiniert** (von Hand gesetzte Positionen) ist. * **Kundeninformation** — Kunde verknüpfen, trennen oder anlegen-und-verknüpfen sowie Kontaktdaten bearbeiten. Ein Banner **Übereinstimmender Kunde gefunden** schlägt einen bestehenden Datensatz vor, wenn die Angaben übereinstimmen. * **Kundenwünsche** — die für diese Anfrage erfassten strukturierten Wünsche (siehe [Kundenwünsche](#kundenw%C3%BCnsche) unten); wird angezeigt, sobald Wünsche erfasst sind, und immer bei [objektlosen Anfragen](#objektlose-anfragen). * **Zahlung** — der Zahlungsmodus, den diese Anfrage nach Veröffentlichung verwendet. Belasse ihn beim Tenant-Standard oder lege einen bestimmten Modus fest. (Nur sichtbar, wenn mehr als ein Modus verfügbar ist.) * **Interne Notizen** — private Notizen, die dem Gast nie angezeigt werden. ## Kundenwünsche [Section titled “Kundenwünsche”](#kundenwünsche) Jedes Feld ist optional — Wünsche sind eine schrittweise Erfassung, kein Formular, das vor dem Weitergehen vollständig ausgefüllt sein muss: * **Reisezeitraum** — früheste Anreise und späteste Abreise. * **Aufenthaltsdauer** — gewünschte Anzahl an Tagen. * **Reisegruppe** — Erwachsene, Kinder, Haustiere. * **Budget** — ein Von-bis-Bereich in der Tenant-Währung. * **Gewünschte Ausstattung** — ausgewählt aus dem Ausstattungskatalog des Tenants. * **Lagewunsch** — Freitext („nahe am See“, ein Regionsname, …). * **Der Kundenwunsch** — seine eigenen Worte, wörtlich aus Anruf, E-Mail oder Kontaktformular. Erfasse sie im **Wünsche**-Schritt des Assistenten oder bearbeite sie später auf der Detailseite der Anfrage über den Stift der Karte **Kundenwünsche** — das Speichern dieser Karte ist unabhängig vom Rest der Anfrage. Die Wünsche fließen in das Angebot ein, das du letztlich erstellst: Wenn du den Schritt **Details & Preisgestaltung** des Assistenten betrittst oder bei einer Interessens-Anfrage **Angebot ausarbeiten** öffnest (bzw. **Neues Angebot** bei einer Anfrage, die schon eines hat), werden Reisegruppengröße, Haustiere und Reisezeitraum übernommen, sofern noch nicht angefasst — der Reisezeitraum beginnt bei der frühesten Anreise und läuft über die gewünschte Zahl Nächte, ersatzweise über das vollständige Fenster früheste–späteste, falls keine Aufenthaltsdauer erfasst wurde. Was du bereits selbst gesetzt hast, wird nie überschrieben, und die Vorbelegung ist nur ein Startpunkt: **Interesse anlegen** speichert allein die Wünsche, nicht die vorbelegten Daten. Während du das Angebot erstellst, bleibt oben im Dialog eine kompakte Wünsche-Zusammenfassung sichtbar, und die Filter der Objektauswahl werden aus denselben Wünschen vorbelegt — Gästezahl, Haustiere erlaubt, gewünschte Ausstattung und das Verfügbarkeitsfenster. Oder erstelle es gar nicht erst von Hand — siehe [Ein Angebot mit KI entwerfen](#ein-angebot-mit-ki-entwerfen) weiter unten. ## Objektlose Anfragen [Section titled “Objektlose Anfragen”](#objektlose-anfragen) Eine über **Interesse erfassen** erfasste Anfrage kann ganz ohne Objekt oder Daten existieren — nur Gast und Wünsche. Bis ein Angebot ihr eines gibt: * Die Detailseite zeigt ein Info-Banner, **„Anfrage — noch keine Unterkunft ausgewählt“**, anstelle der üblichen Warnung zu fehlenden Angaben. * Der Kontextstreifen oben auf der Seite (auf jedem Tab sichtbar) zeigt **„Anfrage — noch keine Unterkunft oder Daten“** statt der Objekt-, Zeitraum- und Gäste-Chips. * Die Karte **Aktives Angebot** zeigt einen Leerzustand, der auf die Angebotserstellung verweist, statt leerer Felder, und die Preiszusammenfassung bleibt verborgen, bis es einen echten Preis zu zeigen gibt. * Das Panel **Angebotsverlauf** zeigt **„Noch kein Angebot ausgearbeitet“** mit einem Button **Angebot ausarbeiten**, und die Kopfzeile der Seite zeigt **Angebot ausarbeiten** anstelle von **Neues Angebot** — beide öffnen denselben Angebotseditor, vorbelegt aus den Wünschen. Das noch nicht ausgearbeitete Angebot der Anfrage erscheint nie als eigenes Angebot, es gibt also nichts versehentlich zu duplizieren. Ein Angebot zu erstellen ist der Weg, wie eine Anfrage ein Objekt und Reisedaten bekommt. Dieses Angebot an den Gast zu senden oder als Buchung zu veröffentlichen braucht Objekt und Daten genau wie bei jeder anderen Anfrage (siehe [Angebote](#angebote)) — nur der Erfassungsschritt ist objektlos. ## Angebote [Section titled “Angebote”](#angebote) Ein **Angebot** ist eine versionierte Momentaufnahme des ausgehandelten Deals (Objekt, Daten, Gäste, Haustiere, Preis), nummeriert wie `BD1001-2`. Du verhandelst nach, indem du neue Angebote erstellst — sobald ein Angebot gesendet wurde, ist es gesperrt und kann nicht mehr bearbeitet werden. Das Panel **Angebotsverlauf** listet sie auf. * **Neues Angebot** erstellt die nächste Version und übernimmt die Angaben der aktuellen. Hat der Gast das aktuelle Angebot bereits angenommen, startet das neue stattdessen als ungesendeter Entwurf, statt zu übernehmen — das angenommene Angebot bleibt der aktive Deal, bis du das neue explizit aktivierst (siehe unten), sodass die Annahme eines Gastes nie stillschweigend durch einen neuen Entwurf verloren geht. Ein ganz neues Angebot übernimmt außerdem, was an [Kundenwünschen](#kundenw%C3%BCnsche) noch nicht durch deine eigenen Änderungen überholt wurde. * **An Kunden senden** sperrt das aktive Angebot, friert seinen Preis ein, sendet dem Gast eine Angebots-E-Mail — mit einem Link zu seiner persönlichen [Gast-Angebotsseite](#der-gast-angebotslink) — und verschiebt die Anfrage auf **Angebot gesendet**. Zum Senden müssen Objekt, Zeitraum und Gäste gesetzt sein, außerdem E-Mail sowie Vor- und Nachname des Gastes (und im benutzerdefinierten Preismodus mindestens eine Preisposition) — bis dahin sind **An Kunden senden** und **Angebot erneut senden** deaktiviert und zeigen per Tooltip, was noch fehlt. Der Sendedialog hat ein optionales Feld **Nachricht an den Kunden** — Freitext, der als hervorgehobener „Nachricht“-Block in der E-Mail erscheint — sowie ein Feld **Gültig für (Tage)** (1–90, Standard 7), das festlegt, wie lange das Angebot gültig bleibt, mit einer Vorschau des resultierenden Ablaufdatums. Ist **Bei Gastannahme automatisch veröffentlichen** aktiv und die Postanschrift des Gastes noch unvollständig, ergänzt der Dialog einen Hinweis, dass ein angenommenes Angebot auf deine manuelle Veröffentlichung wartet. * **Als aktiv setzen** holt ein früher gesendetes Angebot als Arbeitsversion zurück; **Angebot erneut senden** sendet das aktive Angebot erneut (mit einer Warnung, falls es bereits gesendet wurde). Wurde das aktuell aktive Angebot bereits vom Gast angenommen, fragt die Aktivierung eines anderen Angebots stattdessen nach Bestätigung: **„Angebot aktivieren und Annahme widerrufen?“** — die Bestätigung widerruft die Annahme des Gastes und aktiviert das andere Angebot in einem Schritt, sodass eine Annahme durch Wechseln der Angebote nie stillschweigend verwaist. * Der eigene Status eines Angebots durchläuft **Entwurf → Gesendet → Angenommen / Abgelehnt**, sowie **Zurückgezogen** (von dir zurückgezogen) und **Abgelaufen**. Der Ablauf erfolgt entweder, weil du es von Hand als veraltet markierst, oder automatisch, sobald sein Gültigkeitsfenster verstreicht — eine stündliche Prüfung setzt das Angebot auf Abgelaufen und bringt die Anfrage zurück auf **Angebot bereit**, und die Angebotsseite des Gastes behandelt ein überfälliges Angebot bereits vor dieser Prüfung als abgelaufen. Ein gesendetes Angebot zeigt einen Hinweis **Läuft in N Tagen ab**, der sich in eine Überfälligkeits-Warnung verwandelt, wenn die Frist kurz vor der stündlichen Prüfung verstreicht. * Im Panel **Angebotsverlauf** hat jedes Angebot im Entwurfsstatus einen Bearbeiten-Stift — nicht nur das aktive —, während gesendete Angebote ein Schloss-Symbol mit Tooltip zeigen, der dich auf **Neues Angebot** zum Nachverhandeln verweist. Ein ungesendetes, automatisch bepreistes Angebot zeigt eine live geschätzte Gesamtsumme mit dem Präfix **\~** (der endgültige Preis steht erst beim Senden fest), und das aktive Angebot trägt ein eigenes **Aktiv**-Badge neben seinem Status-Badge, unabhängig davon, welcher Status das ist. ### Ein Angebot mit KI entwerfen [Section titled “Ein Angebot mit KI entwerfen”](#ein-angebot-mit-ki-entwerfen) Neben dem manuellen Erstellen verwandelt **Angebot mit KI entwerfen** — neben der Kopfzeile des Panels **Angebotsverlauf** — die [Kundenwünsche](#kundenw%C3%BCnsche) einer Anfrage in einen prüfbereiten Angebotsentwurf. Die Schaltfläche ist verfügbar, solange noch Angebote erstellt werden können (ausgeblendet, sobald die Anfrage **Abgelehnt** oder **Veröffentlicht** ist), braucht zum Suchen aber mindestens erfasste Wünsche oder eigene Kriterien. Der Dialog fragt nach: * **Anzahl Unterkünfte** — wie viele Optionen vorgeschlagen werden sollen, 1–5 (Standard 3). * **Zusätzliche Kriterien** — optionaler Freitext (z. B. „nur Apartments, bevorzugt Meerblick, max. 120 € pro Nacht“). Deine Kriterien haben bei einem Konflikt Vorrang vor den Kundenwünschen. Die KI durchsucht daraufhin deine im Storefront sichtbaren Objekte nach Übereinstimmungen bei Ausstattung, Reisegruppengröße, Haustieren, Budget und dem gewünschten Reisezeitraum — einschließlich der einzelnen freien Zeiträume innerhalb eines flexiblen Fensters, wenn eine Aufenthaltsdauer angegeben wurde —, prüft die tatsächliche Verfügbarkeit und berechnet echte Preise. Anschließend erstellt sie ein normales Angebot im **Entwurfsstatus** mit bis zu der gewünschten Anzahl an Optionen, jede mit kurzem Label und einsätzlicher Begründung, über [alternative Optionen](#alternative-optionen-mehrfachangebote) — genau wie ein von Hand erstelltes Mehrfachangebot. Es wird nie automatisch etwas an den Gast gesendet — du prüfst, bearbeitest und sendest das Ergebnis wie jedes andere Angebot. Das Ergebnis enthält außerdem einen **Nachrichtenvorschlag** in der Kommunikationssprache der Anfrage, mit Kopieren-Button. Er wird nicht auf dem Angebot gespeichert (das Nachrichtenfeld des Angebots wird erst beim Senden befüllt) — füge ihn bei Bedarf im Sendedialog in das Feld **Nachricht an den Kunden** ein. Passt nichts — Budget zu knapp, im Zeitfenster nichts verfügbar, kein Objekt passt zu den Wünschen —, wird kein Angebot erstellt, und der Dialog erklärt stattdessen, warum. Ein paar Dinge macht die KI bewusst nicht: gewünschte Kinder werden dem Angebot nicht automatisch als Gäste hinzugefügt (ihr Alter ist aus den Wünschen nicht bekannt — füge sie selbst hinzu, bevor du sendest), und es werden nur im Storefront sichtbare Objekte berücksichtigt. Jeder Lauf zählt wie jede andere KI-Funktion gegen die KI-Nutzung deines Mandanten — siehe [Kosten und Kontingente](/de/docs/ai/overview/#kosten-und-kontingente). Du kannst denselben Ablauf auch an zwei anderen Stellen starten: * Der **Wünsche**-Schritt des Assistenten **Interesse erfassen** hat eine Checkbox **Nach dem Erstellen ein Angebot mit KI entwerfen** (mit denselben Feldern für Anzahl und Kriterien) — der Lauf startet direkt nach dem Anlegen des Interesses und läuft im **Aktivität**-Tab des Assistenten weiter, während du auf der neuen Anfrage landest. * Bitte den [KI-Assistenten](/de/docs/ai/assistant/), ein Angebot für eine Anfrage zu entwerfen (z. B. „entwirf ein Angebot für BD1042“) und bestätige die angezeigte Vorschlagskarte. ### Alternative Optionen (Mehrfachangebote) [Section titled “Alternative Optionen (Mehrfachangebote)”](#alternative-optionen-mehrfachangebote) Ein Angebot kann dem Gast neben der Hauptoption bis zu **10 Alternativen** präsentieren — nützlich, wenn mehrere Objekte oder Zeiträume infrage kommen. Im Angebots-Editor fügt **Alternative hinzufügen** eine hinzu: jede Alternative hat ein eigenes optionales Label (z. B. „Meerblick, etwas kleiner“), Objekt, Reisedaten und Preis, berechnet auf dieselbe Weise wie das Hauptangebot. Gäste, Haustiere und die Kundennachricht gelten für alle Optionen gemeinsam — nur die Unterkunft selbst variiert zwischen ihnen. Die Angebots-E-Mail listet jede Option auf und verwendet dabei einen eigenen Einleitungstext: **Text (mehrere Optionen)** unter *Einstellungen → Benachrichtigungen*, beim Angebots-Template. Der normale **Text** spricht von einem einzelnen Objekt — typischerweise über die Variable *Objektname*, die immer die Hauptoption benennt — und würde über einer Liste von Alternativen wie eine Zusage für genau dieses eine Objekt wirken. Bleibt das Feld leer, greift ein passender Standardtext im Plural. Der Gast wählt eine Option auf seiner Angebotsseite aus. Welche er wählt, wird zum Deal: Das Angebotsverlauf-Panel der Konsole markiert sie als **Vom Gast gewählt**, und die Veröffentlichung verwendet Objekt, Daten und Preis dieser Option — die nicht gewählten Optionen bleiben zu Referenzzwecken erhalten. Die Verfügbarkeit jeder Option wird live geprüft, wenn der Gast das Angebot ansieht und annimmt, sodass eine Option, deren Daten in der Zwischenzeit anderweitig gebucht wurden, dem Gast als nicht verfügbar angezeigt wird (er kann trotzdem eine der anderen wählen). ## Der Gast-Angebotslink [Section titled “Der Gast-Angebotslink”](#der-gast-angebotslink) Jede gesendete Angebots-E-Mail enthält einen Link zu einer persönlichen, tokenisierten Angebotsseite, auf der der Gast das Angebot direkt annehmen oder ablehnen kann — ohne Antwort-E-Mail. Der Link gehört zur Anfrage, nicht zu einem einzelnen Angebot: verhandle nach und sende ein neues Angebot, und derselbe Link bleibt gültig und zeigt immer das aktuelle aktive Angebot des Gastes. Sobald jemals ein Angebot gesendet wurde, erscheint neben dem Angebot im Details-Tab eine Schaltfläche **Gast-Angebotslink kopieren** — sie bleibt während der Nachverhandlung sichtbar, selbst während du ein neues, ungesendetes Angebot vorbereitest, sodass du den Link jederzeit selbst teilen kannst (Telefon, Chat, ein anderer Kanal), statt darauf zu vertrauen, dass der Gast ihn in seinem Postfach findet. Daneben zeigt ein **Gast-Link**-Badge — **offen / angenommen / abgelehnt / zurückgezogen / abgelaufen / gebucht / in Überarbeitung** — was der Gast gerade sieht, wenn er diesen Link öffnet; **in Überarbeitung** bedeutet, dass das aktive Angebot wieder im Entwurf ist, während du nachverhandelst, sodass die Seite des Gastes noch keinen konkreten Deal zeigen kann. Auf der Angebotsseite sieht der Gast das/die Objekt(e), Daten, Preis, deine persönliche Nachricht und die Ablauffrist und kann: * **Annehmen** — dabei wählt er zunächst eine Alternative, falls das Angebot mehr als eine hat. Die Annahme verschiebt die Anfrage auf **Vom Kunden bestätigt**, sendet dir eine Benachrichtigungs-E-Mail und speichert, welche Option gewählt wurde. * **Ablehnen** — mit einer optionalen Nachricht. Die Ablehnung verschiebt die Anfrage auf **Angebot abgelehnt**, sendet dir eine Benachrichtigungs-E-Mail und legt — wenn der Gast eine Nachricht hinterlassen hat — diese als neue ungelesene Nachricht in die [Postfach-Konversation](/de/docs/communication/inbox/) der Anfrage, genau als hätte er dir eine E-Mail geschickt. Jede Aktion des Gastes erscheint im **Aktivität**-Tab der Anfrage mit **Gast** als Akteur, neben deinen eigenen Aktionen. Wurde eine Annahme irrtümlich erfasst (z. B. eine telefonische Buchung, die der Gast dann auch online bestätigt hat), macht **Annahme widerrufen** im Details-Tab dies rückgängig — das Angebot kehrt zu **Gesendet** zurück und die Anfrage zu **Angebot bereit** — solange die Anfrage noch nicht veröffentlicht wurde. Annahme widerrufen funktioniert auch, wenn das angenommene Angebot nicht mehr das aktive ist — etwa weil ein anderes Angebot aktiviert wurde, nachdem der Gast bereits angenommen hatte. Reynt markiert diesen Zustand mit einem Warnbanner im Details-Tab, da ein verwaistes angenommenes Angebot nicht von selbst reaktiviert oder veröffentlicht werden kann; die eigene Schaltfläche **Annahme widerrufen** des Banners löscht ihn, sodass du mit dem Verhandeln fortfahren kannst. Kein Inventar wird blockiert, während ein Angebot aussteht: Die Daten bleiben für alle anderen buchbar, bis der Gast annimmt (oder du manuell veröffentlichst), und die Verfügbarkeit wird sowohl bei Annahme als auch bei Veröffentlichung erneut geprüft. ## Anfrage-Status [Section titled “Anfrage-Status”](#anfrage-status) Eine Anfrage durchläuft folgende Status (angezeigt als Haupt-Badge): | Status | Bedeutung | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Neue Anfrage** | Eine Storefront-Anfrage, die auf Sichtung wartet. | | **In Bearbeitung** | Du bearbeitest die Anfrage aktiv — Standard für in der Konsole erstellte Anfragen, auch für über **Interesse erfassen** aufgenommene, wünsche-only Anfragen. | | **Angebot bereit** | Ein Angebot ist vorbereitet und bereit zum Senden. | | **Angebot gesendet** | Das Angebot ging an den Gast; wartet auf dessen Antwort. | | **Vom Kunden bestätigt** | Der Gast hat angenommen — [online über seinen Angebotslink](#der-gast-angebotslink) oder du hast eine telefonische Zusage erfasst. Bereit zur Veröffentlichung. | | **Angebot abgelehnt** | Der Gast hat abgelehnt — online, oder du hast es selbst als abgelehnt markiert. | | **Abgelehnt** | Du hast die gesamte Anfrage abgelehnt (kann wiederhergestellt werden). | | **Veröffentlicht** | In eine Buchung umgewandelt. | Aus **Angebot gesendet** kannst du ein Angebot auch selbst **zurückziehen** oder **als abgelaufen markieren**, und ein unbeantwortetes Angebot läuft automatisch ab, sobald sein Gültigkeitsfenster verstreicht — beides bringt die Anfrage zurück auf **Angebot bereit**. **Archivieren** blendet eine Anfrage aus der Standardliste aus, ohne ihren Status zu beeinflussen. ## Eine Anfrage als Buchung veröffentlichen [Section titled “Eine Anfrage als Buchung veröffentlichen”](#eine-anfrage-als-buchung-veröffentlichen) Sobald der Gast zugestimmt hat, veröffentlichst du die Anfrage: * **Als Buchung veröffentlichen** erscheint, wenn das aktive Angebot angenommen und die Anfrage vollständig ist. Für telefonisch vereinbarte Deals übernimmt **Bestätigen & Veröffentlichen** das aktive Angebot und veröffentlicht in einem Schritt. * Die Veröffentlichung braucht alles, was auch zum Senden eines Angebots nötig ist (siehe [Angebote](#angebote)), zusätzlich die vollständige Postanschrift des Gastes. Bis das alles vorliegt, sind beide Schaltflächen deaktiviert und zeigen per Tooltip, was fehlt, und im Details-Tab erscheint eine Warnung **Fehlende Angaben** mit derselben Liste — deren Schaltfläche **Kundendaten vervollständigen** öffnet direkt den Bearbeitungsdialog für Kundeninformationen, wenn ein Gastfeld (Name, E-Mail, Adresse) die Lücke ist. Der automatische Modus berechnet den Preis bei Veröffentlichung neu; der benutzerdefinierte Preismodus benötigt weiterhin einen nicht leeren Preis, der bereits zum Senden erforderlich ist. * Eine Anfrage blockiert ihre Daten nie — überschneiden sie sich in der Zwischenzeit mit einer anderen Buchung oder blockierten Daten, listet eine **Konflikt-Warnung** die Blocker mit Links auf (auch die Anfragenliste markiert betroffene Zeilen). Die Veröffentlichung über einen Konflikt hinweg ist blockiert: Die Veröffentlichung prüft die Verfügbarkeit erneut und lehnt mit *„Diese Daten sind nicht mehr verfügbar“* ab, falls die Daten inzwischen belegt wurden. * Der Veröffentlichungsdialog zeigt den verknüpften Kunden, den effektiven Zahlungsmodus und einen Schalter dafür, ob dem Gast eine Bestätigungs-E-Mail gesendet wird — mit einer optionalen persönlichen **Nachricht an den Kunden**, die in diese E-Mail aufgenommen wird. Ist **Bei Gastannahme automatisch veröffentlichen** aktiviert (Einstellungen → Buchungseinstellungen — siehe [Buchungseinstellungen](/de/docs/bookings/booking-settings/)), veröffentlicht eine Online-Annahme des Gastes die Anfrage automatisch — ohne manuellen Klick auf **Als Buchung veröffentlichen**. Reynt prüft zuerst erneut die Verfügbarkeit; wurden die Daten inzwischen belegt, oder fehlen der Anfrage die für die Veröffentlichung nötigen Gastangaben (E-Mail, Telefon, vollständige Adresse — bei knappen, manuell erstellten Anfragen kann das der Fall sein), bleibt die Anfrage auf **Vom Kunden bestätigt** stehen, damit du sie klärst und von Hand veröffentlichst. Ist die Einstellung deaktiviert (der Standard), wartet jede Annahme — online oder telefonisch — auf deine Veröffentlichung. Bei der Veröffentlichung erstellt Reynt die Buchung (ausstehend oder bestätigt, je nach deiner Auto-Bestätigen-Einstellung), blockiert die Daten, richtet Zahlungen und Rechnungen ein, verknüpft eine eventuelle Postfach-Konversation mit der neuen Buchung und behält die Anfrage als **Veröffentlicht** markiert. Die Kopfzeile der veröffentlichten Anfrage verlinkt zur Buchung (**Veröffentlicht als B-1001**), und die Buchung verlinkt zurück mit **Erstellt aus Anfrage** — der Verhandlungsverlauf ist immer einen Klick entfernt. ## Aktivität und Benachrichtigungen [Section titled “Aktivität und Benachrichtigungen”](#aktivität-und-benachrichtigungen) Der **Aktivität**-Tab der Anfrage protokolliert jede Änderung — Statusübergänge, Angebotsaktionen, Kundenverknüpfungen und E-Mails — gefiltert nach **Alle / E-Mails / Ereignisse**. Die Karte **Benachrichtigungen** bietet manuelle Sendungen dort, wo sie sinnvoll sind, etwa eine **Anfragebestätigung** oder eine **Ablehnungsmitteilung**. Das Senden eines Angebots und die Veröffentlichung senden ihre E-Mails automatisch. Wo immer ein Dialog dem Gast eine E-Mail sendet (Angebot senden, veröffentlichen, ablehnen), enthält er eine optionale Freitext-**Nachricht an den Kunden**, die in der E-Mail dargestellt wird. # Buchungseinstellungen > Buchungsverhalten konfigurieren — Buchungsablauf, automatische Bestätigung, Abschluss, Verfügbarkeitsblockierung, Zeitplanung und die Buchungszusammenfassung-PDF. Das Buchungsverhalten wird unter **Einstellungen → Buchungseinstellungen** (Zahnrad-Symbol) konfiguriert. Diese Seite steuert, wie eingehende Buchungen behandelt werden, deine Standard-Check-in-/Check-out-Zeiten und das Buchungsfenster sowie die Buchungszusammenfassung-PDF. Jede Karte speichert für sich. ## Wie dein Betrieb läuft [Section titled “Wie dein Betrieb läuft”](#wie-dein-betrieb-läuft) Die erste Karte auf der Seite stellt die ganze Frage an einer Stelle: **wie dein Betrieb läuft**. Drei Modelle, jedes als der Weg dargestellt, den eine Buchung darunter tatsächlich nimmt — im selben Wortlaut wie unter *Was mit einer Buchung passiert*. * **Anfrage & Angebot** — Gäste fragen an, du antwortest mit einem Angebot, und kassiert wird erst, wenn du bestätigst. Die klassische Agentur- und Ferienwohnungs-Variante. * **Sofortbuchung, du bestätigst** — deine Website nimmt rund um die Uhr Buchungen an, jede wartet aber weiterhin auf deine Entscheidung. Genau das tut eine schlichte „Sofortbuchung“, wenn die automatische Bestätigung aus ist — also besser bewusst wählen als versehentlich dort landen. * **Sofortbuchung, bestätigt** — gebucht, bestätigt und zahlbar ohne dich. Wählst du ein Modell, zeigt die Karte **was sich dadurch ändert**, bevor etwas gespeichert wird — eine Zeile je Einstellung. Zwei dieser Änderungen solltest du genau lesen: * Alles mit der Markierung **Zahlungseinstellungen** ändert, ab wann Gäste zahlen dürfen; das liegt unter [Wann du kassierst](/de/docs/payments/when-you-collect/). Ein Modell, bei dem du jede Buchung prüfst, gibt die Zahlung erst mit deiner Bestätigung frei — Geld zu verlangen, bevor du entschieden hast, erzeugt vermeidbare Rückerstattungen. * Hast du noch nie eine Zahlungsregel festgelegt, **entsteht** mit dem Anwenden eine, und sie gilt dann für alle Zahlungsarten, statt dass jede ihrem eigenen Zeitpunkt folgt. Die Karte weist vorher darauf hin. Ein Modell ist ein Ausgangspunkt, keine Festlegung. Jede einzelne Einstellung darunter bleibt danach änderbar; die Karte zeigt dann, auf welchem Modell du bist und wie viele Einstellungen du seither geändert hast. Änderst du deinen Buchungsablauf, nachdem deine AGB-Seite erzeugt wurde, wird diese Seite **nicht** umgeschrieben — die Karte warnt dich, und du erzeugst sie neu oder passt die Stelle selbst an. ## Buchungseinstellungen [Section titled “Buchungseinstellungen”](#buchungseinstellungen) Die Hauptkarte steuert, wie Buchungen ihren Lebenszyklus durchlaufen. * **Buchungsablauf** — **Buchungsanfrage** (Standard): eingehende Buchungen starten als ausstehend und warten auf deine Bestätigung oder Ablehnung. **Sofortbuchung** ist die Alternative mit direkter Bestätigung. * **Buchungen automatisch bestätigen** — wenn aktiviert, überspringen Buchungen den ausstehenden Zustand und werden bei Veröffentlichung sofort bestätigt. Lass es deaktiviert, um jede Anfrage von Hand zu prüfen. * **Bei Gastannahme automatisch veröffentlichen** — wenn aktiviert, veröffentlicht die Annahme eines Angebots durch einen Gast auf seiner [Gast-Angebotsseite](/de/docs/bookings/booking-drafts-and-offers/#der-gast-angebotslink) die Anfrage automatisch als Buchung (die Verfügbarkeit wird zuerst erneut geprüft; bei einem Konflikt, oder wenn der Anfrage erforderliche Gastangaben fehlen, bleibt sie auf **Vom Kunden bestätigt** stehen, damit du sie von Hand klärst). Standardmäßig deaktiviert — dann wartet jede Annahme darauf, dass du manuell veröffentlichst. Ist die Postanschrift eines Gastes beim Senden eines Angebots noch unvollständig, weist der Sendedialog vorab darauf hin, dass eine Annahme bei dieser Einstellung eine manuelle Veröffentlichung braucht. Siehe [Anfragen und Angebote](/de/docs/bookings/booking-drafts-and-offers/) für den vollständigen Gast-Annahme-Ablauf. * **Standard-Stornierungsrichtlinie** — die Richtlinie, die für jedes Objekt ohne eigene Richtlinie gilt. Siehe [Stornierungen und Erstattungen](/de/docs/bookings/cancellations-and-refunds/). * **Vorgemerkte Buchungen blockieren Storefront** — wenn aktiviert (Standard), blockiert eine ausstehende Buchung diese Daten im Storefront: die Suche blendet das Objekt aus, der öffentliche Kalender zeigt sie als nicht verfügbar, und überlappende Checkouts werden abgelehnt. Wenn deaktiviert, ignoriert der Storefront ausstehende Buchungen und nimmt weiterhin neue für diese Daten an. In jedem Fall behandelt die Betreiberkonsole ausstehende Buchungen immer als blockierend. * **Buchungen automatisch abschließen** — wenn aktiviert (Standard), wird eine bestätigte Buchung automatisch eine festgelegte Anzahl Tage nach Abreise als abgeschlossen markiert. Deaktiviere es, um für jeden Aufenthalt einen manuellen Abschluss zu verlangen. * **Tage nach Abreise** — wie viele Tage nach der Abreise die automatische Fertigstellung ausgeführt wird (nur sichtbar, wenn die automatische Fertigstellung aktiviert ist). * **Meldeschein (Gästeregistrierung)** und **Länder der Registrierung** — die gesetzliche Gästeregistrierung aktivieren und eingrenzen. Siehe [Meldeschein](/de/docs/bookings/guest-registration/). ## Zeitplanung [Section titled “Zeitplanung”](#zeitplanung) * **Buchungskalender-Zeitfenster** — wie weit im Voraus Gäste buchen können, eingegeben als **Jahre** und **Monate**. Daten außerhalb dieses Fensters sind nicht verfügbar. * **Standard-Check-in-Zeit** und **Standard-Check-out-Zeit** — die Zeiten, die auf Buchungen, E-Mails und PDFs angezeigt werden, sofern eine Buchung sie nicht überschreibt. * **Anreiseinfos vor dem Check-in senden** und **Tage vor Anreise** — schickt jedem bestätigten Gast ein paar Tage vor der Reise Anfahrt, Übergabekontakt und Check-in-Zeit. Standardmäßig aus; siehe [Vor der Anreise](/de/docs/bookings/before-arrival/). ## Buchungszusammenfassung-Vorlagen [Section titled “Buchungszusammenfassung-Vorlagen”](#buchungszusammenfassung-vorlagen) Gestalte die **Buchungszusammenfassung-PDF**, die Gäste erhalten. Der Block-Editor lässt dich Rich-Text-Blöcke mit einem Buchungspreiszusammenfassungs-Block (der die Preistabellen einfügt) und Seitenumbrüchen kombinieren. Füge Buchungsvariablen ein, indem du `$` tippst, und nutze **PDF-Vorschau**, um das Ergebnis vor dem Speichern zu sehen. ## Weitere Karten auf dieser Seite [Section titled “Weitere Karten auf dieser Seite”](#weitere-karten-auf-dieser-seite) Die Seite Buchungseinstellungen enthält auch ein paar angrenzende Einstellungen, die sich auf Buchungen auswirken: * **Haustiere** — ob Haustiere standardmäßig erlaubt sind und die Standard-Haustiergebühr (pro Objekt überschreibbar). * **Gästekategorien** — Altersschwellen für Kinder und Kleinkinder, und welche Kinder kostenlos übernachten. * **Customer booking view** — nur sichtbar, wenn **Einstellungen → Modus der Kunden-Oberfläche** auf **Benutzerdefiniert** steht (du betreibst deinen eigenen Storefront statt des integrierten von Reynt): die Basis-URL deines Storefronts sowie Pfad-Überschreibungen für die kundenseitige Buchungsseite und die [Gast-Angebotsseite](/de/docs/bookings/booking-drafts-and-offers/#der-gast-angebotslink). Bleibt die URL der Angebotsseite leer, lassen Angebots-E-Mails die Annehmen/Ablehnen-Schaltfläche einfach weg (Gäste antworten dann per E-Mail) — trage sie ein, sobald deine eigene Seite eine Angebotsseite hat. Der Abschnitt enthält außerdem die benutzerdefinierten Statusmeldungen, die auf der Buchungsseite angezeigt werden (ausstehend / bestätigt / storniert). Beim integrierten Storefront (Standard) existieren beide Seiten automatisch, und kein Pfad muss konfiguriert werden. Buchungsreferenz-Präfixe und -Nummerierung findest du unter [Rechnungen → Erstellung und Nummerierung](/de/docs/invoices/creation-and-numbering/); die Zeitpunkte der Zahlungsabbuchung findest du unter [Zahlungen](/de/docs/payments/overview/). # Stornierungen und Erstattungen > Definiere Stornierungsrichtlinien mit Erstattungsstufen und storniere eine Buchung mit einer richtliniengesteuerten Erstattungsvorschau. Reynt behandelt Stornierungen in zwei Teilen: **Stornierungsrichtlinien**, die du einmal definierst, und den **Stornierungsablauf** auf einer Buchung, der die passende Richtlinie anwendet und die Erstattung anzeigt, bevor du sie bestätigst. ## Stornierungsrichtlinien [Section titled “Stornierungsrichtlinien”](#stornierungsrichtlinien) Verwalte Richtlinien unter **Einstellungen → Stornierungsrichtlinien**. Jede Richtlinie hat: * **Name** — ein kurzes Label wie *Flexibel* oder *Strikt*. * **Beschreibung** — die vollständigen, dem Kunden im Storefront angezeigten Bedingungen. * **Erstattungsplan** — die strukturierten Stufen. Jede Zeile verknüpft einen Schwellenwert **Tage vor Anreise** mit einem **Erstattungs-%**. Die Stufen sind nach der längsten Vorlaufzeit absteigend sortiert, und jeder Schwellenwert muss eindeutig sein. Zum Beispiel könnte eine *Flexibel*-Richtlinie **100%** bei 7+ Tagen vor Anreise und **50%** bei 1+ Tag erstatten. Storniert ein Gast, gewinnt die erste Stufe, deren Schwellenwert erreicht ist; eine Stornierung innerhalb des kleinsten Fensters bedeutet **0%**. Vorgefertigte **Presets** (Flexibel, Moderat, Strikt) liefern dir einen Ausgangspunkt. Eine Richtlinie **ohne Erstattungsplan** zeigt nur ihre Beschreibung — bei einer Stornierung wird dann der volle bezahlte Betrag erstattet, und der Stornierungsdialog zeigt diesen Betrag in der Vorschau. ### Eine Richtlinie zuweisen [Section titled “Eine Richtlinie zuweisen”](#eine-richtlinie-zuweisen) * **Pro Objekt** — setze **Stornierungsrichtlinie** auf der Fakten-Seite des Objekts, um den Standard für dieses Objekt zu überschreiben. * **Tenant-Standard** — setze **Standard-Stornierungsrichtlinie** unter **Einstellungen → Buchungseinstellungen**; sie gilt für jedes Objekt ohne eigene Richtlinie. ## Eine Buchung stornieren [Section titled “Eine Buchung stornieren”](#eine-buchung-stornieren) Öffne die Buchung und wähle **Buchung stornieren**. Der Dialog führt dich durch: 1. **Was passiert** — die gebuchten Daten werden im Kalender freigegeben, und alle ausstehenden (unbezahlten) Zahlungen werden storniert. Ist bereits Geld eingegangen, wirst du gewarnt, dass Erstattungen möglicherweise bearbeitet werden müssen. 2. **Erstattungsvorschau** — Reynt zeigt die zutreffende Richtlinie und zwei Beträge: die **Erstattung laut Richtlinie** (der Anspruch der Stufe) und **jetzt zu erstatten** (der Betrag, der tatsächlich bewegt wird, gedeckelt auf das, was der Gast gezahlt hat). Im Marktplatz-Modus wird die Erstattung zusätzlich aufgeteilt in das, was der **Betreiber** erstattet, und das, was der **Eigentümer** erstattet. 3. **Grund** — eine Notiz für deine Unterlagen und die Gast-E-Mail. 4. **Benachrichtigung senden** — ob die Stornierungs-E-Mail jetzt rausgeht. ### Die Erstattung anpassen [Section titled “Die Erstattung anpassen”](#die-erstattung-anpassen) * **Volle Erstattung — Verschulden unsererseits** — ein Erstattungsmodus- Schalter oben im Dialog. Wähle ihn, wenn die Stornierung auf dich (oder den Eigentümer) zurückgeht: Die Stufen der Richtlinie werden ignoriert und **100% von allem, was der Gast bezahlt hat**, wird erstattet. Im Marktplatz-Modus erstattet jede Partei genau das, was sie eingenommen hat. Die Wahl wird im Aktivitätsverlauf der Buchung festgehalten. * **Erstattungsbetrag überschreiben** *(nur im Richtlinien-Modus)* — gib einen anderen Betrag ein (bis zum gezahlten Betrag), wenn du mit dem Gast etwas anderes vereinbart hast. Er ersetzt den aus der Richtlinie abgeleiteten Betrag. * **Provisionserstattung %** *(nur Marktplatz)* — eine Dreifach-Wahl aus **Behalten (0%)**, **50/50 teilen** oder **Erstatten (100%)**, die steuert, wie viel deiner Provision mit der Buchung zurückerstattet wird. Bei 100% wird die Provision mit der Buchung erstattet; bei 0% behältst du sie, und der Eigentümer trägt die Erstattung. Dies überschreibt den Standard der Buchung nur für diese Stornierung. Erstattungen werden manuell ausgezahlt, jeweils über die ursprüngliche Zahlungsmethode der Partei. Nach der Stornierung kann die **Buchung-storniert**-E-Mail über die Benachrichtigungen-Karte der Buchung erneut gesendet werden, und die gesamte Stornierung wird im [Aktivitätsverlauf](/de/docs/bookings/lifecycle/) protokolliert. # Gästeregistrierung > Länderspezifische Gästeregistrierung — der deutsche Meldeschein und das österreichische Gästeblatt, erfasst, unterschrieben, gespeichert und gelöscht. Viele Länder verlangen von Beherbergungsbetrieben, für jeden Gast einen unterschriebenen Registrierungsnachweis zu erfassen. Reynt erfasst diesen Nachweis pro Buchung, erstellt die offizielle PDF auf Anfrage und löscht sie automatisch, sobald die gesetzliche Aufbewahrungsfrist endet. Aktuell haben zwei Länder einen zertifizierten Feldsatz: **Deutschland (Meldeschein)** und **Österreich (Gästeblatt)**. Das Feature ist ein *Erfassungs- und Aufbewahrungs*-System: Der Gast füllt ein Formular aus und unterschreibt es, du speicherst es, und du zeigst es den Behörden auf Anfrage. Reynt übermittelt **keine** Daten an ein Behördenportal. ## Aktivieren [Section titled “Aktivieren”](#aktivieren) Die Gästeregistrierung ist standardmäßig deaktiviert. Aktiviere sie unter **Einstellungen → Buchungseinstellungen** (siehe [Buchungseinstellungen](/de/docs/bookings/booking-settings/)): * **Gästeregistrierung (Meldeschein)** — der Hauptschalter. * **Länder der Registrierung** — die Objektländer, für die das Formular gilt. Wähle **DE**, **AT** oder beides. Eine Buchung zeigt ein Formular nur, wenn das Land des zugehörigen Objekts in dieser Auswahl enthalten ist. Das anzuwendende Recht richtet sich nach dem **Land des Objekts**, nicht nach dem des Gastes oder deinem eigenen. Ein deutsches Objekt verwendet immer den Meldeschein; ein österreichisches Objekt immer das Gästeblatt. Eine Buchung für ein Objekt in einem anderen Land (oder ohne gesetztes Land) zeigt nie ein Formular. ## Was jedes Land erfasst [Section titled “Was jedes Land erfasst”](#was-jedes-land-erfasst) | | 🇩🇪 Deutschland — Meldeschein | 🇦🇹 Österreich — Gästeblatt | | ------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Standardfelder | Name, Geburtsdatum, Staatsangehörigkeit, Adresse, An-/Abreise, Unterschrift | Gleich | | Zusätzlich erforderliche Felder | — | Geschlecht und Herkunftsland | | Dokument für ausländische Gäste | Ausweis-/Passnummer | Art, Nummer, Ausstellungsdatum und ausstellende Behörde des Reisedokuments | | Aufbewahrung | 1 Jahr nach Anreise | 7 Jahre nach Einreise | | Dokumententitel | „Besonderer Meldeschein“ | „Gästeblatt“ | Das Formular passt sich automatisch an das Land des Objekts an — du wählst keine Vorlage aus. ## Wie ein Datensatz erfasst wird [Section titled “Wie ein Datensatz erfasst wird”](#wie-ein-datensatz-erfasst-wird) Es gibt zwei Wege, wie die Registrierung einer Buchung ausgefüllt wird: * **Selbsterfassung durch den Gast.** Der Gast öffnet seine Buchungsseite (denselben Link, über den er die Buchung einsieht) und füllt das Formular aus, inklusive einer gezeichneten oder getippten Unterschrift. Ein separater Login ist nicht nötig. * **Erfassung durch dich.** Du kannst den Datensatz selbst über die **Meldeschein**-Karte auf der Buchungs-Detailseite ausfüllen oder vervollständigen. Ein Gast, der das Formular nicht ausgefüllt hat, bekommt **am Tag vor der Anreise eine Erinnerung** mit dem Link dorthin — siehe [Vor der Anreise](/de/docs/bookings/before-arrival/). Sie geht nur an Buchungen, für die die Meldepflicht gilt, und nur solange der Eintrag leer ist. Ein Datensatz durchläuft **Ausstehend** → **Eingereicht** (Angaben erfasst, noch nicht unterschrieben) → **Abgeschlossen** (unterschrieben). Sobald ein Gast einen abgeschlossenen Datensatz unterschrieben hat, kann die Selbsterfassung ihn nicht mehr löschen — die Unterschrift ist der gesetzliche Nachweis. Als Betreiber kannst du ihn weiterhin ändern. ## Die Buchungskarte und die PDF [Section titled “Die Buchungskarte und die PDF”](#die-buchungskarte-und-die-pdf) Jede Buchung, deren Objekt in einem aktivierten Land liegt, zeigt auf ihrer Detailseite eine **Meldeschein**-Karte. Die Karte zeigt den aktuellen Status, stellt die erfassten Felder für dieses Land dar und bietet einen **Meldeschein-PDF herunterladen**-Button — den offiziellen Meldeschein oder das Gästeblatt, inklusive Unterschrift. ## Aufbewahrung und Löschung [Section titled “Aufbewahrung und Löschung”](#aufbewahrung-und-löschung) Jeder Datensatz speichert ein *Aufbewahren-bis*-Datum — Anreise plus das Aufbewahrungsfenster des jeweiligen Landes (1 Jahr für Deutschland, 7 Jahre für Österreich). Eine tägliche Hintergrundaufgabe löscht Datensätze endgültig, sobald dieses Datum verstrichen ist. Du musst dich darum nicht kümmern; es hält dich ohne manuellen Aufwand konform mit den Datenminimierungsregeln. Registrierungsdaten werden verschlüsselt gespeichert und sind nur innerhalb der Konsole lesbar. Das Selbsterfassungsformular für Gäste kann einen Datensatz übermitteln, aber nie die Daten eines anderen Gastes lesen. Note Registrierungsvorschriften — Pflichtfelder, Aufbewahrungsfristen und Fristen — ändern sich mit der Zeit und unterscheiden sich je nach Land. Behandle dieses Feature als praktisches Werkzeug und prüfe die aktuellen gesetzlichen Anforderungen für dein Land. # Lebenszyklus einer Buchung > Die Zustände, die eine Buchung durchläuft, der Lebenszyklus der Reservierung und was du auf der Buchungs-Detailseite siehst. Eine **Buchung** ist eine bestätigte oder ausstehende Reservierung für ein Objekt. Diese Seite beschreibt die Zustände, die eine Buchung durchläuft, wie sie in der Konsole dargestellt wird, und die Karten auf ihrer Detailseite. Angebote und Verhandlungen, bevor eine Buchung existiert, findest du unter [Anfragen und Angebote](/de/docs/bookings/booking-drafts-and-offers/). ## Buchungs-Zustand vs. Lebenszyklus-Status [Section titled “Buchungs-Zustand vs. Lebenszyklus-Status”](#buchungs-zustand-vs-lebenszyklus-status) Jede Buchung hat einen zugrunde liegenden **Zustand** und einen aussagekräftigeren **Lebenszyklus-Status**, den die Konsole als Haupt-Badge anzeigt. Die drei Zustände sind: * **Ausstehend** — wartet auf deine Entscheidung (entsteht durch einen Buchungsanfrage-Ablauf). * **Bestätigt** — verbindlich; die Daten sind im Kalender des Objekts blockiert. * **Storniert** — beendet. Der **Lebenszyklus-Status** zeigt dir, was noch erledigt werden muss: | Status | Bedeutung | | --------------------------- | ----------------------------------------------------------------------------- | | **Wartet auf Entscheidung** | Eine ausstehende Buchung, die du bestätigen oder ablehnen musst. | | **Bevorstehend** | Bestätigt; der Aufenthalt hat noch nicht begonnen. | | **Aktuell vor Ort** | Der Gast ist gerade im Aufenthalt. | | **Wartet auf Abschluss** | Der Aufenthalt ist beendet; als abgeschlossen oder Nichterscheinen markieren. | | **Abgeschlossen** | Abgeschlossen — der Aufenthalt hat stattgefunden. | | **Nicht erschienen** | Abgeschlossen — der Gast ist nie angereist. | | **Storniert** | Vor Abschluss beendet. | ## Buchungsmodi [Section titled “Buchungsmodi”](#buchungsmodi) Wie eine Reservierung entsteht, hängt von zwei unabhängigen Einstellungen ab. **Buchungsablauf** (eingestellt unter **Einstellungen → Buchungseinstellungen**): * **Buchungsanfrage** — ein Checkout im Storefront erzeugt eine *ausstehende* Buchung, die du prüfst. Dies ist die Standardeinstellung. * **Sofortbuchung** — die Alternative mit direkter Bestätigung. Wenn **Buchungen automatisch bestätigen** aktiviert ist, überspringen Buchungen den ausstehenden Zustand und werden bei Veröffentlichung sofort bestätigt — unabhängig vom Ablauf. Siehe [Buchungseinstellungen](/de/docs/bookings/booking-settings/). **Betriebsmodus** — ein Tenant läuft entweder im **Direkt**-Modus (du vermietest deine eigenen Objekte) oder im **Marktplatz**-Modus (du verwaltest Buchungen im Auftrag von Eigentümern und rechnest die Provision mit ihnen ab). Der Marktplatz-Modus fügt Eigentümer-Abrechnungsrechnungen und Zahlungsaufteilungen pro Partei hinzu. ## Abschluss [Section titled “Abschluss”](#abschluss) Wenn das Abreisedatum eines Aufenthalts vergangen ist, wechselt eine bestätigte Buchung zu **Wartet auf Abschluss**. Du löst das mit **Als abgeschlossen markieren** oder **Als Nichterscheinen markieren** auf; ein Fehler lässt sich mit **Buchung wieder öffnen** rückgängig machen. Ist **Buchungen automatisch abschließen** aktiviert, markiert Reynt Aufenthalte automatisch nach einer festgelegten Anzahl Tage nach Abreise als abgeschlossen. ## Reisezeitraum vs. Buchungszeitraum [Section titled “Reisezeitraum vs. Buchungszeitraum”](#reisezeitraum-vs-buchungszeitraum) Reynt unterscheidet zwei Arten, dieselben Daten auszudrücken, jede mit eigenem Symbol: * **Reisezeitraum** (🧳) — Anreise bis **Abreisetag**, gezählt in **Nächten**. Das ist der Aufenthalt des Gastes. * **Buchungszeitraum** (📅) — Anreise bis zum **letzten gebuchten Tag** (die letzte Nacht, in der das Objekt belegt ist), gezählt in **Tagen**. Die Buchungsliste zeigt den Reisezeitraum; die Detailseite zeigt beide. ## Die Buchungs-Detailseite [Section titled “Die Buchungs-Detailseite”](#die-buchungs-detailseite) Öffne eine Buchung, um ihre Detailseite zu erreichen, die drei Tabs hat — **Details**, **Konversation** (der Nachrichtenverlauf mit dem Gast) und **Aktivität**. Der Details-Tab zeigt folgende Karten: * **Buchungsinformationen** — Objekt, Eigentümer, Reise- und Buchungszeitraum, Check-in-/Check-out-Zeiten, Gäste und Haustiere. * **Preisübersicht** — Unterkunft, Zusatzleistungen, Rabatte, Gesamtsumme, Anzahlung sowie eine eventuelle Plattformgebühr und MwSt. * **Stornierungsrichtlinie** — die geltende Richtlinie und die Erstattungsstufen. * **Kunde** — Kontaktdaten des Gastes, Kommunikationssprache und Verknüpfung zu einem gespeicherten [Kundendatensatz](/de/docs/customers-and-owners/customers/). * **Verwaltung** — Kanal-Referenz, voraussichtliche Ankunftszeit, der Buchungsseiten-Zugangslink des Gastes (neu generieren / widerrufen) und interne Notizen. * **Meldeschein** — die Meldeschein-/Gästeblatt-Karte, sofern zutreffend. Siehe [Meldeschein](/de/docs/bookings/guest-registration/). * **Zahlung** — der Zahlungsplan und was jede Partei schuldet oder bereits bezahlt hat. Siehe [Zahlungen](/de/docs/payments/overview/). * **Rechnung** — Kunden- und Eigentümerrechnungen, mit Schaltflächen zum Erstellen. * **Benachrichtigungen** — Gast-E-Mails senden (Buchung erstellt/bestätigt/ storniert, Zahlungsanweisungen). ### Aktivitätsverlauf [Section titled “Aktivitätsverlauf”](#aktivitätsverlauf) Der **Aktivität**-Tab ist ein einziger Prüfprotokoll-Feed mit Filter-Tabs — **Alle**, **Lebenszyklus**, **E-Mails**, **Änderungen** und **Zahlungen** — der jede Statusänderung, gesendete E-Mail, Änderung und Geldbewegung protokolliert, mit wer sie wann vorgenommen hat. ## Kopfzeilen-Aktionen [Section titled “Kopfzeilen-Aktionen”](#kopfzeilen-aktionen) Der Kopfbereich der Detailseite zeigt die für den aktuellen Zustand verfügbaren Aktionen. Solange eine Buchung **ausstehend** ist, stehen **Buchung bestätigen** und **Buchung stornieren** nebeneinander — eine ausstehende Anfrage lehnst du über **Buchung stornieren** ab, eine separate Ablehnen-Aktion gibt es nicht. Der Bestätigungsdialog erlaubt dir, eine optionale persönliche **Nachricht an den Kunden** anzuhängen, die als hervorgehobener Block in der Bestätigungs-E-Mail erscheint. Sobald eine Buchung bestätigt ist, wandert **Buchung stornieren** ins Überlaufmenü als destruktive Aktion, zusammen mit **Entwurf erstellen**, **PDF herunterladen**, **In andere Unterkunft verlegen**, **Buchung archivieren** und **Endgültig löschen**. **Wartet auf Abschluss** zeigt stattdessen **Als abgeschlossen markieren** / **Als Nichterscheinen markieren**, und **Buchung ändern** bleibt durchgehend verfügbar (bis die Buchung storniert ist). Siehe [Buchung ändern](/de/docs/bookings/modify-a-booking/) und [Stornierungen und Erstattungen](/de/docs/bookings/cancellations-and-refunds/) für diese Abläufe. ## Archivierung [Section titled “Archivierung”](#archivierung) **Buchung archivieren** blendet eine Buchung aus der Standardliste aus, ohne sie zu löschen — Kalenderblockierungen, Zahlungen und Rechnungen bleiben unangetastet, und du kannst sie jederzeit **wiederherstellen**. Die Liste hat einen eigenen **Archiviert**-Filter. Dies ist etwas anderes als **Endgültig löschen**, was nur für Buchungen ohne Rechnungen, E-Mails, Zahlungen oder Änderungsverlauf verfügbar ist. # Buchung ändern > Ändere Daten, Gäste oder Preise direkt in der Buchung mit automatischer Abwicklung von Nachforderung/Erstattung, verlege eine Buchung in ein anderes Objekt und weise Eigentümer neu zu. Du kannst eine bestätigte oder ausstehende Buchung direkt ändern. Reynt berechnet den Preis neu, ermittelt die Differenz und gleicht sie automatisch als neue Zahlungsrate oder Erstattung aus — bereits gezahlte Beträge bleiben gesperrt, nur der verbleibende Saldo ist betroffen. Rechnungen werden dabei nicht automatisch angefasst; korrigiere eine bereits ausgestellte Rechnung selbst, falls die Änderung sie betrifft. ## Eine Buchung ändern [Section titled “Eine Buchung ändern”](#eine-buchung-ändern) Öffne die Buchung und wähle **Buchung ändern**. Im Dialog kannst du den **Aufenthaltszeitraum**, **Gäste**, **Haustiere** und die Preisgestaltung (Zusatzleistungen und Positionen) ändern. Das Objekt selbst ist hier fest — um es zu ändern, siehe *Eine Buchung verlegen* weiter unten. Während du bearbeitest, zeigt ein **Vorschau**-Panel den ursprünglichen Gesamtbetrag, den neuen Gesamtbetrag und die Differenz: * **Zusätzlicher Betrag** — eine **Nachzahlung**-Rate wird für den Mehrbetrag hinzugefügt; erfasse sie wie jede andere Zahlung (siehe [Wie Zahlungen funktionieren](/de/docs/payments/overview/)). * **Erstattung** — eine Erstattungsverpflichtung wird für die Differenz erfasst. War dieser Betrag noch nicht bezahlt, ist es einfach eine Gutschrift — der geschuldete Betrag sinkt, es gibt nichts zurückzusenden. Nur der Anteil, den der Gast tatsächlich bezahlt hatte, wird zu einer echten Auszahlung, die du von Hand abgleichst (siehe [Teilzahlungen und Erstattungen](/de/docs/payments/partial-payments-and-refunds/)). Du musst einen Grund angeben und eine Bestätigung anhaken, bevor du übernimmst. * **Keine Änderung** — es wird nichts berechnet oder erstattet. In keinem der beiden Fälle wird eine Rechnung angefasst — Rechnungsstellung bleibt manuell. Hat die Buchung bereits eine ausgestellte Rechnung, korrigiere sie selbst (eine Gutschrift bei einer Abwärts-Änderung, eine neue Rechnung für den Mehrbetrag). ### Hinweis zur Preisänderung [Section titled “Hinweis zur Preisänderung”](#hinweis-zur-preisänderung) Reicht dein neuer Zeitraum über die Daten hinaus, gegen die die Buchung ursprünglich bepreist wurde, zeigt Reynt einen Hinweis **Aktuelle Preise verwendet** — der neue Gesamtbetrag verwendet die heutigen Objektpreise statt der zum Buchungszeitpunkt eingefrorenen Preise. Änderungen innerhalb der ursprünglichen Daten behalten die ursprünglichen Preise bei. ### Teilstornierungen [Section titled “Teilstornierungen”](#teilstornierungen) Eine Änderung, die die Buchung nur *verkleinert* (weniger Nächte, weniger Gäste), wird als **Teilstornierung** erfasst und erzeugt eine Erstattung über denselben Ablauf — es gibt dafür keinen separaten Bildschirm. ### Benutzerdefinierte Preisgestaltung [Section titled “Benutzerdefinierte Preisgestaltung”](#benutzerdefinierte-preisgestaltung) Wenn der automatische Preis nicht das ist, was du willst, aktiviere **Gesamtbetrag manuell überschreiben**, um eigene Positionen und einen eigenen Gesamtbetrag einzugeben. Reynt speichert genau das, was du festlegst, statt neu zu berechnen. ### Provisionserstattung *(Marktplatz)* [Section titled “Provisionserstattung (Marktplatz)”](#provisionserstattung-marktplatz) Führt eine Änderung zu einer Erstattung bei einer Buchung mit Provision, erscheint dieselbe **Provisionserstattung %**-Auswahl wie bei Stornierungen — **Behalten**, **50/50 teilen** oder **Erstatten** — die steuert, wie viel Provision zurückerstattet wird. Sie überschreibt den Standard der Buchung nur für diese Änderung. ### Verlauf und Benachrichtigungen [Section titled “Verlauf und Benachrichtigungen”](#verlauf-und-benachrichtigungen) Jede Änderung wird in den **Aktivität**-Verlauf der Buchung als Änderungshistorie-Eintrag geschrieben, mit Zeitraum und Gesamtbetrag vor/nach der Änderung, der Differenz und wer die Änderung vorgenommen hat. Eine **Buchung-geändert**-E-Mail kann beim Übernehmen gesendet werden, oder später aus dem Verlauf gesendet und erneut gesendet werden. ## Eine Buchung in ein anderes Objekt verlegen [Section titled “Eine Buchung in ein anderes Objekt verlegen”](#eine-buchung-in-ein-anderes-objekt-verlegen) Über das Überlaufmenü der Buchung überträgt **In andere Unterkunft verlegen** eine ausstehende oder bestätigte Buchung auf ein anderes Objekt. Du wählst, wie sie bepreist wird: * **Aktuellen Preis beibehalten** — der vereinbarte Gesamtbetrag bleibt bestehen; keine Erstattung oder Nachforderung. Künftige Änderungen werden gegen das neue Objekt bepreist. * **Gegen neue Unterkunft neu berechnen** — der Gesamtbetrag wird zu den Preisen des neuen Objekts neu berechnet, und die Differenz wird wie bei einer Änderung erstattet oder nachgefordert. Nur infrage kommende Objekte werden angeboten. Eine Verlegung setzt voraus, dass das Ziel **denselben Eigentümer**, **dasselbe Land** und **dieselbe Währung** hat. Im Modus *Preis beibehalten* muss außerdem die erhobene **Kurtaxe** unverändert bleiben — wechsle zur Neuberechnung, falls sie abweichen würde. Bevor du bestätigst, zeigt Reynt eine Vorschau eventueller Kalenderkonflikte, Hausregel-Probleme (Aufenthaltsdauer, Gästeobergrenzen) sowie Unterschiede bei Stornierungsrichtlinie oder Kaution. Eine Verlegung mit Neuberechnung gleicht die Differenz genauso aus wie eine Änderung (eine Nachzahlung-Rate oder eine Erstattungsverpflichtung), fasst aber keine bereits ausgestellte Rechnung an — korrigiere sie von Hand, falls der neue Gesamtbetrag sie veralten lässt. ## Eigentümer neu zuweisen *(Marktplatz)* [Section titled “Eigentümer neu zuweisen (Marktplatz)”](#eigentümer-neu-zuweisen-marktplatz) Wechselt ein Objekt den Besitzer, kannst du dessen bestehende Buchungen zu einem neuen Eigentümer verschieben. Das findest du auf der **Eigentümer-Seite des Objekts**, nicht bei einzelnen Buchungen: öffne das Objekt, gehe zu **Eigentümer**, und nutze **Buchungen übertragen**. Ein kurzer Assistent lässt dich den neuen Eigentümer auswählen, festlegen, welche aktiven Buchungen verschoben werden sollen, und optional diesen Eigentümer zum Standard für künftige Buchungen machen. Buchungen, die bereits an den aktuellen Eigentümer **bezahlt** wurden, können nicht neu zugewiesen werden — sie zeigen ein **Bezahlt**-Badge und müssen zuerst abgerechnet oder erstattet werden. Die Neuzuweisung aktualisiert den Eigentümer jeder Buchung und erstellt die betroffenen Eigentümer-Abrechnungsrechnungen neu. # Katalog-Übersicht > Definiere Ausstattung, Attribute, Tags, Objekttypen, Reiseziele und Entfernungen einmal und nutze sie in jedem Objekt wieder. Im Katalog definierst du die Bausteine, die deine Objekte wiederverwenden — Ausstattung, Attribute, Tags, Objekttypen, Reiseziele und Entfernungstypen. Du erstellst jeden Eintrag einmal, und er steht dann zur Zuweisung an jedes Objekt bereit. Ein gemeinsamer Katalog sorgt für einheitliche Bezeichnungen, Icons und Übersetzungen in deinem gesamten Portfolio. ## Die Katalogseiten [Section titled “Die Katalogseiten”](#die-katalogseiten) Jeder Katalogtyp hat seine eigene Seite, gesammelt unter **Einstellungen → Kataloge**: * **Ausstattung** — Merkmale, die eine Unterkunft bietet (WLAN, Pool, Parkplatz). * **Attribute** — typisierte Fakten über eine Unterkunft (siehe [Ausstattung, Attribute und Tags](/de/docs/listings/amenities-attributes-and-tags/)). * **Tags** — freie Bezeichnungen, die als Filter-Pills im Storefront genutzt werden. * **Objekttypen** — Wohnung, Haus, Villa und so weiter. Siehe [Objekttypen](/de/docs/catalog/property-types/). * **Reiseziele** und **Entfernungen** — Gebiete und Sehenswürdigkeiten. Siehe [Reiseziele und Entfernungen](/de/docs/catalog/places-and-distances/). Ausstattung, Attribute, Tags und Entfernungen sind einfache Listen: Jeder Eintrag hat eine ID, eine sprachspezifische Bezeichnung bzw. einen Namen, ein Icon und (wo relevant) ein **sichtbar**- oder **durchsuchbar**-Flag, das steuert, ob der Eintrag im Storefront angezeigt wird. Du fügst Einträge direkt auf der Seite hinzu, bearbeitest oder löschst sie. ## Der globale Katalog [Section titled “Der globale Katalog”](#der-globale-katalog) Statt jede Ausstattung von Grund auf einzutippen, kannst du aus Reynts **globalem Katalog** schöpfen — einer kuratierten, professionell übersetzten Bibliothek, die plattformweit geteilt wird. Auf den Seiten **Ausstattung**, **Attribute** und **Entfernungen** findest du zwei Buttons: * **Aus Katalog hinzufügen** — durchsuche die globale Bibliothek, wähle die zu deinem Geschäft passenden Einträge aus und importiere sie. Jeder Import wird zu einer **verknüpften Kopie**: Du kannst sie bearbeiten, aber ihre zusätzlichen Sprachbezeichnungen und die Standardbeschreibung kommen weiterhin aus dem Katalog, sofern du sie nicht überschreibst. Importierte Einträge tragen ein kleines **Katalog**-Badge. * **Mit Katalog verknüpfen** — du hast bereits eine eigene Liste erstellt? Beim Verknüpfen werden deine bestehenden Einträge mit dem globalen Katalog abgeglichen, sodass sie dessen mehrsprachige Bezeichnungen und Beschreibungen erhalten, während deine eigenen Bezeichnungen als Überschreibung erhalten bleiben. Wenn du einen verknüpften Eintrag bearbeitest, erbt jede Sprachbezeichnung oder Beschreibung, die du leer lässt, aus dem Katalog; alles, was du ausfüllst, überschreibt sie. ## KI-Katalogauswahl [Section titled “KI-Katalogauswahl”](#ki-katalogauswahl) Beide Abläufe sind KI-unterstützt: * Bei **Aus Katalog hinzufügen** wählt **Für mein Geschäft vorschlagen** die für deine Unterkünfte relevantesten Katalogeinträge vorab aus, damit du nicht die ganze Bibliothek durchsuchen musst. * Bei **Mit Katalog verknüpfen** analysiert Reynt deine bestehenden Einträge und schlägt Übereinstimmungen vor — gekennzeichnet als exakte Übereinstimmung oder KI-Übereinstimmung —, die du prüfen und bestätigen kannst. Siehe [KI-Übersicht](/de/docs/ai/overview/) für die Funktionsweise der KI-Funktionen in der gesamten Konsole. ## Icons und KI-Icon-Vorschläge [Section titled “Icons und KI-Icon-Vorschläge”](#icons-und-ki-icon-vorschläge) Ausstattung, Attribute, Objekttypen und Entfernungen erhalten jeweils ein **Icon**, das aus einem durchsuchbaren Icon-Auswähler gewählt wird. Sobald der Eintrag bereits einen Namen hat, bietet der Auswähler einen **Mit KI vorschlagen**-Button, der passende Icons für dich vorschlägt — eine schnelle Möglichkeit, jedem Katalogeintrag ein einheitliches, wiedererkennbares Symbol im Storefront zu geben. # Reiseziele und Entfernungen > Organisiere Objekte nach Reisezielen und beschreibe die Nähe zu Sehenswürdigkeiten mit Entfernungstypen. Zwei Katalogtypen kümmern sich um den Standort: **Reiseziele** gruppieren deine Objekte geografisch, und **Entfernungen** beschreiben, wie nah eine Unterkunft an Sehenswürdigkeiten liegt. ## Reiseziele [Section titled “Reiseziele”](#reiseziele) Ein Reiseziel ist ein benanntes Gebiet, dem Objekte zugeordnet werden können — **in beliebiger Größenordnung**. Es muss keine Stadt sein: Land, Region, Küste, See, Insel, Tal, Gebirge, Nationalpark, Stadt und Stadtteil sind alle zulässige Typen. „Bodensee“, „Costa del Sol“ und „Allgäu“ sind genauso gültige Reiseziele wie „Konstanz“. Reiseziele sind hierarchisch organisiert, sodass du einen Stadtteil unter einer Stadt unter einer Region verschachteln kannst. Das ist der eigentliche Nutzen: Ein Objekt unter „Altstadt“ wird automatisch auch gefunden, wenn ein Gast nach „Konstanz“ oder „Bodensee“ sucht. Im Storefront helfen Reiseziele Gästen, von grob nach spezifisch zu stöbern — und die oberste Ebene bildet standardmäßig auch die Storefront-Navigation. Verwalte sie auf der Seite **Reiseziele**, die ein Sidebar-Layout nutzt: Reiseziele werden links aufgelistet, und die Auswahl eines Reiseziels öffnet rechts sein Detailpanel. Erstelle oder bearbeite ein Reiseziel im Editor, in dem du Folgendes festlegst: * **Typ** — die Größenordnung (Land, Region, Küste, See, Stadt, Stadtteil …). Es gibt bewusst keine Vorauswahl: Der Typ steuert unter anderem, wie weit die Storefront-Karte herauszoomt, wenn ein Gast das Reiseziel wählt. * **Name** — die Bezeichnung des Reiseziels (pro Sprache). * **Koordinaten** — ein optionaler Breiten-/Längengrad. Gemeint ist der Mittelpunkt des Gebiets, nicht eine Hausadresse. * **Auf Karte anzeigen** — ob das Reiseziel auf der Storefront-Karte eingezeichnet wird. * **Beschreibung** — eine optionale Rich-Text-Beschreibung (pro Sprache), die im Storefront auf den Objektseiten dieses Gebiets angezeigt wird. * **Übergeordnet** — das Reiseziel, dem dieses untergeordnet ist, wodurch die Hierarchie aufgebaut wird. Jedes Reiseziel zeigt an, wie viele Objekte ihm zugewiesen sind. Ein Objekt wird immer dem **spezifischsten** passenden Reiseziel zugewiesen — die übergeordneten ergeben sich automatisch. Nutze dafür den Bereich **Standort** in der Objekt-Detailansicht, der auch die eigenen Koordinaten und die Postanschrift des Objekts enthält; die gehören zum Objekt, nicht zum Reiseziel. ### KI-Reiseziel-Koordinaten [Section titled “KI-Reiseziel-Koordinaten”](#ki-reiseziel-koordinaten) Von der Seite **Reiseziele** aus kannst du eine KI-Aktion ausführen, die automatisch Koordinaten für deine Reiseziele ermittelt und dir so das manuelle Nachschlagen von Breiten- und Längengraden erspart. Siehe [KI-Übersicht](/de/docs/ai/overview/). ## Entfernungen [Section titled “Entfernungen”](#entfernungen) Ein Entfernungstyp ist eine Kategorie für die Nähe zu Sehenswürdigkeiten — „Strand“, „Flughafen“, „Stadtzentrum“, „Skilift“. Du definierst die *Typen* im Katalog; die tatsächliche Entfernung für jede Unterkunft wird pro Objekt eingetragen. Verwalte die Typen auf der Seite **Entfernungen**. Jeder Entfernungstyp hat: * **ID** — einen URL-freundlichen Bezeichner. * **Bezeichnung** — den Anzeigenamen (pro Sprache). * **Icon** — das daneben angezeigte Symbol. * **Durchsuchbar** — ob diese Entfernung zu einem Storefront-Suchfilter wird. Wie Ausstattungsmerkmale können Entfernungstypen aus dem [globalen Katalog](/de/docs/catalog/overview/#der-globale-katalog) importiert oder mit ihm verknüpft werden. ### Entfernungen bei einem Objekt [Section titled “Entfernungen bei einem Objekt”](#entfernungen-bei-einem-objekt) Im Bereich **Entfernungen** eines Objekts erfasst du die tatsächlichen Werte: Wähle einen Entfernungstyp aus und trage ein, wie weit die Unterkunft davon entfernt ist (z. B. 500 m zum Strand), oder füge eine einmalige, nur für dieses Objekt geltende Entfernung hinzu. Als **durchsuchbar** markierte Entfernungstypen erlauben es Gästen, im Storefront nach Nähe zu filtern — siehe [Suche und Karten](/de/docs/storefront/search-and-maps/). # Objekttypen > Eingebaute und benutzerdefinierte Objekttypen und wo sie in Objekten und der Kurtaxe verwendet werden. Ein Objekttyp klassifiziert ein Objekt — Wohnung, Haus, Villa und so weiter. Reynt liefert eine Reihe eingebauter Typen mit, und du kannst auf der Katalogseite **Objekttypen** eigene definieren. ## Eingebaute Typen [Section titled “Eingebaute Typen”](#eingebaute-typen) Jeder Mandant startet mit einem Standardsatz an Objekttypen: Haus, Wohnung, Villa, Hütte, Eigentumswohnung, Cottage, Bungalow, Chalet, Reihenhaus, Loft, Studio und *Sonstiges*. Diese sind immer verfügbar — du musst sie nicht erstellen. ## Benutzerdefinierte Objekttypen [Section titled “Benutzerdefinierte Objekttypen”](#benutzerdefinierte-objekttypen) Wenn die eingebaute Liste eine von dir genutzte Kategorie nicht abdeckt, füge auf der Seite **Objekttypen** einen eigenen hinzu. Jeder benutzerdefinierte Typ hat: * **ID** — einen URL-freundlichen Bezeichner. * **Bezeichnung** — den Anzeigenamen (pro Sprache). * **Icon** — ein optionales Symbol, mit KI-Icon-Vorschlägen, sobald die Bezeichnung gesetzt ist. Benutzerdefinierte Typen stehen überall dort neben den eingebauten zur Auswahl, wo ein Objekttyp gewählt wird. Bearbeite oder lösche sie auf derselben Seite. ## Wo Objekttypen verwendet werden [Section titled “Wo Objekttypen verwendet werden”](#wo-objekttypen-verwendet-werden) Der Objekttyp eines Objekts wird in seinem Bereich **Objektdaten** festgelegt (siehe [Inhalt und Medien](/de/docs/listings/content-and-media/#objektdaten)). Objekttypen dienen nicht nur der Beschriftung des Objekts, sondern steuern auch: * **Kurtaxe-Regeln** — wenn du die Kurtaxe (Tourismusabgabe) konfigurierst, kannst du unterschiedliche Sätze pro Objekttyp festlegen, sodass eine Wohnung und eine Villa unterschiedlich besteuert werden können. Siehe [Steuern](/de/docs/invoices/taxes/). * **Filterung in der Konsole** — der Objekttyp ist einer der Filter in der Liste **Objekte** und hilft dir, ein großes Portfolio einzugrenzen. Da benutzerdefinierte Typen sowohl das Objektformular als auch die Kurtaxe-Stufen speisen, aktualisiert das Hinzufügen oder Umbenennen eines Typs die Auswahlmöglichkeiten an beiden Stellen. # E-Mail-Bestätigungssperre > Automatische Gast- und Eigentümer-E-Mails vor dem Versand zur Prüfung im Mail-Ausgang zurückhalten. Die **E-Mail-Bestätigungssperre** lässt dich automatische E-Mails prüfen, bevor sie einen Gast erreichen. Ist sie aktiviert, sendet Reynt eine Buchungsbestätigung, Zahlungsanweisung oder eine andere von dir ausgelöste Kunden- oder Eigentümer-E-Mail nicht sofort, sondern rendert sie und legt sie zuerst im **Mail-Ausgang** ab. E-Mails, die etwas bestätigen, das der Gast gerade selbst getan hat, werden nie zurückgehalten – siehe [Was gehalten wird und was nicht](#was-gehalten-wird-und-was-nicht). Sie ist ein Sicherheitsnetz – nützlich, während du Vorlagen einrichtest, Daten importierst oder einfach möchtest, dass ein Mensch jede Gast-E-Mail vor dem Versand überprüft. ## Aktivieren [Section titled “Aktivieren”](#aktivieren) Aktiviere sie unter **Einstellungen → E-Mail-Zustellung** → **E-Mail-Bestätigungssperre** (“Automatische E-Mails vor dem Versand zur Prüfung zurückhalten”). Es ist ein Schalter pro Tenant und standardmäßig deaktiviert. Schaltest du sie aus, werden automatische E-Mails wieder sofort versendet. ## Was danach passiert [Section titled “Was danach passiert”](#was-danach-passiert) Ist die Sperre aktiv, entscheidest du, wie eine zurückgehaltene E-Mail aufgelöst wird: * **Auf mich warten** – es geht nichts raus, bis du es im Mail-Ausgang sendest. Die sicherste Einstellung und der richtige Anfang. Der Preis: Jede automatische E-Mail wird zur Aufgabe – arbeitet niemand den Mail-Ausgang ab, hören deine Gäste nichts. * **Nach einer Wartezeit senden** – die E-Mail versendet sich selbst, sobald die Wartezeit um ist (standardmäßig 15 Minuten, einstellbar von 1 Minute bis 24 Stunden). Du bekommst sofort beim Zurückhalten eine Benachrichtigung, mit Zeit zum Draufschauen und – falls etwas nicht stimmt – zum Zurückhalten. Die zweite Variante passt besser, sobald sich deine Vorlagen eingespielt haben. Sie macht aus der Sperre statt einer Freigabe-Warteschlange ein Zeitfenster zum Eingreifen: Im Normalfall musst du nichts tun und bekommst den Ausnahmefall trotzdem noch zu fassen. Die sinnvolle Aktion in diesem Fenster ist **Zurückhalten**, nicht Senden – die E-Mail wäre ohnehin rausgegangen. Zurückhalten stoppt die Uhr für genau diese E-Mail, die dann auf dich wartet wie im Modus “Auf mich warten”. Du musst also nur entscheiden, *dass* eine E-Mail einen genaueren Blick braucht – nicht schon innerhalb der Wartezeit fertig hinschauen. Caution Im Modus “Nach einer Wartezeit senden” hängt die Freigabe an einem Hintergrund-Task. Stoppt der, geht verzögerte Post nicht mehr raus – und weil niemand auf eine Freigabe wartet, fällt die Stille leicht nicht auf. Melden Gäste, dass keine E-Mails ankommen, sieh im Mail-Ausgang nach, ob sich dort E-Mails über ihrer Sendezeit stapeln. ## Was gehalten wird und was nicht [Section titled “Was gehalten wird und was nicht”](#was-gehalten-wird-und-was-nicht) Nur E-Mails, die **du in Gang setzt**, werden zurückgehalten – eine Buchungsbestätigung, eine Stornierung, eine abgelehnte Anfrage, ein Angebot, eine Änderung. Diese *nicht* zurückgehalten werden: * **Bestätigungen für etwas, das der Gast gerade getan hat** – die Bestätigung einer Buchungsanfrage, einer Anfrage, einer Kontaktformular-Nachricht oder einer eingegangenen Zahlung. Der Gast wartet in diesem Moment darauf, und eine fehlende Antwort wirkt wie “das Formular hat nicht funktioniert” – sie geht deshalb immer sofort raus. * **Sofortbuchungen** – steht dein Buchungsablauf auf *sofort*, bestätigt sich eine Storefront-Buchung selbst und ihre Bestätigung geht direkt an den Gast. Eine Prüfung würde bedeuten, dass der Gast, der gerade gezahlt hat, nichts hört. * **Deine Posteingang-Antworten** – vom Betreiber geschriebene Antworten aus dem [Posteingang](/de/docs/communication/inbox/) werden in Echtzeit versendet. * **Team-Benachrichtigungen** – Buchungsanfrage- und Kontaktformular-Alerts an deinen eigenen Posteingang. * **Test-E-Mails** – die “Test senden”-Buttons im Benachrichtigungen-Hub. Eine automatische E-Mail, die im [Benachrichtigungen](/de/docs/communication/notifications-and-email/)-Hub deaktiviert ist, wird von vornherein nie erzeugt und erreicht daher nie den Ausgang – die Präferenzprüfung erfolgt vor der Sperre. ## Der Mail-Ausgang [Section titled “Der Mail-Ausgang”](#der-mail-ausgang) Öffne **Mail-Ausgang** in der Haupt-Seitenleiste – er erscheint dort nur, während die Bestätigungssperre aktiv ist. Er listet jede zurückgehaltene E-Mail mit Typ, Empfänger, Betreff und – im Modus “Nach einer Wartezeit senden” – dem Sendezeitpunkt auf. Steht in einer Zeile **Wartet auf dich**, läuft für sie keine Uhr: Entweder bist du im Modus “Auf mich warten”, oder jemand hat diese E-Mail zurückgehalten. Für jede Zeile kannst du: * **Vorschau** – die genaue gerenderte E-Mail öffnen, die du versenden willst. * **Senden** – sie unverändert an den Empfänger versenden. * **Zurückhalten** – den automatischen Versand stoppen, sodass sie auf dich wartet. Wird nur angezeigt, solange tatsächlich ein Versand geplant ist, und lässt sich mit “Senden” wieder aufheben. * **Verwerfen** – sie abbrechen; sie wird nie versendet (das kann nicht rückgängig gemacht werden). Bei einem Rückstau wirken **Alle bestätigen** und **Alle verwerfen** auf alle wartenden E-Mails gleichzeitig. Schlägt ein Versand fehl, bleibt die E-Mail ausstehend, sodass du es erneut versuchen kannst. Der Navigationseintrag **Mail-Ausgang** zeigt ein Badge mit der Anzahl wartender E-Mails, und die Benachrichtigungsglocke in der oberen Leiste zeigt dieselbe Anzahl, damit zurückgehaltene Mails nicht vergessen werden. Sobald eine E-Mail aus dem Ausgang versendet wurde, wird sie wie jede andere ausgehende Mail in den [E-Mail-Protokollen](/de/docs/communication/mail-logs/) erfasst. # Posteingang > Ein gemeinsamer Posteingang für Gästekonversationen – per E-Mail antworten, zuweisen, zurückstellen und eine Nachricht in eine Buchungsanfrage umwandeln. Der **Posteingang** ist dein gemeinsamer Team-Posteingang für die Gästekommunikation. Jede Nachricht – die automatischen E-Mails, die Reynt sendet, und die menschlichen Antworten, die zurückkommen – lebt in einer einzigen Timeline, verankert an der Buchung oder Anfrage, um die es geht. Öffne ihn über **Posteingang** in der Haupt-Seitenleiste. ## Die Konversationsliste [Section titled “Die Konversationsliste”](#die-konversationsliste) Die linke Seitenleiste listet Konversationen, neueste Aktivität zuerst, mit einem Ungelesen-Punkt und einem Status-Badge an jeder. Filtere die Liste nach: * **Status** – offen, wartend, zurückgestellt oder geschlossen. * **Zugewiesen an** – mir zugewiesen, nicht zugewiesen, oder einem bestimmten Teammitglied. * **Kanal** – E-Mail oder Kontaktformular. * **Nur ungelesene**. Weil Nachrichteninhalte verschlüsselt gespeichert werden, filtert der Posteingang statt einer Volltextsuche; du kannst aber weiterhin nach dem Klartext-Betreff filtern. ## Der Thread [Section titled “Der Thread”](#der-thread) Wähle eine Konversation aus, um ihre Timeline rechts zu öffnen. Gast- und Betreiber-Nachrichten werden als Chat-Blasen dargestellt; die automatischen E-Mails, die Reynt gesendet hat (Buchung bestätigt, Zahlungsanweisungen und so weiter), erscheinen als kompakte Systemzeilen mit einem Zustellungs-Badge. Ein **Kontext**-Panel verlinkt die Konversation mit ihrer Buchung, Anfrage oder ihrem Kunden und zeigt das Wesentliche (Objekt, Daten, Gäste, Gesamtbetrag, Zahlungsstatus), sodass du antworten kannst, ohne die Seite zu verlassen. Enthielt die E-Mail eines Gastes Anhänge, zeigt jede Nachricht sie mit einem **Herunterladen**-Button. Anhänge werden sicher gespeichert und über die Konsole heruntergeladen, nie als öffentliche Links offengelegt. ## Antworten [Section titled “Antworten”](#antworten) Tippe deine Antwort in den Composer und drücke **Senden** – sie wird in Echtzeit an den Gast gemailt (der Composer zeigt genau, an welche Adresse). Eine Antwort wird nie von der [Bestätigungssperre](/de/docs/communication/email-confirmation-gate/) zurückgehalten; die gilt nur für automatische Mails. Der Composer bietet dir außerdem: * **Interne Notiz** – aktiviere dies, um eine Notiz an der Konversation zu hinterlegen, die *nie* an den Gast gesendet wird, nur für dein Team. * **Textbaustein** – füge ein wiederverwendbares Snippet ein (siehe unten). * **Mit KI entwerfen** und **Überarbeiten** – optionale KI-Hilfe, die nur den Composer befüllt; du prüfst und versendest immer selbst. Das Entwerfen basiert auf der echten Buchung, es zitiert also die tatsächlichen Daten und Preise. Siehe [KI-Übersicht](/de/docs/ai/overview/). Reynt kann Antworten auch von sich aus vorbereiten (oder senden), sobald ein Gast schreibt, statt zu warten, bis du danach fragst. Das ist standardmäßig aus — siehe [KI-Antworten an Gäste](/de/docs/ai/guest-replies/). Hat ein Thread keine Antwortadresse (eine anonyme Kontaktformular-Nachricht ohne erfasste E-Mail), können nur interne Notizen hinzugefügt werden. ## Eingehende Antworten [Section titled “Eingehende Antworten”](#eingehende-antworten) Damit Gastantworten wieder in den Posteingang einlaufen, aktiviere **Eingehende E-Mail-Antworten** unter **Einstellungen → E-Mail-Zustellung**. Ist es aktiv, tragen ausgehende Kunden-E-Mails eine spezielle Reynt-Antwortadresse, sodass die Antwort eines Gastes automatisch in der richtigen Konversation landet, wenn er einfach auf “Antworten” klickt. Ist es deaktiviert, gehen Antworten an deine normale Antwortadresse und werden hier nicht erfasst. Dies wird in [Benachrichtigungen und E-Mail](/de/docs/communication/notifications-and-email/) behandelt. ## Zuweisen, zurückstellen und erledigen [Section titled “Zuweisen, zurückstellen und erledigen”](#zuweisen-zurückstellen-und-erledigen) Behandle den Posteingang wie ein Helpdesk: * **Zuweisen** einer Konversation an dich selbst oder ein beliebiges Teammitglied. * **Zurückstellen** bis später (morgen, in 3 Tagen, nächste Woche oder eine benutzerdefinierte Zeit) – sie verschwindet aus deiner offenen Liste und taucht wieder auf, wenn es so weit ist. * **Erledigen** zum Schließen, **Wieder öffnen** um sie zurückzuholen, und **Als ungelesen markieren**, um sie zur Nachverfolgung zu kennzeichnen. ### Automatische Aufräumarbeiten [Section titled “Automatische Aufräumarbeiten”](#automatische-aufräumarbeiten) Der Posteingang hält sich selbst aufgeräumt, damit die offene Liste sich um echte Arbeit dreht: * Konversationen, die nur dazu dienen, automatische Benachrichtigungs-E-Mails festzuhalten, starten **geschlossen** – sie überfüllen nie die offene Warteschlange, und eine Gastantwort öffnet sie sofort wieder. * Ein nächtlicher Durchlauf schließt veraltete Threads, mit denen du fertig bist: wartende Threads ohne Aktivität seit einer Weile, und gelesene Buchungs-Threads, die seit deutlich nach dem Check-out ruhig sind. **Ungelesene Threads werden nie automatisch geschlossen.** * Du kannst die Durchläufe ausschalten oder die Ruhezeiten anpassen, unter **Einstellungen → E-Mail-Zustellung → Posteingang**. ## Textbausteine [Section titled “Textbausteine”](#textbausteine) Wiederverwendbare Antwort-Snippets liegen unter **Einstellungen → Textbausteine**. Erstelle dort betitelte Snippets und füge sie dann mit dem **Textbaustein**-Picker in den Composer ein. Sie werden wortwörtlich eingefügt; nutze **Mit KI entwerfen**, wenn du lieber einen Baustein an den konkreten Gast anpassen möchtest. ## Eine Buchungsanfrage aus einer Nachricht erstellen [Section titled “Eine Buchungsanfrage aus einer Nachricht erstellen”](#eine-buchungsanfrage-aus-einer-nachricht-erstellen) Wenn eine Gastnachricht eigentlich eine Buchungsanfrage ist, nutze **Buchungsanfrage erstellen** im Kontext-Panel der Konversation. Reynt öffnet den [Buchungsanfrage](/de/docs/bookings/booking-drafts-and-offers/)-Assistenten im Interesse-erfassen-Modus — Name, E-Mail und Telefonnummer werden aus dem Kontakt vorausgefüllt, und die Nachricht des Gastes wird als [Kundenwunsch-Text](/de/docs/bookings/booking-drafts-and-offers/#kundenw%C3%BCnsche) übernommen — und verknüpft die neue Anfrage nach dem Erstellen mit der Konversation, sodass die Anfrage und das daraus entstehende Angebot Teil desselben Threads bleiben. ## Die Benachrichtigungsglocke [Section titled “Die Benachrichtigungsglocke”](#die-benachrichtigungsglocke) Die Glocke in der oberen Leiste fasst zusammen, was in der gesamten Konsole Aufmerksamkeit braucht – neue ungelesene Posteingang-Konversationen und E-Mails, die im [Mail-Ausgang](/de/docs/communication/email-confirmation-gate/) warten – und verlinkt direkt zu jeder. Der Navigationseintrag **Posteingang** trägt ebenfalls eine Ungelesen-Anzahl. # E-Mail-Protokolle > Das Protokoll jeder von Reynt gesendeten E-Mail, mit Zustellstatus, um "Ich habe die E-Mail nie erhalten"-Tickets zu klären. **E-Mail-Protokolle** ist das Protokoll jeder E-Mail, die Reynt tatsächlich an deine Kunden und Eigentümer gesendet hat. Wenn ein Gast sagt “Ich habe die Bestätigung nie bekommen”, prüfst du hier, was passiert ist. Öffne es über **Einstellungen → E-Mail-Protokolle**. ## Was erfasst wird [Section titled “Was erfasst wird”](#was-erfasst-wird) Jede Zeile ist eine ausgehende E-Mail, mit: * **Datum**, an dem sie gesendet wurde. * **Typ** – welche E-Mail es war (Buchung bestätigt, Zahlungsanweisungen und so weiter). * **Empfänger** – die Adresse, an die sie ging. * **Absender** – ob sie über **deinen eigenen Server** oder den **Plattform**-Mailer lief (Reynts Fallback, genutzt, wenn du keinen Mailserver konfiguriert hast). * **Betreff**. * **Status**. * **Fehlermeldung**, wenn ein Versand fehlgeschlagen ist. Filtere die Liste nach Typ oder Status, um einzugrenzen. ## Zustellstatus [Section titled “Zustellstatus”](#zustellstatus) * **Gesendet** – Reynt hat die E-Mail an den Mailserver übergeben. * **Zugestellt** – der empfangende Server hat sie für den Empfänger akzeptiert. * **Zurückgewiesen** – der Server des Empfängers hat sie abgelehnt (falsche Adresse, Postfach voll, blockiert). Sie ist nicht angekommen. * **Fehlgeschlagen** – der Versand selbst kam nicht durch. > **Die Zustellverfolgung hängt von deinem Mail-Transport ab.** Beim Plattform-Mailer ist sie immer aktiv. Bei **deinem eigenen Brevo- oder Mailjet-Konto** braucht sie einen einmaligen Einrichtungsschritt – siehe unten. Bei **SMTP** gibt es nichts zu beobachten: Das Protokoll meldet nach der Übergabe nichts zurück, diese E-Mails bleiben also auf **Gesendet** stehen, selbst wenn sie ankommen. ## Zustellverfolgung für dein eigenes Mailkonto aktivieren [Section titled “Zustellverfolgung für dein eigenes Mailkonto aktivieren”](#zustellverfolgung-für-dein-eigenes-mailkonto-aktivieren) Wenn du über dein eigenes Brevo- oder Mailjet-Konto sendest, muss dieses Konto Reynt melden, was mit jeder E-Mail passiert ist. Die Einrichtung dauert eine Minute: 1. Gehe zu **Einstellungen → E-Mails → Mailserver** und stelle sicher, dass dein Anbieter konfiguriert und aktiviert ist. 2. Klicke unter **Zustellverfolgung** auf **Zustellverfolgung aktivieren** und kopiere die angezeigte URL. 3. Trage sie bei deinem Anbieter ein und wähle die Ereignisse unten aus. ### Brevo [Section titled “Brevo”](#brevo) Einstellungen → Webhooks → Webhook hinzufügen, die URL einfügen und genau diese anhaken: `delivered` · `hard_bounce` · `soft_bounce` · `blocked` · `spam` · `invalid_email` · `deferred` · `error` `delivered` macht aus einer gesendeten E-Mail eine zugestellte; die übrigen sind die Arten, wie ein Versand scheitern kann. ### Mailjet [Section titled “Mailjet”](#mailjet) Kontoeinstellungen → Ereignisbenachrichtigungen (Event API). Mailjet nimmt einen Eintrag pro Ereignis, lege also vier an – jeweils mit derselben URL: `sent` (Gesendet) · `bounce` (Bounce/Rückläufer) · `spam` (Spam) · `blocked` (Geblockt) **`sent` wird am häufigsten vergessen und ist das entscheidende.** Mailjet hat kein eigenes *Zugestellt*-Ereignis – sein `sent` bedeutet, dass der Server des Empfängers die E-Mail angenommen hat, und genau das macht aus *Gesendet* erst *Zugestellt*. Ohne dieses Ereignis siehst du nur Fehlschläge, nie Bestätigungen. Aktiviere außerdem **„Events zusammenfassen“**. Mailjet bündelt die Ereignisse dann, statt eine Anfrage pro Ereignis zu schicken – Reynt verarbeitet beides. ### Beides [Section titled “Beides”](#beides) Lass Öffnungen, Klicks und Abmeldungen aus. Reynt verwirft sie, sie kosten nur Anfragen an deinen Webhook. Ab dann zeigen die E-Mail-Protokolle den echten Zustellstatus, statt bei *Gesendet* stehen zu bleiben, und bei einer Rückweisung siehst du den Grund, den der empfangende Server genannt hat. > Die URL enthält ein Geheimnis – behandle sie wie ein Passwort. Falls sie jemals durchsickert, mache sie mit **Geheimnis erneuern** ungültig und trage die neue URL bei deinem Anbieter ein. Dazwischen ist die Verfolgung unterbrochen, mache beide Schritte also zusammen. ## Zustellung debuggen [Section titled “Zustellung debuggen”](#zustellung-debuggen) Eine typische “fehlende E-Mail”-Prüfung: 1. Finde die E-Mail nach Empfänger und Datum. **Gar keine Zeile** bedeutet, sie wurde nie gesendet – prüfe, ob die Benachrichtigung in [Benachrichtigungen](/de/docs/communication/notifications-and-email/) deaktiviert ist, oder ob sie noch im [Mail-Ausgang](/de/docs/communication/email-confirmation-gate/) wartet. 2. **Zurückgewiesen** oder **Fehlgeschlagen** – lies die Fehlermeldung; meist eine falsche Adresse oder ein Postfachproblem. Korrigiere die E-Mail des Kunden und sende erneut von der Buchung aus. 3. **Zugestellt**, aber der Gast findet sie nicht – sie ist wahrscheinlich im Spam gelandet; bitte ihn nachzusehen. Testest du mit importierten Daten, beachte, dass eine umgeleitete E-Mail den vorgesehenen Empfänger als Präfix `[→ guest@example.com]` im Betreff zeigt. ## Beziehung zum Posteingang [Section titled “Beziehung zum Posteingang”](#beziehung-zum-posteingang) Gast-gerichtete E-Mails erscheinen auch in der Timeline der Buchung im [Posteingang](/de/docs/communication/inbox/), wo jede dasselbe Zustellungs-Badge zeigt (zugestellt, gesendet, fehlgeschlagen, zurückgewiesen). E-Mail-Protokolle sind das vollständige technische Protokoll *jeder* ausgehenden E-Mail; der Posteingang zeigt die gast-gerichteten im Kontext der Konversation, zu der sie gehören. # Benachrichtigungen und E-Mail > Wähle, welche automatischen E-Mails versendet werden, bearbeite ihre Vorlagen pro Sprache und richte ein, wie Mail zugestellt wird. Reynt sendet transaktionale E-Mails bei jedem wichtigen Buchungsereignis – Buchung erstellt und bestätigt, Zahlungsanweisungen und Belege, Stornierungen, Antworten auf Anfragen und mehr. Zwei Konsolenbereiche steuern sie: der **Benachrichtigungen**-Hub entscheidet, *welche* E-Mails versendet werden und *was sie sagen*, und **E-Mail-Zustellung** entscheidet, *wie* sie zugestellt werden. ## Der Benachrichtigungen-Hub [Section titled “Der Benachrichtigungen-Hub”](#der-benachrichtigungen-hub) Öffne **Einstellungen → Benachrichtigungen**. Die linke Leiste listet jede Benachrichtigung, gruppiert in Anfragen & Angebote, Buchungen, Zahlungen und Kontaktformulare. Jede Zeile zeigt, ob sie aktiv ist und für wen sie ist (den Gast oder dein Team). Wähle eine aus, um sie rechts zu verwalten: * **Zustellung** – ein Kanal-Schalter (heute E-Mail). Ihn zu deaktivieren ist eine harte Abschaltung: Diese automatische Benachrichtigung wird nie erzeugt, selbst wenn eine Buchungsaktion sie anfordert. Manuelle Erneut-senden-Buttons sind davon nicht betroffen – sie senden immer. * **E-Mail-Vorlage** – der bearbeitbare Inhalt für gast-gerichtete E-Mails (siehe unten). * **Vorschau** – die tatsächliche E-Mail mit Beispieldaten direkt in der Konsole rendern, sodass du das Ergebnis von Vorlagenänderungen prüfen kannst, ohne etwas zu versenden. * **Test-E-Mail senden** – dir selbst eine Kopie mit Beispieldaten an eine beliebige Adresse senden, in der Sprache deiner Wahl. Ein paar Zeilen verhalten sich etwas anders: Die beiden Team-Benachrichtigungen (Buchungsanfrage und Kontaktformular) haben keinen bearbeitbaren Inhalt – nur einen Schalter und einen Testversand – und **Zahlungsanweisungen** ist eine ausschließlich manuell versendbare E-Mail ohne automatischen Auslöser. ### Die Benachrichtigungen [Section titled “Die Benachrichtigungen”](#die-benachrichtigungen) | Benachrichtigung | Gesendet an | Ausgelöst wenn | | ---------------------------------- | ----------- | ----------------------------------------------------------------- | | Buchungsanfrage eingegangen (Team) | Dein Team | Ein Gast reicht eine Anfrage im Storefront ein | | Buchungsanfrage-Bestätigung | Gast | Direkt nachdem diese Anfrage eingereicht wurde | | Angebot gesendet | Gast | Du sendest ein Angebot aus einer Buchungsanfrage | | Anfrage abgelehnt | Gast | Du lehnst eine Anfrage ab | | Buchung erstellt | Gast | Eine Anfrage wird als ausstehende Buchung veröffentlicht | | Buchung bestätigt | Gast | Eine Buchung wird bestätigt | | Buchung geändert | Gast | Du änderst eine Buchung und entscheidest dich, zu benachrichtigen | | Buchung storniert | Gast | Du stornierst eine Buchung | | Zahlung eingegangen | Gast | Du markierst eine Überweisung als bezahlt | | Rückerstattungsbestätigung | Gast | Eine Rückerstattung wird verarbeitet | | Kontaktformular eingegangen (Team) | Dein Team | Ein Gast reicht das Kontaktformular im Storefront ein | | Kontaktformular-Bestätigung | Gast | Dieselbe Einreichung, automatische Antwort an den Gast | Die meisten Buchungsaktionen (veröffentlichen, bestätigen, stornieren, ändern, als bezahlt markieren) zeigen in ihrem Dialog außerdem eine “E-Mail-Benachrichtigung senden”-Checkbox. Ist die Benachrichtigung im Hub deaktiviert, wird diese Checkbox mit einem Hinweis hierher ausgeblendet. ## E-Mail-Vorlagen bearbeiten [Section titled “E-Mail-Vorlagen bearbeiten”](#e-mail-vorlagen-bearbeiten) Für jede gast-gerichtete E-Mail kannst du **Betreff**, **Überschrift**, **Text** und **Fußzeile** anpassen. Lässt du ein Feld leer, greift Reynts integrierter Standard. Tippe im Text **`$`**, um eine Variable einzufügen – Platzhalter wie der Name des Gastes, der Objektname, An- und Abreisedatum, Nächteanzahl, Gästeanzahl, Beträge und offene Summen, Währung und Zahlungsreferenzen werden pro E-Mail eingesetzt. Manche Vorlagen bieten außerdem Optionen zur Dateneinbindung (ob Zahlungsanweisungen, der Zeitplan, Belege, Check-in-Details, die Kaution oder ein Buchungslink enthalten sein sollen). Die E-Mail “Buchung geändert” übernimmt diese von “Buchung bestätigt”. ### Vorlagen pro Sprache [Section titled “Vorlagen pro Sprache”](#vorlagen-pro-sprache) Vorlagentexte sind **pro Sprache**. Unterstützt du mehr als eine Sprache, bearbeite jedes Feld pro Locale und wähle eine **Vorschau-Sprache**, wenn du einen Test sendest. Beim Versand nutzt Reynt die Kommunikationssprache des Empfängers (siehe [Kunden](/de/docs/customers-and-owners/customers/)), um den richtigen Text auszuwählen. Fehlende Vorlagensprachen werden auf der [Übersetzungsseite](/de/docs/languages/translations-page/) angezeigt, sodass du die Lücken dort füllen kannst (und dort auch KI-Übersetzung nutzen kannst). ## E-Mail-Zustellung [Section titled “E-Mail-Zustellung”](#e-mail-zustellung) Öffne **Einstellungen → E-Mail-Zustellung**, um zu steuern, wie Mail versendet wird: * **Mailserver** – dein eigenes SMTP-, Mailjet- oder Brevo-Konto. Ist es konfiguriert und aktiviert, wird deine gesamte Mail darüber versendet. Du kannst es vorübergehend deaktivieren, um über Reynt zu leiten, ohne deine Zugangsdaten zu verlieren. * **Zustellverfolgung** – bei Brevo und Mailjet eine URL, die du bei deinem Anbieter einträgst, damit er Zustellungen und Rückweisungen an Reynt meldet. Ohne sie bleiben deine [E-Mail-Protokolle](/de/docs/communication/mail-logs/) bei *Gesendet* stehen. * **Plattform-E-Mail-Versand** – hast du keinen aktiven Mailserver, lässt du Reynt in deinem Namen von einer Plattform-Adresse senden (“Dein Name via Reynt”), mit Antworten, die in deinen Benachrichtigungs-Posteingang geleitet werden. Deaktiviere dies, um deinen eigenen Server *zu verlangen*. Reynt versendet deine Mail nie stillschweigend von einer Plattform-Adresse, wenn dies deaktiviert ist. * **Benachrichtigungs-Adresse** – der Posteingang, der deine Team-Benachrichtigungen und Testversände erhält. Halte ihn gepflegt. * **E-Mail-Branding** – eine Markenfarbe, die alle Kunden-E-Mails thematisiert: das Kopfband, Buttons und Akzente. (Dies ist unabhängig von der [Themenfarbe](/de/docs/storefront/appearance-and-theming/) des Storefronts.) * **Gemeinsame Signatur** – wird am Ende jeder ausgehenden Kunden-E-Mail angehängt (ebenfalls pro Sprache, mit `$`-Variablen). * **E-Mail-Bestätigungssperre** – automatische Kunden-/Eigentümer-Mail vor dem Versand zur Prüfung zurückhalten. Siehe [E-Mail-Bestätigungssperre](/de/docs/communication/email-confirmation-gate/). * **Eingehende E-Mail-Antworten** – Gastantworten zurück in den [Posteingang](/de/docs/communication/inbox/) leiten. * **E-Mail Rechtliche URLs** – Links zu Datenschutzerklärung und AGB, die in die Fußzeile von Kunden-E-Mails eingefügt werden. * **Posteingang: Automatisches Schließen** – ob (und nach wie vielen ruhigen Tagen) erledigte Posteingang-Konversationen automatisch geschlossen werden. Siehe [Posteingang](/de/docs/communication/inbox/) für das Verhalten der Durchläufe. ## Glocke und Protokolle für die Zustellung [Section titled “Glocke und Protokolle für die Zustellung”](#glocke-und-protokolle-für-die-zustellung) Die Glocke in der oberen Leiste verlinkt zu Dingen, die Aufmerksamkeit brauchen (ungelesene Posteingang-Konversationen, im Ausgang zurückgehaltene E-Mails). Jede tatsächlich gesendete E-Mail wird in den [E-Mail-Protokollen](/de/docs/communication/mail-logs/) erfasst, wo du ihren Zustellstatus prüfen kannst. # API-Schlüssel > Schlüssel für den programmatischen Zugriff auf die Reynt-API erstellen und widerrufen. Mit API-Schlüsseln kannst du die Reynt-API aus deinen eigenen Skripten, Integrationen oder deiner CI heraus aufrufen – überall dort, wo du programmatischen Zugriff statt eines Logins über die Konsole brauchst. Du verwaltest sie unter **Einstellungen → API-Schlüssel**. Jeder Schlüssel ist an die Person gebunden, die ihn erstellt hat, und erbt deren Zugriffsrechte. Verlierst du den Zugriff auf den Tenant, funktioniert jeder von dir erstellte Schlüssel nicht mehr – erstelle Schlüssel daher unter einem Konto, das bestehen bleibt. ## Einen Schlüssel erstellen [Section titled “Einen Schlüssel erstellen”](#einen-schlüssel-erstellen) Klicke auf **Neuer API-Schlüssel** und fülle aus: * **Name** – eine Bezeichnung, damit du den Schlüssel später wiedererkennst (zum Beispiel “CI Deploy-Bot”). * **Läuft ab** – **Läuft in 90 Tagen ab** (Standard), **Läuft nie ab**, oder **Eigenes Datum**. Wählst du ein eigenes Datum, erscheint ein Datumsauswähler. Sende ab, und Reynt zeigt den vollständigen Schlüssel an. ### Speichere den Schlüssel sofort [Section titled “Speichere den Schlüssel sofort”](#speichere-den-schlüssel-sofort) Der vollständige Schlüssel wird **nur einmal** angezeigt, direkt nach der Erstellung, unter **Bearer-Token**. Kopiere ihn mit dem **Kopieren**-Button und speichere ihn in deinem Passwort-Manager oder Secret-Store, bevor du den Dialog schließt – der Dialog schließt sich nicht von selbst, solange der Schlüssel sichtbar ist. Reynt speichert nur eine gehashte Version; es gibt keine Möglichkeit, ihn erneut anzuzeigen. Verlierst du ihn, widerrufe den Schlüssel und erstelle einen neuen. Schlüssel sehen aus wie `rynt_…`. Sende den vollständigen Wert als Bearer-Token: `Authorization: Bearer rynt_…`. ## Die Schlüsseltabelle [Section titled “Die Schlüsseltabelle”](#die-schlüsseltabelle) Jeder von dir erstellte Schlüssel wird aufgelistet mit: * **Name** * **Präfix** – der sichtbare Anfang des Schlüssels (der geheime Teil wird nie wieder angezeigt). * **Status** – **Aktiv**, **Widerrufen**, oder **Abgelaufen**. * **Zuletzt verwendet**, **Läuft ab** und **Erstellt** (jedes davon kann **Nie** lauten). ## Einen Schlüssel widerrufen [Section titled “Einen Schlüssel widerrufen”](#einen-schlüssel-widerrufen) Um einen Schlüssel stillzulegen, klicke auf das Widerrufen-Symbol (Papierkorb) in seiner Zeile und bestätige. Der Widerruf ist sofort und dauerhaft: Jede Anfrage mit diesem Schlüssel beginnt sofort zu scheitern, und die Aktion kann nicht rückgängig gemacht werden. Widerrufe einen Schlüssel, sobald er nicht mehr gebraucht wird oder durchgesickert sein könnte, und erstelle bei Bedarf einen neuen. ## Wer Schlüssel verwalten kann [Section titled “Wer Schlüssel verwalten kann”](#wer-schlüssel-verwalten-kann) Das Erstellen und Widerrufen von API-Schlüsseln erfordert eine Admin-Rolle. Siehe [Mitglieder & Rollen](/de/docs/configuration/members-and-roles/). # Mitglieder & Rollen > Lade Teammitglieder zu deinem Tenant ein, weise Rollen zu und verwalte den Zugriff. Dein Tenant ist ein gemeinsamer Arbeitsbereich. Jeder, der daran arbeitet, hat sein eigenes Login, sodass du sehen kannst, wer was getan hat, und den Zugriff entziehen kannst, wenn jemand geht. Du verwaltest das Team unter **Einstellungen → Mitglieder**. Nur Admins sehen **Mitglieder** überhaupt und können die Seite öffnen – für alle anderen taucht der Eintrag in den Einstellungen nicht auf, und ein direkt aufgerufener Link schickt ein Mitglied oder einen Betrachter zurück zum Dashboard. ## Die Mitglieder-Seite [Section titled “Die Mitglieder-Seite”](#die-mitglieder-seite) **Mitglieder** hat zwei Teile: * **Mitglieder** – jeder mit Zugriff auf diese Organisation, mit Name, E-Mail, Rolle und Beitrittsdatum. * **Einladungen** – von dir gesendete Einladungen, die noch nicht angenommen wurden. Dieser Abschnitt erscheint nur, wenn mindestens eine Einladung offen ist; nimmt jemand an, wandert er automatisch in die Liste **Mitglieder**. ## Ein Teammitglied einladen [Section titled “Ein Teammitglied einladen”](#ein-teammitglied-einladen) Klicke auf **Mitglied einladen** und gib ein: * **E-Mail** – die E-Mail-Adresse der Person. * **Rolle** – **Admin**, **Mitglied** oder **Betrachter** (standardmäßig Mitglied). Sende ab, und Reynt schickt eine Einladungs-E-Mail. Nimmt die Person an, richtet sie ihr eigenes Login ein und erscheint in der Liste **Mitglieder**. Gehört die E-Mail bereits einem Mitglied, erhältst du eine “bereits Mitglied”-Meldung. ## Rollen [Section titled “Rollen”](#rollen) Reynt nutzt drei Rollen. Die Trennlinie ist einfach: **Mitglied führt das Tagesgeschäft; Admin steuert zusätzlich den Account selbst.** * **Admin** – voller Zugriff auf alles: Objekte, Buchungen, Rechnungen, Zahlungen, den Storefront, alle Einstellungen sowie das Einladen von Mitgliedern, das Ändern von Rollen und das Erstellen von API-Schlüsseln. * **Mitglied** – alles fürs tägliche Geschäft: Buchungen, Objekte, Kunden, Rechnungen und den Storefront-/Content-Katalog anlegen und bearbeiten. Ein Mitglied kann tenantweite Einstellungen nicht ändern (**Einstellungen** bleiben nur lesbar), kann das Team nicht einladen oder verwalten und kann eine Buchung nicht endgültig löschen – nur archivieren. Eigentümer-Datensätze (Bank- und Steuerdaten) sind nur lesbar/bearbeitbar, nicht anlegbar oder löschbar. * **Betrachter** – Lesezugriff überall, auch bei **Einstellungen**. Nichts anlegen, bearbeiten oder löschen, und kein Zugriff auf das Team. Passend für eine Steuerberaterin, einen stillen Mitinhaber oder alle, die nur Einblick brauchen. Vergib **Admin** sparsam – an Personen, die den Account selbst konfigurieren und über den Zugriff darauf entscheiden dürfen. ## Eine Rolle ändern oder jemanden entfernen [Section titled “Eine Rolle ändern oder jemanden entfernen”](#eine-rolle-ändern-oder-jemanden-entfernen) In der Tabelle **Mitglieder**: * **Eine Rolle ändern** – nutze das Rollen-Dropdown in der Zeile der jeweiligen Person. Die Änderung wirkt sofort. * **Ein Mitglied entfernen** – klicke auf das Entfernen-Symbol (Papierkorb) und bestätige. Der Zugriff endet sofort. Du kannst dich nicht selbst entfernen – der Entfernen-Button ist in deiner eigenen Zeile deaktiviert. Reynt sorgt außerdem immer für mindestens einen Admin: Der Versuch, den letzten Admin des Tenants herabzustufen oder zu entfernen, wird mit einer Fehlermeldung abgelehnt, damit sich ein Tenant nie selbst aus den eigenen Einstellungen und dem Team aussperrt. ## Dein eigenes Konto [Section titled “Dein eigenes Konto”](#dein-eigenes-konto) Rollen steuern, was du *innerhalb eines Tenants* tun kannst. Wie du dich persönlich anmeldest – Passwort, Zwei-Faktor, Passkeys, aktive Sitzungen – liegt auf deiner [Konto](/de/docs/getting-started/console-tour/)-Seite und wird über das sichere Identitätsportal verwaltet. # Tenant-Einstellungen > Eine Übersicht des Einstellungsbereichs – jeder Konfigurationstab in der Konsole und was er steuert. Alles, was du für einen Tenant konfigurierst, liegt unter dem **Einstellungen**-Zahnrad am unteren Ende der Seitenleiste. Einstellungen öffnet eine zweite Seitenleiste, gegliedert in fünf Gruppen: **Konfiguration**, **Abrechnung**, **Kommunikation**, **Kataloge** und **Plattform**. Jeder Tab ist ein Satz von Karten, die du unabhängig voneinander bearbeitest und speicherst – die meisten Änderungen wirken sofort. Diese Seite ist eine Übersicht darüber, was jeder Tab macht und wo du mehr darüber lesen kannst. ## Konfiguration [Section titled “Konfiguration”](#konfiguration) * **Identität** – dein Firmenname, Logo, Terminologie-Voreinstellung (Standard, Ferienvermietung oder Hotel), Standardwährung und Zeitzone. Zeigt außerdem deinen Betriebsmodus (Direkt oder Marktplatz, bei der Tenant-Erstellung festgelegt und hier nicht bearbeitbar) und lässt dich den Einrichtungsassistenten erneut ausführen oder die Dashboard-Onboarding-Checkliste wiederherstellen. * **Sprachen** – deine Standardsprache und die Menge der Sprachen, die dein Inhalt und dein Storefront unterstützen. Siehe [Mehrsprachige Inhalte](/de/docs/languages/multilingual-content/). * **Übersetzungen** – eine Arbeitsseite, die jede fehlende Übersetzung in deinem Inhalt auflistet, damit du sie an einem Ort ergänzen kannst. Siehe [Übersetzungsseite](/de/docs/languages/translations-page/). * **Marke** – deine Social-Media-Profillinks (Instagram, Facebook, YouTube, X, LinkedIn, TikTok, Pinterest). * **Rechtliches** – registrierter Firmenname, Adresse, Land, USt-IdNr., Registerangaben (Vertretungsberechtigte, Registergericht und -nummer – für eingetragene Unternehmen Pflichtangaben auf Geschäftsbriefen, also auch in E-Mails) und rechtlicher Kontakt, verwendet auf Rechnungen, in E-Mail-Fußzeilen und auf rechtlichen Seiten. * **Buchungseinstellungen** – wie sich Buchungen verhalten: sofort vs. auf Anfrage, automatische Bestätigung, Standard-Stornierungsrichtlinie, Check-in-/Check-out-Zeiten, Haustiere, Gästekategorien und Gästeregistrierung. Siehe [Buchungseinstellungen](/de/docs/bookings/booking-settings/). * **Stornierungsrichtlinien** – erstelle und verwalte die wiederverwendbaren Richtlinien, die du Objekten und Buchungen zuweist. Siehe [Stornierungen & Rückerstattungen](/de/docs/bookings/cancellations-and-refunds/). * **Kunden-Oberfläche** – technische Einrichtung für deine öffentliche Seite: Storefront-Modus, die Go-Live-Veröffentlichungssperre, Katalog- und Objektseiten-Optionen, Suchpaginierung und -ranking, benutzerdefinierte Domains, Kartenkacheln und Analytics. Siehe [Domains & SEO](/de/docs/storefront/domains-and-seo/) und [Suche & Karten](/de/docs/storefront/search-and-maps/). Branding und Theming liegen auf der separaten Seite **Erscheinungsbild** – siehe [Erscheinungsbild & Theming](/de/docs/storefront/appearance-and-theming/). * **Weiterleitungen** – URL-Weiterleitungen von alten Pfaden auf neue, nützlich bei der Migration von einer bestehenden Website oder nach der Änderung eines Seiten-Slugs. Siehe [Domains & SEO](/de/docs/storefront/domains-and-seo/#url-weiterleitungen). ## Abrechnung [Section titled “Abrechnung”](#abrechnung) * **Abonnement** – eine schreibgeschützte Ansicht deines aktuellen Plans: Status, Preis, Objekt- und KI-Limits, Abrechnungszeitraum und enthaltene Funktionen. * **Zahlungen** – deine Überweisungsdaten und Zahlungsraten sowie, im Marktplatz-Modus, deine Plattformgebühr und Provisionseinstellungen. Siehe [Zahlungsanbieter](/de/docs/payments/providers/). * **Rechnungen** – Rechnungsstellung aktivieren, Verhalten der automatischen Erstellung wählen, Steuermodi festlegen sowie Rechnungsvorlagen und PDF-Fußzeile bearbeiten. Siehe [Rechnungserstellung und Nummerierung](/de/docs/invoices/creation-and-numbering/). * **Steuersätze** – länderspezifische Steuersätze, die auf Buchungen und Rechnungen angewendet werden. Siehe [Steuern](/de/docs/invoices/taxes/). * **Referenzen** – die Präfixbuchstaben und Startnummern für Buchungs-, Entwurfs-, Zahlungs-, Rechnungs- und Kundenreferenznummern. ## Kommunikation [Section titled “Kommunikation”](#kommunikation) * **Textbausteine** – wiederverwendbare Antwortvorlagen, die du beim Nachrichtenschreiben an Gäste und Eigentümer einfügst. * **E-Mail-Protokolle** – die Historie jeder an Kunden und Eigentümer gesendeten E-Mail. Siehe [E-Mail-Protokolle](/de/docs/communication/mail-logs/). * **Benachrichtigungen** – der Benachrichtigungs-Hub: Lege für jedes Ereignis (Buchung erstellt, Zahlung eingegangen und so weiter) fest, welche Kanäle auslösen, bearbeite die E-Mail-Vorlage und sende einen Test. Siehe [Benachrichtigungen & E-Mail](/de/docs/communication/notifications-and-email/). * **E-Mail-Zustellung** – Mail-Transport und -Zustellung: dein eigener Mailserver oder der Plattform-Fallback, Benachrichtigungs-Adresse, E-Mail-Branding (Markenfarbe), gemeinsame Signatur, die Bestätigungssperre, eingehende Antworten, rechtliche E-Mail-Links und automatisches Schließen des Posteingangs. Siehe [Benachrichtigungen & E-Mail](/de/docs/communication/notifications-and-email/) und [E-Mail-Bestätigungssperre](/de/docs/communication/email-confirmation-gate/). ## Kataloge [Section titled “Kataloge”](#kataloge) Die wiederverwendbaren Bausteine, auf die deine Objekte zurückgreifen – richte sie einmal ein und nutze sie in deinem gesamten Portfolio. Siehe [Katalog-Übersicht](/de/docs/catalog/overview/). * **Ausstattung** – Merkmale, die eine Unterkunft bietet (WLAN, Pool, Parkplatz). * **Attribute** – typisierte Fakten über eine Unterkunft. * **Objekttypen** – Wohnung, Haus, Villa und so weiter. Siehe [Objekttypen](/de/docs/catalog/property-types/). * **Tags** – freie Bezeichnungen, die als Filter-Pills im Storefront genutzt werden. * **Reiseziele** und **Entfernungen** – Gebiete und Sehenswürdigkeiten. Siehe [Reiseziele und Entfernungen](/de/docs/catalog/places-and-distances/). ## Plattform [Section titled “Plattform”](#plattform) * **KI** – dein KI-Anbieterschlüssel, Modell, benutzerdefinierte Anweisungen und Embedding-Einstellungen, die die KI-Funktionen der Konsole antreiben. Siehe [KI-Übersicht](/de/docs/ai/overview/). * **KI-Nutzung** – ein schreibgeschütztes Dashboard des KI-Token-Verbrauchs, der Kosten und der Workflow-Historie. * **API-Schlüssel** – Schlüssel für den programmatischen Zugriff auf die API erstellen und widerrufen. Siehe [API-Schlüssel](/de/docs/configuration/api-keys/). * **Datentransfer** – exportiere die Konfiguration, Referenzdaten und den Storefront-Inhalt deines Tenants in eine Datei, oder importiere aus einem früheren Export. ## Wer Einstellungen ändern kann [Section titled “Wer Einstellungen ändern kann”](#wer-einstellungen-ändern-kann) Das Verwalten von Einstellungen – sowie das Einladen von Teammitgliedern oder Erstellen von API-Schlüsseln – erfordert eine Admin-Rolle. Siehe [Mitglieder & Rollen](/de/docs/configuration/members-and-roles/). # Kunden > Gastprofile, ihre Buchungshistorie und ihre Kommunikationssprache verwalten. Ein **Kunde** ist ein Gast – die Person, die eine Buchung vorgenommen oder eine Anfrage gestellt hat. Reynt führt pro Gast ein Profil, sodass dessen Buchungen, Anfragen, Rechnungen, Zahlungen und Konversationen alle an einem Ort zusammenhängen. Öffne **Kunden** (unter der Gruppe **Personen** in der Seitenleiste), um die Liste zu sehen. ## Die Kundenliste [Section titled “Die Kundenliste”](#die-kundenliste) Die Liste ist eine Tabelle mit der Referenz, dem Namen, der E-Mail-Adresse, der Kommunikationssprache und dem Erstellungsdatum des Kunden. Klicke auf eine Zeile, um die Detailseite des Kunden zu öffnen. Die meisten Kunden werden automatisch angelegt, sobald ein Gast zum ersten Mal über den Storefront bucht oder eine Anfrage sendet. Du kannst auch von Hand einen anlegen mit **Neuer Kunde** – nützlich für telefonische Buchungen oder Vor-Ort-Buchungen, die du selbst erfasst. ## Einen Kunden anlegen oder bearbeiten [Section titled “Einen Kunden anlegen oder bearbeiten”](#einen-kunden-anlegen-oder-bearbeiten) Der Editor ist in Abschnitte unterteilt: * **Grundinformationen** – Vor- und Nachname. * **Kontakt** – E-Mail und Telefon. * **Adresse** – Straße, Stadt, Region, PLZ, Land. * **Präferenzen** – die Kommunikations-**Sprache** und etwaige **Besondere Anforderungen**. * **Notizen** – interne Notizen, nur für dein Team sichtbar. Bearbeite einen bestehenden Kunden über dessen Detailseite (**Kunde bearbeiten**) – derselbe Editor, bereits vorausgefüllt. ## Kommunikationssprache [Section titled “Kommunikationssprache”](#kommunikationssprache) Das Feld **Sprache** ist die bevorzugte Sprache des Gasts. Es ist für den Betreiber sichtbar und bearbeitbar und bestimmt, in welcher Sprache Reynt diesem Gast E-Mails schickt: Die sprachspezifischen Vorlagentexte, die du unter **Einstellungen → Benachrichtigungen** einrichtest, werden anhand dieser Sprache ausgewählt. Stelle sie korrekt ein, dann erreicht jede Buchungsmail, Zahlungsanweisung und Bestätigung den Gast in seiner eigenen Sprache. ## Die Detailseite [Section titled “Die Detailseite”](#die-detailseite) Die Detailseite des Kunden zeigt seinen Kontakt und seine Adresse, eine Statistikleiste (Gesamt-, bestätigte und stornierte Buchungen sowie Gesamtausgaben) sowie seine besonderen Anforderungen und internen Notizen. Darunter fassen vier Tabs alles zusammen, was mit dem Kunden verknüpft ist: * **Buchungen** – jede Buchung, mit Referenz, Objekt, Zeitraum, Gesamtbetrag und Status. * **Anfragen** – Buchungsanfragen, die noch nicht veröffentlicht sind. * **Rechnungen** – für diesen Kunden ausgestellte Rechnungen. * **Zahlungen** – Zahlungen und Rückerstattungen, die zu seinen Buchungen erfasst wurden. ## Wie Kunden mit Buchungen verknüpft werden [Section titled “Wie Kunden mit Buchungen verknüpft werden”](#wie-kunden-mit-buchungen-verknüpft-werden) Eine Buchung oder Anfrage wird mit einem Kunden verknüpft, wenn du diesen Kunden bei der Erstellung auswählst, oder wenn ein Gast im Storefront zur Kasse geht und Reynt sein Profil per E-Mail zuordnet (oder anlegt). Konversationen im Posteingang werden genauso verknüpft – die Antwort-E-Mail eines Gastes wird automatisch dem passenden Kunden zugeordnet. Sobald verknüpft, erscheinen die Buchung, ihre Rechnungen, ihre Zahlungen und ihre Konversation sowohl auf der Detailseite des Kunden als auch auf der Kunden-Timeline im [Posteingang](/de/docs/communication/inbox/). Kontaktdaten werden sicher gespeichert; nur dein Team kann die Notizen und besonderen Anforderungen eines Kunden einsehen. # Eigentümer > Immobilieneigentümer, ihre Bank- und Auszahlungsdaten sowie die Übertragung von Objekten bei einer Übergabe verwalten. Ein **Eigentümer** ist die Person oder das Unternehmen, dem eine von dir verwaltete Immobilie gehört. Eigentümer spielen im **Marktplatz-Modus** eine Rolle, in dem du Gäste mit Immobilieneigentümern zusammenbringst und pro Buchung eine Provision verdienst: Jedes Objekt gehört einem Eigentümer, und jede Buchung erzeugt eine Auszahlung an diesen Eigentümer und, sobald du eine erstellst, eine Abrechnungsrechnung (Provision). Wenn du im **Direktmodus** arbeitest (du besitzt und verwaltest deine eigenen Immobilien selbst), kannst du Eigentümer vollständig ignorieren. Öffne **Eigentümer** (unter der Gruppe **Personen**), um sie zu verwalten. ## Die Eigentümer-Ansicht [Section titled “Die Eigentümer-Ansicht”](#die-eigentümer-ansicht) Eigentümer nutzen ein Sidebar-Layout: Die Liste der Eigentümer bleibt links, und die Details des ausgewählten Eigentümers füllen das Panel rechts. Der ausgewählte Eigentümer wird in der Seiten-URL abgebildet, sodass du direkt zu einem bestimmten verlinken kannst. Lege einen Eigentümer mit **Neuer Eigentümer** an – ein kurzes Modal fragt nach den Grunddaten (Name und ob es sich um ein registriertes Unternehmen handelt). Den Rest füllst du anschließend im Detailpanel aus. ## Eigentümerdetails [Section titled “Eigentümerdetails”](#eigentümerdetails) Das Detailpanel gruppiert die Informationen eines Eigentümers in Abschnitte, die du direkt bearbeitest: * **Kontakt** – E-Mail, Festnetz- und Mobiltelefon. * **Adresse** – Straße, Stadt, Region, PLZ, Land. * **Bankverbindung** – Bankname, IBAN und BIC, verwendet für Abrechnungen. * **Mollie** – das eigene Mollie-Konto dieses Eigentümers, wenn Mollie in deinem Workspace verfügbar ist. Siehe unten. * **Zahlungsbedingungen** – wer die Buchungen dieses Eigentümers kassiert und wie sein Anteil bei ihm ankommt. Siehe unten. * **Steuer** – Unternehmens-Flag, Steuer-ID und USt-IdNr., verwendet auf Abrechnungsrechnungen. * **Notizen** – interne Notizen für dein Team. ## Das Mollie-Konto eines Eigentümers verbinden [Section titled “Das Mollie-Konto eines Eigentümers verbinden”](#das-mollie-konto-eines-eigentümers-verbinden) Wenn der Anteil des Eigentümers an einer Buchung über Mollie bezahlt wird, geht er auf **sein eigenes** Mollie-Konto, nicht auf deins — dieses Konto muss also verbunden sein, bevor solche Buchungen möglich sind. Die Karte **Mollie** im Detailpanel ist der Ort dafür, und sie zeigt, wie weit der Eigentümer gekommen ist: * **Nicht verbunden** – noch nichts begonnen. * **Eingeladen** – ein Link existiert, aber der Eigentümer hat nicht abgeschlossen. * **Wartet auf Mollie** – der Eigentümer hat verbunden, und Mollie verlangt noch eine Identifizierung oder hat noch keine Zahlungsmethode freigeschaltet. Über dieses Konto kann noch nicht abgerechnet werden. * **Bereit** – Mollie hat das Konto für Zahlungen freigegeben. **Einladungslink erstellen** erzeugt den Link. Reynt verschickt ihn **nicht** per E-Mail: Ein Eigentümer ist ein Datensatz in deinem Workspace, kein Benutzer mit einer verifizierten Adresse — es gibt also keinen Kanal dorthin. Du verschickst ihn selbst, über den Weg, den du mit diesem Eigentümer ohnehin nutzt. Der Link ist die Berechtigung Wer den Link hat, kann ein Mollie-Konto mit diesem Eigentümer verbinden — schick ihn also direkt an den Eigentümer. Er funktioniert **einmal** und läuft nach **14 Tagen** ab. Falls er abhandenkommt, erstelle einen neuen: der alte Link funktioniert dann sofort nicht mehr. Bricht der Eigentümer die Verbindung zwischendurch ab, funktioniert derselbe Link weiterhin: Er ist erst verbraucht, wenn tatsächlich ein Mollie-Konto verbunden wurde. Ein Eigentümer braucht das nur, wenn sein Anteil tatsächlich über Mollie ankommt. Wird er per Überweisung bezahlt oder nimmt er seinen Anteil bar, kannst du die Karte ignorieren — siehe unten. ## Zahlungsbedingungen für einen einzelnen Eigentümer [Section titled “Zahlungsbedingungen für einen einzelnen Eigentümer”](#zahlungsbedingungen-für-einen-einzelnen-eigentümer) Die meisten Agenturen rechnen mit allen Eigentümern gleich ab – dafür ist **Einstellungen → Zahlungen** da. Aber eine Vereinbarung schließt du mit einer *Person*, und ein einzelner Eigentümer kann etwas anderes ausgehandelt haben: Er nimmt seinen Anteil per Überweisung, während alle anderen bar an der Tür kassieren, oder er kassiert selbst beim Gast. Die Karte **Zahlungsbedingungen** im Detailpanel des Eigentümers ist der Ort für diese Ausnahme. Sie hat zwei Felder, und beide stehen zunächst auf **Wie dein Standard**: * **Wer kassiert das Geld** – dieselben drei Antworten wie dein Workspace- Standard: alles an dich, alles an den Eigentümer, oder aufgeteilt (deine Provision an dich, der Rest an den Eigentümer). * **Wie der Anteil des Eigentümers ankommt** – Überweisung, Mollie oder bar bei der Anreise. Wird nur angezeigt, wenn die Antwort oben „aufgeteilt“ ist, denn nur dann hat der Eigentümer einen eigenen Anteil. Deine Provision wird immer online bezahlt, wenn der Gast bucht; hier geht es nur um den Teil des Eigentümers. Lässt du ein Feld auf **Wie dein Standard**, *folgt* es deinem Workspace – auch späteren Änderungen unter **Einstellungen → Zahlungen**. Die Karte zeigt auf einen Blick **Eigene Vereinbarung** oder **Wie dein Standard**, sodass du siehst, mit welchen Eigentümern du gesondert verhandelt hast. Das gilt nur im Marktplatz-Modus: Im Direktmodus gibt es keinen Eigentümer, mit dem du eine Vereinbarung schließen könntest, und die Karte wird nicht angezeigt. Note Ein Angebot behält die Bedingungen, mit denen es versendet wurde. Änderst du die Zahlungsbedingungen eines Eigentümers, nachdem du einem Gast ein Angebot geschickt hast, wird dieses Angebot – und die Buchung, die daraus entsteht – weiterhin so abgerechnet, wie es dem Gast mitgeteilt wurde. Neue Angebote verwenden die neuen Bedingungen. ## Abrechnungsrechnungen [Section titled “Abrechnungsrechnungen”](#abrechnungsrechnungen) Wenn der Marktplatz-Modus aktiv ist, erstellst du die Abrechnungsrechnung (Provision) für eine Buchung selbst — die Veröffentlichung erzeugt sie nicht automatisch. Auf der **Rechnungen**-Karte der Buchung erstellt **Eigentümerrechnung erstellen** sie für den Eigentümer des jeweiligen Objekts (ausstehende oder bestätigte Buchungen); **Neue Rechnung** unter **Finanzen → Rechnungen** funktioniert jederzeit von Grund auf. Dein Provisionssatz wird unter **Einstellungen → Zahlungen** festgelegt. Siehe [Rechnungserstellung und Nummerierung](/de/docs/invoices/creation-and-numbering/). ## Eigentümer bei Buchungen [Section titled “Eigentümer bei Buchungen”](#eigentümer-bei-buchungen) Eine Buchung speichert **zu welchem Eigentümer sie gehört** zum Zeitpunkt ihrer Erstellung und zeigt diesen Eigentümer auf der Buchungsdetailseite an (mit Link zum Eigentümerprofil). Weil dies auf der Buchung festgehalten wird, leitet eine spätere Änderung des Eigentümers eines Objekts keine Zahlungen für bereits getätigte Buchungen still um. ## Buchungen bei einer Übergabe übertragen [Section titled “Buchungen bei einer Übergabe übertragen”](#buchungen-bei-einer-übergabe-übertragen) Wenn eine Immobilie den Eigentümer wechselt – etwa weil sie an einen neuen Eigentümer verkauft wird – öffne die **Eigentümer**-Seite des Objekts und nutze **Buchungen übertragen**. Ein kurzer Assistent lässt dich: 1. Den neuen Eigentümer auswählen. 2. Auswählen, welche der bestehenden Buchungen des Objekts verschoben werden sollen. 3. Bestätigen – und optional den neuen Eigentümer zum Standard für künftige Buchungen machen. Buchungen, die bereits an den aktuellen Eigentümer ausgezahlt wurden, können nicht übertragen werden, bis sie abgerechnet oder erstattet sind. # Konsolentour > Eine geführte Tour durch das Dashboard, die Navigation, den Kalender, die Befehlspalette und die Hilfe in der Reynt-Konsole. Diese Tour zeigt die Bereiche der Konsole, die du am häufigsten nutzt. Alles ist mandantenbezogen: Seitenleiste, Dashboard und Seiten spiegeln immer den Mandanten (die Organisation) wider, in dem du dich gerade befindest. ## Das Dashboard [Section titled “Das Dashboard”](#das-dashboard) Deine Startseite (**Dashboard**) ist eine gestapelte Sammlung von Widgets auf einen Blick: * **Übersicht**- und **Umsatz**-Statistikkarten — Summen für Buchungen, Buchungsanfragen und Objekte, plus Umsatzzahlen. Im Marktplatz-Modus siehst du zusätzlich Plattformumsatz und durchschnittliche Plattformgebühr. * **Buchungstrends** — ein Diagramm von Umsatz gegen Buchungszahl über die letzten Monate (der Zeitraum wird unter **Einstellungen → Identität** festgelegt). * **Letzte Aktivität** — die neuesten Buchungen und Anfragen, jeweils mit Link zur Detailansicht. * **Handlung erforderlich** und **Erfordert Aufmerksamkeit** — ausstehende Buchungsanfragen, Konversationen, die auf eine Antwort warten, und abgeleitete Warnungen (zum Beispiel ein Kalender-Sync- oder Mail-Fehler), jeweils mit einem Button, der dich direkt zur Aufgabe bringt. * **Erste Schritte** — die Onboarding-Checkliste für einen neuen Mandanten (siehe [Erste Schritte](/de/docs/getting-started/first-steps/)). Sie verschwindet, sobald du sie abschließt oder ausblendest; du kannst sie über **Einstellungen → Identität** wieder einblenden. * **Bevorstehende Check-ins** und **Inserateinrichtung** — deine nächsten Anreisen und Objekte, die noch Arbeit brauchen. ## Navigation [Section titled “Navigation”](#navigation) Die linke Seitenleiste ist danach gruppiert, was du gerade tust. Der obere Bereich ist der tägliche Arbeitsbereich — **Dashboard**, **Posteingang**, **Kalender**, **Buchungen**, **Anfragen** (und **Mail-Ausgang**, wenn die Bestätigungssperre aktiv ist) — gefolgt von den Gruppen **Objekte**, **Finanzen** und **Personen**. Badges an **Posteingang** und **Mail-Ausgang** zeigen, wie viele Einträge Aufmerksamkeit brauchen. Die Gruppe **Kunden-Oberfläche** und die **Smarte Suche** (unter Objekte) erscheinen erst, sobald du ein vollständig eingerichtetes Objekt hast — bis dahin bleibt die Seitenleiste auf den Kernbetrieb fokussiert. Einmal eingeblendet, bleiben sie sichtbar; bis dahin sind beide über die Befehlspalette oder direkte URL erreichbar. Unten öffnet das Zahnrad **Einstellungen** eine zweite Seitenleiste mit den Gruppen Konfiguration, Abrechnung, Kommunikation, Kataloge und Plattform — siehe [Mandanteneinstellungen](/de/docs/configuration/tenant-settings/). Die obere Leiste hat einen Button **Storefront ansehen**, der deine live geschaltete öffentliche Seite öffnet (oder eine Vorschau, falls sie noch nicht live ist), den KI-Assistenten, die Suche, die Benachrichtigungsglocke und den Organisationswähler. ## Globaler Kalender [Section titled “Globaler Kalender”](#globaler-kalender) **Kalender** zeigt jedes Objekt nebeneinander — eine Zeile pro Objekt, eine Spalte pro Tag des ausgewählten Monats. Jede Zelle ist farbcodiert (verfügbar, gebucht, vorgemerkt, blockiert, externer Kalender, kein Preis). Fahre über eine Zelle für Status, Grund und Preis, mit Links zum Öffnen der Buchung oder des eigenen Kalenders dieses Objekts. Filtere nach Titel oder Tags, um das Raster einzugrenzen. ## Befehlspalette und Suche [Section titled “Befehlspalette und Suche”](#befehlspalette-und-suche) Drücke **Cmd/Strg + K**, um die Befehlspalette zu öffnen. Tippe, um zu einer beliebigen Seite zu springen — einschließlich jeder Einstellungen-Seite und allem, was in der Seitenleiste ausgeblendet ist, wie die Kunden-Oberfläche-Seiten oder die Smarte Suche bei einem neuen Mandanten — oder suche live nach einem Objekt, einer Buchung, einer Anfrage, einem Kunden, Eigentümer, einer Rechnung, einer Konversation oder einer Storefront-Seite und öffne sie direkt. Ganz oben gibt es immer eine Option **KI fragen**, die deine Frage an das Assistenten-Panel übergibt. Zwei Abkürzungen lohnen sich: * **Referenzen springen direkt zum Datensatz.** Eine Buchungsreferenz wie `B9001` durchsucht nur Buchungen und Anfragen, eine Kundenreferenz wie `C1234` nur Gäste. Die genauen Präfixe richten sich nach dem, was du jeweils konfiguriert hast. * **`#` findet ein Objekt über seinen Schlüssel.** `#3` liefert jedes Objekt, dessen Schlüssel mit `3` beginnt — exakte Treffer zuerst, sonst nichts. Nützlich bei kurzen Schlüsseln: Eine bloße `3` liegt unter der Mindestlänge von zwei Zeichen und ginge selbst dann in allen Beschreibungen unter, in denen zufällig eine 3 vorkommt. ## Reynt fragen (KI-Assistent) [Section titled “Reynt fragen (KI-Assistent)”](#reynt-fragen-ki-assistent) Der Button **Reynt fragen…** in der oberen Leiste (Shortcut **Cmd/Strg + J**) öffnet den Assistenten als angedocktes Panel rechts. Er kann die Daten deines Mandanten lesen, Fragen beantworten und Änderungen vorschlagen, die du vor der Ausführung bestätigst. Wenn du auf einem Datensatz bist, benennt ihn ein kleiner Chip über dem Eingabefeld — du kannst also „diese Buchung“ sagen und dir die Referenz sparen. Den Chip kannst du jederzeit entfernen oder über **Kontext hinzufügen** weitere Datensätze ergänzen. Zwei verwandte Dinge sitzen daneben: * **KI-Aktivität** — das Symbol neben der Glocke öffnet ein Fach mit laufenden und kürzlich abgeschlossenen KI-Workflows, sodass du den Fortschritt verfolgen und Ergebnisse prüfen kannst, ohne die Seite zu verlassen (oder den Chat zu unterbrechen). * **Hilfe** — Hinweise zur aktuellen Seite, geöffnet über den **Hilfe**-Button dieser Seite; sie legt sich über den Chat, **Zurück zum Chat** bringt dich wieder heraus. Siehe [Der KI-Assistent](/de/docs/ai/assistant/) für das, was er kann. ## Kontextbezogene Hilfe [Section titled “Kontextbezogene Hilfe”](#kontextbezogene-hilfe) Seiten mit Hinweisen zeigen einen **Hilfe**-Button im Seiten-Header. Er öffnet das Assistenten-Panel auf dem Tab **Hilfe** mit Tipps speziell zu dieser Seite — nützlich bei Buchungen, Objektinhalten, dem Storefront-Seiteneditor und mehr. ## Benachrichtigungen [Section titled “Benachrichtigungen”](#benachrichtigungen) Die **Glocke** in der oberen Leiste fasst die Seitenleisten-Badges zusammen — ungelesene Posteingang-Konversationen und, wenn die Bestätigungssperre aktiv ist, im Mail-Ausgang wartende E-Mails. Öffne sie, um zu springen, wo du gebraucht wirst, oder sieh „Alles erledigt“. ## Organisation wechseln [Section titled “Organisation wechseln”](#organisation-wechseln) Wenn dein Konto zu mehr als einem Mandanten gehört, ist der Organisationsname oben in der Seitenleiste ein Wähler. Wähle eine andere Organisation, um die gesamte Konsole dorthin zu wechseln, oder wähle **Manage**, um alle deine Mandanten zu sehen. Deine letzte Wahl wird gespeichert. ## Dein Konto [Section titled “Dein Konto”](#dein-konto) Die Seite **Konto** verwaltet, wie *du* dich anmeldest — dein Profil (Name, E-Mail, Sprache) und Sicherheit (Passwort, Zwei-Faktor-Authentifizierung, Passkeys, aktive Sitzungen). Diese öffnen das sichere Zitadel-Kontoportal in einem neuen Tab. Kontoeinstellungen sind persönlich; sie ändern nicht die Mandantenkonfiguration. # Demo-Modus > Sieh eine Buchung einmal komplett durchlaufen — mit Beispielinhalten und Zahlungen, bei denen kein Geld fließt — bevor du irgendetwas einrichtest. Der Demo-Modus füllt einen neuen Workspace mit Beispielinhalten und stellt Zahlungen auf eine Testschiene um. So kannst du als Gast eine Buchung machen und zusehen, wie sie in deiner Konsole ankommt. Keine der Fragen auf der Livegang-Checkliste musst du vorher beantworten. Es gibt ihn, weil die Checkliste vierzehn Fragen stellt und nur vier davon tatsächlich etwas blockieren. Der Demo-Modus ist die Antwort auf „Kann ich das erst mal in Aktion sehen, bevor ich einen Nachmittag investiere?“ ## Starten [Section titled “Starten”](#starten) Auf der Seite **Live gehen** — dort landet ein neuer Workspace — bietet dir die erste Karte den Demo-Modus an. Ein Klick: * **Beispielinhalte** kommen dazu: ein eingerichtetes, bepreistes Objekt mit Fotos, ein kleiner Katalog aus Ausstattung und Merkmalen, eine veröffentlichte *Über uns*-Seite und eine Überschrift auf deiner Startseite. * **Testzahlungen** werden aktiviert und zu deiner Standard-Zahlungsart. * Deine **Website öffnet sich** in einem neuen Tab. Starten kannst du eine Demo nur, solange deine Website nicht veröffentlicht ist. Bei einer veröffentlichten Website wird das Angebot nicht angezeigt — der Start würde deine Live-Seite vom Netz nehmen. ## Deine Website bleibt währenddessen privat [Section titled “Deine Website bleibt währenddessen privat”](#deine-website-bleibt-währenddessen-privat) Das ist der Handel, und genau er macht den Demo-Modus sicher: Solange Testzahlungen an sind, ist deine öffentliche Website für niemanden erreichbar. Wer deine Adresse aufruft, sieht eine Wartungsseite. Du selbst kommst weiterhin hin — der Button **Website öffnen** gibt deinem Browser einen Vorschau-Pass, der alle Sperren aufhebt, auch die Prüfung, die Reynt gerade für deinen Workspace durchführt. Deshalb solltest du dem Link aus der Konsole folgen, statt deine Adresse einzutippen. ## Der komplette Durchlauf [Section titled “Der komplette Durchlauf”](#der-komplette-durchlauf) Das ist der Teil, der sich lohnt, und er dauert etwa zwei Minuten: 1. **Buche einen Aufenthalt** auf deiner eigenen Website, so wie ein Gast es täte. Nimm deinen eigenen Namen und deine E-Mail — hier erreicht nichts eine echte Person. 2. **Geh zurück in die Konsole.** Die Glocke oben hat einen neuen Eintrag: deine Buchungsanfrage. Klick sie an. 3. **Veröffentliche die Anfrage.** Daraus wird eine Buchung mit einer Zahlung. (Wenn du deinen Buchungsablauf auf Sofortbuchung umgestellt hast, gibt es keine Anfrage — es ist bereits eine Buchung.) 4. **Öffne die Zahlungsseite** über die Zahlungskarte der Buchung und bezahle. Die Testschiene ist mit einem Klick beglichen, und es fließt kein Geld. 5. **Schau dir an, was sich geändert hat** — Zahlungsverlauf, Rechnung, Kalender, Dashboard. Das ist alles die echte Maschinerie; nur das Geld fehlt. Solange dein Workspace auf die Prüfung durch Reynt wartet, werden E-Mails zurückgehalten — die Buchungsbestätigung und der Zahlungslink landen während der Demo also nicht in deinem Postfach. Alles oben erreichst du stattdessen über die Konsole. ## Währenddessen ändert sich ein Schritt der Checkliste [Section titled “Währenddessen ändert sich ein Schritt der Checkliste”](#währenddessen-ändert-sich-ein-schritt-der-checkliste) **Zahlungen einrichten** wird durch **Demo-Modus verlassen, um live zu gehen** ersetzt. Das ist Absicht: Die Testschiene ist keine Zahlungsart, die ein echter Gast nutzen kann — die Zahlungsfrage lässt sich während der Demo also gar nicht beantworten. Sie kommt zurück, unbeantwortet, sobald du die Demo verlässt. ## Verlassen [Section titled “Verlassen”](#verlassen) Verlassen kannst du jederzeit, und es ist ein Schritt auf der Livegang-Checkliste. Dabei wird: * die Testschiene abgeschaltet, * deine vorherige Zahlungsart wiederhergestellt (oder die erste aktive, falls es die vorherige nicht mehr gibt), * deine Website nicht länger von der Demo zurückgehalten — die übrigen Schritte zum Livegang gelten weiterhin. **Die Beispielinhalte bleiben.** Sie gehören jetzt dir: Benenne das Beispielobjekt in dein eigenes um, schreib die *Über uns*-Seite neu, oder lösch beides. Reynt kann ein bearbeitetes Beispiel nicht von einem Objekt unterscheiden, das du selbst angelegt hast — genau deshalb löscht es nichts für dich. **Der Demo-Modus ist eine einmalige Entscheidung.** Wenn du ihn verlassen hast, kannst du keine zweite Demo starten — die Beispiele lassen sich nicht erneut anlegen, eine zweite Demo würde also nur wieder deine Website abschalten. Möchtest du danach einen wirklich leeren Workspace, nutze **Einstellungen → Identität → Workspace zurücksetzen**: Das löscht Inhalte, behält aber deine Einstellungen. ## Demo-Modus und deine kostenlose Testphase sind zweierlei [Section titled “Demo-Modus und deine kostenlose Testphase sind zweierlei”](#demo-modus-und-deine-kostenlose-testphase-sind-zweierlei) Deine 14-tägige kostenlose Testphase läuft ab dem Tag deiner Anmeldung und läuft während einer Demo weiter. Früher aus dem Demo-Modus auszusteigen verkürzt sie nicht, und drin zu bleiben verlängert sie nicht — dir bleibt so oder so die verbleibende Zeit, und du kannst damit live gehen. # Erste Schritte > Vom frischen Mandanten zum ersten veröffentlichten Objekt und einer live geschalteten Storefront. Das ist der kürzeste Weg von einem brandneuen Mandanten zu einem veröffentlichten Objekt auf einer live geschalteten Storefront. Die Seite **Live gehen** verfolgt das alles für dich — ein neuer Mandant landet dort, sie steht in der Seitenleiste, und jeder Schritt öffnet die echte Einstellungskarte direkt an Ort und Stelle, statt dich woanders hinzuschicken. Dein Dashboard zeigt eine kurze Zusammenfassung davon. **Eilig, oder noch unsicher?** Der [Demo-Modus](/docs/getting-started/demo-mode/) füllt den Workspace mit Beispielinhalten und lässt dich eine Buchung komplett durchspielen — mit Zahlungen, bei denen kein Geld fließt — bevor du irgendetwas davon beantwortest. Keiner der Schritte unten steht dem im Weg. Die Checkliste hat zwei Stufen: **Erforderlich** (das brauchst du, um Buchungen anzunehmen) und **Empfohlen** (das machst du als Nächstes). Hier ist die Reihenfolge, die funktioniert. **Jeder erforderliche Schritt endet mit einem Button.** Ein Schritt ist erst erledigt, wenn du auf der Karte, die er öffnet, **Bestätigen** drückst (oder **Speichern**, wenn du etwas geändert hast) — nicht schon dann, wenn die Einstellung zufällig passt. Für mehrere dieser Fragen ist bereits eine sinnvolle Voreinstellung gesetzt, und die Checkliste führt dich einmal an jeder davon vorbei, damit du weißt, womit du arbeitest, statt es später herauszufinden. Wenn die Karte eines Schritts so passt, wie sie ist: Bestätigen drücken und weiter — es wird nichts geschrieben, und die Zeile schließt sich. Ein paar Schritte haben keinen eigenen Button: dein erstes Objekt oder dein erster Eigentümer beantwortet sich dadurch, dass du ihn anlegst, und die Prüfung deines Workspace schließen wir, nicht du. ## 1. Geschäftsname festlegen [Section titled “1. Geschäftsname festlegen”](#1-geschäftsname-festlegen) Öffne **Einstellungen → Identität** und lege deinen Geschäftsnamen fest, zusammen mit Währung, Zeitzone und Logo. Das ist die Identität deines Mandanten über Konsole, Storefront und E-Mails hinweg. ## 2. Rechtliche Angaben hinzufügen [Section titled “2. Rechtliche Angaben hinzufügen”](#2-rechtliche-angaben-hinzufügen) Füge unter **Einstellungen → Rechtliches** deinen rechtlichen (Firmen-)Namen, Adresse, Land und eine rechtliche Kontakt-E-Mail hinzu. Diese erscheinen auf Rechnungen und rechtlichen Seiten, und die Storefront geht ohne sie nicht live. ## 3. Zahlungsmethode einrichten [Section titled “3. Zahlungsmethode einrichten”](#3-zahlungsmethode-einrichten) Aktiviere unter **Einstellungen → Zahlungen** die Banküberweisung und trage IBAN sowie Kontoinhaber ein. Ohne Zahlungsmethode werden Buchungen ohne Zahlungspflicht veröffentlicht. Siehe [Zahlungsanbieter](/de/docs/payments/providers/). ## 4. Benachrichtigungs-E-Mail festlegen [Section titled “4. Benachrichtigungs-E-Mail festlegen”](#4-benachrichtigungs-e-mail-festlegen) Lege unter **Einstellungen → E-Mail-Zustellung** die Adresse fest, die Benachrichtigungen für neue Buchungen und Anfragen erhalten soll. Andernfalls wirst du nicht per E-Mail benachrichtigt, wenn Gäste buchen. Siehe [E-Mail-Zustellung](/de/docs/configuration/tenant-settings/). ## 5. Stornierungsbedingungen festlegen [Section titled “5. Stornierungsbedingungen festlegen”](#5-stornierungsbedingungen-festlegen) Erstelle eine Richtlinie unter **Einstellungen → Stornierungsrichtlinien** und wähle sie als Standard in **Einstellungen → Buchungseinstellungen**. Siehe [Stornierungen & Erstattungen](/de/docs/bookings/cancellations-and-refunds/). ## 6. (Nur Marktplatz) Eigentümer hinzufügen [Section titled “6. (Nur Marktplatz) Eigentümer hinzufügen”](#6-nur-marktplatz-eigentümer-hinzufügen) Wenn dein Mandant im Marktplatz-Modus läuft, füge mindestens einen Eigentümer unter **Eigentümer** hinzu — in diesem Modus kann ein Objekt ohne zugewiesenen Eigentümer nicht veröffentlicht werden. Im Direktmodus gibt es keine Eigentümer, und du kannst diesen Schritt überspringen. Siehe [Eigentümer](/de/docs/customers-and-owners/owners/). ## 7. Erstes Objekt erstellen [Section titled “7. Erstes Objekt erstellen”](#7-erstes-objekt-erstellen) Gehe zu **Objekte** und klicke, um eines zu erstellen. Der Standardablauf ist der **KI-Import**: füge eine URL, Text oder ein PDF ein, oder lade Fotos hoch, und Reynt extrahiert die Details und generiert Inhalte in allen deinen Sprachen. Möchtest du lieber selbst eintippen? Wechsle zu **Details manuell eingeben**. Siehe [Objekt erstellen](/de/docs/listings/create-a-listing/). ## 8. Kritische Punkte ausfüllen und veröffentlichen [Section titled “8. Kritische Punkte ausfüllen und veröffentlichen”](#8-kritische-punkte-ausfüllen-und-veröffentlichen) Ein neues Objekt startet als **Entwurf**. Der Vollständigkeitsbalken am Objekt zeigt, was noch fehlt. Um den Entwurfsstatus zu verlassen und veröffentlichbar zu werden, braucht ein Objekt mindestens ein **Bild**, ein **Hauptbild** und **Preise** (plus einen **Eigentümer** im Marktplatz-Modus). Sobald das erledigt ist, aktiviert sich der **Veröffentlichen**-Button im Objekt-Header — klicke ihn, um das Objekt auf deiner Storefront live zu schalten. Siehe [Veröffentlichung & Sichtbarkeit](/de/docs/listings/publishing-and-visibility/). ## 9. Storefront live schalten [Section titled “9. Storefront live schalten”](#9-storefront-live-schalten) Das Veröffentlichen eines Objekts schaltet deine öffentliche Seite nicht von selbst live. Unter **Einstellungen → Kunden-Oberfläche** listet der Abschnitt **Storefront veröffentlichen** vier Voraussetzungen auf: ein **Impressum**, eine **Datenschutzerklärung**, eine **Benachrichtigungs-E-Mail** und eine **Zahlungsmethode**. Sobald alle vier erfüllt sind, aktiviere **Storefront live**. ## 10. (Optional) Eigene Domain verwenden [Section titled “10. (Optional) Eigene Domain verwenden”](#10-optional-eigene-domain-verwenden) Weiterhin unter **Einstellungen → Kunden-Oberfläche** lässt dich der Abschnitt **Eigene Domains** deine eigene Domain hinzufügen (zum Beispiel `booking.meinedomain.com`). Füge sie hinzu, erstelle den angezeigten CNAME-Eintrag und klicke dann auf **DNS prüfen**. Sobald sie aktiv ist, kannst du sie **Als primär setzen**. Siehe [Domains & SEO](/de/docs/storefront/domains-and-seo/). ## 11. (Optional) E-Mails von der eigenen Domain versenden [Section titled “11. (Optional) E-Mails von der eigenen Domain versenden”](#11-optional-e-mails-von-der-eigenen-domain-versenden) Standardmäßig versendet Reynt deine Gast-E-Mails in deinem Namen von einer Plattform-Adresse („Dein Name über Reynt“). Damit sie stattdessen von einer Adresse auf deiner eigenen Domain kommen, hinterlege unter **Einstellungen → E-Mail-Zustellung** deinen eigenen Mailserver — SMTP, Brevo oder Mailjet — und setze die Absenderadresse auf eine Adresse deiner Domain. Das setzt nicht nur deinen Namen auf den Umschlag, sondern richtet auch SPF, DKIM und DMARC auf deine Domain aus — genau das hält deine E-Mails aus dem Spam-Ordner. Siehe [Benachrichtigungen & E-Mail](/de/docs/communication/notifications-and-email/). Diese beiden letzten Schritte sind optional: deine Storefront läuft und deine E-Mails gehen raus, auch ohne sie. Auf der Seite **Live gehen** erscheinen sie unter **Empfohlen**, sobald du live bist. # Willkommen bei Reynt > Eine kurze Orientierung zur Reynt-Plattform und was jeder Bereich der Admin-Konsole macht. Reynt ist eine Vermietungsmanagement-Plattform, die um drei Ideen herum aufgebaut ist: **Objekte** (die Unterkünfte, die du vermietest), **Buchungen** (die Reservierungen dazu) und deine **Storefront** (die öffentliche Website, auf der Gäste stöbern und buchen). Du steuerst alles über die Admin-Konsole. ## Wer nutzt die Konsole? [Section titled “Wer nutzt die Konsole?”](#wer-nutzt-die-konsole) Die Konsole ist für Betreiber gedacht — Property-Manager, Host-Teams und Marktplatz-Betreiber. Gäste sehen sie nie; sie sehen deine Storefront. Jede Person in deinem Team loggt sich mit einem eigenen Konto ein, und du legst unter **Einstellungen → Mitglieder** fest, was sie tun darf (siehe [Mitglieder & Rollen](/de/docs/configuration/members-and-roles/)). ## Die großen Bausteine [Section titled “Die großen Bausteine”](#die-großen-bausteine) Die linke Seitenleiste der Konsole gruppiert alles, was du brauchst. Der obere Bereich ist dein täglicher Arbeitsbereich, gefolgt von benannten Gruppen: * **Operate** — das **Dashboard**, der **Posteingang** für Gästenachrichten, der **Kalender** über alle Objekte hinweg, dazu **Buchungen** und **Anfragen**. Wenn du die E-Mail-Bestätigungssperre aktivierst, erscheint hier auch ein **Mail-Ausgang**. * **Objekte** — jedes Objekt, das du vermietest, plus **Smarte Suche**-Analysen. * **Finanzen** — **Zahlungen** und **Rechnungen**. * **Personen** — **Kunden**, und **Eigentümer**, wenn du im Marktplatz-Modus arbeitest. * **Kunden-Oberfläche** — deine öffentliche Seite: **Seiten**, **Navigation**, **Blog**, **Medien**, **Aktionen** und **Erscheinungsbild**. * **Einstellungen** (das Zahnrad unten) — die gesamte Mandantenkonfiguration, gegliedert in Konfiguration, Abrechnung, Kommunikation, Kataloge und Plattform. Kataloge enthält die wiederverwendbaren Bausteine, auf die Objekte zurückgreifen — **Ausstattung**, **Attribute**, **Objekttypen**, **Tags**, **Orte** und **Entfernungen** — und Konfiguration enthält **Weiterleitungen** für die Kunden-Oberfläche. Siehe [Mandanteneinstellungen](/de/docs/configuration/tenant-settings/). Die Gruppe **Kunden-Oberfläche** und die **Smarte Suche** erscheinen in der Seitenleiste erst, sobald du ein vollständig eingerichtetes Objekt hast; bis dahin sind sie über die Befehlspalette oder direkte URL erreichbar. Alles unter **Einstellungen** ist immer sichtbar. ## Direkt- vs. Marktplatz-Modus [Section titled “Direkt- vs. Marktplatz-Modus”](#direkt--vs-marktplatz-modus) Ein Mandant läuft in einem von zwei Modi, der bei der Erstellung festgelegt wird: * **Direkt** — du verwaltest deine eigenen Objekte. Es gibt keine separaten Eigentümer. * **Marktplatz** — du verwaltest Objekte im Auftrag externer Eigentümer. Ein zusätzlicher Bereich **Eigentümer** erscheint, jedes Objekt gehört einem Eigentümer, und Eigentümer-Abrechnungsrechnungen kommen ins Spiel. Der Modus ist für einen Mandanten fest vorgegeben und wird (nur lesbar) unter **Einstellungen → Identität** angezeigt. ## Mehrere Marken [Section titled “Mehrere Marken”](#mehrere-marken) Jeder Reynt-Mandant ist vollständig isoliert — eigene Objekte, Gäste, Rechnungen und Markenauftritt. Wenn du mehr als eine Marke betreibst, führe sie als separate Mandanten und wechsle zwischen ihnen über den Organisationswähler oben in der Seitenleiste. Bereit für die Einrichtung? Weiter zu [Erste Schritte](/de/docs/getting-started/first-steps/). # Rechnungserstellung und -nummerierung > Wann Reynt Rechnungen erstellt, der Rechnungs-Editor, wie die Nummerierung funktioniert und wie du mit Gutschriften korrigierst. Rechnungen werden immer von Hand erstellt und korrigiert — Reynt erstellt nie automatisch eine. Rechnungsstellung ist ein Hauptschalter (**Rechnungen aktivieren** unter **Einstellungen → Rechnungen**), der unabhängig davon ist, ob du Zahlungen entgegennimmst. ## Wann Rechnungen erstellt werden [Section titled “Wann Rechnungen erstellt werden”](#wann-rechnungen-erstellt-werden) * **Aus einer Buchung heraus** — auf der **Rechnungen**-Karte der Buchung erstellt **Rechnung erstellen** (Direkt-Modus) oder **Eigentümerrechnung erstellen** (Marktplatz-Modus) die **Kundenrechnung** bzw. die **Eigentümer-Abrechnungsrechnung (Provisionsrechnung)** für diese Buchung; beide stehen für ausstehende oder bestätigte Buchungen zur Verfügung. **Individuelle Rechnung erstellen** funktioniert bei jedem Buchungsstatus. * **Jederzeit manuell** — nutze **Neue Rechnung** auf der Seite **Finanzen → Rechnungen**, um eine für einen beliebigen Empfänger von Grund auf zu erstellen. * **Änderungen und Stornierungen erstellen keine Rechnungen** — sie bewegen nur Geld (eine Erstattungsverpflichtung wird erfasst, die du von Hand abgleichst); betrifft die Änderung eine bereits ausgestellte Rechnung, korrigiere sie selbst mit einer Gutschrift. Siehe [Buchung ändern](/de/docs/bookings/modify-a-booking/). ## Rechnungsempfänger [Section titled “Rechnungsempfänger”](#rechnungsempfänger) Jede Rechnung hat einen **Empfängertyp** (ihr *Target*): * **Kunde** — die Rechnung an den Gast (Direkt-Modus). * **Eigentümer** — die Provisions-/Abrechnungsrechnung an einen Eigentümer (Marktplatz-Modus). Verlegst und bepreist du eine Buchung neu, wird diese nicht automatisch neu erstellt — korrigiere sie von Hand (eine Gutschrift plus eine neue Rechnung), falls sich die Abrechnung ändert. *Lieferant* existiert der Vollständigkeit halber ebenfalls als Ziel, aber mit **Kunde** und **Eigentümer** wirst du hauptsächlich arbeiten. ## Der Rechnungs-Editor [Section titled “Der Rechnungs-Editor”](#der-rechnungs-editor) Du bearbeitest eine Rechnung auf ihrer Detailseite — jeder Abschnitt hat sein eigenes **Bearbeiten**-Modal, und Bearbeitung ist nur möglich, solange die Rechnung ein **Entwurf** ist (einmal ausgestellt, ist eine Rechnung gesperrt). Die Abschnitte sind: * **Empfänger** — Empfängertyp, Name, E-Mail und USt-IdNr. * **Positionen** — eine Zeile pro Posten, jeweils mit einem Typ (*Unterkunft*, *Zusatzleistung*, *Reinigungsgebühr*, *Rabatt*, *Steuer*), Beschreibung, Menge, Einheit und Einzelpreis. * **Einstellungen** — Rechnungstyp, Währung, Fälligkeitsdatum und Steueroptionen (Steuerland, Sätze und Befreiungsgrund). * **Benutzerdefinierter Text** — Freitextblöcke, die oberhalb, unterhalb oder rund um die Rechnungsdetails platziert werden. Tippe `$`, um Vorlagenvariablen einzufügen, oder wende eine Buchungsvorlage an, um sie zu befüllen. Eine **Zahlungsplan**-Karte wird ebenfalls angezeigt, ist aber nur lesbar — sie spiegelt die Zahlungsraten der Buchung wider, statt auf der Rechnung bearbeitet zu werden. ## Nummerierung [Section titled “Nummerierung”](#nummerierung) Rechnungsnummern verwenden eine Sequenz pro Tenant: ein **Präfix** (Standard `I`, eingestellt als **Rechnungsnummer-Präfix** unter **Einstellungen → Referenzen**) plus eine fortlaufende Nummer, formatiert wie `I-2026-00001`. Die Sequenz **setzt sich jedes Jahr zurück**. Du kannst eine **Nächste Rechnungsnummer** als Untergrenze festlegen (auch unter **Einstellungen → Referenzen**), um vorzuspringen — nützlich bei der Migration von einem anderen System. Die nächste Rechnung nimmt die höhere der natürlichen nächsten Nummer oder deiner Untergrenze; sie wird nicht rückwirkend angewendet. Es gibt eine Sequenz pro Konto — Reynt bietet keine separaten konfigurierbaren Nummernsequenzen pro Geschäftseinheit an. ## Korrekturen mit Gutschriften [Section titled “Korrekturen mit Gutschriften”](#korrekturen-mit-gutschriften) Ausgestellte Rechnungen können nicht bearbeitet werden. Um eine zu korrigieren, öffne sie und wähle **Gutschrift erstellen**. Die Gutschrift storniert das Original vollständig und verweist darauf, sodass die Prüfspur erhalten bleibt, die die meisten Steuerbehörden verlangen. Erstelle danach bei Bedarf eine neue Rechnung mit den korrigierten Positionen. (Eine Abwärts-Änderung an einer Buchung erstellt sie nicht automatisch für dich — prüfe, ob eine ausgestellte Rechnung korrigiert werden muss, und erstelle die Gutschrift selbst.) **Stornieren** verhält sich je nach Status unterschiedlich: Ein Entwurf wird einfach storniert, aber das Stornieren einer ausgestellten Rechnung erstellt eine separate **Stornorechnung**, die sie storniert — auch hier, damit die Papierspur intakt bleibt. # Zahlungsstatus und PDFs > Wie eine Rechnung den Zahlungsstatus verfolgt und wie Rechnungs-PDFs erstellt werden und Gäste erreichen. Eine Rechnung verfolgt zwei Dinge: wo sie sich in ihrem Lebenszyklus befindet (Entwurf → ausgestellt → bezahlt) und wie ihre PDF aussieht. Tatsächliches Geld wird gegen die **Buchung** erfasst, nicht gegen die Rechnung — der Zahlungsstatus der Rechnung folgt automatisch. ## Rechnungsstatus [Section titled “Rechnungsstatus”](#rechnungsstatus) * **Entwurf** — bearbeitbar, noch kein rechtsgültiges Dokument. * **Ausgestellt** — finalisiert und nummeriert; kann nicht mehr bearbeitet werden. * **Teilweise bezahlt** — ein Teil des Gesamtbetrags ist eingegangen. * **Bezahlt** — vollständig beglichen. * **Storniert** — storniert (ein Entwurf wird direkt storniert; eine ausgestellte Rechnung wird mit einer Stornorechnung storniert — siehe [Rechnungserstellung und -nummerierung](/de/docs/invoices/creation-and-numbering/)). Du filterst die Liste **Finanzen → Rechnungen** nach Status (und nach Empfänger), um zu finden, was noch offen ist. ## Wie der Zahlungsstatus verfolgt wird [Section titled “Wie der Zahlungsstatus verfolgt wird”](#wie-der-zahlungsstatus-verfolgt-wird) Bei Rechnungen, die an eine Buchung gebunden sind, wird der Zahlungsstatus **automatisch synchronisiert** aus den Zahlungen der Buchung. Erfasst du eine Überweisung auf der **Zahlung**-Karte der Buchung, wechselt die verknüpfte Rechnung von selbst zu *Teilweise bezahlt* oder *Bezahlt*. Die **Zahlung**-Karte der Rechnung ist nur lesbar und spiegelt lediglich die Zahlungsübersicht der Buchung. Du kannst den Status einer Rechnung auch direkt mit **Als bezahlt markieren** setzen — nützlich für manuelle oder plattformfremde Rechnungen, die nicht von den Zahlungsraten einer Buchung gesteuert werden. Es gibt keinen separaten Schritt „eine Zahlung auf der Rechnung erfassen“; erfasse das Geld auf der Buchung (siehe [Wie Zahlungen funktionieren](/de/docs/payments/overview/)). ## PDFs [Section titled “PDFs”](#pdfs) Jede Rechnung erzeugt eine PDF, die du von ihrer Detailseite aus per **PDF-Vorschau** oder **PDF herunterladen** abrufen kannst. Die PDF wird erstellt aus: * Den Positionen und Summen der Rechnung. * Deinen **benutzerdefinierten Textblöcken** — dem Textinhalt, den du rund um die Rechnungsdetails anordnest, mit ausgefüllten Vorlagenvariablen. * Dem **Fußzeilentext** — bis zu zwei zusätzliche Fußzeilenspalten, die du als *Fußzeilentext 1* und *Fußzeilentext 2* unter **Einstellungen → Rechnungen** festlegst. PDFs werden in der **Sprache des Empfängers** gerendert: Die Rechnung friert die Buchungssprache des Gastes (und den lokalisierten Fußzeilentext) bei ihrer Erstellung ein, sodass der Gast die Rechnung immer in der Sprache erhält, in der er gebucht hat. ## Wie Gäste ihre Rechnungen erhalten [Section titled “Wie Gäste ihre Rechnungen erhalten”](#wie-gäste-ihre-rechnungen-erhalten) Gäste greifen über den **Storefront** auf ihre Rechnungs-PDF zu, über den sicheren Link zu ihrer Buchung — denselben Ort, an dem sie ihre Reservierung verwalten. Die Rechnung wird nicht als E-Mail-Anhang verschickt; sie steht auf Abruf zum Download bereit. # Steuern und MwSt. > Konfiguriere MwSt.-Sätze und -Anzeige sowie das erstklassige Modell für die Stadt-/Tourismusabgabe. Reynt behandelt zwei unterschiedliche Arten von Steuern: **MwSt.** auf Unterkunft und Leistungen, und eine separate **Stadt-/Tourismusabgabe**. Sie werden an unterschiedlichen Stellen konfiguriert und verhalten sich unterschiedlich. ## MwSt.-Einstellungen [Section titled “MwSt.-Einstellungen”](#mwst-einstellungen) Aktiviere die MwSt. und wähle, wie sie angezeigt wird, unter **Einstellungen → Rechnungen → Steuereinstellungen**: * **Steuer aktivieren** — der Hauptschalter. Wenn deaktiviert, sind alle Beträge steuerfrei. * **Kunden Steuer berechnen** — lässt dich Kundenpreise steuerfrei halten (z. B. als Kleinunternehmer), während auf Eigentümer-Abrechnungsrechnungen weiterhin Steuer anfällt. * **Kunden-Steuermodus** — *Brutto* (Preise inkl. Steuer, der B2C-Standard) oder *Netto* (Steuer wird aufgeschlagen). * **Abrechnungs-Steuermodus** (nur Marktplatz) — *Brutto* oder *Netto* (der B2B-Standard) für Eigentümer-Abrechnungsrechnungen. * **Steuerbefreiungstext-Überschreibungen** — der Hinweis, der auf einer Rechnungs-PDF gedruckt wird, wenn eine Steuerbefreiung gilt, den du pro Grund und Sprache anpassen kannst. Deine eigene USt-IdNr. stammt aus den **Rechtlichen Angaben**; die USt-IdNr. des Empfängers wird pro Rechnung im Editor eingegeben. ## Ländersteuersätze [Section titled “Ländersteuersätze”](#ländersteuersätze) MwSt.-Prozentsätze findest du unter **Einstellungen → Steuersätze** (*Ländersteuersätze*). Füge eine Zeile pro Land mit einem **Unterkunftssatz (%)** und einem **Dienstleistungssatz (%)** hinzu — zum Beispiel 7% für Unterkunft und 19% für Dienstleistungen in Deutschland. Du kannst gängige Sätze mit **Aus Katalog hinzufügen** importieren. Wird eine Rechnung erstellt, ermittelt Reynt das Land (das Land des Objekts, ersatzweise dein registriertes Land), sucht die passenden Sätze und wendet den Unterkunfts- oder Dienstleistungssatz auf jede Position gemäß ihrer Kategorie an. Ist die Steuer aktiviert, aber existiert kein Satz für das Land, ist die Rechnungserstellung blockiert, bis du einen hinzufügst. ## Steuerbefreiungen und Reverse-Charge [Section titled “Steuerbefreiungen und Reverse-Charge”](#steuerbefreiungen-und-reverse-charge) Jede Rechnung kann einen **Steuerbefreiungsgrund** tragen — darunter *Reverse-Charge*, *Export*, *Befreit*, *Kleinunternehmerregelung* und *Differenzbesteuerung* —, der den entsprechenden 0%-Hinweis auf der PDF zeigt. Bei grenzüberschreitenden Marktplatz-Abrechnungsrechnungen setzt Reynt dies automatisch anhand der Geografie: gleiches Land ist Inland, ein anderes EU-Land ist Reverse-Charge, und ein Objekt außerhalb der EU wird als Export behandelt. Du kannst den Grund auch manuell auf jeder Rechnung setzen. Reynt validiert USt-IdNrn. **nicht** gegen VIES — trage die USt-IdNr. des Empfängers ein und wähle den Befreiungsgrund selbst. ## Stadt-/Tourismusabgabe [Section titled “Stadt-/Tourismusabgabe”](#stadt-tourismusabgabe) Viele Städte erheben eine Tourismusabgabe zusätzlich zum Unterkunftspreis. Dies ist ein erstklassiges Modell, konfiguriert pro **Reiseziel** (unter **Reiseziele → Kurtaxe / Tourismusabgabe**) und pro Objekt überschreibbar. Eine Regel legt fest: * **Berechnungsbasis** — *pro Person pro Nacht*, *pro Nacht* (ein fester Betrag pro Nacht) oder *Prozentsatz* der Unterkunfts-Gesamtsumme. * **Staffelsätze** — ein oder mehrere Sätze, jeweils optional beschränkt auf eine **Saison** (wiederkehrendes Datumsfenster) und bestimmte **Objekttypen**. Die passendste Stufe gilt für jede Nacht. * **Nächte-Obergrenze** — eine maximale Anzahl besteuerter Nächte (z. B. die ersten 10). * **Kinderfreigrenze** — ein Alter, unterhalb dessen Gäste nicht gezählt werden. * **Erhebung** — wie die Steuer abgewickelt wird: * **Zusätzlich berechnet** — wird zusätzlich zur Buchung erhoben; sie erscheint als *Kurtaxe*-Position auf der Rechnung und als *Kurtaxe*-Rate bei der Zahlung. * **Im Preis enthalten** — bereits im Unterkunftspreis enthalten; wird nur zur Information angezeigt. * **Separat zu zahlen** — dem Gast offengelegt, aber außerhalb der Buchung eingezogen (z. B. bar bei Anreise oder über ein Stadtportal), mit einem optionalen Hinweis, wie zu zahlen ist. Die Tourismusabgabe wird Gästen im Storefront während der Buchung angezeigt, und — im Modus *zusätzlich berechnet* — fließt sie in die Rechnung und die Zahlung ein. Im Marktplatz-Modus wird die zusätzlich berechnete Tourismusabgabe an den Eigentümer weitergereicht und auf der Abrechnungsrechnung ausgewiesen. # Mehrsprachige Inhalte > Lege die Sprachen fest, in denen dein Unternehmen tätig ist, und übersetze jeden kundenseitigen Text. Reynt ist durchgängig mehrsprachig. Du legst die Sprachen fest, die dein Unternehmen unterstützt, und jeder Text, den du verfasst — Objekte, Katalogbezeichnungen, Website-Inhalte, Blogbeiträge und E-Mail-Vorlagen — kann einmal pro Sprache geschrieben werden. Der Storefront liefert jedem Besucher seine Sprache aus, und Gäste-E-Mails und -Dokumente werden in der vom Gast gewählten Sprache versendet. ## Wähle deine Sprachen [Section titled “Wähle deine Sprachen”](#wähle-deine-sprachen) Öffne **Einstellungen → Sprachen**, um den Sprachumfang für dein Konto festzulegen. * **Unterstützte Sprachen** — die Sprachen, in die Betreiber Inhalte übersetzen können. Gängige Voreinstellungen (Englisch, Deutsch, Französisch, Italienisch, Spanisch, Niederländisch, Ungarisch und andere) erscheinen im Dropdown, und du kannst jedes beliebige BCP-47-Kürzel eingeben (zum Beispiel `pt`, `pl`, `cs`, `sv`). * **Standardsprache** — der Fallback für ausgehende E-Mails, Rechnungs- und Buchungs-PDFs, KI-generierte Inhalte, Zahlenformatierung und jedes Feld, das noch nicht übersetzt wurde. Sie muss eine deiner unterstützten Sprachen sein. Fehlt eine Übersetzung für eine Sprache, fällt der Storefront auf die Standardsprache zurück, statt eine Lücke zu zeigen — die Standardsprache sollte daher immer deine vollständigste sein. ### Formelles vs. informelles Deutsch [Section titled “Formelles vs. informelles Deutsch”](#formelles-vs-informelles-deutsch) Deutsch hat zwei Registervarianten: `de` (du) und `de-formal` (Sie). Wähle **eine** — beide werden unter derselben `/de/`-Storefront-URL ausgeliefert, du kannst also nicht beide gleichzeitig aktivieren. Dieselbe formelle/informelle Option steht auch für andere Sprachen zur Verfügung, die sie benötigen. ### Schutzmechanismen beim Ändern von Sprachen [Section titled “Schutzmechanismen beim Ändern von Sprachen”](#schutzmechanismen-beim-ändern-von-sprachen) Zwei Änderungen werden vor dem Speichern bestätigt, weil sie bestehende Inhalte betreffen: * **Ändern der Standardsprache** — Inhalte sind unter der aktuellen Standardsprache gespeichert, daher kann nach dem Wechsel jedes Feld ohne Wert in der neuen Standardsprache leer erscheinen, bis du es übersetzt. * **Entfernen einer unterstützten Sprache** — bereits in diese Sprache übersetzte Inhalte werden im Storefront ausgeblendet, aber nichts wird gelöscht. Füge die Sprache später erneut hinzu, um sie wiederherzustellen. Du siehst außerdem nicht blockierende Warnungen, wenn eine unterstützte Sprache **keine E-Mail-Vorlage** hat (Buchungs-E-Mails fallen auf die Standardsprache zurück) oder **keine Storefront-Route** (Besucher, die sie wählen, sehen den englischen Storefront, bis Unterstützung hinzugefügt wird). ## Was übersetzbar ist [Section titled “Was übersetzbar ist”](#was-übersetzbar-ist) Nahezu jeder von Betreibern verfasste, kundenseitige Text trägt einen Wert pro Sprache: * **Objekte** — Titel, Auszug, Beschreibung, Ausstattung/Preise/Rabatttext, Kundeninformationen, SEO-Titel und -Beschreibung sowie Bildbeschriftungen. * **Katalog** — Bezeichnungen für Ausstattung, Attribute, Entfernungen, Tags und Objekttypen sowie Ortsnamen und -beschreibungen. * **Website-Inhalte** — CMS-Seitentitel, Slugs, Inhaltsabschnitte, Menübezeichnungen und Blogbeiträge. * **Benachrichtigungen** — sprachspezifische E-Mail- und Benachrichtigungsvorlagentexte (siehe **Einstellungen → Benachrichtigungen**). * **Einstellungen** — Storefront-SEO-Titel und -Beschreibung, Kontaktadresse, Buchungsseiten-Nachrichten, Optionen für die Herkunftsquelle und Alt-Texte für Partner-Logos. ## Pro Sprache bearbeiten [Section titled “Pro Sprache bearbeiten”](#pro-sprache-bearbeiten) Wo immer ein Feld übersetzbar ist, zeigt der Editor einen **Sprach-Tab pro unterstützter Sprache** — fülle jeden Tab aus, oder lasse eine Sprache leer, um auf die Standardsprache zurückzufallen. Felder tragen außerdem einen kleinen **KI**-Button, der den Text über deine Sprachen hinweg generieren oder übersetzen kann; siehe [Inhaltsgenerierung und Übersetzung](/de/docs/ai/content-generation-and-translation/). Um alles noch Unübersetzte an einem Ort zu finden, nutze die [Übersetzungen-Seite](/de/docs/languages/translations-page/). ## Verhalten des Storefronts [Section titled “Verhalten des Storefronts”](#verhalten-des-storefronts) Sobald du mehr als eine Sprache unterstützt, wird der Storefront vollständig lokalisiert: * **Sprachpräfixierte URLs** — jede Seite liegt unter einem Sprachpräfix (`/en/…`, `/de/…`), und ein Sprachumschalter im Header lässt Besucher die Sprache wechseln. * **Automatische Erstbesuchs-Sprache** — einem neuen Besucher wird seine Browsersprache zugeordnet (mit Fallback auf deine Standardsprache), und seine Wahl wird für wiederkehrende Besuche gemerkt. * **SEO** — jede Seite gibt `hreflang`-Alternativen und eine kanonische URL aus und erscheint in einer sprachspezifischen Sitemap, damit Suchmaschinen jede Sprache korrekt indexieren. ## Sprache der Kundenkommunikation [Section titled “Sprache der Kundenkommunikation”](#sprache-der-kundenkommunikation) Jede Buchung speichert eine **Kommunikationssprache**, sodass die Bestätigungs-E-Mails, Rechnungen und Buchungs-PDFs des Gasts in der von ihm verwendeten Sprache versendet werden. Du kannst sie bei der Buchung (oder Buchungsanfrage) unter **Kommunikationssprache** ändern, und jeder Kundendatensatz trägt ein **Sprache**-Feld, das für von Betreibern erstellte Buchungen verwendet wird. Eigentümer- und interne Betreiber-E-Mails verwenden immer deine Standardsprache. # Übersetzungen-Seite > Finde jede fehlende Übersetzung in deinen Inhalten und schließe die Lücken mit KI-Prüfung. Die **Übersetzungen**-Seite sammelt jeden fehlenden Übersetzungswert in deinem gesamten Konto — Objekte, Katalog, Website-Inhalte, Benachrichtigungen und Einstellungen — in einer Tabelle, damit du nie durch einzelne Editoren suchen musst, um zu finden, was noch unübersetzt ist. Öffne sie im Einstellungsbereich unter **Einstellungen → Übersetzungen** (sie erscheint neben **Einstellungen → Sprachen**). Hat dein Konto nur eine unterstützte Sprache, sagt dir die Seite, dass es nichts zu übersetzen gibt, und verlinkt dich zum Hinzufügen weiterer Sprachen. ## Nach Lücken suchen [Section titled “Nach Lücken suchen”](#nach-lücken-suchen) Die Vollständigkeitsprüfung ist gründlich, daher läuft sie nur auf Anfrage. Klicke auf **Jetzt prüfen**, um jeden Text zu durchsuchen; das Ergebnis wird für deine Sitzung zwischengespeichert und übersteht das Navigieren in einen Editor und zurück. Nutze **Aktualisieren**, um sie nach Änderungen erneut auszuführen. Nach einer Prüfung siehst du: * Eine **Zusammenfassung pro Sprache** — ein Badge pro Sprache, das zeigt, wie viele Werte noch fehlen, sowie eine laufende Gesamtzahl. * Eine **Übersichtstabelle**, gegliedert in **Unterkünfte**, **Katalog & Verkauf**, **Website-Inhalte**, **Benachrichtigungen & E-Mails** und **Einstellungen**. Jede Zeile nennt die Entität und die fehlenden Felder sowie die Sprachen, in denen sie fehlen. Filtere die Tabelle nach Bereich oder nach einer einzelnen Sprache, um dich zu fokussieren. Jede Zeile hat eine **Öffnen**-Aktion, die direkt zum zugehörigen Editor führt (das Objekt, der Katalogeintrag, die Seite, die E-Mail-Vorlage oder die Einstellung), damit du es im Kontext beheben kannst. Fehlt nichts, zeigt die Seite **Alle Übersetzungen vollständig**. ## Mit KI ausfüllen [Section titled “Mit KI ausfüllen”](#mit-ki-ausfüllen) Statt von Hand zu übersetzen, kannst du KI Übersetzungsvorschläge aus deiner Standardsprache erstellen lassen. * **Alle mit KI übersetzen** übersetzt jeden fehlenden Wert; **Auswahl übersetzen** übersetzt nur das, was deinem aktuellen Bereichs-/Sprachfilter entspricht. * Bevor es läuft, zeigt eine Bestätigung, wie viele Werte und Texte übersetzt werden. **Es wird noch nichts gespeichert** — die KI schlägt nur vor. * Der Fortschritt wird inline während der Ausführung angezeigt. ### Prüfung, bevor irgendetwas gespeichert wird [Section titled “Prüfung, bevor irgendetwas gespeichert wird”](#prüfung-bevor-irgendetwas-gespeichert-wird) Wenn der Lauf abgeschlossen ist, öffnet sich ein **Prüfungsfenster** über den Vorschlägen. Jede vorgeschlagene Übersetzung ist standardmäßig ausgewählt — **wähle ab, was du nicht möchtest**, und übernimm dann. Nur die Werte, die du behältst, werden in deine Inhalte zurückgeschrieben. Nach dem Übernehmen erscheint über der Tabelle ein **Übersetzungsbericht**, der zusammenfasst, was übernommen, übersprungen und vorgeschlagen wurde. Schlägt ein Lauf fehl, wird nichts gespeichert (die Ausfüllfunktion schlägt nur vor), und du kannst es erneut versuchen. ## E-Mail-Vorlagen inbegriffen [Section titled “E-Mail-Vorlagen inbegriffen”](#e-mail-vorlagen-inbegriffen) Sprachspezifische E-Mail- und Benachrichtigungsvorlagentexte sind ebenfalls Teil der Prüfung, unter der Gruppe **Benachrichtigungen & E-Mails** — ein fehlender deutscher Buchungsbestätigungstext erscheint hier also neben unübersetzten Objekten, und der zugehörige **Öffnen**-Link führt dich zum Vorlagen-Editor unter **Einstellungen → Benachrichtigungen**. # Zusatzleistungen > Optionale und verpflichtende Extras, die Gäste zusätzlich zum Aufenthalt buchen können — Reinigung, Frühstück, Transfers und mehr. Zusatzleistungen sind Extras, die ein Gast zusätzlich zum Aufenthalt buchen kann — eine Reinigungsgebühr, Frühstück, ein Flughafentransfer, Fahrradverleih. Du definierst sie pro Objekt im Abschnitt **Zusatzleistungen** der Objekt-Detailansicht. ## Eine Zusatzleistung erstellen [Section titled “Eine Zusatzleistung erstellen”](#eine-zusatzleistung-erstellen) Klicke auf **Erstellen** und fülle aus: * **Name** — was der Gast sieht (pro Sprache). * **Beschreibung** — eine optionale längere Erklärung (pro Sprache). * **Preis** — der Betrag, in deiner Mandantenwährung. * **Preistyp** — wie der Preis angewendet wird: * **Pro Aufenthalt** — eine einzelne Pauschale für die gesamte Buchung. * **Pro Tag** — multipliziert mit der Anzahl der Nächte. * **Pro Gast** — multipliziert mit der Anzahl der Gäste. * **Pro Gast/Tag** — multipliziert mit Gästen und Nächten. * **Pro Einheit** — der Gast wählt eine Menge (bis zu einem optionalen Maximum). * **Pflicht** — wenn aktiviert, wird die Zusatzleistung immer angewendet, und der Gast kann nicht abwählen (nutze das für unvermeidbare Kosten wie eine obligatorische Reinigungsgebühr). Wenn deaktiviert, ist sie beim Checkout optional. * **Max. Menge** — nur für Zusatzleistungen mit *pro Einheit*; begrenzt, wie viele der Gast auswählen kann. * **Steuerkategorie** — ob die Zusatzleistung als Unterkunft oder als Dienstleistung versteuert wird, was sich darauf auswirkt, wie sie auf Rechnungen behandelt wird. Siehe [Steuern](/de/docs/invoices/taxes/). ## Wo Gäste sie sehen [Section titled “Wo Gäste sie sehen”](#wo-gäste-sie-sehen) Optionale Zusatzleistungen erscheinen beim Checkout auf der Storefront, wo Gäste die gewünschten auswählen (und eine Menge, bei Zusatzleistungen pro Einheit). Pflicht-Zusatzleistungen werden automatisch hinzugefügt. Ausgewählte Zusatzleistungen fließen in die Buchungssumme, Zahlungen und die Rechnung des Gasts ein. ## Bearbeiten und entfernen [Section titled “Bearbeiten und entfernen”](#bearbeiten-und-entfernen) Wähle eine beliebige Zusatzleistung in der Tabelle, um sie zu bearbeiten, oder nutze **Löschen**, um sie zu entfernen. Änderungen gelten für zukünftige Buchungen; Zusatzleistungen, die bereits an bestehenden Buchungen hängen, sind davon nicht betroffen. # Ausstattung, Attribute und Tags > Ausstattung, Attribute, Tags und Entfernungen einem Objekt zuweisen, und wie jedes davon als Storefront-Filter erscheint. Vier Objektabschnitte beschreiben, was ein Objekt bietet, und steuern, wie Gäste auf der Storefront filtern und sortieren: **Ausstattung**, **Attribute**, **Tags** und **Entfernungen**. Jeder greift auf deinen mandantenweiten [Katalog](/de/docs/catalog/overview/) zurück — du definierst ein Element einmal und nutzt es in jedem Objekt wieder. ## Ausstattung [Section titled “Ausstattung”](#ausstattung) Ausstattung sind die Merkmale, die ein Objekt bietet — WLAN, Pool, Parkplatz und so weiter. Im Abschnitt **Ausstattung** des Objekts wählst du aus deinem Ausstattungskatalog: zugewiesene Ausstattung steht in einer Liste, alles andere in einer „verfügbar“-Liste, und du verschiebst Elemente zwischen ihnen. Jede Ausstattung trägt ein Symbol, sodass sie auf der Storefront-Objektseite als Symbol mit Beschriftung erscheint, und Ausstattungen werden zu Filteroptionen, nach denen Gäste suchen können. Um eine neue Ausstattung zur Auswahl hinzuzufügen, erstelle sie im Katalog unter **Ausstattung** — siehe [Katalogübersicht](/de/docs/catalog/overview/). ## Attribute [Section titled “Attribute”](#attribute) Attribute sind **typisierte** Fakten über ein Objekt, jeweils mit einem Wert, den du pro Objekt einträgst. Der Typ eines Attributs bestimmt, was du eingibst: * **Text** / **Mehrzeiliger Text** — Freitext. * **Zahl** — eine reine Zahl. * **Entfernung** — ein Entfernungswert. * **Größe** — ein Flächenwert. * **Ja/Nein** — ein Wahrheitswert. Im Abschnitt **Attribute** des Objekts weist du ein Attribut zu und gibst ihm einen Wert. Weil Attribute strukturiert sind, kann die Storefront sie in sortierbaren, vergleichbaren Filtern nutzen. Definiere die verfügbaren Attribute (und ihre Typen) im Katalog **Attribute**. ## Tags [Section titled “Tags”](#tags) Tags sind einfache Beschriftungen — „ski-in/ski-out“, „haustierfreundlich“, „Meerblick“. Im Abschnitt **Tags** des Objekts weist du Tags aus deinem Tag-Katalog zu, indem du sie zwischen zugewiesen und verfügbar hin- und herklickst. Tags erscheinen als Filter-Pills auf der Storefront und lassen Gäste Ergebnisse auf ein Thema eingrenzen. Verwalte die Tag-Liste im Katalog **Tags**. ## Entfernungen [Section titled “Entfernungen”](#entfernungen) Entfernungen sagen Gästen, wie weit das Objekt von Sehenswürdigkeiten entfernt ist — „500 m zum Strand“, „3 km zum Flughafen“. Im Abschnitt **Entfernungen** des Objekts fügst du einen Eintrag hinzu, indem du einen Entfernungstyp aus deinem Katalog wählst und die Entfernung einträgst, oder indem du eine einmalige benutzerdefinierte Entfernung für dieses Objekt definierst. Entfernungstypen, die als *durchsuchbar* markiert sind, werden zu Storefront-Filtern (zum Beispiel „innerhalb von 1 km zum Strand“). Siehe [Reiseziele und Entfernungen](/de/docs/catalog/places-and-distances/). ## Wie sie auf die Storefront gelangen [Section titled “Wie sie auf die Storefront gelangen”](#wie-sie-auf-die-storefront-gelangen) Alles, was du hier zuweist, fließt in die Suche und Filterung der Storefront ein. Welche Filter tatsächlich erscheinen und wie sie gruppiert sind, ist Teil deiner Storefront-Einrichtung — siehe [Suche und Karten](/de/docs/storefront/search-and-maps/). # Inhalte und Medien > Die Abschnitte Texte, Objektdaten, Bilder und SEO — die Worte, Zahlen und Fotos, aus denen ein Objekt besteht. Vier Abschnitte der Objekt-Detailansicht enthalten die Inhalte, die Gäste sehen: **Texte**, **Objektdaten**, **Bilder** und **SEO**. Jeder speichert für sich. ## Texte [Section titled “Texte”](#texte) Der Abschnitt **Texte** enthält die Worte des Objekts: * **Titel** — die Hauptüberschrift auf der Storefront. * **Objektschlüssel** — die URL-freundliche Kennung (siehe [Objektübersicht](/de/docs/listings/overview/#der-objektschl%C3%BCssel)). Die Konsole prüft die Verfügbarkeit während der Eingabe. * **Kurzbeschreibung** — eine kurze Zusammenfassung, die auf Suchergebnissen und Objektkarten angezeigt wird. * **Beschreibung** — die vollständige Rich-Text-Beschreibung auf der Objektseite. Titel, Kurzbeschreibung und Beschreibung sind **pro Sprache**: jedes Feld hat einen Tab für jede aktivierte Sprache, sodass du Inhalte direkt vor Ort übersetzt. Neben jedem Feld ist ein KI-Menü — generiere das Feld aus dem Rest des Objekts, oder übersetze das Geschriebene in die anderen Sprachen unter Beibehaltung der Formatierung. Du kannst das Ergebnis vor dem Speichern immer noch bearbeiten. Siehe [KI-Inhaltsgenerierung](/de/docs/ai/content-generation-and-translation/) und [Mehrsprachige Inhalte](/de/docs/languages/multilingual-content/). ## Objektdaten [Section titled “Objektdaten”](#objektdaten) **Objektdaten** erfasst die strukturierten Details: * **Objektart** — Wohnung, Haus, und so weiter (siehe [Objekttypen](/de/docs/catalog/property-types/)). * **Stornierungsrichtlinie** — welche Richtlinie für Buchungen dieses Objekts gilt. * **Kapazität** — maximale Gästezahl (und optional eine Aufteilung nach Erwachsenen, Kindern und Kleinkindern). * **Zimmer** — Schlafzimmer, Badezimmer und Wohnfläche (m²). * **Aufenthaltsgrenzen** — minimaler und maximaler Aufenthalt in Tagen (setze das Maximum auf unbegrenzt, um die Obergrenze zu entfernen). * **Haustiere** — erlaubt, nicht erlaubt, oder Standard übernehmen; plus eine optionale maximale Anzahl an Haustieren. * **Durchsuchbar** — ob das Objekt in der Storefront-Suche und den Filtern erscheint. * **Hervorgehoben** — das Objekt als hervorgehoben für Promotion auf der Storefront markieren. Aufenthaltsgrenzen leben hier auch neben den umfassenderen [Aufenthaltsregeln](/de/docs/pricing/stay-rules/). ## Bilder [Section titled “Bilder”](#bilder) Starke Fotos sind einer der größten Treiber für Buchungen. Im Abschnitt **Bilder** kannst du: * **Hochladen** — ein oder mehrere Fotos auf einmal. * **Neu anordnen** durch Ziehen — die Reihenfolge bestimmt, wie sie in der Galerie erscheinen. * **Titelbild festlegen** — markiere ein Bild als Haupt-/Titelbild. Ein Titelbild ist vor der Veröffentlichung erforderlich. * **Beschriften** jedes Bild (sein Alt-Text) und taggen, was Barrierefreiheit und Suche hilft. ## SEO [Section titled “SEO”](#seo) Der Abschnitt **SEO** steuert, wie das Objekt in Suchmaschinen und Link-Vorschauen erscheint: * **SEO-Titel** — bis zu 255 Zeichen; fällt auf den Objekttitel zurück, wenn leer gelassen. * **Meta-Beschreibung** — bis zu 500 Zeichen. Beide sind pro Sprache, und eine Live-Vorschau zeigt ungefähr, wie das Ergebnis aussehen wird. Ein KI-Menü kann beide aus dem Objektinhalt entwerfen. Sie auszufüllen ist ein Nice-to-have auf der [Vollständigkeitscheckliste](/de/docs/listings/overview/#der-vollst%C3%A4ndigkeitsring) — gut für den Feinschliff, aber nicht erforderlich zum Veröffentlichen. # Objekt erstellen > Ein Objekt per KI-Import aus URL, Text, PDF oder Fotos erstellen — oder manuell ausfüllen. Klicke unter **Objekte** auf **Objekt erstellen**. Reynt öffnet den Erstellungsdialog standardmäßig im Ablauf **KI-Import**, weil das der schnellste Weg zu einem gut ausgefüllten Objekt ist. Ein manueller Assistent ist einen Klick entfernt, falls du lieber alles selbst eintippen möchtest. ## KI-Import (der Standard) [Section titled “KI-Import (der Standard)”](#ki-import-der-standard) Der KI-Import liest, welches Material du bereits über ein Objekt hast, und entwirft das gesamte Objekt — Texte, Eckdaten, Ausstattung, Bilder und SEO — zur Überprüfung durch dich, bevor irgendetwas live geht. ### 1. Quellen hinzufügen [Section titled “1. Quellen hinzufügen”](#1-quellen-hinzufügen) Gib eine beliebige Kombination der folgenden an (mindestens eine): * **Text** — füge eine Beschreibung, ein Inserat von einer anderen Seite oder eigene Notizen ein. * **URL** — ein Link zu einer bestehenden Inseratsseite; Reynt liest die Seite. * **PDF** — lade eine Broschüre oder ein Exposé hoch (bis zu 10 MB). * **Fotos** — bis zu 10 Bilder (JPEG, PNG, WebP oder GIF, je 10 MB). Diese fließen in die Bildanalyse ein, und die importierten Fotos werden zur Galerie des Objekts. Alles zusammen, was du auf einmal hochlädst — das PDF und alle Fotos — muss unter **25 MB insgesamt** bleiben. Die Einzelgrenzen oben lassen sich also nicht alle gleichzeitig ausschöpfen. Das Formular rechnet mit und sagt dir vorher Bescheid. Mehr Material bedeutet einen reichhaltigeren Entwurf. ### 2. Eckdaten bestätigen [Section titled “2. Eckdaten bestätigen”](#2-eckdaten-bestätigen) Der zweite Schritt lässt dich Details festlegen, die die KI **nicht** erfinden darf: * **Standardpreis** — der Grundpreis pro Nacht. * **Eigentümer** — der Objekteigentümer (nur im Marktplatz-Modus). * **Adresse** — Straße, Stadt, Postleitzahl und Land. Was du hier einträgst, wird vor der Generierung auf das Objekt angewendet, sodass der Entwurf auf deinen tatsächlichen Zahlen und deiner Adresse basiert und nicht auf Vermutungen. ### 3. Import starten [Section titled “3. Import starten”](#3-import-starten) Klicke auf **Import starten**. Das Objekt wird sofort erstellt und die KI arbeitet im Hintergrund — du kannst die Seite verlassen. Ein Banner am Objekt zeigt den Fortschritt und sagt dir, wann der Entwurf zur Überprüfung bereit ist. ### 4. Überprüfen und übernehmen [Section titled “4. Überprüfen und übernehmen”](#4-überprüfen-und-übernehmen) Wenn der Import abgeschlossen ist, öffne **Überprüfen & Übernehmen**. Der Überprüfungsbildschirm zeigt alles, was die KI erstellt hat, vollständig bearbeitbar: * Titel, Kurzbeschreibung, Beschreibung, Gästeinformationen und SEO — mit einem Tab pro aktivierter Sprache, sodass du jede Übersetzung vor dem Übernehmen anpassen kannst. * Objektdaten: Art, Kapazität, Zimmer, Aufenthaltsgrenzen, Haustiere, Kaution, Check-in-/Check-out-Zeiten und Adresse. * Zugeordnete Ausstattung und Tags — wähle ab, was nicht passt. * Importierte Fotos — Titelbild festlegen und Beschriftungen bearbeiten. Nichts wird auf das live geschaltete Objekt geschrieben, bis du handelst. Wähle: * **Übernehmen** — die überprüften Inhalte auf das Objekt speichern, im Entwurf bleiben. * **Übernehmen & veröffentlichen** — speichern und, falls das Objekt die Bereitschaftsprüfungen besteht, in einem Schritt live schalten. ## Manuelle Erstellung [Section titled “Manuelle Erstellung”](#manuelle-erstellung) Möchtest du lieber von vorne beginnen? Wechsle im Erstellungsdialog zum manuellen Assistenten (der Stift- / „manuell“-Link). Es ist ein dreistufiges Formular: 1. **Grundlagen** — Titel und Objektschlüssel. 2. **Kapazität** — maximale Gästezahl, Schlafzimmer, Badezimmer und Wohnfläche. 3. **Preise** — ein Standardpreis pro Nacht. Der Abschluss erstellt das Objekt im Entwurf. Anschließend füllst du den Rest aus — Bilder, Beschreibung, Ausstattung, Standort — über die [Abschnitte der Detailansicht](/de/docs/listings/overview/). Du kannst jederzeit im ersten Schritt des Assistenten zum KI-Import zurückwechseln. ## Wie es weitergeht [Section titled “Wie es weitergeht”](#wie-es-weitergeht) Wie auch immer du es erstellst, das Objekt startet als **Entwurf** und erscheint erst auf der Storefront, wenn du es veröffentlichst. Arbeite die [Vollständigkeitscheckliste](/de/docs/listings/overview/#der-vollst%C3%A4ndigkeitsring) ab und [veröffentliche](/de/docs/listings/publishing-and-visibility/) dann. # Objektübersicht > Was ein Objekt in Reynt ist, aus welchen Abschnitten es besteht und wie der Vollständigkeitsring die Bereitschaft verfolgt. Ein Objekt ist eine einzelne buchbare Unterkunft. Es ist der Datensatz, an dem alles andere hängt — Buchungen, Preise, Verfügbarkeit, Bilder und Storefront-Seiten verweisen alle auf ein Objekt. Du verwaltest sie unter **Objekte**. ## Die Objekt-Detailansicht [Section titled “Die Objekt-Detailansicht”](#die-objekt-detailansicht) Das Öffnen eines Objekts führt dich zu seiner Detailansicht, einer einzelnen Seite mit einem Abschnittsmenü auf der linken Seite. Es gibt keinen separaten „Bearbeiten“-Bildschirm — jeder Abschnitt wird direkt bearbeitet und speichert unabhängig. Die Abschnitte sind: * **Übersicht** — ein Dashboard: Buchungsstatistiken, Auslastung, bevorstehende Check-ins, Kalender-Sync-Status und Schnellaktionen. * **Texte** — Titel, Objektschlüssel, Kurzbeschreibung und vollständige Beschreibung (pro Sprache). Siehe [Inhalte und Medien](/de/docs/listings/content-and-media/). * **Objektdaten** — Objektart, Kapazität, Zimmer, Aufenthaltsgrenzen, Haustiere, Stornierungsrichtlinie und Sichtbarkeits-Flags. * **Bilder** — hochladen, neu anordnen, Titelbild festlegen und Beschriftungen hinzufügen. * **SEO** — Suchtitel und Meta-Beschreibung mit Live-Vorschau. * **Preise**, **Rabatte**, **Gebühren**, **Zusatzleistungen**, **Preisinformationen** — alles rund ums Geld. Siehe [Preise](/de/docs/pricing/base-and-seasonal/) und [Zusatzleistungen](/de/docs/listings/addons/). * **Ausstattung**, **Attribute**, **Tags**, **Entfernungen** — was das Objekt bietet und wie es gefiltert wird. Siehe [Ausstattung, Attribute und Tags](/de/docs/listings/amenities-attributes-and-tags/). * **Standort** — Ort, Koordinaten und Adresse. * **Eigentümer** — der Objekteigentümer (nur im Marktplatz-Modus). * **Check-in** — Check-in- und Check-out-Zeiten. * **Kalender** und **Sperrzeiten** — Verfügbarkeit auf einen Blick und blockierte Zeiträume. Siehe [Verfügbarkeit](/de/docs/availability/block-dates/). * **Externe Kalender** — iCal-Sync mit anderen Kanälen. Siehe [iCal-Sync](/de/docs/availability/ical-sync/). * **Objekt löschen** — das Objekt dauerhaft entfernen. ## Der Objektschlüssel [Section titled “Der Objektschlüssel”](#der-objektschlüssel) Jedes Objekt hat einen **Schlüssel** — eine kurze, URL-freundliche Kennung (Buchstaben, Zahlen, Bindestriche und Unterstriche). Das ist das feste Kennzeichen des Objekts: Er ist Teil der Storefront-Webadresse und daran erkennst du es in Listen. Du legst ihn im Abschnitt **Texte** fest, wo die Konsole in Echtzeit prüft, dass der Schlüssel nicht bereits von einem anderen Objekt verwendet wird. Du kannst ihn später ändern, aber beachte, dass bestehende Links zur alten Adresse dann nicht mehr funktionieren. ## Der Vollständigkeitsring [Section titled “Der Vollständigkeitsring”](#der-vollständigkeitsring) Während du ein Objekt aufbaust, verfolgt eine **Vollständigkeits**-Anzeige, wie ausgefüllt es ist. Sie bewertet jedes Feld — von den kritischen bis hin zu den Nice-to-haves — zu einem einzigen Prozentsatz und einer Bereitschaftsstufe: * **Entwurf** — eines oder mehrere *kritische* Elemente fehlen noch, sodass das Objekt noch nicht live gehen kann. * **Bereit** — alle kritischen Elemente sind vorhanden; empfohlener Feinschliff fehlt noch. * **Vollständig** — auch jedes empfohlene Element ist ausgefüllt (bei 100 % sind auch die Nice-to-haves abgehakt). Die Checkliste gruppiert das noch Fehlende in drei Stufen: * **Kritisch** — mindestens ein Bild, ein festgelegtes Titelbild und mindestens ein Preis. Im Marktplatz-Modus ist auch ein zugewiesener Eigentümer kritisch. Diese blockieren die Veröffentlichung. * **Empfohlen** — Objektart, eine Beschreibung und Kurzbeschreibung, Land und vollständige Adresse, Kartenkoordinaten, ein zugewiesenes Reiseziel und fünf oder mehr Bilder. * **Nice to have** — Schlafzimmer, Badezimmer, Wohnfläche, Ausstattung, Tags sowie SEO-Titel und -Beschreibung. **Kartenkoordinaten** sind ein Sonderfall: Bei Mandanten mit aktivierter Kartensuche (ein Karten-Tile-Key ist unter **Einstellungen → Kunden-Oberfläche** konfiguriert) zählen fehlende Koordinaten als kritisch — das Objekt wird als **Entwurf** angezeigt und kann nicht neu veröffentlicht werden, bis sie gesetzt sind. Ein bereits live geschaltetes Objekt bleibt sichtbar, fällt aber ohne Koordinaten aus den Ergebnissen, sobald ein Gast die Storefront-Karte bewegt (siehe [Suche & Karten](/de/docs/storefront/search-and-maps/)). Jedes fehlende Element verlinkt zum Abschnitt, der es behebt, sodass du die Liste abarbeiten kannst. Ein Objekt kann erst veröffentlicht werden, wenn es **Bereit** erreicht — siehe [Veröffentlichung und Sichtbarkeit](/de/docs/listings/publishing-and-visibility/). ## Objekte erstellen [Section titled “Objekte erstellen”](#objekte-erstellen) Neue Objekte starten standardmäßig mit einem KI-gestützten Import-Ablauf, wobei ein manueller Weg immer einen Klick entfernt ist. Siehe [Objekt erstellen](/de/docs/listings/create-a-listing/). # Veröffentlichung und Sichtbarkeit > Wie sich Entwurf, veröffentlicht, versteckt und durchsuchbar bei Objekten unterscheiden, und die Bereitschaftsprüfungen, die das Live-Gehen freischalten. Zwei unabhängige Steuerungen entscheiden, ob ein Objekt auf der Storefront erscheint und ob Gäste es in der Suche finden können: sein **veröffentlicht**-Status und sein **durchsuchbar**-Flag. Ein Entwurfs-Objekt ist nie sichtbar, egal was. ## Entwurf vs. veröffentlicht [Section titled “Entwurf vs. veröffentlicht”](#entwurf-vs-veröffentlicht) Jedes Objekt startet als **Entwurf**: Es existiert nur in der Konsole und erscheint nie auf der Storefront. Ein Entwurf kann auf der öffentlichen Seite keine echten Buchungen annehmen. Das Veröffentlichen schaltet es live. Öffne das Objekt und klicke im Header auf **Veröffentlichen**. Reynt bittet dich um Bestätigung — sobald du bestätigst, geht das Objekt online und wird öffentlich erreichbar. Ein veröffentlichtes Objekt zeigt ein **Sichtbar**-Badge; ein Entwurf zeigt **Versteckt**. ## Bereitschaftsprüfungen blockieren die Veröffentlichung [Section titled “Bereitschaftsprüfungen blockieren die Veröffentlichung”](#bereitschaftsprüfungen-blockieren-die-veröffentlichung) Du kannst nur ein Objekt veröffentlichen, das seine kritischen [Vollständigkeitsprüfungen](/de/docs/listings/overview/#der-vollst%C3%A4ndigkeitsring) bestanden hat. Solange ein kritisches Element fehlt, bleibt das Objekt auf der Bereitschaftsstufe **Entwurf**, und der **Veröffentlichen**-Button ist deaktiviert — beim Überfahren mit der Maus wird genau aufgelistet, was fehlt. Die kritischen Elemente sind: * Mindestens ein Bild * Ein festgelegtes Titelbild * Mindestens ein Preis * Ein zugewiesener Eigentümer (nur im Marktplatz-Modus) Sobald diese vorhanden sind, erreicht das Objekt **Bereit**, und du kannst veröffentlichen. Das wird auch serverseitig durchgesetzt, sodass es keine Möglichkeit gibt, ein unvollständiges Objekt live zu schalten. Empfohlene und Nice-to-have-Elemente blockieren die Veröffentlichung nicht, aber sie auszufüllen lässt das Storefront-Objekt vollständiger aussehen. ## Offline nehmen [Section titled “Offline nehmen”](#offline-nehmen) Um ein live geschaltetes Objekt offline zu nehmen, öffne es und klicke im Header auf **Offline nehmen**. Es wird sofort von der Storefront entfernt, und sein Badge kehrt zu **Versteckt** zurück. Bestehende Buchungen sind davon nicht betroffen. Du kannst jederzeit erneut veröffentlichen (vorbehaltlich derselben Bereitschaftsprüfungen). ## Durchsuchbar vs. sichtbar [Section titled “Durchsuchbar vs. sichtbar”](#durchsuchbar-vs-sichtbar) Die Veröffentlichung steuert, ob das Objekt überhaupt auf der Storefront existiert. **Durchsuchbar** — ein Schalter im Abschnitt **Objektdaten** — steuert, ob ein veröffentlichtes Objekt in der Storefront-Suche und den Filtern auftaucht. Schalte es aus, um ein Objekt per direktem Link erreichbar zu halten, während es aus Durchsuchen und Suchergebnissen ausgeblendet wird; schalte es ein, um es einzuschließen. Ein Objekt zeigt entsprechend ein **Auffindbar**- oder **Nicht auffindbar**-Badge. Es gibt im selben Abschnitt auch ein **Hervorgehoben**-Flag, um ein Objekt auf der Storefront zu bewerben. ## Ein Altobjekt stilllegen [Section titled “Ein Altobjekt stilllegen”](#ein-altobjekt-stilllegen) Ein Objekt, das du nicht mehr vermietest — ein Eigentümer, der gegangen ist, eine verkaufte Wohnung — gehört **archiviert**, nicht gelöscht. Öffne das Objekt und klicke im Header auf **Archivieren**. Ein archiviertes Objekt: * geht sofort offline (das Archivieren nimmt es für dich offline) * verschwindet aus deiner Objektliste, dem Kalender, den Objekt-Auswahllisten in Buchungen und Angeboten, der Suche, deinem Dashboard und deinen Auswertungen * bleibt an jeder bisherigen Buchung und Rechnung sichtbar, sodass Historie und Zahlen unverändert bleiben * lässt sich jederzeit mit **Wiederherstellen** zurückholen — bewusst weiterhin offline, damit du die Inhalte prüfen kannst, bevor du es erneut veröffentlichst Um deine archivierten Objekte zu sehen, öffne die Filter auf der Objektseite und setze das Häkchen bei **Archivierte Objekte**. Sie ersetzen die aktiven Objekte, solange der Filter aktiv ist. Reynt verweigert das Archivieren, solange ein Aufenthalt auf dem Objekt noch läuft oder bevorsteht oder eine offene Buchungsanfrage es anbietet — sonst wäre das Objekt aus dem Kalender verschwunden, während du es noch brauchst. Erledige oder storniere das zuerst. ## Ein Objekt löschen [Section titled “Ein Objekt löschen”](#ein-objekt-löschen) Das Löschen im Abschnitt **Objekt löschen** der Detailansicht ist endgültig und nur für ein Objekt möglich, das **nie** gebucht oder angeboten wurde — ein Tippfehler, ein Test, ein aufgegebener Entwurf. Sobald es zu einem Objekt eine Buchung oder Buchungsanfrage gibt, verweigert Reynt das Löschen. Das ist Absicht: Buchungen und Rechnungen lesen Name und Adresse des Objekts aus dem Objekt selbst — beim Löschen würden deine eigenen Unterlagen leer laufen. Archiviere es stattdessen. # Registrierung für Kurzzeitvermietung und Datenexport > Erkläre, ob eine Unterkunft eine Registriernummer für Kurzzeitvermietung braucht, trag die Nummer ein, und exportiere dein gesamtes Portfolio nach Excel, um zu sehen, was noch fehlt. Die EU-Verordnung 2024/1028 gilt seit dem **20. Mai 2026**. Liegt eine Unterkunft in einem ausgewiesenen Registrierungsgebiet für Kurzzeitvermietung, braucht sie eine Registriernummer — und diese Nummer muss **im Inserat angezeigt** werden. Reynt gibt jedem Objekt dafür zwei Felder und warnt dich, solange eines davon offen ist. Die Erklärung gibst du ab. Reynt leitet sie nie aus der Adresse ab, denn in den meisten Mitgliedstaaten legt die Region oder die Gemeinde das Registrierungsgebiet fest — und nur du weißt, ob eine bestimmte Unterkunft darin liegt. ## Ein Objekt erklären [Section titled “Ein Objekt erklären”](#ein-objekt-erklären) Öffne das Objekt und geh auf **Standort**. Der Abschnitt **Registrierung für Kurzzeitvermietung** hat zwei Felder: **Registrierungspflicht** — deine Erklärung, mit zwei Antworten: * *In einem Registrierungsgebiet — Nummer erforderlich* * *Nicht in einem Registrierungsgebiet — keine Nummer nötig* Bleibt das Feld leer, gilt das Objekt als **noch nicht erklärt**. Das ist ein eigener Zustand, verschieden von beiden Antworten, und der, um dessen Klärung Reynt dich bittet. **Registriernummer** — die Nummer selbst. Sie darf der Erklärung nachlaufen: Du kannst eine Registrierungspflicht erklären, während du noch auf die Nummer der Behörde wartest. Reynt akzeptiert diese Lücke und warnt darüber, statt dich zu blockieren. Trag die Nummer genau so ein, wie sie ausgestellt wurde, führende Nullen inklusive. Speichere den Abschnitt, wenn du fertig bist. Reynt hält das Datum deiner Erklärung fest und zeigt es als *Zuletzt erklärt am …*. ### Ungarn: Nummer und Unterkunftsart [Section titled “Ungarn: Nummer und Unterkunftsart”](#ungarn-nummer-und-unterkunftsart) Ungarn ist der strengste Fall, und die dortigen Regeln sind älter als die EU-Verordnung. Jede Unterkunft muss im **NTAK** registriert sein, das eine 10-stellige Registriernummer vergibt, und ungarisches Recht verlangt seit dem **1. Oktober 2020**, dass eine über ein Buchungsportal angebotene Unterkunft **sowohl die NTAK-Nummer als auch ihre gesetzliche Unterkunftsart** — *magánszálláshely*, *egyéb szálláshely*, *panzió* und so weiter — für Gäste sichtbar ausweist. Zwei praktische Folgen: * **Jede ungarische Unterkunft braucht eine Nummer.** Die Frage nach dem Registrierungsgebiet stellt sich nicht — das ganze Land ist erfasst, ein Häuschen am Balaton genauso wie eine Wohnung in Budapest. Wähl *In einem Registrierungsgebiet* und trag die NTAK-Nummer ein. * **Die Nummer allein reicht nicht.** Bei ungarischen Objekten erscheint unter der Nummer ein drittes Feld, **Gesetzliche Unterkunftsart**. Wähl die Art aus der Liste — sie enthält die neun Arten des Registers — oder schreib deine eigene, falls das Register sie anders führt. Die Storefront zeigt dann beides nebeneinander, genau wie § 5 (4) es verlangt. Prüf dasselbe auf allen anderen Portalen, auf denen du inserierst. Die Art wird **auf Ungarisch und unübersetzt** gespeichert und angezeigt, in jeder Sprachfassung deiner Storefront. Das ist Absicht: Verlangt ist der Begriff, den das Register führt — eine übersetzte Umschreibung würde die Art der Unterkunft für niemanden nachprüfbar machen. **Viele auf einmal ausfüllen.** Wenn die meisten deiner ungarischen Objekte dieselbe Art haben, filter die Objektliste auf Ungarn und nutz **Unterkunftsart für … ergänzen** in der Toolbar. Damit wird die gewählte Art bei jedem ungarischen Objekt eingetragen, das noch keine hat — Objekte mit bereits eingetragener Art bleiben unberührt. Also erst den Regelfall setzen, dann die Ausnahmen einzeln korrigieren. **Angezeigt wird nur eine Nummer — und man greift leicht zur falschen.** Eine ungarische Unterkunft hat drei Kennungen: | Kennung | Was es ist | Gehört nach Reynt? | | ----------------------------------------- | ------------------------------------------------------------------ | ----------------------------- | | NTAK-Registriernummer (10 Stellen) | vom NTAK vergeben | **Ja — das ist das Feld** | | *Nyilvántartási szám* | vom Notar (*jegyző*) bei der Registrierung des Anbieters vergeben | Nein — rein verwaltungsintern | | *Adatszolgáltatási azonosító* (8 Stellen) | der Code von vor Oktober 2020, weiterhin für die Datenübermittlung | Nein | Im Register des Notars steht auch die gesetzliche Unterkunftsart — du kannst NTAK-Nummer und passende Art also demselben Dokument entnehmen. ### Länder, die landesweit registrieren [Section titled “Länder, die landesweit registrieren”](#länder-die-landesweit-registrieren) Manche Mitgliedstaaten führen ein einziges nationales Register für das gesamte Staatsgebiet — Ungarn (NTAK), Italien (CIN), Portugal (AL), Griechenland (AMA), Kroatien (eVisitor). Liegt das Objekt in einem dieser Länder, weist der Abschnitt darauf hin und nennt das erwartete Register. Denn dort hat die Frage „welches Gebiet?“ keine lokale Antwort: Jede Unterkunft im Land braucht eine Nummer, unabhängig von der Gemeinde. *Nicht in einem Registrierungsgebiet* trifft für solche Objekte nur selten zu. Reynt wählt die Registrierungspflicht trotzdem nicht für dich vor. Die Erklärung hat rechtliches Gewicht, und eine vorausgefüllte Erklärung ist keine, die jemand abgegeben hat. Wo das Verfahren stattdessen regional oder kommunal ist — die deutschen Zweckentfremdungsregeln, Wien und die österreichischen Freizeitwohnsitz-Regeln, Frankreich, die Niederlande, Belgien, Spanien — hängt es wirklich von der Adresse ab, ob eine Nummer nötig ist, und du musst das lokale Verfahren prüfen. ### Deutschland: die veröffentlichte Liste prüfen [Section titled “Deutschland: die veröffentlichte Liste prüfen”](#deutschland-die-veröffentlichte-liste-prüfen) In Deutschland ist es jedem Bundesland und jeder Kommune freigestellt, ein Registrierungsverfahren einzuführen. Die **Bundesnetzagentur** — die nationale Behörde für den EU-Datenaustausch — veröffentlicht die Liste der Gebiete, die eines eingeführt haben, und Reynt verlinkt sie direkt im Registrierungsabschnitt, sobald ein Inserat in Deutschland liegt. Schlag den Standort deiner Unterkunft in dieser Liste nach und trag das Ergebnis ein. Steht das Gebiet nicht darauf, ist *Nicht in einem Registrierungsgebiet* heute die richtige Erklärung; die Liste wächst, wenn weitere Kommunen dazukommen — es lohnt sich also, beim nächsten Bearbeiten eines Inserats erneut zu prüfen. Die Nummer selbst kommt immer von der **Kommune**, nie von der Bundesnetzagentur. ### Österreich: derzeit gar kein Registrierungsverfahren [Section titled “Österreich: derzeit gar kein Registrierungsverfahren”](#österreich-derzeit-gar-kein-registrierungsverfahren) Österreich hatte dieselbe Wahl — und **kein einziges Bundesland hat sie genutzt**. Laut dem Bundesministerium für Wirtschaft, Energie und Tourismus (BMWET) wird die Verordnung vorerst in keinem Bundesland umgesetzt. Das heißt: keine Registrierungspflicht für Vermieterinnen und Vermieter und landesweit keine Nummer, die im Inserat stehen müsste. Für ein österreichisches Inserat ist *Nicht in einem Registrierungsgebiet* also heute die richtige Erklärung. Reynt weist im Registrierungsabschnitt darauf hin und nennt das Datum, an dem der Stand zuletzt geprüft wurde. Zwei Dinge dazu: * **Das kann sich ändern.** Jedes Bundesland entscheidet selbst und kann später ein Verfahren einführen. Passiert das, stimmen die jetzt abgegebenen Erklärungen nicht mehr — das Datum im Hinweis ist ein „geprüft am“, keine Garantie. * **Andere österreichische Regeln gelten weiter.** Die Wiener Bauordnung für die Kurzzeitvermietung, die Freizeitwohnsitz-Verzeichnisse in Tirol und Salzburg, Gewerbeordnung und Privatzimmervermietung — davon ist durch die EU-Verordnung nichts berührt, und keine davon vergibt eine Nummer, die in dieses Feld gehört. Lass die Registriernummer leer. ## Wo Reynt dich warnt [Section titled “Wo Reynt dich warnt”](#wo-reynt-dich-warnt) **In der Objektzeile.** Die Objektliste zeigt bei allem Offenen ein Abzeichen — *Registrierung nicht erklärt*, *Registriernummer fehlt* oder *Unterkunftsart fehlt*. Ein geklärtes Objekt zeigt gar kein Abzeichen: Das Fehlen bedeutet „in Ordnung“, nie „unbekannt“. **Im Dashboard.** Zwei Hinweise zählen deine **veröffentlichten** Objekte mit offener Registrierung und verlinken direkt dorthin: * *… veröffentlichte Inserate ohne Registrierungsangabe* * *… veröffentlichte Inserate warten auf ihre Registriernummer* Jeder Hinweis verschwindet, sobald alle veröffentlichten Objekte geklärt sind, und erscheint erneut für später angelegte Objekte. **Im Vollständigkeitsring.** Die Registrierung ist ein *empfohlener* Punkt. Sie hält ein Objekt unter **Vollständig**, blockiert aber die Veröffentlichung nicht — siehe [Veröffentlichung und Sichtbarkeit](/de/docs/listings/publishing-and-visibility/). **Um sie als Gruppe zu prüfen,** öffne die Objektliste, klick auf den Filter-Button und setze **Registrierung Kurzzeitvermietung (EU 2024/1028)** auf *Nicht erklärt*, *Nummer fehlt*, *Unterkunftsart fehlt* oder *Registrierung offen* für alles davon. ## Auf der Storefront [Section titled “Auf der Storefront”](#auf-der-storefront) Sobald eine Nummer gespeichert ist, zeigt die Storefront-Seite des Objekts sie als *Registriernummer: …* — genau das verlangt die Verordnung. Sie steht als unaufdringliche Zeile am Fuß der Seite: Die Verordnung schreibt vor, *dass* die Nummer angezeigt wird, nicht *wo* — so kommt sie dem nicht in die Quere, was Gäste tatsächlich lesen. Ist eine Unterkunftsart verlangt und eingetragen, steht sie in derselben Zeile hinter der Nummer. Solange das Nummernfeld leer ist, wird nichts angezeigt. ## Portfolio nach Excel exportieren [Section titled “Portfolio nach Excel exportieren”](#portfolio-nach-excel-exportieren) Objekte einzeln durchzugehen ist bei einer Handvoll in Ordnung und bei einigen Hundert unpraktikabel. Die Objektliste hat einen **Exportieren**-Button, der dein gesamtes Portfolio als Excel-Arbeitsmappe herunterlädt. Der Export umfasst **genau die Objekte, die die Liste gerade zeigt** — filtere oder such also zuerst, dann passt die Tabelle dazu. Filtere auf *Registrierung offen*, und du erhältst nur die Objekte, die noch Aufmerksamkeit brauchen. Die Arbeitsmappe hat vier Blätter: | Blatt | Inhalt | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **README** | Hier öffnet sich die Datei: ein Verzeichnis der Blätter, was jede Spalte bedeutet und welche ein künftiger Import zurücklesen wird. | | **Listings** | Eine Zeile pro Objekt: Kennung, Registrierungsstatus, -nummer und Unterkunftsart, Vollständigkeit, Adresse, Eigentümer, Kapazität, Aufenthaltsregeln, Veröffentlichungsstatus sowie Bild- und Preisanzahl. | | **Prices** | Die Saisonpreise jedes Objekts. | | **Owners** | Kontaktdaten der Eigentümer hinter den exportierten Objekten. Nur enthalten, wenn deine Rolle Eigentümer lesen darf; Bank- und Steuerdaten werden nie exportiert. | Drei Spalten im Blatt **Listings** beantworten „was fehlt?“ direkt: * **missingCritical** — Punkte, die die Veröffentlichung blockieren (Fotos, ein Titelbild, ein Preis, und im Marktplatz-Modus ein Eigentümer) * **missingRecommended** — Punkte, die das Objekt unter **Vollständig** halten, die Registrierung eingeschlossen * **missingOptional** — der letzte Schritt zu 100 % Sortiere oder filtere in Excel danach, und du hast eine Arbeitsliste. `completenessPercent` und `completenessLevel` werden beim Export frisch berechnet und spiegeln das Objekt also immer im aktuellen Stand. Die Spalte **key** identifiziert jedes Objekt. Lass sie unverändert — ein künftiger Import ordnet damit Zeilen wieder Objekten zu. Note Ist dein Portfolio größer, als ein Export tragen kann, sagt das README-Blatt das in seinen ersten Zeilen. Grenze die Filter ein und exportiere erneut, um den Rest abzudecken — ein unvollständiger Export sieht nie unvollständig aus. ### Was der Export nicht ist [Section titled “Was der Export nicht ist”](#was-der-export-nicht-ist) Er ist eine **schreibgeschützte Momentaufnahme**. Eine Zelle zu ändern und die Datei zu behalten ändert nichts in Reynt; einen Upload gibt es noch nicht. Die Masseneingabe von Registriernummern ist als Folgeschritt geplant; bis dahin werden Nummern pro Objekt im Tab **Standort** eingetragen. Falls du den JSON-Export unter **Datentransfer** suchst: Das ist ein anderes Werkzeug. Es verschiebt Konfiguration und Inhalte zwischen Mandanten, keine Objektdaten zum Lesen in einer Tabelle. # Wie Zahlungen funktionieren > Wie das Geld bei einer Buchung fließt — Zahlungsraten, Status und der Unterschied zwischen Direkt- und Marktplatz-Modus. Jede bestätigte Buchung hat einen Zahlungsdatensatz, der festhält, was der Gast schuldet, was eingegangen ist und wie das Geld zwischen dir und (im Marktplatz-Modus) dem Eigentümer aufgeteilt wird. Diese Seite erklärt die Begriffe, die dir in der gesamten Konsole begegnen; die alltäglichen Aufgaben findest du unter [Zahlungsanbieter](/de/docs/payments/providers/) und [Teilzahlungen und Erstattungen](/de/docs/payments/partial-payments-and-refunds/). *Ab wann* ein Gast zahlen kann, was passiert, wenn er es nicht tut, und ob unbezahlte Termine irgendwann freigegeben werden, ist eine einzige Regel — siehe [Wann du kassierst](/de/docs/payments/when-you-collect/). ## Zahlungsraten [Section titled “Zahlungsraten”](#zahlungsraten) Der Gesamtbetrag einer Buchung wird in einer oder mehreren **Raten** eingezogen. Welche Raten existieren, hängt davon ab, wie du Zahlungen eingerichtet hast: * **Anzahlung** — ein Teil des Gesamtbetrags, der im Voraus bei Erstellung der Buchung erhoben wird. Nicht zu verwechseln mit der **Kaution**: Die Anzahlung ist echtes Geld auf der Buchung und wird mit dem Gesamtbetrag verrechnet, die Kaution ist eine reine Angabe außerhalb der Zahlungsraten — siehe [Rabatte und Gebühren](/de/docs/pricing/discounts-and-fees/). * **Restzahlung** — der verbleibende Betrag, fällig näher am Check-in. * **Gesamtzahlung** — der komplette Betrag in einer Rate (wenn keine Anzahlungsaufteilung verwendet wird). * **Nachzahlung** — ein zusätzlicher Betrag, der bei einer Aufwärts-Änderung einer Buchung hinzukommt. * **Kurtaxe** — eine Stadt-/Tourismusabgabe-Rate, wenn das Reiseziel des Objekts eine erhebt. Siehe [Steuern und MwSt.](/de/docs/invoices/taxes/). Jede Rate ist eine Zeile auf der **Zahlung**-Karte der Buchung und in der **Zahlungen**-Liste, mit eigenem Betrag, Fälligkeitsdatum und Status. ## Zahlungsstatus [Section titled “Zahlungsstatus”](#zahlungsstatus) Die Zahlung einer Buchung durchläuft folgende Status: * **Zahlung ausstehend** — fällig, aber noch nichts eingegangen. * **Teilweise bezahlt** — etwas Geld ist eingegangen (z. B. die Anzahlung ist bezahlt, die Restzahlung aber noch nicht). * **Bezahlt** — der gesamte Betrag ist beglichen. * **Storniert** — die Buchung wurde storniert und ausstehende Beträge wurden ungültig gemacht. Einzelne Raten (Überweisungen) zeigen sich als **Ausstehend** oder **Bezahlt**, mit einem *Teilweise bezahlt*-Badge, sobald ein Teil einer Rate eingegangen ist. ## Direkt- vs. Marktplatz-Modus [Section titled “Direkt- vs. Marktplatz-Modus”](#direkt--vs-marktplatz-modus) Dein **Betriebsmodus** wird bei der Erstellung deines Kontos festgelegt. Du siehst ihn unter **Einstellungen → Zahlungen**, der Abschnitt *Betriebsmodus* ist nur lesbar — in der Konsole gibt es dafür keinen Schalter. Hast du den falschen erwischt, melde dich bei Reynt: solange der Workspace leer ist, lässt er sich noch umstellen. Sobald es Buchungen, Zahlungen, Rechnungen oder Gästemeldungen gibt, ist der Modus endgültig fixiert, weil Erstattungen und Auswertungen daraus abgeleitet werden. Er entscheidet, ob du deine eigenen Objekte vermietest oder im Auftrag von Eigentümern tätig bist: * **Direkt-Modus** — das gesamte Geld geht an dich (den Betreiber). Es gibt keine Eigentümer-Aufteilung und keine Provision. * **Marktplatz-Modus** — die Buchung wird zwischen dir und dem Eigentümer aufgeteilt. Du behältst eine **Plattform-Provision** (den *Provisionssatz*, z. B. 15%, unter **Einstellungen → Zahlungen**), und der Eigentümer erhält den Rest. ## Wer kassiert das Geld [Section titled “Wer kassiert das Geld”](#wer-kassiert-das-geld) **Einstellungen → Zahlungen** stellt diese Frage über den Zahlungsmethoden, denn sie ist keine Eigenschaft einer Methode — sie ist Bestandteil deiner Vereinbarung mit einem Eigentümer. Sie entscheidet, wer der Vertragspartner des Gastes ist, wer ihm die Rechnung stellt, wessen Umsatzsteuer gilt und ob deine Provision direkt einbehalten oder nachträglich abgerechnet wird. Es gibt drei Antworten: * **Alles an dich** — der Gast zahlt dir die gesamte Buchung. Du behältst deine Provision und zahlst dem Eigentümer seinen Anteil selbst aus, außerhalb von Reynt. * **Alles an den Eigentümer** — der Gast zahlt dem Eigentümer die gesamte Buchung. Du stellst dem Eigentümer deine Provision nachträglich in Rechnung. * **Aufgeteilt** — der Gast zahlt zweimal: deine Provision an dich bei der Buchung, den Rest an den Eigentümer. Nichts, was du dem Eigentümer schuldest, läuft jemals über dein Konto. Bei einer Aufteilung fragt eine weitere Checkbox, ob **der Eigentümer seinen Anteil in bar** nimmt — bei der Anreise übergeben, statt über eine Zahlungsmethode zu laufen. Deine Provision wird weiterhin online bezahlt, wenn der Gast bucht; Reynt hält fest, was dem Eigentümer zusteht, und du bestätigst den Eingang. Das betrifft ausschließlich den Anteil des *Eigentümers*: Dein eigener Anteil ist nie bar, und eine Anzahlung, die erst bei der Anreise übergeben wird, sichert nichts ab. Das Bestätigen ist wirklich freiwillig — nichts drängt dich dazu. Ein Baranteil wird nie angemahnt (der Gast übergibt ihn bei der Anreise, es gibt also nichts, woran man ihn erinnern könnte) und er taucht auch nicht unter *Überfällige Zahlungen* auf, weil ein längst vergangener Aufenthalt sonst dauerhaft als Schuld dort stehen bliebe. Das ist Absicht: Das Geld ging vom Gast direkt an den Eigentümer und hat dein Konto nie berührt. Was dir zusteht — die Provision — ist bei der Buchung eingegangen. Die [Eigentümer-Abrechnung](/de/docs/invoices/creation-and-numbering/) weist den Barbetrag ohnehin aus, ob du ihn bestätigt hast oder nicht. Ein Eigentümer, bei dem nichts angekommen ist, hat damit ein Dokument zum Nachfragen — und genau darüber erfährst du davon. Im Direktmodus gibt es genau eine Abrechnung und keinen Eigentümer, an den etwas geleitet werden könnte — die Frage wird deshalb nicht angezeigt. Davon unabhängig hat jede **Zahlungsmethode**, die du aktivierst — Banküberweisung, Mollie — ihr eigenes Panel, und eine davon ist als **Standard** markiert: mit dieser Methode starten neue Buchungen. Bei einer Aufteilung entspricht die **Anzahlung deiner Provision** und geht an dich, während die **Restzahlung an den Eigentümer** geht. Die Provision steuert auch die [Eigentümer-Abrechnungsrechnung](/de/docs/invoices/creation-and-numbering/). ### Wenn ein Eigentümer abweicht [Section titled “Wenn ein Eigentümer abweicht”](#wenn-ein-eigentümer-abweicht) Was du hier einstellst, ist dein **Standard**, keine feste Regel. Im Marktplatz-Modus kann ein einzelner Eigentümer anders abrechnen — siehe [Zahlungsbedingungen für einen einzelnen Eigentümer](/de/docs/customers-and-owners/owners/#zahlungsbedingungen-f%C3%BCr-einen-einzelnen-eigent%C3%BCmer). Seine Buchungen werden nach seinen eigenen Bedingungen angeboten, abgerechnet und beglichen — vom Preis, den ein Gast in deinem Storefront sieht, bis zum Zahlungsdatensatz; alle anderen folgen weiterhin deinem Standard. ## Was ein Gast auswählt [Section titled “Was ein Gast auswählt”](#was-ein-gast-auswählt) Wenn du **mehr als eine Zahlungsart aktiviert** hast, wählt der Gast beim Checkout zwischen ihnen. Bei nur einer Zahlungsart gibt es nichts zu wählen und Reynt zeigt die Frage gar nicht — das ist derzeit bei den meisten Workspaces so. Zwei Dinge wählt ein Gast nie: * **Wer das Geld einzieht.** Das ist Teil deiner Vereinbarung mit dem Eigentümer, keine Checkout-Einstellung. Alle angezeigten Optionen werden deshalb gleich abgerechnet. * **Eine Option, die du nicht einlösen kannst.** Reynt prüft vor der Anzeige, ob eine Zahlungsart tatsächlich bezahlbar ist — Mollie auf einem Konto, das noch keine Zahlungen annehmen kann, taucht schlicht nicht auf. Beim Absenden wird erneut geprüft, damit ein zwischenzeitlich getrenntes Konto nicht durchrutscht. Nimmt ein Gast ein **Angebot** an, das du verschickt hast, kann er nur eine Zahlungsart wählen, die den im Angebot genannten Zahlungsplan beibehält. Sonst würden sich die Beträge nachträglich ändern, die ihm mitgeteilt wurden. ## Wo du Zahlungen siehst [Section titled “Wo du Zahlungen siehst”](#wo-du-zahlungen-siehst) * **Dashboard → Finanzen** — die Karten **Offene Zahlungen** und **Überfällige Zahlungen** fassen zusammen, was über alle Buchungen hinweg noch offen ist. Die Beträge rechnen eine noch nicht eingezogene Preisminderung aus einer Abwärts-Änderung heraus, sodass sie mit dem übereinstimmen, was die Zahlung-Karte der einzelnen Buchung als geschuldet zeigt — nicht mit der ursprünglichen (Brutto-)Belastung. Baranteile zählen **nicht** mit: Dieses Geld kommt nie bei dir an, ein längst vergangener Aufenthalt stünde dort also als Schuld, die du gar nicht eintreiben kannst. Auf der Zahlung-Karte der Buchung siehst du ihn weiterhin. * **Buchungsdetail → Zahlung-Karte** — der Geldfluss für eine Buchung. Jede Zeile liest sich als *Zahler → Empfänger via Methode* (z. B. der Gast → Betreiber via Überweisung), mit Gesamtbetrag fällig, Gesamtbetrag bezahlt und Rest, und lässt dich eine Rate als bezahlt markieren. Ein *Teilweise bezahlt*-Badge und eine „X von Y erhalten“-Zeile erscheinen, sobald ein Teil einer Rate eingegangen ist. * **Finanzen → Zahlungen** — eine Liste jeder Buchungszahlung mit **Referenz**, **Anbieter**, **Betrag**, **Status** und **Erstellt**-Datum. Filtere nach Status, um zu finden, was noch offen ist. * **Zahlungsdetail** — öffne eine Zahlung, um die Parteien (Zahler, Objekt, Eigentümer), den Geldfluss jeder Überweisung und die Aktionen zum Erfassen von Zahlungen, Erstattungen und dem Abgleich von Erstattungen zu sehen. Der Verlauf **Aktivität → Zahlungen** der Buchung protokolliert jede einzelne Belastung, Gutschrift, Erstattung und Stornierung mit Ursache und Ziel, sodass du immer eine vollständige Prüfspur der Geldbewegungen bei einer Buchung hast. ## „Bei einer Buchung geht der Zahlungsdatensatz nicht auf“ [Section titled “„Bei einer Buchung geht der Zahlungsdatensatz nicht auf“”](#bei-einer-buchung-geht-der-zahlungsdatensatz-nicht-auf) Jede Nacht prüfen wir bei jeder Buchung den Zahlungsverlauf gegen den Betrag, der laut Buchung offen ist. Passt beides nicht zusammen, erscheint auf deinem Dashboard eine **kritische** Meldung mit den betroffenen Buchungen und der Abweichung. Es ist die einzige kritische Meldung dort, und der Unterschied lohnt sich: Jede andere Meldung ist eine Aufgabe, die du noch nicht erledigt hast — diese sagt, dass sich zwei Aufzeichnungen desselben Geldes widersprechen. * **Die Antwort ist eine Nacht alt.** Die Meldung nennt, wann zuletzt geprüft wurde — was du heute Morgen behoben hast, steht bis zum Lauf morgen früh weiterhin da. * **Es gibt nichts wegzuklicken.** Bring die Buchung in Ordnung, und die Meldung ist beim nächsten Lauf weg. Das ist Absicht: Ein „Erledigt“-Knopf würde erlauben, eine echte Abweichung wegzuwischen statt zu beheben. * **Öffne Aktivität → Zahlungen der Buchung**, um zu sehen, welche Einträge sich widersprechen. Ist es nicht offensichtlich, frag lieber den Support, statt von Hand nachzujustieren. # Teilzahlungen und Erstattungen > Teilzahlungen und Nachzahlungen erfassen, mit Überzahlungen umgehen und Rückerstattungen bei Überweisungsbuchungen abgleichen. Überweisungsbuchungen werden selten in einer sauberen Zahlung beglichen. Reynt lässt dich genau erfassen, was eingegangen ist — einschließlich Teilzahlungen, Nachzahlungen und Überzahlungen — und Geld verwalten, das du zurücksenden musst. All das geschieht auf der **Zahlung**-Karte einer Buchung oder der **Zahlungen**-Detailseite. ## Teilzahlungen [Section titled “Teilzahlungen”](#teilzahlungen) Zahlt ein Gast weniger als den offenen Betrag einer Rate, verwende **Zahlung erfassen** und gib den tatsächlich eingegangenen Betrag ein. Die Rate bleibt **Ausstehend** mit einem *Teilweise bezahlt*-Badge und einer „X von Y erhalten“-Zeile, und die Gesamtzahlung der Buchung wechselt auf **Teilweise bezahlt**. Von da an fordern alle Zahlungsanweisungen, die Reynt dem Gast anzeigt oder per E-Mail sendet — die Erinnerung, die „Anweisungen senden“-E-Mail und der EPC-QR-Code — den **verbleibenden Restbetrag** an, nicht den ursprünglichen Betrag, und können anzeigen, wie viel bereits eingegangen ist. Der Gast erhält weiterhin eine Zahlungsbestätigung für den Teilbetrag. ## Nachzahlungen [Section titled “Nachzahlungen”](#nachzahlungen) Eine teilweise bezahlte Rate kann erneut erfasst werden — Zahlungseingänge summieren sich, bis die Rate vollständig gedeckt ist. Ist eine Rate einmal vollständig **Bezahlt**, kann sie nicht erneut erfasst werden. ## Überzahlungen [Section titled “Überzahlungen”](#überzahlungen) Sendet ein Gast mehr als den offenen Betrag, erfasse trotzdem den vollen Betrag. Reynt akzeptiert ihn, und die Rate zeigt ein **Überzahlt um X**-Badge. Du kannst den Überschuss dann als Erstattung zurückgeben. ## Eine erfasste Zahlung korrigieren [Section titled “Eine erfasste Zahlung korrigieren”](#eine-erfasste-zahlung-korrigieren) Eine Überweisung mit dem falschen Betrag erfasst? Jeder Eintrag auf der Karte **Erfasste Zahlungen** (auf der Zahlungsdetailseite) hat eine Aktion **Betrag korrigieren**. Trage ein, was tatsächlich eingegangen ist — der ursprüngliche Eintrag bleibt sichtbar, grau hinterlegt und mit *korrigiert* gekennzeichnet, sodass die Korrektur als Prüfspur nachvollziehbar bleibt statt den Eintrag stillschweigend zu ändern. * Der Zahlungsstatus wird anhand des korrigierten Betrags in beide Richtungen neu abgeleitet: Ein reduzierter Eintrag kann **Bezahlt** wieder zu **Teilweise bezahlt** machen, ein zu niedrig erfasster Betrag kann **Teilweise bezahlt** zu **Bezahlt** machen. * Trägst du **0** ein, wird die Zahlung ganz entfernt — nutze das, wenn das Geld nie eingegangen ist. * Eine verknüpfte Rechnung gleicht ihren Zahlungsstatus entsprechend ab. * Eine Zahlung kann nur einmal korrigiert werden. Korrigierst du das Ergebnis einer früheren Korrektur, zielt das auf diesen neuen Eintrag, nicht auf den ursprünglichen. ## Ad-hoc-Erstattungen [Section titled “Ad-hoc-Erstattungen”](#ad-hoc-erstattungen) Um bereits erhaltenes Geld zurückzugeben — eine Überzahlung oder eine Kulanzgeste — verwende **Rückerstattung erfassen** auf der bezahlten oder überzahlten Rate. Gib den Betrag und die Partei ein, von der er stammt. Dies erfasst eine Erstattungs-**Verpflichtung**; es bewegt nicht von sich aus Geld. Du kannst nie eine Erstattung für mehr erfassen, als von dieser Partei tatsächlich eingegangen ist. Sobald du das Geld überwiesen hast, gleichst du die Verpflichtung ab: * Öffne die Karte *Offene Rückerstattungen* (auf der Zahlungsdetailseite oder im Verlauf **Aktivität → Zahlungen** der Buchung). * Wähle **Als erstattet markieren** und gib die Überweisungsreferenz deiner Bank ein. Das hält das Hauptbuch der Buchung ehrlich darüber, was noch geschuldet wird und was bereits zurückgegeben wurde. Eine Erstattung lässt sich nur in voller erfasster Höhe abgleichen — Reynt lässt dich nie mehr abgleichen, als für diese Partei tatsächlich eingegangen ist, auch nicht teilweise. **Bei Mollie-Zahlungen musst du nichts überweisen.** Wurde die Rate über deine Mollie-Bezahlseite bezahlt, bietet die Karte *Offene Rückerstattungen* statt des manuellen Abgleichs eine Aktion **Über Mollie erstatten** an: Reynt beauftragt Mollie mit der Rückzahlung und erfasst den Abgleich, sobald Mollie sie bestätigt. Die Erstattung läuft immer über die Organisation zurück, die das Geld erhalten hat — es gibt keinen Rückgriff über Organisationen hinweg; eine vom Eigentümer kassierte Rate wird also von dessen Konto erstattet, nicht von deinem. ## Erstattungen aus Stornierungen und Änderungen [Section titled “Erstattungen aus Stornierungen und Änderungen”](#erstattungen-aus-stornierungen-und-änderungen) Erstattungen entstehen auch automatisch, wenn sich eine Buchung ändert: * **Eine Buchung nach unten zu ändern** (einschließlich einer Teilstornierung — siehe [Buchung ändern](/de/docs/bookings/modify-a-booking/)) erfasst eine Erstattungsverpflichtung für die Differenz (es wird dabei keine Rechnung automatisch erstellt oder korrigiert). * **Eine Buchung zu stornieren** erstattet das Bezahlte gemäß der geltenden Stornierungsrichtlinie. Ob diese Verpflichtung Geld ist, das du tatsächlich zurückgeben musst, hängt davon ab, was der Gast bereits bezahlt hatte: * War der reduzierte Betrag **noch nicht bezahlt**, ist es eine **Gutschrift auf die Belastung** — der geschuldete Betrag sinkt einfach, es gibt nichts zurückzusenden. Das erscheint nicht in *Offene Rückerstattungen* und lässt sich nicht abgleichen. * Hatte der Gast diesen Betrag **bereits bezahlt**, ist es eine echte Auszahlung und landet in *Offene Rückerstattungen*, damit du sie mit **Als erstattet markieren** abgleichst — genau wie eine Ad-hoc-Erstattung. Hatte er nur einen Teil des reduzierten Betrags bezahlt, ist auch nur dieser bezahlte Anteil rückzahlbar — Reynt begrenzt den Abgleich auf das, was tatsächlich eingegangen ist. Wie die Erstattungsbeträge zustande kommen und wie die Richtlinie angewendet wird, ist beschrieben unter [Stornierungen und Erstattungen](/de/docs/bookings/cancellations-and-refunds/) und [Buchung ändern](/de/docs/bookings/modify-a-booking/). # Zahlungsanbieter > Richte Banküberweisung und Mollie unter Einstellungen → Zahlungen ein und steuere, womit Gäste bezahlen können. Du aktivierst und konfigurierst die Zahlung unter **Einstellungen → Zahlungen**. **Banküberweisung** und **Mollie** sind die Methoden, die du aktivierst, und [wer das Geld kassiert](/de/docs/payments/overview/#wer-kassiert-das-geld) entscheidet, wie es geleitet wird. Im Marktplatz-Modus kannst du den Eigentümer seinen Anteil außerdem bar bei der Anreise statt per Überweisung nehmen lassen. ## Banküberweisung [Section titled “Banküberweisung”](#banküberweisung) Die Banküberweisung ist die primäre, produktionsreife Methode. Aktiviere **Banküberweisung aktivieren** und trage dann ein: * **Kontoinhaber**, **IBAN** und **BIC / SWIFT** — das Konto, auf das Gäste einzahlen. Diese sind erforderlich, bevor Überweisungszahlungen angefordert werden können; die Konsole warnt dich, wenn sie unvollständig sind. * **Anzahlung** (Prozentsatz) — wie viel vom Gesamtbetrag die Anzahlung ausmacht. * Drei Tagesfelder legen fest, wann welche Rate fällig wird. Jedes nennt das Datum, ab dem es zählt: * **Anzahlung fällig (Tage nach Buchung)** zählt *vorwärts* ab dem Tag der Buchung. Wenn du keine Anzahlung nimmst, legt es die Fälligkeit des Gesamtbetrags fest. * **Anzahlung spätestens (Tage vor Anreise)** zählt *rückwärts* ab der Anreise und begrenzt das Feld darüber — so muss auch eine kurzfristige Buchung noch vor der Anreise bezahlt werden. * **Restzahlung fällig (Tage vor Anreise)** zählt *rückwärts* ab der Anreise. Kein Fälligkeitsdatum liegt jemals in der Vergangenheit — bei einer kurzfristigen Buchung wird die Rate einfach sofort fällig. (Bei einer Aufteilung im Marktplatz-Modus ist der Anzahlungs-Prozentsatz auf deinen Provisionssatz festgelegt.) Das **Zahlungsreferenz-Präfix** (Standard `P`) wird verwendet, um die Referenz zu bilden, die Gäste bei ihrer Überweisung angeben. ### Was der Gast sieht [Section titled “Was der Gast sieht”](#was-der-gast-sieht) Für jede ausstehende Überweisungs-Rate zeigt Reynt dem Gast **Zahlungsanweisungen**: die Referenz, den Betrag, das Fälligkeitsdatum, deine Bankdaten und einen **EPC-QR-Code** („Zum Bezahlen scannen“), den er mit seiner Banking-App scannen kann. Gäste erhalten diese auch per E-Mail — siehe [Benachrichtigungen und E-Mail](/de/docs/communication/notifications-and-email/). ### Zahlungseingang bestätigen [Section titled “Zahlungseingang bestätigen”](#zahlungseingang-bestätigen) Überweisungen gehen außerhalb des Systems ein, daher bestätigst du sie selbst. Auf der **Zahlung**-Karte einer Buchung oder auf der **Zahlungen**-Detailseite: * **Als bezahlt markieren** erfasst eine vollständige Rate als eingegangen. * **Zahlung erfassen** erfasst einen Teilbetrag oder eine Nachzahlung (siehe [Teilzahlungen und Erstattungen](/de/docs/payments/partial-payments-and-refunds/)). * Wenn du Geld zurückschuldest, listet die Karte *Offene Rückerstattungen* ungeklärte Erstattungen mit einer Aktion **Als erstattet markieren** — erfasse sie, nachdem du das Geld überwiesen hast. ## Mollie [Section titled “Mollie”](#mollie) Gäste zahlen über eine gehostete Mollie-Bezahlseite — Karte, iDEAL, Bancontact und die weiteren Methoden, die dein Mollie-Konto freigeschaltet hat. **Das Geld geht direkt auf deine eigene Mollie-Organisation** — Reynt hält das Geld deiner Gäste zu keinem Zeitpunkt und ist nicht Partei der Zahlung, sondern erstellt sie nur in deinem Auftrag. ### Mollie-Organisation verbinden [Section titled “Mollie-Organisation verbinden”](#mollie-organisation-verbinden) Unter **Einstellungen → Zahlungen** findest du die Karte **Mollie-Verbindung**: 1. **Mollie verbinden** leitet dich zu Mollie, um Reynt zu autorisieren. Wenn du noch kein Mollie-Konto hast, lege dort zuerst eines an. 2. Zurück in der Konsole zeigt die Karte deine **Organisation** und dein **Zahlungsprofil** mit einem Status: * **Bereit** — Mollie-Zahlungen können angeboten werden. * **Wartet auf Mollie** — verbunden, aber Mollie hat das Konto noch nicht für Zahlungen freigegeben. Erledige die offenen Schritte in deinem Mollie-Dashboard und klicke dann **Status neu prüfen**. * **Nicht abgeschlossen** — eine Verbindung wurde begonnen, aber nie fertiggestellt. Verbinde erneut. 3. Aktiviere **Mollie-Zahlungen annehmen**. Das setzt eine verbundene Organisation voraus, die tatsächlich Zahlungen annehmen kann. Meldet die Karte, dass Mollie **auf dieser Installation nicht eingerichtet** ist, dann ist plattformseitig keine Mollie-Connect-App konfiguriert — das kannst du hier nicht beheben; wende dich an deinen Plattform-Administrator. **Trennen** verhindert, dass neue Buchungen über Mollie bezahlt werden. Bereits geleistete Zahlungen bleiben davon unberührt und verbleiben bei deiner Mollie-Organisation. ### Wann der Gast den Zahlungslink bekommt [Section titled “Wann der Gast den Zahlungslink bekommt”](#wann-der-gast-den-zahlungslink-bekommt) **Wann der Zahlungslink verschickt wird** steuert den Zeitpunkt: * **Sofort** — der Gast bekommt den Link direkt bei Veröffentlichung der Buchung. * **Näher an der Anreise** — der Link wird zurückgehalten, sinnvoll bei lange im Voraus gebuchten Aufenthalten. Setze dazu **Tage vor Anreise**; die Verfügbarkeit wird stündlich geprüft. Anders als bei der Banküberweisung bestätigst du Mollie-Zahlungen **nicht** selbst — Mollie meldet Reynt den Geldeingang, und der Zahlungsstatus der Buchung aktualisiert sich von allein. Auch Erstattungen werden gegenüber Mollie ausgeführt, statt nach einer manuellen Überweisung erfasst zu werden. ### Im Marktplatz-Modus [Section titled “Im Marktplatz-Modus”](#im-marktplatz-modus) Auf welcher Mollie-Organisation die jeweilige Rate landet, folgt daraus, [wer das Geld kassiert](/de/docs/payments/overview/#wer-kassiert-das-geld) — die Mollie-Schiene führt diese Antwort aus, statt sie noch einmal zu treffen: | Wer kassiert | Wohin das Geld geht | | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Alles an dich** | Der Gast bezahlt die gesamte Buchung in einem Checkout auf dein Mollie-Konto. | | **Alles an den Eigentümer** | Die gesamte Buchung geht auf das Mollie-Konto des Eigentümers; deine Provision rechnest du separat ab. | | **Aufgeteilt** | Zwei Online-Zahlungen: deine Provision bei Buchung auf dein Konto, der Rest vor Anreise auf das des Eigentümers. **Der Eigentümer braucht ein [eigenes Mollie-Konto](/de/docs/customers-and-owners/owners/#das-mollie-konto-eines-eigent%C3%BCmers-verbinden).** | | **Aufgeteilt**, mit *Der Eigentümer nimmt seinen Anteil in bar* | Deine Provision wird bei Buchung online bezahlt; den Rest zahlt der Gast dem Eigentümer bar bei der Anreise. Der Eigentümer braucht kein Mollie-Konto. | Ein einzelner Eigentümer kann abweichend von deinem Standard auf einer anderen dieser Varianten stehen — siehe [Zahlungsbedingungen für einen einzelnen Eigentümer](/de/docs/customers-and-owners/owners/#zahlungsbedingungen-f%C3%BCr-einen-einzelnen-eigent%C3%BCmer). ## Testzahlungen (Demo-Modus) [Section titled “Testzahlungen (Demo-Modus)”](#testzahlungen-demo-modus) **Testzahlungen** sind eine Schiene, auf der kein Geld fließt: Der Gast begleicht die ganze Buchung mit einem Klick auf einer Zahlungsseite, die Reynt für dich bereitstellt. Sie braucht keine Zugangsdaten und keine Bankverbindung, und jede Belastung, jeder Eingang und jede Erstattung landen genauso im Zahlungsverlauf wie bei einer echten — Rechnungen, Änderungen und Abrechnung verhalten sich also ganz normal. Es ist keine Möglichkeit, Zahlungen entgegenzunehmen. Solange sie an ist, ist **deine Website für niemanden erreichbar**: Die Öffentlichkeit sieht eine Wartungsseite, und du erreichst deine eigene Seite über die Konsole. Genau das macht das Einschalten sicher — und deshalb bittet dich die Livegang-Checkliste, den Demo-Modus zu verlassen, statt Zahlungen einzurichten. Einschalten solltest du sie über die Seite **Live gehen**, nicht hier — die Karte dort legt auch die Beispielinhalte an, die dir überhaupt etwas zum Buchen geben. Siehe [Demo-Modus](/docs/getting-started/demo-mode/). ## Womit Gäste bezahlen können [Section titled “Womit Gäste bezahlen können”](#womit-gäste-bezahlen-können) Gästen wird angeboten, was für die jeweilige Buchung gilt. Bei Banküberweisung erhalten sie Zahlungsanweisungen und einen QR-Code; bei Mollie eine gehostete Bezahlseite; und wenn der Eigentümer seinen Anteil in bar nimmt, wird dessen Restzahlung stattdessen bei der Anreise eingezogen — dafür gibt es keine eigene Konfiguration, das ergibt sich daraus, wie diese Buchung abgerechnet wird. Was gilt, wird pro Buchung entschieden: aus den [Zahlungsbedingungen](/de/docs/customers-and-owners/owners/#zahlungsbedingungen-f%C3%BCr-einen-einzelnen-eigent%C3%BCmer) des Eigentümers dieses Objekts, wenn er eigene hat, und sonst aus deinem Standard. # Wann du kassierst > Eine Regel dafür, ab wann ein Gast zahlen kann, welche Teile des Preises angefordert werden und was passiert, wenn eine Zahlung überfällig wird. Bisher brachte jede Zahlungsart ihren eigenen Zeitpunkt mit: Online-Checkout hatte eine eigene Einstellung, bei der Überweisung entschied darüber, welche Zeilen deine Buchungs-E-Mails gerade anzeigten. **Einstellungen → Zahlungen → Zahlungszeitpunkt festlegen** ersetzt das durch eine Regel, die für jede aktivierte Zahlungsart gilt. Sie steht bewusst über den Zahlungsarten: Wann du kassierst, ist eine Geschäftsbedingung und keine Eigenschaft eines Zahlungsdienstleisters. Sie ausgeschaltet zu lassen ist eine echte Entscheidung und kein halber Schritt — jede Zahlungsart behält dann ihren bisherigen Zeitpunkt, es ändert sich nichts. ## Ab wann ein Gast zahlen kann [Section titled “Ab wann ein Gast zahlen kann”](#ab-wann-ein-gast-zahlen-kann) | Einstellung | Bedeutung | | --------------------------------------- | --------------------------------------------------------------------------------------------------- | | **Sobald die Buchung existiert** | Ab dem Moment der Veröffentlichung, vorgemerkt wie bestätigt. So verhält es sich ohne Regel. | | **Erst wenn ich die Buchung bestätige** | Solange du noch prüfst, gibt es nichts zu zahlen. Der Zahlungslink erscheint, sobald du bestätigst. | | **Kurz vor der Anreise** | Die Zahlung öffnet eine bestimmte Anzahl Tage vor dem Check-in, stündlich geprüft. | Die Forderung selbst entsteht immer bei der Veröffentlichung der Buchung — der Preis steht ohnehin ab da fest. Diese Einstellung ändert nur, ab wann der Gast darauf reagieren kann. ### Was sie zurückhalten kann und was nicht [Section titled “Was sie zurückhalten kann und was nicht”](#was-sie-zurückhalten-kann-und-was-nicht) * **Online-Zahlung (Mollie) und Testzahlungen** — vollständig zurückgehalten. Es wird keine Checkout-Sitzung geöffnet, es gibt also keinen Link. * **Überweisung** — **nur ein Hinweis.** Dein Gast hat deine IBAN bereits und kann jederzeit überweisen. Die Regel hält Zahlungs*links* und den Online-Checkout zurück, keine Überweisung. * **Barzahlung bei Anreise** — nicht anwendbar, sie ist per Definition beim Check-in fällig. Die Konsole sagt dir das direkt an der Einstellung, statt es dich an einem Gast herausfinden zu lassen, der trotzdem überwiesen hat. ### Wenn du es später änderst [Section titled “Wenn du es später änderst”](#wenn-du-es-später-änderst) **Lockern wirkt von selbst.** Wechselst du von „Erst wenn ich bestätige“ auf „Sobald die Buchung existiert“, bekommen die wartenden Buchungen ihre Zahlungslinks innerhalb einer Stunde. **Verschärfen gilt für Links, die noch nicht raus sind.** Wer schon einen Online-Zahlungslink erhalten hat, behält ihn — wir nehmen niemandem einen Link weg, der vielleicht gerade mitten im Bezahlen ist. Willst du eine bestimmte Zahlung stoppen, storniere oder ändere diese Buchung statt der Regel. ## Welche Teile des Preises du anforderst [Section titled “Welche Teile des Preises du anforderst”](#welche-teile-des-preises-du-anforderst) Die klassische Aufteilung — eine Anzahlung, solange du prüfst, der Rest nach der Bestätigung — ist ein Schalter: **Vor und nach der Bestätigung unterschiedliche Beträge anfordern**. Du wählst, was eine vorgemerkte Buchung angefordert bekommt und was eine bestätigte, aus *Anzahlung*, *Restbetrag* und *Gesamtbetrag*. Das gilt für jede Zahlungsart und ändert, was der Gast angefordert bekommt, nicht was die Buchung kostet. Preis und Fälligkeiten stehen seit der Veröffentlichung fest. Bleibt der Schalter aus, entscheidet wie bisher jede Buchungs-E-Mail für sich. ## Wenn eine Zahlung überfällig wird [Section titled “Wenn eine Zahlung überfällig wird”](#wenn-eine-zahlung-überfällig-wird) Überschreitet eine Zahlung ihr Fälligkeitsdatum, macht eine tägliche Prüfung eines von drei Dingen: | Einstellung | Wer davon erfährt | | ---------------------------- | ---------------------------------------------------------------------------------------------------- | | **Nichts** | Niemand. Fälligkeiten werden festgehalten, aber nichts passiert. | | **Nur mich benachrichtigen** | Du — als Eintrag in deiner Glocke. Kein Gast bekommt je eine E-Mail. **Das ist die Voreinstellung.** | | **Gast erinnern** | Du bekommst weiterhin den Glocken-Eintrag, und der Gast bekommt eine Erinnerung. | Die mittlere Stufe gibt es, damit du das erst beliebig lange an deinen eigenen Buchungen mitlesen kannst, bevor du entscheidest, ob ein Gast davon hören soll. Vier Dinge lohnt es zu wissen, bevor du das einschaltest: * **Der erste Lauf startet nur die Uhr.** Er verschickt nichts. Eine Fälligkeit, die verstrichen ist, während niemand hingesehen hat, ist eine nie gestellte Rechnung und kein Gast, der eine Erinnerung ignoriert hat. * **Es greift nie zurück.** Zahlungen, die länger als 30 Tage überfällig sind, bleiben bei jedem Lauf außen vor — ein Nachholen nach einer ruhigen Phase kann also nichts über das letzte Frühjahr verschicken. * **Eine Buchung ist ein Gespräch.** Drei überfällige Zahlungen derselben Buchung ergeben eine E-Mail mit der Gesamtsumme, nicht drei. * **Es mahnt nichts an, was der Gast nicht zahlen kann.** Eine Zahlung, die deine eigene Regel noch nicht geöffnet hat, wird nie angemahnt. Gäste werden drei Tage vor Fälligkeit erinnert, dann einen Tag danach und noch einmal eine Woche später. Diese Zeitpunkte sind fest — die Frage, die sich zu entscheiden lohnt, ist, ob du überhaupt nachfasst und ob der Gast es hört, und das ist die Tabelle oben. Die beiden Erinnerungs-E-Mails kannst du unter **Einstellungen → Benachrichtigungen** einzeln abschalten und im Wortlaut anpassen. ## Termine freigeben, wenn niemand zahlt [Section titled “Termine freigeben, wenn niemand zahlt”](#termine-freigeben-wenn-niemand-zahlt) **Termine freigeben, wenn niemand zahlt** ist die Vereinbarung „wir halten die Termine, bis die Anzahlung da ist“. Sie ist standardmäßig aus und die einzige Einstellung auf dieser Seite, die eine Buchung rückgängig macht — es lohnt sich, sie ganz zu lesen. Setzt du eine Anzahl Tage, wird eine vorgemerkte Buchung, die so lange nach ihrer Fälligkeit unbezahlt bleibt, **storniert** und ihre Termine freigegeben. Storniert, nicht nur freigegeben: Deine Stornobedingungen greifen, es wird sauber verbucht, und der Gast bekommt dieselbe Stornierungs-E-Mail wie wenn du selbst storniert hättest. Nur die Termine freizugeben würde eine lebende Buchung ohne Objekt dahinter hinterlassen — eine Doppelbuchung mit Ansage. Was nie angetastet wird: * **Eine Buchung, auf die schon etwas gezahlt wurde.** Wer einen Teil bezahlt hat, ist ein Gespräch und kein Automatismus. * **Eine bestätigte Buchung.** Nur vorgemerkte kommen infrage. * **Eine Buchung, die aus einem anderen Grund gehalten wird** — ein Halten, das auf deine Entscheidung wartet, hat keine Frist. * **Alles außerhalb derselben 30-Tage-Grenze**, die auch für die Überfälligkeits-Prüfung gilt. Du bekommst am Tag **davor** einen Glocken-Eintrag, wenn eine Buchung zur Freigabe ansteht, und einen weiteren, wenn es passiert ist. Die Option erscheint erst, wenn du dich entschieden hast, bei überfälligen Zahlungen überhaupt etwas zu tun — steht dort „Nichts“, hast du diese Frage schon beantwortet. ## Wo du das Ergebnis siehst [Section titled “Wo du das Ergebnis siehst”](#wo-du-das-ergebnis-siehst) * **Dashboard → Geld** — die Karte *Überfällige Zahlungen*. * **Deine Glocke** — überfällige Zahlungen, anstehende Freigaben und erfolgte Freigaben. * **Einstellungen → Zahlungen**, ganz oben — eine klare Antwort darauf, ob Gäste überhaupt zur Zahlung aufgefordert werden, mit Link auf das, was gerade im Weg steht. Fünf Einstellungen entscheiden darüber und vier davon erwähnen Geld mit keinem Wort; nach jeder Änderung hier lohnt sich ein Blick. # Preise und saisonale Zeiträume > Wie Reynt einen Übernachtungspreis aus wiederkehrenden und jahresspezifischen Preiszeiträumen bildet. Reynt verwendet keinen einzelnen Grundpreis mit Multiplikatoren. Stattdessen hat jedes Objekt eine Liste von **Preiszeiträumen**, und jeder Zeitraum trägt einen absoluten Preis pro Nacht. Wenn ein Gast Daten auswählt, sucht Reynt den Zeitraum, der jede Nacht abdeckt, und berechnet diesen Preis. Öffne ein Objekt und wähle den Tab **Preise**, um sie zu verwalten. ## Preiszeiträume [Section titled “Preiszeiträume”](#preiszeiträume) Klicke auf **Erstellen**, um einen Zeitraum hinzuzufügen. Jeder hat: * **Saisonname** — optionale Bezeichnung (z. B. „Hochsaison“), die in der Preisaufschlüsselung angezeigt wird. * **Zeitraum** — der Datumsbereich, für den der Preis gilt. * **Preis pro Nacht** — der Übernachtungspreis, in der Währung des Objekts. * **Gültig ab** — siehe [Preisänderung planen](#%C3%A4nderung-planen) unten. ### Wiederkehrend vs. jahresspezifisch [Section titled “Wiederkehrend vs. jahresspezifisch”](#wiederkehrend-vs-jahresspezifisch) Der Schalter **Wiederkehrend** entscheidet, ob sich der Zeitraum jedes Jahr wiederholt: * **Wiederkehrend (an)** — wähle einen Start- und End-**Tag und -Monat** ohne Jahr. Der Zeitraum gilt jedes Jahr und wird in der Tabelle als **Jedes Jahr** gekennzeichnet. Das ist die Standardeinstellung und deckt die meisten Preisfälle ab. Ein wiederkehrender Bereich, dessen Ende vor seinem Beginn liegt, wechselt einfach ins folgende Jahr (z. B. 1. Oktober – 31. März). * **Wiederkehrend (aus)** — wähle konkrete Kalenderdaten, sodass der Zeitraum nur für **ein Jahr** gilt (gekennzeichnet z. B. mit „Nur 2026“). Wenn der Bereich eine Jahresgrenze überschreitet, behalten beide Enden ihr Jahr (z. B. „Nur 2026–2027“) — nützlich für ein bestimmtes Weihnachts-/Neujahrsfenster. ### Preise nach Gästeanzahl [Section titled “Preise nach Gästeanzahl”](#preise-nach-gästeanzahl) Aktiviere **Individuelle Preise pro Gästeanzahl**, um je nach Anzahl der buchenden Gäste einen anderen Übernachtungspreis zu berechnen — zum Beispiel einen niedrigeren Preis für 2 Gäste als für die maximale Gästeanzahl des Objekts. Lässt du eine Gästeanzahl leer, wird auf den Preis des Zeitraums zurückgegriffen. ## Wie sich der Übernachtungspreis ergibt [Section titled “Wie sich der Übernachtungspreis ergibt”](#wie-sich-der-übernachtungspreis-ergibt) Für jede Nacht eines Aufenthalts sucht Reynt den Preiszeitraum, der diese Nacht abdeckt. Wenn sich Zeiträume überschneiden, entscheiden drei Regeln, welcher gewinnt: 1. **Jahresspezifisch schlägt wiederkehrend** — ein für ein bestimmtes Jahr festgelegter Zeitraum überschreibt für dieselben Daten immer einen wiederkehrenden. 2. **Zuletzt wirksam gewinnt** — ein Zeitraum mit einem späteren **Gültig ab**-Datum hat Vorrang. 3. **Enger schlägt weiter** — ein kurzes Sommerfenster überschreibt einen ganzjährigen Zeitraum an den Tagen, die sie gemeinsam haben. Nutze den **Preistester** am Ende des Tabs, um ein beliebiges Datum auszuwählen und zu bestätigen, welchen Zeitraum (und Preis) Reynt anwenden wird. ### Änderung planen [Section titled “Änderung planen”](#änderung-planen) Bei einem wiederkehrenden Zeitraum ermöglicht dir **Gültig ab**, eine Preisänderung zu planen, ohne bestehende Angebote zu stören: Der neue Preis gilt nur für Nächte an oder nach diesem Datum. Lege heute den höheren Preis für nächstes Jahr fest, und laufende Buchungen behalten den alten Preis. ## Objektwährung [Section titled “Objektwährung”](#objektwährung) Standardmäßig kalkuliert ein Objekt in der Standardwährung des Mandanten. Die Karte **Währung** im Tab „Preise“ überschreibt dies pro Objekt (EUR, USD, CHF oder GBP) — praktisch für ein grenzüberschreitendes Portfolio. Belasse es bei **Mandanten-Standard übernehmen**, außer die Unterkunft kalkuliert tatsächlich in einer anderen Währung. ## Der „Ab“-Preis im Storefront [Section titled “Der „Ab“-Preis im Storefront”](#der-ab-preis-im-storefront) Suchkarten und Objektseiten zeigen einen einzigen Leitpreis, der aus diesen Zeiträumen abgeleitet wird. Wie er abgeleitet wird, ist eine storefrontweite Einstellung unter **Kunden-Oberfläche → Erscheinungsbild → Anzeige der Unterkünfte → Preisermittlung für die Anzeige**: * **Durchschnittlicher Nachtpreis (Ø)** — der Durchschnitt über die Zeiträume des Jahres. * **Günstigster Preis (ab …)** — der niedrigste Zeitraumpreis. Diese Wahl bestimmt auch, wogegen der Storefront-Preisfilter und die Preissortierung vergleichen. ## Siehe auch [Section titled “Siehe auch”](#siehe-auch) * [Aufenthaltsregeln](/de/docs/pricing/stay-rules/) — Mindest-/Höchstaufenthalt und An-/Abreisebeschränkungen. * [Rabatte und Gebühren](/de/docs/pricing/discounts-and-fees/) — Aufenthaltsdauer-Rabatte, Frühbucherangebote, Kautionen und Haustiergebühren. # Rabatte und Gebühren > Automatische Aufenthaltsdauer- und Frühbucherrabatte, Kautionen und Haustiergebühren. Über den Übernachtungspreis hinaus kann ein Objekt automatische Rabatte anwenden und ein paar Gebühren berechnen. Beide finden sich in der Objekt-Detailansicht. ## Automatische Rabatte [Section titled “Automatische Rabatte”](#automatische-rabatte) Öffne ein Objekt und wähle den Tab **Rabatte**. Ein Rabatt reduziert den Preis, sobald seine Bedingungen zutreffen — der Gast benötigt dafür keinen Code (das sind [Aktionscodes](/de/docs/pricing/promo-codes/)). Jeder Rabatt hat: * **Zusammenfassung** — die Bezeichnung, die in der Preisaufschlüsselung des Gastes angezeigt wird (z. B. „Wochenrabatt“). * **Beschreibung** — optionaler längerer Text, der beim Checkout angezeigt wird. * **Typ und Wert** — **Prozentsatz**, **Festbetrag** (einmal pro Buchung) oder **Festbetrag pro Tag** (pro Nacht). * **Bedingungen** — die Regeln, die entscheiden, wann der Rabatt gilt. ### Bedingungen [Section titled “Bedingungen”](#bedingungen) Füge eine oder mehrere Bedingungen hinzu; **alle müssen zutreffen**, damit der Rabatt angewendet wird. Lässt du die Liste leer, gilt der Rabatt **immer**. Verfügbare Bedingungen: * **Aufenthaltsdauer (Nächte)** — z. B. 7 Nächte oder mehr. * **Anzahl Gäste** — z. B. mindestens 4 Gäste. * **Tage vor Anreise (Frühbucher)** — wie weit im Voraus die Buchung vorgenommen wird. * **Anreise-Wochentag** — nur für Aufenthalte, die an ausgewählten Tagen beginnen. * **Abreise-Wochentag** — nur für Aufenthalte, die an ausgewählten Tagen enden. Geprüft wird der Abreisetag (der Morgen, an dem der Gast abreist) — ein Samstag-zu-Samstag-Aufenthalt zählt also als Samstag-Abreise. Kombiniere ihn mit **Anreise-Wochentag**, um vollständige Wechseltag-Aufenthalte zu belohnen. * **Reisezeitraum (saisonal)** — der Aufenthalt überschneidet sich mit einem Datumsfenster. * **Buchungsdatum** — die Buchung wird innerhalb eines Datumsfensters vorgenommen. * **Buchung bis Stichtag (pro Reisejahr)** — eine Frühbucher-Frist, die am **Reisejahr** verankert ist: Die Buchung muss z. B. spätestens am 31. März des Jahres der Anreise vorgenommen werden. Da sie sich am Reisejahr statt an einem festen Kalenderdatum orientiert, qualifiziert sich eine weit im Voraus vorgenommene Buchung immer. ### Bewerben und Ablauf [Section titled “Bewerben und Ablauf”](#bewerben-und-ablauf) Aktiviere **In Suchergebnissen bewerben**, um einen Rabatt als Badge auf Storefront-Karten zu bewerben — Gäste müssen ihre Daten oder Personenzahl eventuell anpassen, um sich zu qualifizieren. Sind die Bedingungen eines Rabatts an bestimmte Kalenderjahre gebunden, zeigt Reynt sein Ablaufdatum an und deaktiviert ihn automatisch, sobald dieses Datum verstrichen ist. ## Gebühren [Section titled “Gebühren”](#gebühren) Öffne den Tab **Gebühren**. Reynt hält Gebühren bewusst minimal — es gibt **kein Reinigungsgebühren- oder Buchungsgebühren**-Feld. Du kannst festlegen: * **Kaution** — die rückerstattbare Sicherheitsleistung, die du für dieses Objekt verlangst. * **Haustierpreis** mit einem **Haustierpreis-Typ** — wie die Haustiergebühr berechnet wird: **Pro Aufenthalt**, **Pro Tag**, **Pro Haustier** oder **Pro Haustier/Tag**. Die Haustiergebühr wird berechnet: Sie erscheint als eigene Zeile in der Preisaufschlüsselung und auf der Rechnung. Die Kaution **nicht**. Reynt nennt lediglich den Betrag — er wird nie zur Summe addiert, nie in Rechnung gestellt und von Reynt weder eingezogen noch zurückerstattet oder nachgehalten. Die Kaution einzubehalten und nach dem Check-out zurückzuzahlen, bleibt vollständig dein eigener Prozess außerhalb des Systems. Reynt nennt sie dem Gast an zwei Stellen: * **Auf der Objektseite**, als eigener Hinweis neben den Stornierungsbedingungen. Standardmäßig sichtbar: Die Kaution ist eine Zahlungsverpflichtung, die in keiner Preisaufschlüsselung auftaucht — hier sieht ein Gast sie als Einziges vor der Buchung. Zum Ausblenden schalte **Kaution anzeigen** unter **Kunden-Oberfläche → Website → Objektdetail** ab — siehe [Einstellungen integrierter Ansichten](/de/docs/storefront/built-in-view-settings/#objektdetail). * **In der E-Mail „Buchung bestätigt“.** Du kannst sie zusätzlich in die E-Mails **Buchung erstellt** und **Zahlungsanweisungen** aufnehmen — unter [Einstellungen → Benachrichtigungen](/de/docs/communication/notifications-and-email/). Keine der beiden Stellen sagt, *wie* die Kaution gezahlt oder zurückgegeben wird — das teilst du dem Gast selbst mit, in deiner Hausordnung oder der Objektbeschreibung. Für optionale kostenpflichtige Extras (Ausstattung, Services, Pakete) nutze [Zusatzleistungen](/de/docs/listings/addons/) anstelle von Gebühren. ## Kurtaxe und Tourismusabgabe [Section titled “Kurtaxe und Tourismusabgabe”](#kurtaxe-und-tourismusabgabe) Die Kurtaxe/Tourismusabgabe wird **nicht** hier konfiguriert. Sie ist Teil deiner Steuereinrichtung — siehe [Steuern](/de/docs/invoices/taxes/). (Der Tab „Gebühren“ enthält eine objektbezogene Überschreibung dafür, aber die Steuer selbst wird unter **Rechnungen** definiert.) ## Wie es sich dem Gast darstellt [Section titled “Wie es sich dem Gast darstellt”](#wie-es-sich-dem-gast-darstellt) Beim Checkout und in der Buchung listet die Preisaufschlüsselung zunächst die Übernachtungs-Zwischensumme, dann jeden zutreffenden Rabatt mit seiner Zusammenfassung, dann die Haustiergebühr, sofern eine anfällt. Die Kaution ist nicht Teil dieser Aufschlüsselung — sie wird separat in den Buchungs-E-Mails genannt. Ein [Aktionscode](/de/docs/pricing/promo-codes/) ersetzt automatische Rabatte, wenn der Gast einen gültigen Code eingibt. # Aktionscodes > Mandantenweite Rabattcodes, die Gäste beim Checkout eingeben, mit Geltungsbereich und Nutzungslimits. Aktionscodes sind Rabattcodes, die ein Gast beim Checkout eingibt — zum Beispiel `SUMMER5` für 5 % Rabatt. Anders als [automatische Rabatte](/de/docs/pricing/discounts-and-fees/) bleiben sie verborgen, bis ein gültiger Code eingegeben wird. Verwalte sie unter **Kunden-Oberfläche → Aktionen**. ## Einen Code erstellen [Section titled “Einen Code erstellen”](#einen-code-erstellen) Klicke auf **Neue Aktion** und fülle aus: * **Code** — was der Gast eingibt (z. B. `SUMMER5`). Der Abgleich ist nicht case-sensitiv. * **Bezeichnung** — wird in der Preisaufschlüsselung angezeigt, z. B. „Sommeraktion“. * **Beschreibung** — optionaler längerer Text beim Checkout. * **Rabatttyp und -wert** — **Prozent (%)**, **Fester Betrag** oder **Fest pro Nacht**. ## Wo er gilt (Geltungsbereich) [Section titled “Wo er gilt (Geltungsbereich)”](#wo-er-gilt-geltungsbereich) Die Einstellung **Gilt für** steuert, welche Objekte den Code akzeptieren: * **Alle Objekte** — jedes Objekt im Konto. * **Bestimmte Objekte** — nur die von dir gewählten Objekte. * **Objekte mit Tag** — jedes Objekt, das mindestens eines der gewählten Tags trägt. Neue Objekte, die das Tag erhalten, werden automatisch einbezogen. ## Gültigkeit und Nutzungslimits [Section titled “Gültigkeit und Nutzungslimits”](#gültigkeit-und-nutzungslimits) * **Gültig ab / Gültig bis** — das Einlösungsfenster. Lass eines der beiden Felder leer für keine Begrenzung. (Für „5 % im Juni“ setze beide auf Juni.) * **Max. Einlösungen** — eine globale Obergrenze über alle Kunden hinweg. Leer bedeutet unbegrenzt. Die Tabelle zeigt Einlösungen als `verwendet / Limit`. * **Limit pro Kunde** — wie oft ein Kunde den Code verwenden darf. Leer bedeutet unbegrenzt. Dieses Limit wird geprüft, wenn die Buchung **bestätigt** wird — ein Kunde kann den Code also eingeben und den Rabatt in seinem Angebot sehen, aber eine wiederholte Nutzung über das Limit hinaus wird erst in diesem letzten Schritt abgelehnt. * **Aktiv** — ein übergeordneter Ein-/Aus-Schalter, unabhängig vom Zeitfenster. ## Zusammenspiel mit automatischen Rabatten [Section titled “Zusammenspiel mit automatischen Rabatten”](#zusammenspiel-mit-automatischen-rabatten) Ein Aktionscode wird **nicht** mit den automatischen Rabatten eines Objekts kombiniert — ein gültiger Code **ersetzt** sie und gilt an ihrer Stelle. Aktionscodes nutzen dieselben Rabatttypen und können dieselben Arten von Voraussetzungen tragen wie automatische Rabatte, sodass ein Code weiterhin z. B. eine Mindestaufenthaltsdauer verlangen kann. ## Wo Gäste ihn eingeben [Section titled “Wo Gäste ihn eingeben”](#wo-gäste-ihn-eingeben) Gäste geben den Code im Checkout-Ablauf deines Storefronts ein. Ist ein Code ungültig — falscher Code, außerhalb seines Zeitfensters, Objekt außerhalb des Geltungsbereichs oder ein Limit erreicht —, liefert das Angebot dennoch einen normalen (codefreien) Preis und zeigt den Grund an, statt die Buchung zu blockieren. ## Siehe auch [Section titled “Siehe auch”](#siehe-auch) * [Rabatte und Gebühren](/de/docs/pricing/discounts-and-fees/) — automatische, codefreie Rabatte. * [Ausstattung, Attribute und Tags](/de/docs/listings/amenities-attributes-and-tags/) — lege die Tags fest, die von tag-gebundenen Codes genutzt werden. # Aufenthaltsregeln > Mindest- und Höchstaufenthalt sowie An-/Abreisebeschränkungen, objektweit und pro Saison. Aufenthaltsregeln steuern, wie lange ein Gast buchen kann und an welchen Tagen er an- oder abreisen darf. Sie kommen in zwei Ebenen: ein objektweiter Standard und saisonale Überschreibungen. Es gibt keine separate „Wochenendpreisgestaltung“ — Wochentage wirken sich nur auf Aufenthaltsbeschränkungen aus, nicht auf den Preis. ## Objektweite Standardwerte [Section titled “Objektweite Standardwerte”](#objektweite-standardwerte) Öffne ein Objekt, gehe zum Tab **Objektdaten** und lege fest: * **Mindestaufenthalt** — die wenigsten Nächte, die ein Gast buchen darf. * **Maximaler Aufenthalt** — die meisten Nächte, die ein Gast buchen darf (0 = unbegrenzt). Diese gelten für jedes Datum, sofern keine Saisonregel sie überschreibt. ## Saisonale Aufenthaltsregeln [Section titled “Saisonale Aufenthaltsregeln”](#saisonale-aufenthaltsregeln) Für Regeln, die nur während eines Teils des Jahres gelten, öffne den Tab **Aufenthaltsregeln** des Objekts und klicke auf **Erstellen**. Jede Regel hat: * **Saison** — den Datumsbereich, den sie abdeckt. Wie Preiszeiträume ist eine Regel **Wiederkehrend** (wiederholt sich jedes Jahr) oder auf ein **bestimmtes Jahr** begrenzt. * **Gilt an** — schränkt die Regel auf bestimmte Wochentage ein. Belasse sie bei **Jeden Tag**, oder wähle bestimmte Tage — z. B. nur Samstage, um Samstag-zu-Samstag-Aufenthalte durchzusetzen. * **Mindestaufenthalt** — in dieser Saison erforderliche Nächte. Leer lassen, um den Objektstandard zu übernehmen. * **Höchstaufenthalt** — in dieser Saison erlaubte Nächte. Leer lassen für kein Maximum. * **Keine Anreise (closed to arrival)** — Gäste können an den abgedeckten Daten/Wochentagen keinen Aufenthalt beginnen. * **Keine Abreise (closed to departure)** — Gäste können an den abgedeckten Daten/Wochentagen nicht auschecken. Geprüft wird der **Abreisetag** (der Morgen, an dem der Gast abreist), nicht die letzte Übernachtung. Mit „Keine Anreise“ und „Keine Abreise“ baust du Wechseltage auf — erlaube zum Beispiel in der Hochsaison Anreisen nur freitags. ### Wenn sich Regeln überschneiden [Section titled “Wenn sich Regeln überschneiden”](#wenn-sich-regeln-überschneiden) Wenn zwei saisonale Regeln dieselben Daten abdecken, löst Reynt dies wie bei Preisen auf: * Die **engere Saison** gewinnt an den Tagen, die sie gemeinsam haben. * Sind die Bereiche ansonsten gleich, gewinnt die Regel mit dem zuletzt liegenden **Gültig ab**-Datum. Der Editor warnt dich inline, wenn eine neue Regel eine bestehende überschneidet. ## Wie der Storefront sie durchsetzt [Section titled “Wie der Storefront sie durchsetzt”](#wie-der-storefront-sie-durchsetzt) Aufenthaltsregeln werden automatisch an zwei Stellen durchgesetzt: * **Im Buchungskalender** — Nächte, die den Mindest-/Höchstaufenthalt oder eine An-/Abreisebeschränkung verletzen würden, können nicht ausgewählt werden. * **Beim Checkout** — ein Aufenthalt, der eine Regel bricht, wird abgelehnt, bevor die Buchung bestätigt wird, sodass keine regelwidrige Buchung durchrutschen kann. Du musst nichts separat veröffentlichen; das Speichern einer Regel wirkt sich sofort auf den Storefront aus. ## Siehe auch [Section titled “Siehe auch”](#siehe-auch) * [Preise und saisonale Zeiträume](/de/docs/pricing/base-and-seasonal/) — den Übernachtungspreis pro Zeitraum festlegen. * [Daten sperren](/de/docs/availability/block-dates/) — ein Objekt unabhängig von Aufenthaltsregeln als nicht verfügbar markieren. # Erscheinungsbild und Theme > Branding-, Theme-, Kontakt-, Rechts- und Anzeigeeinstellungen für den integrierten Storefront. **Kunden-Oberfläche → Erscheinungsbild** enthält die visuellen und inhaltlichen Einstellungen für deinen integrierten Storefront — Branding, Theme, Kontaktdaten, SEO und wie Objekte angezeigt werden. Jeder Abschnitt speichert für sich. ## Branding [Section titled “Branding”](#branding) Lege dein **Storefront-Logo** und **Favicon** fest, beide aus deiner Mediathek ausgewählt. Das sind die kundenseitigen Markenzeichen — getrennt vom Betreiber-Logo, das auf Rechnungen und PDFs verwendet wird. ## Theme [Section titled “Theme”](#theme) Das Erscheinungsbild deines Storefronts: * **Primärfarbe** — die Markenfarbe für Buttons, Akzente und Überschriften. Leer lassen für die Standardeinstellung. * **Basis-Schriftart** — die Schriftart für den gesamten Text (Standard: Inter). * **Signatur-Schriftart** — eine optionale Schriftart für Überschriften und hervorgehobenen Text; verwendet standardmäßig die Basis-Schriftart. ## SEO-Standardwerte [Section titled “SEO-Standardwerte”](#seo-standardwerte) Standard-SEO-Metadaten für Seiten, die keine eigenen festlegen: **Standard-Meta-Titel** (verwendet standardmäßig deinen Mandantennamen), **Standard-Meta-Beschreibung** und ein **Standard-OG-Bild**, das beim Teilen von Links in sozialen Medien angezeigt wird. Einzelne Seiten und Beiträge können diese überschreiben. ## Kontaktkanäle [Section titled “Kontaktkanäle”](#kontaktkanäle) Die im Storefront-Header und -Footer sowie auf der Kontaktseite angezeigten Kontaktdaten: **Öffentliche Telefonnummer**, **Öffentliche E-Mail-Adresse** und **Adresse**. Lass ein Feld leer, um es auszublenden. ## Rechtliche Seiten [Section titled “Rechtliche Seiten”](#rechtliche-seiten) Datenschutzerklärung, AGB und Impressum legst du unter **Einstellungen → Kunden-Oberfläche** fest — direkt neben dem Veröffentlichen-Schalter, den sie freischalten. Siehe [Domains und SEO](/de/docs/storefront/domains-and-seo/) und die Checkliste in der [Storefront-Übersicht](/de/docs/storefront/overview/). ## Partner-Logos [Section titled “Partner-Logos”](#partner-logos) Eine optionale Logoleiste im Footer für Partner, Zertifizierungen oder Kooperationen. Füge jedes Logo (aus deiner Mediathek) mit Alt-Text und optionalem Link zur Website des Partners hinzu; ordne sie bei Bedarf neu an. ## Objektanzeige [Section titled “Objektanzeige”](#objektanzeige) Legt fest, was Gäste auf Objektkarten und -seiten sehen: * **Preisanzeige auf der Übersichtsseite** — wie Preise auf Suchergebniskarten erscheinen: **Keine** (ausgeblendet) oder **Zusammenfassung** (durchschnittlicher Preis pro Nacht). * **Preisanzeige auf der Detailseite** — wie saisonale Preise auf der Objektseite erscheinen: **Keine**, **Zusammenfassung** (durchschnittlicher Preis pro Nacht) oder **Detailliert** (vollständige saisonale Aufschlüsselung). * **Reiseziel-Anzeige** auf den Objektkarten — ausblenden oder den Reiseziel-Namen, die übergeordneten Reiseziele oder beides anzeigen. * **Entfernungen anzeigen** — wähle, welche Entfernungstypen (z. B. nächster Strand) auf Ergebniskarten erscheinen, oder blende sie alle aus. ## Optionen für die Herkunftsquelle [Section titled “Optionen für die Herkunftsquelle”](#optionen-für-die-herkunftsquelle) Die Auswahlmöglichkeiten im Checkout-Feld „Wie haben Sie von uns erfahren?“. Füge die gewünschten Optionen hinzu (z. B. Google, Instagram, ein Freund); lass die Liste leer, um das Feld ganz auszublenden. Jede Auswahl wird bei der resultierenden Buchung gespeichert. ## Blog [Section titled “Blog”](#blog) Anzeigeoptionen für den Blog — zum Beispiel steuert **Veröffentlichungsdatum bei Beiträgen anzeigen**, ob das Datum auf Blogkarten und Beitragsseiten erscheint. Siehe [Blog](/de/docs/storefront/blog/). # Blog > Blogbeiträge für deinen Storefront schreiben und veröffentlichen. Der **Blog**-Editor (unter **Kunden-Oberfläche → Blog**) lässt dich Beiträge schreiben, die auf dem Blog-Index deines Storefronts und als einzelne Artikel erscheinen. Er funktioniert wie der Seiten-Editor: eine Seitenleiste mit Beiträgen links und der Editor des ausgewählten Beitrags rechts mit Live-Vorschau. ## Beitragsliste [Section titled “Beitragsliste”](#beitragsliste) Die linke Seitenleiste listet jeden Beitrag mit seinem Status (Entwurf oder Veröffentlicht) und bei mehrsprachigen Mandanten ein Übersetzungsvollständigkeits-Badge auf. Nutze **Beitrag erstellen**, um einen neuen zu beginnen, oder wähle einen bestehenden Beitrag zum Bearbeiten aus. Du kannst nach Status filtern. ## Beitragseinstellungen [Section titled “Beitragseinstellungen”](#beitragseinstellungen) Öffne die **Einstellungen** eines Beitrags, um zu bearbeiten: * **Titel** und **URL-Pfad** (Slug, z. B. `my-post` → `/blog/my-post`) — beides pro Sprache. * **Status** — Entwurf (ausgeblendet) oder Veröffentlicht (live). * **Veröffentlichungsdatum** — wird auf dem Beitrag angezeigt und zur Sortierung der Beiträge verwendet. Es ist optional; du kannst es allein zur Steuerung der Sortierreihenfolge setzen, selbst wenn du das Datum auf dem Storefront ausblendest. * **Auszug** — eine kurze Zusammenfassung, die in der Blogliste und den Suchergebnissen angezeigt wird. * **Beitragsbild** — das Hauptbild oben im Beitrag und in Listenansichten. * **SEO-Metadaten** — Meta-Titel (verwendet standardmäßig den Beitragstitel) und Meta-Beschreibung (verwendet standardmäßig den Auszug), plus ein OG-Bild für das Teilen in sozialen Medien. * **Tags** — zum Gruppieren und Filtern von Beiträgen. ## Beitragsinhalt [Section titled “Beitragsinhalt”](#beitragsinhalt) Der Beitragstext wird aus denselben **Abschnitten** wie CMS-Seiten aufgebaut (Rich Text, Bild + Text, Bildergalerie, Video und mehr — eine Auswahl mit Fokus auf Artikelinhalte). Füge Abschnitte hinzu, ordne sie neu an, blende sie aus und bearbeite sie genau wie andernorts, mit sprachspezifischem Inhalt und einer Vorschau-Sprachauswahl. Siehe [Eigene Seiten und CMS](/de/docs/storefront/custom-pages-and-cms/) für die Funktionsweise von Abschnitten. Eine Live-Vorschau rechts zeigt den Beitrag so, wie er auf dem Storefront erscheinen wird, und aktualisiert sich beim Speichern. ## Einen Beitrag mit KI generieren [Section titled “Einen Beitrag mit KI generieren”](#einen-beitrag-mit-ki-generieren) Blogbeiträge unterstützen KI-Inhaltsgenerierung: Starte den Workflow aus der Abschnittsliste des Beitrags, damit Reynt Artikelabschnitte für dich entwirft, die du prüfen und bearbeiten kannst. Siehe [Inhaltsgenerierung und Übersetzung](/de/docs/ai/content-generation-and-translation/). ## Veröffentlichung [Section titled “Veröffentlichung”](#veröffentlichung) Setze den Status eines Beitrags auf **Veröffentlicht**, um ihn live zu schalten — es gibt keinen Planungsschritt. Entwurfsbeiträge bleiben für die Öffentlichkeit ausgeblendet, sind aber in der Vorschau sichtbar. Veröffentlichte Beiträge erscheinen auf der **Blog**-Indexseite deines Storefronts (sortiert nach Veröffentlichungsdatum) und unter ihrer eigenen `/blog/`-URL. ## Blog-Anzeigeoptionen [Section titled “Blog-Anzeigeoptionen”](#blog-anzeigeoptionen) Steuere die Blog-Darstellung unter **Kunden-Oberfläche → Erscheinungsbild → Blog** — zum Beispiel, ob das Veröffentlichungsdatum auf Beitragskarten und Detailseiten erscheint. Siehe [Erscheinungsbild und Theme](/de/docs/storefront/appearance-and-theming/). # Einstellungen integrierter Ansichten > Die Optionen, die neben einer einzelnen integrierten Storefront-Ansicht liegen — Suchkarten, Objektdetail, Buchungsformular, Blog und Seitentexte. Die meisten Storefront-Einstellungen gelten seitenweit und liegen unter **Einstellungen → Storefront**. Einige wenige betreffen genau *eine* Ansicht — und die liegen bei dieser Ansicht: Öffne **Kunden-Oberfläche → Website**, wähle eine integrierte Ansicht und klappe unterhalb ihrer Abschnitte den Block **Einstellungen** auf. Die Regel hilft beim Suchen: Formt eine Einstellung genau eine Ansicht, findest du sie bei dieser Ansicht. Formt sie die ganze Website, steht sie in den Einstellungen. Jede Karte im Block speichert für sich — änderst du eine und speicherst sie, behalten die übrigen ihre Werte. Der Block erscheint nur, wenn deine Rolle Einstellungen lesen darf; zum Speichern braucht es das Recht, sie zu ändern. ## Welche Ansichten Einstellungen haben [Section titled “Welche Ansichten Einstellungen haben”](#welche-ansichten-einstellungen-haben) | Ansicht | Einstellungen | | -------------------- | ------------------------------------------------------------------- | | **Objekte** | Kartenanzeige, Katalog-Layout, Suchfilter, Paginierung, Suchranking | | **Objektdetail** | Welche Abschnitte erscheinen, Preisanzeige der Detailseite | | **Buchungsformular** | Telefonpflicht, Referrer-Optionen, bevorzugte Länder | | **Blog** | Anzeige der Beiträge | | **Buchung** | Seitentexte | | **Angebot** | Seitentexte | **Startseite**, **Merkliste**, **Blogbeitrag** und **Kontakt** haben keine Einstellungen — sie sind reine Inhaltsflächen, der Block erscheint dort nicht. Die Ansicht **Angebot** hat überhaupt keine Inhaltsabschnitte, deshalb ist ihr Einstellungsblock von vornherein aufgeklappt: Dort *sind* die Einstellungen die Seite. ## Objekte [Section titled “Objekte”](#objekte) Die Suchergebnisseite. Fünf Karten: **Anzeige der Suchergebniskarten** — was jede Objektkarte zeigt (Gäste, Schlafzimmer, Bäder, Wohnfläche, Entfernungen) und wie der Ort dargestellt wird: ausgeblendet, nur Ortsname, nur Breadcrumb oder Name plus Breadcrumb. Ausgeblendete Felder werden gar nicht erst an das Storefront übertragen — das gilt also für *jede* Objektkarte deiner Website, auch für Galerie- und Suchabschnitte auf deinen eigenen Seiten. Zwei Preis-Entscheidungen liegen ebenfalls hier: * **Preisanzeige auf der Übersichtsseite** — `Zusammenfassung` zeigt einen Nachtpreis auf jeder Karte, `Keine` blendet Preise ganz aus. * **Preisermittlung für die Anzeige** — ob dieser Preis der Durchschnitt („Ø X pro Nacht“) oder der günstigste Saisonpreis („ab X / Nacht“) ist. Diese Einstellung reicht weiter als die Karte: Sie steuert auch Kartenmarker, die Zusammenfassung auf der Detailseite und die SEO-Daten — und sie entscheidet, womit Preisfilter und Preissortierung vergleichen. **Katalog-Layout** — bei nur wenigen Objekten steht die volle Suchoberfläche (Filter, Karte, Sortierung, Paginierung) in keinem Verhältnis. Das einfache Layout lässt sie weg und ändert außerdem das Standard-Navigationsmenü. **Suchfilter** — die Entfernungsschwellen im Filter-Panel, in Metern (leer = 500 / 1000 / 2000 / 5000 / 10000; bis zu 20 Werte, beim Speichern dedupliziert und sortiert), sowie die Obergrenze des Preis-Sliders (0 = 500 €). **Paginierung der Suchergebnisse** — nummerierte Seiten mit Gesamtanzahl oder schlanke Zurück/Weiter-Schaltflächen. Ohne die Gesamtanzahl spart Reynt bei großen Katalogen eine Datenbankabfrage. Hier legst du auch fest, wie viele Objekte pro Seite erscheinen — das steuert Raster, Kartenmarker und Paginierung gemeinsam. **Suchranking** — justiert den Qualitäts-Score hinter der Empfohlen-Sortierung: relative Gewichte für Vollständigkeit, Beliebtheit und Aktualität (0–1), eine Beliebtheits-Obergrenze, einen Aktualitäts-Horizont in Tagen und Boosts je Tag obendrauf. Hervorgehobene Inserate stehen unabhängig davon immer vorn. Das Bewertungsgewicht ist wirkungslos, solange es keine Bewertungen gibt. ## Objektdetail [Section titled “Objektdetail”](#objektdetail) Eine Karte, **Objektdetailseite**, die steuert, welche Abschnitte eine Objektseite zeigt: * **Stornierungsbedingungen anzeigen** — die Karte mit den Bedingungen, wenn dem Inserat eine zugewiesen ist. * **Kaution anzeigen** — der Hinweis auf die rückerstattbare Kaution. Standardmäßig an, weil Reynt die Kaution nie einzieht und sie in keiner Preisaufschlüsselung auftaucht — siehe [Rabatte und Gebühren](/de/docs/pricing/discounts-and-fees/). * **Standortkarte anzeigen** — die Karte und das Standort-Panel darum. Dazu **Preisanzeige auf der Detailseite**: `Keine` blendet Saisonpreise aus, `Zusammenfassung` zeigt den durchschnittlichen Nachtpreis, `Detailliert` die vollständige Saisonaufstellung. ## Buchungsformular [Section titled “Buchungsformular”](#buchungsformular) **Buchungsformular** — ob eine Telefonnummer zum Buchen verlangt wird. Schalte sie ab, wenn du Gäste nie anrufst: Das Feld bleibt als optional markiert stehen, und ein Pflichtfeld weniger bedeutet weniger Abbrüche. Das gilt auch für deine eigene Website, denn Buchungen laufen dort über dieselbe API. **Referrer-Optionen** — die Auswahl im Feld „Wie hast du von uns erfahren?“, je Sprache. Bleibt die Liste leer, verschwindet das Feld. **Bevorzugte Länder** — welche Länder im Buchungsformular oben in der Länderauswahl stehen. ## Blog [Section titled “Blog”](#blog) **Anzeige der Beiträge** — ob das Veröffentlichungsdatum auf Blogkarten und in der Beitragsansicht erscheint. Aus geschaltet bleibt das Datum am Beitrag setzbar und steuert weiter die Sortierung; die strukturierten Daten (JSON-LD) bleiben unberührt. ## Buchung und Angebot [Section titled “Buchung und Angebot”](#buchung-und-angebot) Beide tragen **Texte dieser Seite**: Überschreibungen der Storefront-eigenen Formulierungen auf dieser Seite, je Sprache. Was du leer lässt, behält den eingebauten Text — du füllst also nur aus, was du anders sagen willst. Die Felder sind nach Zugehörigkeit gruppiert: Allgemein, Statusmeldungen, Reisedetails, Gastinformationen, Unterkunftsinformationen, Rechnung & Preis, Angebotsoptionen, Aktionen & Dialoge, Statusanzeigen, Hinweise und Fehlermeldungen. Manche Texte nehmen Platzhalter, die unter dem Feld aufgeführt sind; Texte mit Singular- und Pluralform nehmen beide, getrennt durch einen senkrechten Strich (`|`). Sieh dir die Angebotsansicht zuerst an: Sie hat keine Inhaltsabschnitte, diese Texte sind also die gesamte Seite, die ein Gast sieht, wenn du ein Angebot verschickst. # Eigene Seiten und CMS > Storefront-Seiten, integrierte Ansichten und seitenweite Bereiche aus wiederverwendbaren Inhaltsabschnitten aufbauen. Die **Website**-Oberfläche (unter **Kunden-Oberfläche → Website**) ist der Ort, an dem du jede Ansicht deines Storefronts gestaltest — und dort lebt auch die Navigation, direkt neben den Seiten, die sie verlinkt (siehe [Navigation](/de/docs/storefront/navigation/)). Es ist eine einzige Ansicht: eine Seitenleiste links listet alles auf, was du bearbeiten kannst, und das Panel rechts bearbeitet das ausgewählte Element. Inhalte werden aus einer Bibliothek vorgestalteter **Abschnitte** zusammengestellt — ohne Code. ## Drei Arten von Inhalten [Section titled “Drei Arten von Inhalten”](#drei-arten-von-inhalten) Die Seitenleiste gruppiert deinen Storefront in drei Arten von Containern: * **Startseite & eigene Seiten** — deine Landingpage (**Startseite**) und alle eigenständigen Seiten, die du erstellst (Über uns, FAQ, AGB, ein lokaler Reiseführer, eine Kampagnenseite). Jede eigene Seite hat ihre eigene URL und kann aus deinen Menüs verlinkt werden. * **Integrierte Seiten** — feste Storefront-Ansichten, die du anpassen, aber nicht erstellen oder löschen kannst. Jede zeigt einen **gesperrten Kern-Abschnitt** (die Suchergebnisse, das Checkout-Formular, den Beitragsinhalt), der die Aufgabe der Seite erfüllt; eigene Abschnitte fügst du darüber oder darunter hinzu: * **Startseite** — die Landingpage unter `/`. * **Objekte** — die Suchergebnisseite, auf der Gäste Objekte durchsuchen und filtern. * **Objektdetail** — Abschnitte hier erscheinen auf *jeder* Objektseite. * **Buchung** — die Seite, die Gäste beim Abschluss einer Buchung sehen. * **Buchungsbestätigung** — die Bestätigungsseite, die nach einer erfolgreichen Buchung angezeigt wird. * **Merkliste** — wo Gäste gespeicherte Objekte sehen. * **Blog** — die Blog-Indexseite. * **Blogbeitrag** — Abschnitte hier erscheinen auf *jedem* Beitrag, rund um die eigenen Abschnitte des Beitrags. * **Kontakt** — die Kontaktseite mit dem Anfrageformular. * **Layout** — seitenweite Bereiche, die auf jeder Seite erscheinen: die **Ankündigung** ganz oben und der Bereich **Über Fußzeile**. ## Abschnitte [Section titled “Abschnitte”](#abschnitte) Jeder bearbeitbare Bereich — eine Seite, die Regionen um einen integrierten Kern, eine Layout-Leiste — ist eine geordnete Liste von Abschnitten. Füge einen Abschnitt hinzu, fülle seine Felder aus, ordne ihn neu an, und er wird auf dem Storefront angezeigt. Die Bibliothek umfasst: | Gruppe | Abschnitte | | ----------------------- | --------------------------------------------------------------------- | | Hero & Banner | Hero-Suche, Banner, Call to Action | | Objekte | Ausgewählte Unterkünfte, Objektgalerie, Objektsuche, Kategorienraster | | Inhalt | Rich Text, Bild + Text, Bildergalerie, Video, Karte, Einbettung | | Vertrauen & Bewertungen | Kundenstimmen, Statistiken, Logoleiste, Team | | Wie & warum | Features, Vorteile, Schritte, FAQ, Preise | | Interaktion | Blog, Newsletter, Kontaktformular | Ein paar sind besonders erwähnenswert: * **Hero-Suche** — vollbreites Banner mit Suchleiste; ideal als erster Abschnitt auf der Startseite. * **Ausgewählte Unterkünfte** und **Objektgalerie** — präsentieren eine kuratierte Auswahl an Objekten, gefiltert nach Ort, Tags, Ausstattung, Preis oder Verfügbarkeit. * **Objektsuche** — eine eingebettete Suche mit voreingestellten Filtern, mit der Gäste von jeder Seite aus browsen können. * **Rich Text** — freier, formatierter Text für Beschreibungen, Richtlinien oder Ankündigungen. * **Kontaktformular** — ein konfigurierbares Anfrageformular, dessen Einsendungen in deinem Posteingang landen. * **Einbettung** — isoliertes externes HTML für Widgets oder Drittanbieter-Tools. Nicht jeder Abschnitt ist überall verfügbar — Blogbeiträge und einige integrierte Seiten bieten eine fokussierte Auswahl (nichts, was Gäste z. B. aus dem Checkout herausführen würde). ### Einen Abschnitt bearbeiten [Section titled “Einen Abschnitt bearbeiten”](#einen-abschnitt-bearbeiten) Wähle **Abschnitt hinzufügen**, wähle einen Typ und fülle das Konfigurationsformular aus (ein übersichtliches Formular pro Abschnitt — du bearbeitest nie rohes JSON). Jeder Abschnitt hat: * Einen **Sichtbarkeits**-Schalter — einen Abschnitt ausblenden, ohne ihn zu löschen (ausgeblendete Abschnitte werden in der Vorschau weiterhin angezeigt). * **Nach oben / nach unten** verschieben zum Neuanordnen. * **Abschnitte exportieren / importieren** — die Abschnitte einer Seite in eine JSON-Datei speichern und sie in eine andere Seite reimportieren (anhängen oder ersetzen). ### Sprachspezifischer Inhalt [Section titled “Sprachspezifischer Inhalt”](#sprachspezifischer-inhalt) Übersetzbare Felder (Titel, Text, Button-Beschriftungen) werden pro Sprache bearbeitet, mit einem Tab für jede aktivierte Sprache. Der Abschnitts-Editor hat außerdem eine **Vorschau-Sprache**-Auswahl, die den Abschnitt genau so rendert, wie ihn ein Gast in dieser Sprache sehen würde — inklusive Fallback-Verhalten, wenn eine Übersetzung leer ist. Lässt du eine Sprache leer, fällt der Storefront auf deine Standardsprache zurück, statt einen leeren Abschnitt zu zeigen. ## Seiteneinstellungen und SEO [Section titled “Seiteneinstellungen und SEO”](#seiteneinstellungen-und-seo) Jede eigene Seite hat einen Einstellungsbereich mit: * **Titel** und **Slug** (dem URL-Pfad, z. B. `about-us` → `/about-us`) — beides pro Sprache. * **Status** — Entwurf oder Veröffentlicht. * **SEO-Metadaten** — Meta-Titel, Meta-Beschreibung und ein OG-Bild (für das Teilen in sozialen Medien). Diese fallen auf den Seitentitel und sinnvolle Standardwerte zurück, wenn sie leer bleiben. Integrierte Seiten haben feste URLs und keinen Slug oder Entwurfsstatus — nutze stattdessen die Sichtbarkeit einzelner Abschnitte, um Inhalte auszublenden. Manche integrierten Ansichten haben unterhalb ihrer Abschnitte zusätzlich einen Block **Einstellungen** mit den Optionen, die nur diese eine Ansicht betreffen — Felder der Suchkarten, Abschnitte der Objektdetailseite, Pflichtangaben im Buchungsformular, Seitentexte. Seitenweite Storefront-Einstellungen bleiben unter **Einstellungen → Storefront**; eine Einstellung, die genau eine Ansicht formt, lebt bei dieser Ansicht. Was jede Ansicht bietet, steht unter [Einstellungen integrierter Ansichten](/de/docs/storefront/built-in-view-settings/). Einen Slug umbenennen Menülinks verweisen auf die Seite selbst und folgen einer Umbenennung automatisch. Externe Links dagegen nicht: Lesezeichen, geteilte URLs oder Links von anderen Websites zeigen weiter auf den alten Pfad. Lege den Slug fest, bevor du eine Seite öffentlich teilst — oder richte danach eine Weiterleitung vom alten Pfad ein. ## Vorschau, Entwurf und Veröffentlichung [Section titled “Vorschau, Entwurf und Veröffentlichung”](#vorschau-entwurf-und-veröffentlichung) * **Vorschau** öffnet deinen Storefront in einem neuen Tab mit einem kurzlebigen Zugriffstoken (ca. eine Stunde gültig). Entwurfsseiten und ausgeblendete Abschnitte sind nur in der Vorschau sichtbar. Der Editor zeigt außerdem ein Live-Vorschaufenster, zwischen dem du für Smartphone-, Tablet- und Desktop-Breiten wechseln kannst. * Eigene Seiten starten als **Entwurf** und liefern für die Öffentlichkeit *Seite nicht gefunden*, bis du ihren Status auf **Veröffentlicht** setzt. * Es gibt keine geplante Veröffentlichung — Statusänderungen greifen sofort beim Speichern. Einmal veröffentlicht, ist die Seite sofort live. ## Eine Seite mit KI generieren [Section titled “Eine Seite mit KI generieren”](#eine-seite-mit-ki-generieren) Wenn du eine eigene Seite erstellst, kannst du **Mit KI generieren** wählen: Beschreibe die Seite, und Reynt entwirft ihre Inhaltsabschnitte für dich zur Prüfung und Verfeinerung. Oder beginne leer und füge Abschnitte manuell hinzu. Siehe [Inhaltsgenerierung und Übersetzung](/de/docs/ai/content-generation-and-translation/). # Domains und SEO > Eigene Domains, Kartenkacheln, Analyse und Sucheinstellungen für den Storefront. **Einstellungen → Kunden-Oberfläche** enthält das technische Setup für den integrierten Storefront: wie er ausgeliefert wird, eigene Domains, Karten, Analyse und Suchverhalten. (Visuelle und inhaltliche Einstellungen findest du stattdessen unter **Kunden-Oberfläche → Erscheinungsbild** — siehe [Erscheinungsbild und Theme](/de/docs/storefront/appearance-and-theming/).) ## Rechtliche Seiten [Section titled “Rechtliche Seiten”](#rechtliche-seiten) Die im Footer erforderlichen Links für eine rechtskonforme Website: **Datenschutzerklärung**, **AGB** und **Impressum**. Jede kann auf eine externe URL oder eine von dir erstellte CMS-Seite verweisen. Impressum und Datenschutzerklärung sind erforderlich, bevor dein Storefront live gehen kann — deshalb stehen sie direkt über dem Veröffentlichen-Schalter. ## Veröffentlichung [Section titled “Veröffentlichung”](#veröffentlichung) **Storefront veröffentlichen** steuert, ob deine Website live ist. Neue Storefronts starten als Entwurf und zeigen eine Wartungsseite an, bis du veröffentlichst. Reynt blockiert die Veröffentlichung, bis Impressum, Datenschutzerklärung, eine Benachrichtigungs-E-Mail und eine Zahlungsmethode festgelegt sind — jeder offene Punkt in der Checkliste verlinkt direkt auf die Einstellung, die ihn schließt. Siehe die Checkliste in der [Storefront-Übersicht](/de/docs/storefront/overview/). ## Eigene Domains [Section titled “Eigene Domains”](#eigene-domains) Standardmäßig wird dein Storefront auf einer Plattform-Domain ausgeliefert. Um deine eigene zu verwenden: 1. Füge unter **Eigene Domains** deine Domain hinzu (z. B. `booking.mydomain.com`). 2. Erstelle einen **CNAME**-DNS-Eintrag dafür, der auf deine Plattform-Basisdomain verweist (Reynt zeigt dir das genaue Ziel). 3. Nutze **DNS prüfen** — der Status der Domain wechselt von *DNS ausstehend* zu *Aktiv*, sobald der Eintrag gefunden wird. 4. Lege eine Domain als **Primär** fest, wenn du mehrere hast; sie wird zur kanonischen Adresse für Links. ## Kartenkacheln [Section titled “Kartenkacheln”](#kartenkacheln) Die Karten des Storefronts nutzen einen Kachel-Anbieter (standardmäßig MapTiler), mit den Stilen **Straßen**, **Satellit** oder **Outdoor**. Auf der Standard-Plattform-Domain kannst du den Anbieterschlüssel leer lassen, um den Plattform-Standard zu verwenden. **Wenn du den Storefront unter deiner eigenen Domain betreibst, ist dein eigener Anbieterschlüssel erforderlich** — der Plattform-Schlüssel funktioniert nur auf Plattform-Domains, sodass auf einer eigenen Domain ohne ihn keine Karten geladen werden. ## Analyse und Tracking [Section titled “Analyse und Tracking”](#analyse-und-tracking) Füge deine **Google Analytics 4**-Messkennung hinzu, um den Storefront-Traffic zu verfolgen, sowie eine **Google Ads**-Tag-ID mit Conversion-Labels pro Ziel (Checkout/Buchung, Leads und Telefonanrufe), wenn du Anzeigen schaltest. ## Suchverhalten (kurz) [Section titled “Suchverhalten (kurz)”](#suchverhalten-kurz) **Einstellungen → Kunden-Oberfläche** stimmt außerdem die Sucherfahrung ab — ausführlicher behandelt in [Suche und Karten](/de/docs/storefront/search-and-maps/): * **Paginierung der Suchergebnisse** — nummerierte Seiten mit Gesamtanzahl oder ein einfaches Zurück/Weiter; und wie viele Objekte pro Seite angezeigt werden. * **Suchranking** — die Qualitäts-Score-Gewichte und Tag-Boosts hinter der “Empfohlen”-Sortierung. * **Entfernungsfilter-Werte** und **Suchfilter** — die Schwellenwerte und die Preisschieber-Obergrenze, die Gästen angeboten werden. ## SEO [Section titled “SEO”](#seo) Der Storefront ist von Haus aus für Suchmaschinen optimiert: * **Sprachpräfixierte URLs** — jede Sprache hat ihren eigenen URL-Pfad, und Seiten tragen **hreflang**-Alternativen, damit Suchmaschinen die richtige Sprache ausliefern. * **Sprachspezifische Sitemaps** mit dem übersetzten Slug jeder Seite. * **Sprachübergreifende Weiterleitungen** — wenn ein Gast den Slug einer Seite in der falschen Sprache aufruft, leitet der Storefront zur kanonischen URL dieser Sprache weiter. Siehe [Mehrsprachige Inhalte](/de/docs/languages/multilingual-content/) für die Funktionsweise übersetzter Slugs und hreflang. ### URL-Weiterleitungen [Section titled “URL-Weiterleitungen”](#url-weiterleitungen) Nutze **Einstellungen → Konfiguration → Weiterleitungen**, um SEO bei der Migration von einer bestehenden Website oder nach einer Slug-Änderung zu erhalten. Jede Weiterleitung hat einen **Quellpfad**, einen **Zielpfad**, einen **Übereinstimmungstyp** (Exakt oder Präfix), einen Statuscode und einen Aktiviert-Schalter. Alte URLs leiten dann auf die neuen weiter, statt *nicht gefunden* zurückzugeben. # Navigation > Header- und Footer-Menüs für deinen Storefront erstellen. Die Menüs deines Storefronts baust du auf der **Website**-Oberfläche auf (unter **Kunden-Oberfläche → Website**) — direkt neben den Seiten, auf die sie verlinken. Die Seitenleiste zeigt die Website als Baum: den **Header** (die obere Navigationsleiste) und den **Footer** (Links am unteren Rand jeder Seite) als zwei untereinander liegende Bereiche, gefolgt von **Nicht verknüpften Seiten**, den **Gästereise**-Vorlagen und den seitenweiten **Layout**-Leisten. ## Der Menübaum [Section titled “Der Menübaum”](#der-menübaum) Jedes Menü ist ein Baum aus Einträgen, die du zum Neuanordnen ziehen kannst. Ein Klick öffnet das, worauf der Eintrag zeigt: Ein Seiten- oder Ansichts-Link öffnet den Inhalts-Editor dieser Seite, eine Gruppe oder eigene URL ihre eigenen Einstellungen. Das kleine Zahnrad an einem Seiten- oder Ansichts-Link öffnet die Einstellungen des *Menüeintrags* — Beschriftung, Neuer-Tab-Verhalten, Entfernen. Menüs unterstützen zwei Ebenen: Einträge auf oberster Ebene und Einträge, die in einer Gruppe verschachtelt sind. ## Arten von Menüeinträgen [Section titled “Arten von Menüeinträgen”](#arten-von-menüeinträgen) * **Seitenlink** — verweist auf eine deiner eigenen Seiten oder eine **integrierte Ansicht** (Startseite, Objekte, Blog, Merkliste, Kontakt). Der Eintrag referenziert die Seite selbst und folgt Slug-Umbenennungen automatisch — dieselbe Seite kann an mehreren Stellen verlinkt sein, im Header und Footer gleichzeitig. * **Benutzerdefinierte URL** — ein interner Pfad (z. B. `/about`) oder eine beliebige externe Website-Adresse. * **Gruppe** — ein Dropdown, das andere Einträge enthält. Gruppen können nur eine Ebene tief sein — du kannst keine Gruppe in eine Gruppe verschachteln. Füge Einträge mit dem **Hinzufügen**-Button hinzu (wähle Seitenlink, Benutzerdefinierte URL oder Gruppe). Für jeden Link kannst du **In neuem Tab öffnen** aktivieren, typischerweise für externe URLs. ## Sprachspezifische Beschriftungen [Section titled “Sprachspezifische Beschriftungen”](#sprachspezifische-beschriftungen) Die **Beschriftung** jedes Menüeintrags wird pro Sprache bearbeitet, damit deine Menüs in jeder aktivierten Sprache korrekt angezeigt werden. ## Seiten verlinken und neu anordnen [Section titled “Seiten verlinken und neu anordnen”](#seiten-verlinken-und-neu-anordnen) * Unter den beiden Menüs listet **Nicht verknüpfte Seiten** alle Seiten und integrierten Ansichten auf, die in keinem Menü platziert sind. Ziehe eine davon in einen der Bäume — oder klicke sie an, um zuerst ihren Inhalt zu bearbeiten. * Fahre über einen Eintrag, um seinen Ziehgriff einzublenden, und ziehe ihn dann, um ihn innerhalb des Baums neu anzuordnen oder in eine Gruppe hinein- oder herauszubewegen. * Ein Link, der auch im anderen Menü existiert, zeigt eine kleine Markierung — eine Seite, mehrere Menüeinträge, alle öffnen denselben Inhalt. Umbenennen ist im Menü sicher Menüeinträge verweisen direkt auf die Seite (nicht auf ihre URL). Wenn du den Slug einer Seite umbenennst, folgen alle Menülinks automatisch. Nur **Eigene URL**-Einträge speichern einen Pfad als Text — die pflegst du selbst. Ein Menülink auf eine Seite im **Entwurf** bleibt im Editor erhalten, wird Besuchern aber erst nach der Veröffentlichung angezeigt. ## Fallback-Navigation [Section titled “Fallback-Navigation”](#fallback-navigation) Wenn du keine Menüeinträge konfiguriert hast, greift der Storefront auf eine automatische Navigation basierend auf deinen obersten Reisezielen zurück, damit sich Gäste weiterhin zurechtfinden, während du deine Menüs aufbaust. # Storefront-Übersicht > Was der Reynt-Storefront ist, wie er betrieben wird und was Gäste dort tun können. Der Storefront ist deine öffentliche, kundenseitige Buchungswebsite: dort suchen Gäste nach deinen Objekten, öffnen Objektseiten und buchen. Er ist eine eigenständige Website, getrennt von der Verwaltungskonsole — Gäste sehen die Konsole nie, und du öffnest den Storefront selbst nur selten. ## Zwei Arten, einen Storefront zu betreiben [Section titled “Zwei Arten, einen Storefront zu betreiben”](#zwei-arten-einen-storefront-zu-betreiben) Unter **Einstellungen → Kunden-Oberfläche → Modus der Kunden-Oberfläche** legst du fest, wie deine öffentliche Website ausgeliefert wird: * **Integrierte Kunden-Oberfläche** — Reynt hostet und rendert die gesamte Website für dich. Buchungslinks, Objektlinks und deine Website-URL werden automatisch aus deiner Storefront-Domain abgeleitet. Dies ist die Standardeinstellung, und alles in diesem Abschnitt bezieht sich darauf. * **Eigene Website** — du betreibst deine eigene Website und nutzt Reynt nur als Buchungs-Engine. Du legst die Storefront-URLs manuell fest und baust das Frontend selbst mit dem Headless SDK (einem typisierten API-Client für einen vollständig individuellen Storefront). Inhalts-, Erscheinungsbild- und CMS-Einstellungen in der Konsole gelten in diesem Modus nicht. Die restlichen Seiten in diesem Bereich gehen vom integrierten Storefront aus. ## Was Gäste tun können [Section titled “Was Gäste tun können”](#was-gäste-tun-können) * **Suchen** nach deinen Objekten nach Reiseziel (einem Ort), Reisedaten und Personenzahl (Erwachsene, Kinder, Haustiere). Siehe [Suche und Karten](/de/docs/storefront/search-and-maps/). * **Die Karte durchsuchen** und eine **Objekt-Detailseite** mit Fotos, Beschreibung, Ausstattung, Verfügbarkeit, Lage und Preisen öffnen. * **Buchen** — der Checkout folgt dem für das jeweilige Objekt festgelegten Buchungsablauf. Siehe [Buchungslebenszyklus](/de/docs/bookings/lifecycle/). * **Objekte speichern** in einer Merkliste. * **Deinen Blog lesen** und alle von dir veröffentlichten eigenen Seiten (Über uns, FAQ, lokale Reiseführer, AGB). * **Dich kontaktieren** über ein integriertes Kontakt-/Anfrageformular, das in deinem [Posteingang](/de/docs/communication/inbox/) landet. ## Inhalte stammen aus drei Quellen [Section titled “Inhalte stammen aus drei Quellen”](#inhalte-stammen-aus-drei-quellen) * **Objekte**, die du unter **Objekte** verwaltest — werden als durchsuchbare Objektseiten angezeigt. * **CMS-Seiten, Abschnitte, Slots und Navigation**, verwaltet unter **Kunden-Oberfläche → Website** — deine Startseite, Marketingseiten, feste Inhaltsbereiche und die Header-/Footer-Menüs. Siehe [Eigene Seiten und CMS](/de/docs/storefront/custom-pages-and-cms/) und [Navigation](/de/docs/storefront/navigation/). * **Storefront-Einstellungen** — Branding, Theme, Navigation, SEO und Kontaktdaten unter **Kunden-Oberfläche → Erscheinungsbild**, sowie das technische Setup und die rechtlichen Seiten unter **Einstellungen → Kunden-Oberfläche**. Inhaltsänderungen sind innerhalb von etwa einer Minute live — es gibt keinen Deploy-Schritt. ## Mehrere Sprachen [Section titled “Mehrere Sprachen”](#mehrere-sprachen) Der Storefront ist mehrsprachig. Seiten, Blogbeiträge, Menübezeichnungen und Abschnittsinhalte werden alle pro Sprache bearbeitet, und der Storefront liefert sprachpräfixierte URLs mit den passenden SEO-Tags aus. Siehe [Mehrsprachige Inhalte](/de/docs/languages/multilingual-content/). ## Bevor du live gehst [Section titled “Bevor du live gehst”](#bevor-du-live-gehst) Neue Storefronts starten als **Entwurf** und zeigen eine Wartungsseite an, bis du sie unter **Einstellungen → Kunden-Oberfläche → Storefront veröffentlichen** freigibst. Reynt blockiert den Schalter, bis die wichtigsten Angaben vorhanden sind: * **Impressum** — gesetzlich vorgeschrieben; die Website bleibt offline, bis es hinterlegt ist. * **Datenschutzerklärung** — gesetzlich vorgeschrieben; die Website bleibt offline, bis sie hinterlegt ist. * **Eine Benachrichtigungs-E-Mail** — sonst werden neue Buchungen und Anfragen nicht per E-Mail an dich gesendet. * **Eine Zahlungsmethode** — sonst werden Buchungen ohne Zahlungsverpflichtung veröffentlicht. Lege das Impressum und die Datenschutzseite unter **Einstellungen → Kunden-Oberfläche → Rechtliche Seiten** fest, direkt über dem Veröffentlichen-Schalter (siehe [Domains und SEO](/de/docs/storefront/domains-and-seo/)), und sieh dir [Veröffentlichung und Sichtbarkeit](/de/docs/listings/publishing-and-visibility/) an, um Objekte live zu schalten. ## Buchungsformular [Section titled “Buchungsformular”](#buchungsformular) Unter **Kunden-Oberfläche → Website → Buchungsformular** legst du fest, was das Formular von Gästen abfragt. * **Telefonnummer verlangen** — standardmäßig aktiv. Deaktiviere es, wenn du deine Gäste nie anrufst: Das Feld bleibt im Formular, als optional markiert – ein Pflichtfeld weniger bedeutet weniger abgebrochene Buchungen. Lass es aktiv, wenn du die Nummer für Schlüsselübergabe oder späte Anreisen brauchst. Die Einstellung gilt auch für deine eigene Website – Buchungen laufen dort über dieselbe API, die dieselbe Regel durchsetzt. ## Kleiner-Katalog-Modus [Section titled “Kleiner-Katalog-Modus”](#kleiner-katalog-modus) Wenn du nur eine Handvoll Objekte betreibst (etwa ein bis fünf), stelle das **Katalog-Layout** unter **Kunden-Oberfläche → Website → Objekte** auf das einfache Layout um. Der Storefront blendet dann Suchfilter, Karte, Sortierung und Paginierung aus und zeigt deine Objekte als übersichtliches, zentriertes Karten-Raster mit nur Datums- und Gästefiltern. Die Startseite zeigt statt des vollständigen Such-Heros eine Präsentation hervorgehobener Objekte. # Suche und Karten > Wie Gäste deine Objekte suchen und wie sich die Storefront-Karte verhält. Die Suche ist der Weg, auf dem die meisten Gäste ein Objekt finden. Der Storefront kombiniert ein Filterpanel mit einer interaktiven Karte, beide gesteuert durch die Einstellungen der Ansicht **Objekte** unter **Kunden-Oberfläche → Website** (siehe [Einstellungen integrierter Ansichten](/de/docs/storefront/built-in-view-settings/)) und durch **Kunden-Oberfläche → Erscheinungsbild**. ## Das Filterpanel [Section titled “Das Filterpanel”](#das-filterpanel) Gäste öffnen eine **Filter**-Schublade (sie zeigt ein Badge mit der Anzahl aktiver Filter), gegliedert in drei Bereiche: **Reisedetails** * **Suche** — Freitextsuche über deine Objekte. * **Reisezeitraum** — An- und Abreisedatum, mit einer Option „Flexible An-/Abreise“, um den Zeitraum zu erweitern. * **Gäste** — separate Zähler für **Erwachsene** (mindestens einer), **Kinder**, **Kleinkinder** und **Haustiere**. Kinder und Kleinkinder haben keine Alterseingabe pro Kind; stattdessen zeigen die Beschriftungen die von dir konfigurierten Altersgrenzen (ein Höchstalter für Kinder und Kleinkinder). Kleinkinder erscheinen nur, wenn du ein Kleinkind-Höchstalter konfiguriert hast. Haustiere erscheinen, wenn ein Objekt sie erlaubt. * **Preis** — ein Regler mit zwei Griffen. Siehe die Preisobergrenze unten. **Standort** * **Reiseziel-Auswahl** — wähle aus deinen Reisezielen, dargestellt als Hierarchie. Tippst du etwas ein, das kein Reiseziel ist, läuft stattdessen eine Freitext-Standortsuche. * **Entfernungsfilter** — ein Dropdown pro von dir definierter Entfernungskategorie (z. B. nächster Strand). Siehe unten. **Unterkunftsmerkmale** * **Ausstattung** — ein Schalter pro Ausstattungsmerkmal deiner Objekte. * **Tags** — aktive Tag-Filter erscheinen als entfernbare Chips. Der Fuß der Schublade hat **Alle löschen** und einen Button „N Ergebnisse anzeigen“. Über den Ergebnissen bietet eine **Sortierung**-Steuerung Empfehlungen (die “Empfohlen”-Sortierung), Preis aufsteigend/absteigend, Anzahl der Gäste aufsteigend/absteigend, sowie eine „Nähe zu …“-Option pro Entfernungskategorie. ## Die Karte [Section titled “Die Karte”](#die-karte) Ergebnisse erscheinen neben der Liste auf einer interaktiven Karte (standardmäßig MapTiler-Kacheln) — eine fixierte Spalte auf Desktop, ein Slide-over auf Mobilgeräten. * **Preis-Badges** — jedes Objekt erscheint als weißes Preis-Badge mit seinem Preis pro Nacht; Objekte ohne Preis erscheinen als Punkt. Das Hovern über eine Ergebniskarte hebt ihr Badge auf der Karte hervor und umgekehrt. * **Clustering** — nahe beieinanderliegende Pins gruppieren sich zu einem kompakten Zähl-Badge, das sich beim Hineinzoomen des Gasts erweitert. (Clustering kann pro Mandant deaktiviert werden.) * **Ein Badge anklicken**, um eine kleine Objektkarte zu öffnen, die am Pin verankert ist. * **Vollständige Ergebnismenge** — die Karte zeigt jedes passende Objekt, nicht nur die aktuelle Seite der Karten. * **Suche beim Bewegen** — das Verschieben oder Zoomen der Karte filtert die Ergebnisse automatisch auf den sichtbaren Bereich; ein aktiver Kartenbereichs-Filter erscheint als abweisbarer Chip im Panel. Die Suche nach einem Reiseziel rahmt stattdessen das gesamte Gebiet. * **Objekte ohne Koordinaten** — beim ersten Laden, während die Karte die Ergebnisse einfach rahmt, erscheinen Objekte ohne Koordinaten weiterhin in der Liste (sie haben nur keinen Pin). Sobald ein Gast die Karte verschiebt oder zoomt, wird der Kartenbereich zu einem echten Filter, und Objekte ohne Koordinaten fallen heraus — ein weiterer Grund, Koordinaten stets zu pflegen (siehe den Hinweis zur Vollständigkeit in [Objektübersicht](/de/docs/listings/overview/)). Karten erscheinen nur, wenn ein Kartenanbieter-Schlüssel konfiguriert ist. Auf einer eigenen Domain musst du deinen eigenen Schlüssel angeben — siehe [Domains und SEO](/de/docs/storefront/domains-and-seo/). ### Reiseziele auf der Karte durchsuchen [Section titled “Reiseziele auf der Karte durchsuchen”](#reiseziele-auf-der-karte-durchsuchen) Wenn du die Karten-Reiseziel-Auswahl aktiviert hast und deine Reiseziele über Kartenkoordinaten verfügen, können Gäste eine Kartenansicht öffnen, die jedes Reiseziel als beschriftetes Badge zeigt, und durch Klicken eines auswählen — eine visuelle Alternative zum Reiseziel-Dropdown. ## Einstellungen, die die Suche prägen [Section titled “Einstellungen, die die Suche prägen”](#einstellungen-die-die-suche-prägen) ### Preisschieber-Obergrenze [Section titled “Preisschieber-Obergrenze”](#preisschieber-obergrenze) Lege das **Preis-Slider Maximum** unter **Kunden-Oberfläche → Website → Objekte → Suchfilter** fest. Der Regler läuft von 0 bis zu diesem Wert (mit einem `+` am oberen Ende); belasse ihn bei 0, um den Standardwert von 500 € zu verwenden. Eine Auswahl über den gesamten Bereich wendet keinen Preisfilter an. ### Entfernungsfilter [Section titled “Entfernungsfilter”](#entfernungsfilter) Lege unter **Kunden-Oberfläche → Website → Objekte → Suchfilter** die Entfernungsschwellen (in Metern) fest, die in den Entfernungs-Dropdowns angeboten werden. Dieselbe Liste gilt für jede Entfernungskategorie. Lass sie leer, um die Standardwerte zu verwenden (500 m, 1 km, 2 km, 5 km, 10 km); bis zu 20 Werte, beim Speichern dedupliziert und sortiert. Welche Entfernungskategorien existieren, ergibt sich aus deiner Reiseziel- und Entfernungskonfiguration — siehe [Reiseziele und Entfernungen](/de/docs/catalog/places-and-distances/). ### Suchranking (Empfohlen-Sortierung) [Section titled “Suchranking (Empfohlen-Sortierung)”](#suchranking-empfohlen-sortierung) Stimme unter **Kunden-Oberfläche → Website → Objekte → Suchranking** den Qualitäts-Score hinter der Standard-„Empfohlen“-Reihenfolge ab: * **Gewichte** für Profil-**Vollständigkeit**, **Aktualität** kürzlicher Buchungen und Gesamt-**Beliebtheit** (jeweils 0–1, relativ zueinander). * **Aktualitätshorizont** — wie viele Tage als “kürzlich” zählen. * **Popularitätslimit** — die Buchungsanzahl, ab der zusätzliches Volumen ein Objekt nicht mehr weiter nach oben schiebt, damit ein einzelnes beliebtes Objekt nicht dominieren kann. * **Tag-Boosts** — vergeben (oder ziehen ab) Punkte für bestimmte Tags. Hervorgehobene Objekte stehen immer zuerst; Tag-Boosts und der Qualitäts-Score kommen darüber hinaus zum Tragen. ### Paginierung [Section titled “Paginierung”](#paginierung) Wähle unter **Kunden-Oberfläche → Website → Objekte → Paginierung der Suchergebnisse** zwischen nummerierten Seiten mit Gesamtanzahl oder einem einfachen Zurück/Weiter, und lege fest, wie viele Objekte pro Seite angezeigt werden (dies steuert das Raster, die Kartenmarkierungen und die Paginierung gemeinsam). ### Kleiner-Katalog-Modus [Section titled “Kleiner-Katalog-Modus”](#kleiner-katalog-modus) Wenn du nur wenige Objekte betreibst, blendet das einfache **Katalog-Layout** (unter **Kunden-Oberfläche → Website → Objekte**) Suchfilter, Karte, Sortierung und Paginierung vollständig aus, zugunsten eines einfachen Datums- und Gästefilters. Siehe [Storefront-Übersicht](/de/docs/storefront/overview/). # Reynt operator documentation > How to manage listings, bookings, pricing, availability, invoices and your storefront in the Reynt admin console. Welcome to the Reynt operator docs. These pages explain how property managers and marketplace operators use the Reynt admin console day-to-day — from your first listing to a fully running storefront. ## What is Reynt? [Section titled “What is Reynt?”](#what-is-reynt) Reynt is a rental and booking platform. You manage everything from one admin console: your properties, the reservations against them, pricing and availability, payments and invoices, guest communication, and a white-label customer storefront. Guests never see the console — they see your storefront. ## New here? [Section titled “New here?”](#new-here) Start with [Welcome](/docs/getting-started/welcome/) for a quick orientation, then follow [First steps](/docs/getting-started/first-steps/) to take a fresh tenant live. The [Console tour](/docs/getting-started/console-tour/) explains the dashboard, navigation, and shortcuts. Not ready to set anything up yet? [Demo mode](/docs/getting-started/demo-mode/) takes a booking end to end on example content first. ## Find your way around [Section titled “Find your way around”](#find-your-way-around) Use the sidebar to jump to a topic: * **Listings** — create properties, add content and photos, amenities, add-ons, publishing, and [rental registration](/docs/listings/registration/). See [Listings overview](/docs/listings/overview/). * **Catalog** — shared building blocks: [amenities, attributes, tags](/docs/catalog/overview/), [places & distances](/docs/catalog/places-and-distances/), and [property types](/docs/catalog/property-types/). * **Pricing** — base and seasonal rates, stay rules, discounts, fees, and [promo codes](/docs/pricing/promo-codes/). * **Availability** — [block dates](/docs/availability/block-dates/), [iCal sync](/docs/availability/ical-sync/), and calendar views. * **Bookings** — the [booking lifecycle](/docs/bookings/lifecycle/), requests and offers, modifications, cancellations, and guest registration. * **Payments & invoices** — [payment providers](/docs/payments/providers/), partial payments, invoice creation, and taxes. * **Customers & owners** — the people on either side of a booking. * **Communication** — the [inbox](/docs/communication/inbox/), notifications, and the email confirmation gate. * **Storefront** — custom pages, blog, navigation, theming, domains, and search. * **Languages & AI** — multilingual content and AI-assisted generation. * **Configuration** — [tenant settings](/docs/configuration/tenant-settings/), [members & roles](/docs/configuration/members-and-roles/), and [API keys](/docs/configuration/api-keys/). ## Conventions in these docs [Section titled “Conventions in these docs”](#conventions-in-these-docs) * **Console** means the admin web app you log into. * **Storefront** means the customer-facing booking website your guests see. * Console paths are tenant-scoped: the **Owners** page lives at `//owners` in the console. We refer to pages by their sidebar label, in **bold**. # The AI assistant > Ask Reynt — a docked assistant that answers questions from your live data and proposes changes you confirm. **Ask Reynt** is the console’s built-in assistant. Open it with the **Ask Reynt…** button in the top bar or **Cmd/Ctrl + J** — it docks as a panel on the right, so you can keep working while you talk to it. It reads your tenant’s live data to answer questions, and it can prepare changes for you — but it **never changes anything on its own**: every change is shown as a proposal card that you review and confirm first. ## The panel [Section titled “The panel”](#the-panel) The panel is the chat, and only the chat. Two related things sit next to it: * **AI activity** — the icon beside the notification bell in the top bar opens a tray of running and recently finished AI workflows (imports, content generation, translations). Watch progress and open results for review there instead of waiting on the page that started them; a badge shows how many runs are in flight or awaiting review. Because it’s a separate tray, you can keep an eye on a run while you carry on chatting. * **Help** — written guidance for the page you’re on, opened by the **Help** button in that page’s header. It slides over the chat inside the same panel, so it stays beside the content it describes; **Back to chat** returns you. The **Ask AI** entry at the top of the command palette (**Cmd/Ctrl + K**) hands your typed question straight to the chat. ## Chat, and what it’s talking about [Section titled “Chat, and what it’s talking about”](#chat-and-what-its-talking-about) There is **one conversation**, and it always knows what you’re looking at. When you’re on a record — a booking, a request, a listing, an invoice, a guest, an owner, an inbox thread, or a storefront page — a small **chip** appears above the message box naming that record. Anything you send while the chip is there can say “this booking” and skip the reference. The chip is a hint, not a wall: * **Remove it** with its `×` if your question isn’t about that record. Nothing else changes — the assistant can do exactly as much either way. * **Leave it and ask something else anyway.** A tenant-wide question (“how was revenue last month?”) asked from a booking page is still answered as a tenant-wide question. * **Add more** with **+ Add context** to put several records in front of the assistant at once — for example a booking and the listing you’re thinking of moving it to. Sent messages keep the chips they were sent with, so the transcript shows exactly which questions carried context and which didn’t. The **Ask about this booking / listing / page** action in a record’s header just opens the chat — the chip is already there. Conversation history is one list. If a chip is attached, the history menu offers to show only the conversations that were about that record. ## What it can answer [Section titled “What it can answer”](#what-it-can-answer) The chat reads from your real data, so answers cite actual records rather than generic advice. It can look up and summarise: * bookings, requests and offers, and their activity * listings, prices, and availability — including “is this place free 3–7 August?”, answered with the booked and blocked stretches and the free gaps between them * what a specific property actually has — its amenities, tags, attributes and distances, its extras and discounts, its seasonal stay rules, and whether its imported calendar feeds are still syncing * why a listing is not publishable yet, item by item, with the tab that fixes each * customers and owners * invoices and payments, and the tax rules behind their lines — city/tourist tax and VAT rates * cancellation policies, and what cancelling a specific booking would refund * inbox conversations * promo codes and storefront pages * **reports** for a period you name — the revenue summary, revenue over time, the per-listing and per-booking breakdowns, and the commission review. These come from the same source as the console’s Reports page, so the numbers it quotes match what you see there * dashboard figures (all-time) and **occupancy reports** for a period you name * listings via **smart search** (“a sea-view place that allows dogs”) Owner banking and tax details are never shared with the AI — those fields stay masked. ## What it can do (with your confirmation) [Section titled “What it can do (with your confirmation)”](#what-it-can-do-with-your-confirmation) When you ask for a change, the assistant prepares it and shows a **proposal card** describing exactly what will happen. Nothing runs until you confirm, and confirmed actions land in the same audit trails as manual ones. It can propose, among other things: * **Bookings** — confirm, cancel, or close out a booking. A cancellation card names the policy behind the refund and shows both the policy entitlement and what the guest actually gets back * **Requests & offers** — create a request, prepare and send an offer, publish or decline a request, or draft a whole [multi-option offer with AI](/docs/bookings/booking-drafts-and-offers/#draft-an-offer-with-ai) from the request’s captured wishes * **Availability** — block or unblock dates * **Listings** — update listing details, manage prices, assign an owner, or generate listing content with AI * **Invoices & payments** — issue an invoice, mark it paid, cancel it, create a credit note, or mark a payment transfer as paid * **Inbox** — draft a reply, assign a conversation, or change its status * **People** — create or update customers and owners * **Promotions** — create or disable a promo code * **Storefront** — generate a new page section or edit an existing one ## Cost [Section titled “Cost”](#cost) On the platform key, the assistant has its own generous daily token allowance, separate from the AI-workflow limits described in [AI overview](/docs/ai/overview/). Repeated context is cached and weighted cheaply, so normal day-to-day use stays well inside it. With your own API key connected there is no platform limit — usage is billed to your provider account directly. # Content generation and translation > Write and translate listing and website content with AI, reviewing every suggestion before it saves. Once AI is connected (see [AI overview](/docs/ai/overview/)), content generation shows up right where you write — on the fields themselves and in a few guided dialogs. Everything AI produces is shown to you for review before it’s saved. You can also launch listing field generation and storefront page-section generation (or edits) by simply asking the [AI assistant](/docs/ai/assistant/). ## Generate a single field [Section titled “Generate a single field”](#generate-a-single-field) Translatable fields — a listing title, description, SEO text, and so on — carry a small **AI** button. Depending on your languages it offers: * **Generate content** — write this field with AI in every language at once. * **Translate missing languages** — translate the text you’ve already written into the languages still empty. After generating, a preview shows the result per language. **Accept** to write the values into the field, or **Dismiss** to discard them — nothing is saved until you accept. ### Writing tone and length [Section titled “Writing tone and length”](#writing-tone-and-length) The same **AI** menu carries the writing-style dials for the next run: * **Tone** — Warm, Professional or Playful. It starts on the voice you set under **Settings → AI**; picking here changes this one generation, not the setting. * **Length** — Short, Standard or Detailed, on the free-form texts only (description, amenities, guest info, price and discount texts). Both dials appear only on the fields they actually change. A **title**, an **SEO title** or a blog **meta title** shows neither: those are short, keyword-led labels with a hard character budget — a listing title has roughly one line on the card, an SEO title 50-60 characters in Google — so their own rules decide the wording, and a voice preset would only push filler adjectives into a line that has no room for them. Excerpts and meta descriptions are full sentences, so they do take a tone; their character budget still holds. ### Quick-translate on language fields [Section titled “Quick-translate on language fields”](#quick-translate-on-language-fields) On a field with per-language tabs, the **Translate missing languages** action takes a language you’ve already filled in as the source and translates it into the empty tabs, preserving formatting in rich-text fields. It’s the fastest way to fan one language out to the rest. ## Generate several fields at once [Section titled “Generate several fields at once”](#generate-several-fields-at-once) For a larger pass, the listing field-generation dialog lets you pick which fields to generate and how: * **Generate content in** — choose the languages. Your default language is always generated; the others are produced from it. * **Mode**: * **Translate from default** — generate once in the default language, then translate. Cheaper. * **Native per language** — generate each language independently for the best tone, at higher cost. The run shows progress, and the result opens with a **tab per language** so you can review — and edit — each language before applying. Selected fields are applied in every generated language, so check each tab first. ## Whole-page and account-wide generation [Section titled “Whole-page and account-wide generation”](#whole-page-and-account-wide-generation) The same review-before-save pattern applies to the bigger workflows: * **Pages and blog posts** — generate a full set of content sections, then review before applying. * **Catalog, canned responses, referrer options** — generate a tailored starting set you can edit. * **Every missing translation** — the [Translations page](/docs/languages/translations-page/) fills all outstanding translations in one pass, with a review modal where you deselect anything you don’t want. ## Import a whole listing [Section titled “Import a whole listing”](#import-a-whole-listing) To create a listing from an existing source rather than field by field, use AI import — paste a URL, text, or PDF, or upload photos, and AI drafts the entire listing (in all your languages) for you to review and publish. See [Create a listing](/docs/listings/create-a-listing/). # AI replies to guests > Let AI draft — or send — replies to incoming guest messages, with a review window and an autopilot that only answers simple questions. Reynt can answer incoming guest messages in your [Inbox](/docs/communication/inbox/) for you. You choose how far it’s allowed to go: prepare a draft you review, send after a waiting period, or answer simple factual questions immediately. This is **off by default**. Nothing is drafted or sent until you switch it on. ## Choose how much autonomy to give it [Section titled “Choose how much autonomy to give it”](#choose-how-much-autonomy-to-give-it) Go to **Settings → AI** and pick a mode under **AI replies to guests**. | Mode | What happens when a guest writes in | | ---------------------------------- | ------------------------------------------------------------------------------------------------- | | **Off** | Nothing. The AI doesn’t touch incoming messages. | | **Draft for review** | A ready reply waits in the conversation. Nothing is sent without you. | | **Send after a review window** | A reply is prepared and sends itself once the waiting period passes — unless you step in first. | | **Autopilot for simple questions** | Simple factual questions are answered immediately; everything else falls back to a draft for you. | Start with **Draft for review** for a week or two and read what it produces. It’s the honest way to find out whether the answers are good enough for your properties before letting anything send itself. ### The review window [Section titled “The review window”](#the-review-window) In **Send after a review window** mode you set how long the reply waits (1–120 minutes, 10 by default). During that time the conversation shows a countdown, and the reply is cancelled if you: * **Edit in composer** — takes the text into the reply box as your own, * **Dismiss** it, * or simply **reply yourself**. Adding an internal note also cancels the pending send, but leaves the draft available — a note means you’re looking at it, not that the guest has been answered. If you’d rather not wait, **Send now** sends it immediately. ### What autopilot will and won’t answer [Section titled “What autopilot will and won’t answer”](#what-autopilot-will-and-wont-answer) Autopilot only sends by itself when the guest’s message is a straightforward factual question it can verify: * **Availability** — whether dates are free, minimum stays, what a stay costs at your listed prices * **Amenities** — parking, wifi, pets, kitchen, beds, what’s included * **Check-in** — check-in and check-out times, key handover * **Directions** — how to find the property, distances, what’s nearby Everything else is turned into a draft for you instead, including anything about **money** (refunds, discounts, payment problems), **changing a booking** (cancellations, date or guest changes, early or late checkout), **complaints, damage, or legal matters**, and any message it isn’t sure about. A message that mixes a simple question with one of those also goes to you. When it declines, the conversation shows the draft marked **Needs your decision** — you still get the head start, you just make the call. ## What the guest sees [Section titled “What the guest sees”](#what-the-guest-sees) A reply the AI sent by itself carries a short line telling the guest it was generated automatically and that they can just reply to the email. This is deliberate and can’t be switched off: if you’d rather send without that note, use **Edit in composer** and send the message as yourself. In the conversation, anything the AI sent is labelled **AI** so you can always tell your team’s replies from automated ones. ## Where the answers come from [Section titled “Where the answers come from”](#where-the-answers-come-from) The AI reads the conversation and looks up your real data before writing — the booking or inquiry the thread is about, the property, its prices and availability, amenities, and distances. It’s told never to state something it couldn’t verify, and to leave a placeholder for you instead of guessing. It never quotes internal notes to the guest, and it treats anything written in the conversation as information rather than instructions, so a guest can’t talk it into ignoring its rules. ## Requirements and limits [Section titled “Requirements and limits”](#requirements-and-limits) * **AI must be connected.** See [AI overview](/docs/ai/overview/). * **Automatic sending needs inbound replies.** Turn on **Inbound email replies** under **Settings → Email delivery** so a guest’s answer comes back into the conversation — see [Inbound replies](/docs/communication/inbox/#inbound-replies). Without it, the AI only prepares drafts, and the settings page warns you when this applies. * **Daily limit.** A cap on how many AI replies are generated per day (100 by default) protects you from a flood of messages. It’s separate from, and on top of, your [AI token budget](/docs/ai/overview/#cost-and-quotas). * **Email conversations only** — messages that arrive by email or through your website’s contact form. * **Spam is ignored**, and if a newer message arrives before a reply is sent, the outdated one is dropped rather than sent late. ## Costs [Section titled “Costs”](#costs) Guest replies draw on the same daily AI budget as the rest of the console, so heavy inbox traffic and heavy content generation compete for the same allowance. Watch it on the [AI Usage page](/docs/ai/overview/#monitor-usage), and use the daily reply limit as the safety brake. # AI overview > What Reynt AI can do, how to connect it, and how to monitor usage and cost. Reynt has AI woven throughout the console to speed up the repetitive parts of running your business — writing listing content, translating it, importing properties, and drafting website and support text. This page explains what AI can do, how to switch it on, and how to keep an eye on cost. ## What AI can do [Section titled “What AI can do”](#what-ai-can-do) * **Import a listing** — paste a URL, text, or PDF, or upload photos, and AI extracts the details, writes the content in all your languages, and matches amenities. See [Create a listing](/docs/listings/create-a-listing/). * **Generate and translate listing content** — write or translate individual fields (title, description, SEO, and more) across your languages. See [Content generation and translation](/docs/ai/content-generation-and-translation/). * **Label listing images** — vision analysis produces descriptive labels for photos. * **Generate website content** — draft content sections for CMS pages and blog posts. * **Bootstrap your catalog** — generate tags and cancellation policies tailored to your business. * **Suggest icons** — when picking an icon for a catalog item (amenity, attribute, and the like), **Suggest with AI** proposes matching icons based on the item’s name. * **Draft support and checkout text** — reusable canned responses for the inbox, and “How did you hear about us?” referrer options. * **Reply to guests** — draft, or automatically send, replies to incoming guest messages in the inbox. Off by default. See [AI replies to guests](/docs/ai/guest-replies/). * **Fill in place coordinates** — find latitude/longitude for places that are missing them. * **Translate everything** — the [Translations page](/docs/languages/translations-page/) can fill every missing translation with AI. * **Smart search** — describe what a guest wants in plain language and let AI find matching listings. * **Draft a request’s offer** — from a request’s captured customer wishes, find matching listings, check availability and pricing, and create a draft multi-option offer with a suggested customer message. See [Draft an offer with AI](/docs/bookings/booking-drafts-and-offers/#draft-an-offer-with-ai). There’s also **Ask Reynt**, the in-console assistant — a full chat agent that can read your tenant’s data (bookings, listings, prices, customers, invoices, reports, and more), answer questions about the console, and propose changes for you to confirm. See [The AI assistant](/docs/ai/assistant/). ## Connect AI [Section titled “Connect AI”](#connect-ai) AI features are configured under **Settings → AI**. A help panel on the page walks you through the same steps. * **Provider** — choose which vendor serves your account: **Anthropic** (USA) or **Mistral** (EU). This choice works **with or without a key of your own** — where the platform holds its own key for the vendor you pick, your requests run on that access and our data-processing agreement covers them. The page shows which providers are available that way, and where your requests are actually being processed right now. * **API key (optional)** — connect your own key to be billed directly by the provider instead. It also moves the data-protection duties to you — see [Data protection](#data-protection) below. If you pick a provider the platform holds no key for and add no key of your own, AI stays switched off for that provider: we will not quietly route your data to a different vendor instead. * **Model** — leave it on the default (**Claude Sonnet 5** for Anthropic) for a good balance of quality and speed, or pick another model — Anthropic offers Opus 4.8, Opus 4.7, Sonnet 5, Sonnet 4.6, and Haiku 4.5 (faster, cheaper short texts); Mistral offers Mistral Medium, Large, Small, and Magistral Medium. You can also enter a custom model ID. * **Custom instructions** — optional guidance applied to generated content (tone, style, house rules). You can even generate a starting set from your own listings and configuration. * **Smart search** — a separate embedding provider (**OpenAI**, USA, or **Mistral**, EU), optional key, and model power the smart-search index. The same rule applies: the provider is selectable on the platform’s access, and a key of your own is optional. Switching the embedding provider or model re-indexes all your listings. Once AI is available — on the platform’s access or your own key — the AI buttons light up across the console, most visibly on listing detail pages. ## Cost and quotas [Section titled “Cost and quotas”](#cost-and-quotas) The key you use determines how spend is controlled: * **Your own key (BYOK)** — you pay your provider directly and there are no platform limits. It also changes who carries the data-protection duties — see [Data protection](#data-protection) below. * **Platform key** — when no key is connected, AI runs on the platform’s key subject to per-account limits (a cap on how many workflows run at once, per day, and per month). The [AI assistant](/docs/ai/assistant/) has its own daily token allowance on the platform key (generous enough for normal use); connecting your own key lifts it entirely. Each AI run records which key was used, so you can always see where cost landed. ## Data protection [Section titled “Data protection”](#data-protection) AI features send data to a language-model provider. You are the controller for your guests’ and owners’ data, so this is worth understanding before you turn them on. **What leaves the platform.** Only what a given request needs, and only at the moment you trigger it. Depending on the feature that can include guest and owner master data (name, address), contact details (email, phone), booking data including special requests, and — only if you switch on AI replies to inbound guest messages — the text of those messages. **Registration-form (Meldeschein) data is never sent to a model.** Nothing is sent in the background: no call happens unless you or a feature you enabled makes one. **Who processes it.** Whichever provider you selected under **Settings → AI**. Both are listed as approved subprocessors in [Anhang 3 of the AVV](https://www.reynt.co/de/legal/avv): * **Anthropic (USA)** — the default. Each request is a transfer to a third country, on EU standard contractual clauses as the transfer basis. * **Mistral (France, EU)** — selectable on the platform’s access, no key of your own required. Because the vendor is established in the EU, your request is not a third-country transfer by us. Read the limit of that below. Your content is not used to train models (AGB § 6(3)). The settings page shows which of the two is serving you, so you never have to infer it. **Tell your guests.** Your own privacy notice has to mention that AI features process their data — and, if you are on the US provider, that this involves a transfer outside the EU. That duty is yours as controller, not ours (AVV § 5(3)). **If you bring your own key**, the provider you choose is *your* processor, not ours. Our contracts and transfer safeguards do not cover that key. You then need your own Art. 28 agreement with that provider, your own transfer basis if they are outside the EU, and your own notice to data subjects (AVV § 6(6)). BYOK does not automatically make things safer — it moves these duties from us to you. **What choosing the EU provider does and does not settle.** It removes the third-country transfer *from us to the provider*: Mistral is established in France, so that leg stays inside the EU, and it stays under our agreement with them rather than being pushed onto you. It does **not** amount to a promise of EU-only processing end to end. “EU company” and “EU-only processing” are not the same thing — a provider’s own sub-processors and hosting regions are documented per feature and change over time. Our contract therefore points at Mistral’s own transfer regime for those onward steps instead of promising residency we have not verified. If you need a hard residency guarantee rather than an EU-established processor, ask us before you rely on it. **One exception that no provider choice changes:** searching the built-in help knowledge base. That index describes Reynt itself and is built centrally for all accounts, so it always uses the platform’s own embedding provider — your search text goes there regardless of the provider you picked. Anhang 3 lists this separately for that reason. **Reducing what goes out.** **Settings → AI** has a **pseudonymization** option that replaces names, emails, phone numbers and street addresses with placeholders before anything reaches the model, and resolves them again before you see the answer. It is off by default: it costs the assistant some ability to match similar names and to inflect German salutations. It is a protective measure, not anonymization — the data still counts as personal data, and the provider remains a subprocessor. It is most worth enabling on a BYOK key, since that is the path our own safeguards do not reach — and worth considering on the US provider, where each call is a third-country transfer. ## Monitor usage [Section titled “Monitor usage”](#monitor-usage) The **Settings → AI Usage** page gives you visibility into consumption: * **Usage tab** — cards for workflows today, this month, and running now; totals for a chosen period (last 7 days, last 30 days, or this month) covering workflow count, tokens, and **estimated cost**; and a breakdown table by workflow type showing the key source, token counts, and cost. * **Workflows tab** — a history of every AI run with its type, status, related entity, and duration. Open any row to inspect the run’s steps in detail. # Block dates > Manually mark a listing as unavailable for a date range so guests cannot book it. Blocking dates takes a listing off the market for a period without a booking behind it — use it for maintenance, owner stays, renovations, or any dates you simply don’t want bookable. Blocked dates disappear from storefront search and show as unavailable in the calendar. ## Where blocks live [Section titled “Where blocks live”](#where-blocks-live) Open a listing and go to its **Unavailability** tab (**Listings → \[listing] → Unavailability**). This is a plain list of blocked periods — each row shows the start date, end date, number of days, and an optional reason. It is not a drag-on-a-calendar tool; you add each period through a small form. ## Add a block [Section titled “Add a block”](#add-a-block) 1. On the **Unavailability** tab, click **Create**. 2. Pick the **Period** — a start and end date. Each field opens a calendar you can click through. 3. Optionally type a **Reason** (e.g. “Maintenance”, “Owner stay”). This is free text, not a fixed list, and it appears on hover in the calendar. 4. Click **Save**. The date pickers highlight dates that are already taken by an existing block or booking, so you can see overlaps before you commit. The blocked dates leave storefront search as soon as you save. ## Edit or remove a block [Section titled “Edit or remove a block”](#edit-or-remove-a-block) Click any row in the list to reopen it. Change the dates or reason and **Save**, or click **Delete** to remove the block and make those dates bookable again. ## How blocks relate to bookings [Section titled “How blocks relate to bookings”](#how-blocks-relate-to-bookings) Manual blocks and confirmed bookings both make a date unavailable, but they are tracked separately and shown as distinct colours in the [calendar](/docs/availability/calendar-views/) — a manual block is **Blocked** (red), a booking is **Booked** (blue). That lets you tell operational downtime apart from real revenue at a glance. Blocks imported from an external platform are a third, separate layer; see [iCal sync](/docs/availability/ical-sync/). ## Do pending bookings block dates too? [Section titled “Do pending bookings block dates too?”](#do-pending-bookings-block-dates-too) Confirmed bookings always block dates everywhere. Pending bookings (a checkout that hasn’t been paid or confirmed yet) are handled by a setting under **Settings → Booking settings**: **Pending Bookings Block Storefront**. * **On (hard):** pending bookings block the storefront — search hides the listing for those dates, the public calendar shows them unavailable, and new checkouts on overlapping dates are rejected. * **Off (soft):** the storefront ignores pending bookings and keeps taking new bookings on those dates. Either way, the operator console always treats pending bookings as blocked, so your calendar and availability views show them regardless of this setting. # Calendar views > Read availability across all listings or for a single listing, with a colour legend for every status. Reynt has two calendars for reading availability: a global grid covering every listing at once, and a per-listing month view. Both are read-only — you make changes on the [Unavailability](/docs/availability/block-dates/) tab, in [bookings](/docs/bookings/lifecycle/), or through [iCal sync](/docs/availability/ical-sync/) — and both share the same colour legend. ## The global calendar [Section titled “The global calendar”](#the-global-calendar) Open **Calendar** from the main navigation. It shows one row per listing and one column per day of the selected month, so you can scan your whole portfolio side by side. Use the arrows to move between months. * **Filter by title** narrows the rows by listing title or key. You can type several comma-separated terms. * **Filter by tags** limits the grid to listings carrying the tags you pick. Hover a cell for a moment, or click it to pin, and a panel shows that day’s status, any block reason, and the price. From there you can jump straight to **Open booking #…** (when a booking occupies the day) or **Open listing calendar**. ## The per-listing calendar [Section titled “The per-listing calendar”](#the-per-listing-calendar) Each listing has its own **Calendar** tab (**Listings → \[listing] → Calendar**) laid out as a familiar month grid. Every day shows its date and, when a price applies, the nightly price beneath it. Use the arrows to change month. ## What the colours mean [Section titled “What the colours mean”](#what-the-colours-mean) Both calendars use the same legend: * **Available** (green) — bookable, with a price. * **Booked** (blue) — a confirmed booking. * **Pending** (pink) — a booking that isn’t confirmed yet. * **Blocked** (red) — a manual block from the Unavailability tab. * **External Calendar** (purple) — a block imported from another platform via iCal sync. * **No price** (amber) — no pricing rule covers the day, so it can’t be booked until you add one. Some cells are split diagonally into two colours. These are **transition days**: a departure morning after the last booked night, or an arrival afternoon at the start of a stay. The coloured half marks the part of the day the listing is occupied, so back-to-back stays read correctly instead of looking like a full blocked day. ## Prices in the calendar [Section titled “Prices in the calendar”](#prices-in-the-calendar) The per-listing calendar prints the nightly price on each day, and the global calendar shows it in the hover panel. A day marked **No price** has no rule to price it — set base or seasonal pricing on the listing’s [Prices](/docs/pricing/base-and-seasonal/) tab to make it bookable. # iCal sync > Sync availability with booking portals and other platforms using iCal feeds. If you list the same property on other platforms, iCal sync keeps their calendars and Reynt in step. Reynt can **publish** a listing’s availability as an iCal feed and **subscribe** to feeds from other platforms so their bookings block dates in Reynt. Both live on a listing’s **External Calendars** tab (**Listings → \[listing] → External Calendars**). ## Publish your calendar (outgoing) [Section titled “Publish your calendar (outgoing)”](#publish-your-calendar-outgoing) The **iCal Export** section gives each listing a private feed URL you paste into a booking portal, a channel manager, or any calendar that reads iCal. 1. Click **Generate Export URL**. Export is off until you do this. 2. Click **Copy URL** and paste it into the other platform’s “import calendar” field. The feed covers the next 365 days and includes confirmed bookings and every manual block. **Regenerate URL** issues a fresh link and breaks the old one (use it if a URL leaks); **Disable Export** turns the feed off entirely. ## Subscribe to external calendars (incoming) [Section titled “Subscribe to external calendars (incoming)”](#subscribe-to-external-calendars-incoming) The **External Calendars** section pulls availability *in* from other platforms. Add as many feeds as you like: 1. Click **Add Calendar**. 2. Paste the iCal URL the other platform gives you. 3. Click **Save**. Each feed appears in the list with its URL, type, last-sync time, and a status badge. Reynt refreshes every feed automatically **once an hour** — click **Sync All** to pull immediately. Imported bookings show up as blocked dates on the [calendar](/docs/availability/calendar-views/) in the **External Calendar** colour (purple), labelled with the event’s summary from the source. Reynt only learns that a date is taken — it never receives guest details from an external feed. ## When a feed fails [Section titled “When a feed fails”](#when-a-feed-fails) Feeds break — a URL changes, a platform has an outage. Reynt handles this for you: * A failing feed shows **Last sync failed** and is retried automatically with a growing delay (starting at \~15 minutes and backing off from there). * If a feed keeps failing, Reynt stops retrying and marks it **Paused** to avoid hammering a dead URL. A clearly broken URL is paused after a few attempts; intermittent failures are retried for much longer first. * Fix the URL (use **Edit URL**), then open the row’s menu and click **Retry now** — this re-syncs immediately and clears the failure state, resuming a paused feed. You can also **Pause** and **Resume** a healthy feed yourself, or **Delete** it. ## Spotting sync problems [Section titled “Spotting sync problems”](#spotting-sync-problems) You don’t have to open each listing to find broken feeds: * The **dashboard** shows an alert when calendars are failing or have been disabled, with a **Fix sync** / **View** link straight to the affected listing (or the filtered list). * The **Listings** page has a **Calendar sync error** filter that shows only listings with failing feeds. Dashboard links land you here pre-filtered. ## Manual blocks vs synced blocks [Section titled “Manual blocks vs synced blocks”](#manual-blocks-vs-synced-blocks) Blocks imported from an external feed are managed entirely by the sync — they refresh on every run, so you can’t edit or remove them in Reynt. To clear one, remove it at the source platform. Your own manual blocks on the [Unavailability](/docs/availability/block-dates/) tab are independent and removable any time. # Before the guest arrives > The two emails that go out in the days before check-in — arrival information, and the reminder to complete the registration form. Two emails can go out on their own in the days before a guest travels. Both are sent by a daily run in the morning, both are sent **once per booking**, and neither needs anyone to press a button. ## Arrival information [Section titled “Arrival information”](#arrival-information) Switch on **Settings → Booking settings → Send arrival information before check-in** and every confirmed guest is emailed their arrival details a few days before they travel: how to get there, who hands over the keys, and the check-in time. * **Days before arrival** decides how far ahead. The default is three. * The content comes from the **property**, not from the email — fill in the listing’s arrival instructions first, or the email has little to say. It is the same information the confirmation email carries, so the two cannot disagree about the door code. * It is **off unless you switch it on**. A guest who books *inside* the window still gets it, on the next daily run. Nothing goes out on arrival day itself — at that point the guest is already travelling and the email is too late to be useful. Because it is sent once per booking, moving the dates after it has gone out does not send it again. If arrival details change late, use the booking’s own send controls to tell the guest. ## Registration form reminder [Section titled “Registration form reminder”](#registration-form-reminder) Where [guest registration](/docs/bookings/guest-registration/) applies, a guest who has not completed the form gets one reminder the **day before** arrival, with the link to fill it in. * It is sent only for bookings the registration form **actually applies to**, and only when the record is still empty. A guest who has already filled it in — or whose form you completed yourself from the booking — hears nothing. * It has **no setting of its own**. Switching guest registration on is already an explicit decision; this is part of it. * The day-before timing is fixed. Earlier and the guest is not thinking about the trip yet; on the day itself they are on the road. ## Turning either off, and changing the wording [Section titled “Turning either off, and changing the wording”](#turning-either-off-and-changing-the-wording) Both are ordinary notifications: **Settings → Notifications** lists *Send arrival information* and *Registration form reminder* alongside every other guest email, where you can switch each off on its own, edit its wording per language, and send yourself a test. Switching the arrival email off in **Booking settings** stops it for everyone; switching it off in **Notifications** does the same thing from the other end. Use whichever you find first — the arrival details themselves stay where they are either way. # Requests and offers > Build a quote, send an offer to a guest, let them accept or decline online, negotiate, and publish the accepted request as a booking. A **booking request** is a work-in-progress reservation — a quote you build and negotiate with a guest before it becomes a real [booking](/docs/bookings/lifecycle/). 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 [Section titled “Creating a request”](#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](#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](/docs/communication/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](#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](#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 [Section titled “The request editor”](#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](#customer-wishes) below); shown whenever any wishes are captured, and always for [listing-less inquiries](#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 [Section titled “Customer wishes”](#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](#draft-an-offer-with-ai) below. ## Listing-less inquiries [Section titled “Listing-less inquiries”](#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](#offers)) — only the intake step is listing-less. ## Offers [Section titled “Offers”](#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](#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](#the-guest-offer-link) — 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](/docs/bookings/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 [Section titled “Draft an offer with AI”](#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](#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](#alternative-options-multi-option-offers) 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](/docs/ai/overview/#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](/docs/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) [Section titled “Alternative options (multi-option offers)”](#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 [Section titled “The guest offer link”](#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](/docs/communication/inbox/) 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 [Section titled “Request statuses”](#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](#the-guest-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 [Section titled “Publishing a request into a booking”](#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](#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](/docs/bookings/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 [Section titled “Activity and notifications”](#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. # Booking settings > Configure booking behaviour — booking flow, auto-confirm, close-out, availability blocking, timing, and the booking summary PDF. Booking behaviour is configured under **Settings → Booking settings** (the gear icon). This page controls how incoming bookings are handled, your default check-in/out times and booking window, and the booking summary PDF. Each card saves on its own. ## How your business runs [Section titled “How your business runs”](#how-your-business-runs) The first card on the page asks the whole question in one place: **how your business runs**. Three models, each shown as the journey a booking actually takes under it — the same wording you see in *What happens to a booking* below. * **Request & offer** — guests ask, you answer with an offer, and money is only collected once you confirm. The classic agency and holiday-let arrangement. * **Instant booking, you confirm** — your storefront takes bookings around the clock, but each one still waits for your decision. This is what a plain “instant” booking does when auto-confirm is off, so it is worth choosing on purpose rather than arriving at by accident. * **Instant booking, confirmed** — booked, confirmed and payable without you. Picking a model shows **what this changes** before anything is saved, one line per setting. Two of those changes are worth reading closely: * Anything marked **Payment settings** changes when guests may pay, which lives under [When you collect](/docs/payments/when-you-collect/). Choosing a model where you vet each booking sets payment to open only once you confirm — asking for money before you have decided is what produces avoidable refunds. * If you have never set a payment-collection rule, applying a model **creates one**, and that rule then governs every payment method rather than each one following its own timing. The card says so before you apply. A model is a starting point, not a lock. Every individual setting below stays editable afterwards; the card then shows which model you are on and how many settings you have since changed. Changing your booking flow after your terms and conditions page has been generated does **not** rewrite that page — the card warns you, and you regenerate or edit the passage yourself. ## Booking settings [Section titled “Booking settings”](#booking-settings) The main card controls how bookings move through their lifecycle. * **Booking flow** — **Request to Book** (the default): incoming bookings start as pending and wait for you to confirm or decline them. **Instant Booking** is the direct-confirm alternative. * **Auto-confirm bookings** — when on, bookings skip the pending state and are confirmed immediately when published. Leave it off to review every request by hand. * **Auto-Publish on Guest Acceptance** — when on, a guest accepting an offer on their [guest offer page](/docs/bookings/booking-drafts-and-offers/#the-guest-offer-link) automatically publishes the request as a booking (availability is re-checked first; on a conflict, or if the request is missing required guest details, it stays **Customer Confirmed** for you to resolve by hand). Off by default — every acceptance then waits for you to publish manually. If a guest’s postal address is still incomplete when you send an offer, the send dialog flags in advance that an acceptance will need manual publishing under this setting. See [Requests and offers](/docs/bookings/booking-drafts-and-offers/) for the full guest-acceptance flow. * **Default offer validity (days)** — how long a sent offer stays open by default (1–90 days, initially 7). Prefills the **Valid for (days)** field in the send-offer dialogs; you can still adjust it for each individual send. Offers past their validity expire automatically. * **Default cancellation policy** — the policy applied to any listing that doesn’t have its own. See [Cancellations and refunds](/docs/bookings/cancellations-and-refunds/). * **Pending bookings block storefront** — when on (the default), a pending booking blocks those dates on the storefront: search hides the listing, the public calendar shows them unavailable, and overlapping checkouts are rejected. When off, the storefront ignores pending bookings and keeps taking new ones for those dates. Either way, the operator console always treats pending bookings as blocking. * **Auto-complete bookings** — when on (the default), a confirmed booking is automatically marked completed a set number of days after check-out. Turn it off to require manual close-out for every stay. * **Days after checkout** — how many days past check-out before the auto-complete runs (only shown when auto-complete is on). * **Guest registration (Meldeschein)** and **Registration countries** — enable and scope statutory guest registration. See [Guest registration](/docs/bookings/guest-registration/). ## Timing [Section titled “Timing”](#timing) * **Booking calendar window** — how far ahead guests can book, entered as **years** and **months**. Dates beyond this window are unavailable. * **Default check-in time** and **Default check-out time** — the times shown on bookings, emails, and PDFs unless a booking overrides them. * **Send arrival information before check-in** and **Days before arrival** — emails every confirmed guest their directions, handover contact and check-in time a few days before they travel. Off unless you switch it on; see [Before the guest arrives](/docs/bookings/before-arrival/). ## Booking summary templates [Section titled “Booking summary templates”](#booking-summary-templates) Design the **booking summary PDF** that guests receive. The block editor lets you combine rich-text blocks with a **booking price summary** block (which inserts the price tables) and page breaks. Insert booking variables by typing `$`, and use **Preview PDF** to see the result before saving. ## Other cards on this page [Section titled “Other cards on this page”](#other-cards-on-this-page) The Booking settings page also carries a few adjacent settings that affect bookings: * **Pets** — whether pets are allowed by default and the default pet fee (can be overridden per listing). * **Guest categories** — age thresholds for children and infants, and which children stay free. * **Customer booking view** — shown only when Settings → Storefront mode is set to **Custom** (running your own storefront rather than Reynt’s built-in one): your storefront’s base URL, plus path overrides for the customer-facing booking page and the [guest offer page](/docs/bookings/booking-drafts-and-offers/#the-guest-offer-link). If the offer page URL is left blank, proposal emails simply omit the accept/decline button (guests reply by email instead) — set it once your custom site has an offer page. The section also holds the custom status messages shown on the booking page (pending / confirmed / cancelled). On the built-in storefront (the default) both pages exist automatically and neither path needs configuring. Booking reference prefixes and numbering live under [Invoices → creation and numbering](/docs/invoices/creation-and-numbering/); payment charge timing lives under [Payments](/docs/payments/overview/). # Cancellations and refunds > Define cancellation policies with refund tiers, and cancel a booking with a policy-driven refund preview. Reynt handles cancellations in two parts: **cancellation policies** you define once, and the **cancel flow** on a booking that applies the matching policy and previews the refund before you commit. ## Cancellation policies [Section titled “Cancellation policies”](#cancellation-policies) Manage policies under **Settings → Cancellation Policies**. Each policy has: * **Name** — a short label such as *Flexible* or *Strict*. * **Description** — the full terms shown to customers on the storefront. * **Refund schedule** — the structured tiers. Each row pairs a **days before check-in** threshold with a **refund %**. Tiers are sorted from the longest lead time down, and each threshold must be distinct. For example, a *Flexible* policy might refund **100%** at 7+ days before check-in and **50%** at 1+ day. When a guest cancels, the first tier whose threshold is met wins; cancelling inside the smallest window means **0%**. One-click **presets** (Flexible, Moderate, Strict) give you a starting point. A policy with **no refund schedule** shows only its description — cancelling then refunds the full paid balance, and the cancel dialog previews that amount. ### Assigning a policy [Section titled “Assigning a policy”](#assigning-a-policy) * **Per listing** — set **Cancellation Policy** on the listing’s Facts page to override the default for that property. * **Tenant default** — set **Default Cancellation Policy** under **Settings → Booking settings**; it applies to any listing without its own. ## Cancelling a booking [Section titled “Cancelling a booking”](#cancelling-a-booking) Open the booking and choose **Cancel Booking**. The dialog walks you through: 1. **What happens** — the booked dates are freed on the calendar and any pending (unpaid) payments are cancelled. If money has already been collected, you’re warned that refunds may need processing. 2. **Refund preview** — Reynt shows the matched policy and two figures: the **refund per policy** (the tier’s entitlement) and **to refund now** (the amount that actually moves, capped at what the guest has paid). In marketplace mode it also splits the refund into what the **operator** refunds and what the **owner** refunds. 3. **Reason** — a note used for your records and the guest email. 4. **Send notification** — toggle whether the cancellation email goes out now. ### Adjusting the refund [Section titled “Adjusting the refund”](#adjusting-the-refund) * **Full refund — fault on our side** — a refund-mode switch at the top of the dialog. Choose it when the cancellation is your (or the owner’s) fault: the policy tiers are ignored and **100% of everything the guest has paid** is refunded. In marketplace mode each party refunds exactly what it collected. The choice is recorded in the booking’s activity timeline. * **Override refund amount** *(per-policy mode only)* — enter a different figure (up to the amount paid) when you’ve agreed something else with the guest. It replaces the policy-derived amount. * **Commission refund %** *(marketplace only)* — a three-way choice of **Keep (0%)**, **Split 50/50**, or **Refund (100%)** controlling how much of your commission is returned with the booking. At 100% the commission is refunded with the booking; at 0% you keep it and the owner absorbs the refund. This overrides the booking’s default for this cancellation only. Refunds are paid out manually, along each party’s original payment method. After cancelling, the **booking-cancelled** email can be re-sent from the booking’s Notifications card, and the whole cancellation is recorded in the [activity timeline](/docs/bookings/lifecycle/). # Guest registration > Country-aware guest registration — the German Meldeschein and Austrian Gästeblatt, captured, signed, stored, and purged. Many countries require accommodation providers to collect a signed registration record for each guest. Reynt captures that record per booking, generates the official PDF on demand, and deletes it automatically when the statutory retention period ends. Today two jurisdictions have a certified field set: **Germany (Meldeschein)** and **Austria (Gästeblatt)**. The feature is a *capture-and-retain* system: the guest completes and signs a form, you store it, and you show it to the authorities on request. Reynt does **not** transmit any data to a government portal. ## Turning it on [Section titled “Turning it on”](#turning-it-on) Guest registration is off by default. Enable it under **Settings → Booking settings** (see [Booking settings](/docs/bookings/booking-settings/)): * **Guest registration (Meldeschein)** — the master switch. * **Registration countries** — the listing countries the form applies to. Choose **DE**, **AT**, or both. A booking only shows a form when its listing’s country is in this set. The jurisdiction is decided by the **listing’s country**, not the guest’s or your own. A German listing always uses the Meldeschein; an Austrian listing always uses the Gästeblatt. A booking on a listing in any other country (or a listing with no country set) never shows a form. ## What each country collects [Section titled “What each country collects”](#what-each-country-collects) | | 🇩🇪 Germany — Meldeschein | 🇦🇹 Austria — Gästeblatt | | ------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------- | | Standard fields | Name, date of birth, nationality, address, arrival/departure, signature | Same | | Extra required fields | — | Gender and country of origin | | Foreign-national document | ID / passport number | Travel-document type, number, issue date, issuing authority | | Retention | 1 year after arrival | 7 years after entry | | Document title | “Besonderer Meldeschein” | “Gästeblatt” | The form adapts automatically to the listing’s jurisdiction — you don’t pick a template. ## How a record gets captured [Section titled “How a record gets captured”](#how-a-record-gets-captured) There are two ways a booking’s registration is filled in: * **Guest self-service.** The guest opens their booking page (the same link used to view the booking) and completes the form, including a drawn or typed signature. No separate login is needed. * **Operator capture.** You can fill in or complete the record yourself from the booking’s **Guest registration** card on the booking detail page. A guest who has not filled the form in gets **one reminder the day before arrival**, with the link to it — see [Before the guest arrives](/docs/bookings/before-arrival/). It goes only to bookings the form applies to and only while the record is still empty. A record moves through **Pending** → **Submitted** (details entered, not yet signed) → **Completed** (signed). Once a guest has signed a completed record, self-service editing can no longer wipe it — the signature is statutory proof. As the operator you can still amend it. ## The booking card and PDF [Section titled “The booking card and PDF”](#the-booking-card-and-pdf) Every booking whose listing falls in an enabled country shows a **Guest registration** card on its detail page. The card shows the current status, renders the captured fields for that jurisdiction, and offers a **PDF download** — the official Meldeschein or Gästeblatt, including the signature. ## Retention and deletion [Section titled “Retention and deletion”](#retention-and-deletion) Each record stores a *retain-until* date — arrival plus the jurisdiction’s retention window (1 year for Germany, 7 years for Austria). A daily background task permanently deletes records once that date passes. You don’t manage this; it keeps you compliant with data-minimisation rules without manual cleanup. Registration details are stored encrypted and are only readable inside the console. The guest self-service form can submit a record but can never read another guest’s data. Note Registration rules — required fields, retention windows, and deadlines — change over time and differ by country. Treat this feature as a practical tool and confirm the current statutory requirements for your jurisdiction. # Booking lifecycle > The states a booking moves through, the reservation lifecycle, and what you see on the booking detail page. A **booking** is a confirmed or pending reservation on a listing. This page covers the states a booking moves through, how it appears in the console, and the cards on its detail page. Quotes and negotiations before a booking exists live in [Requests and offers](/docs/bookings/booking-drafts-and-offers/). ## Booking state vs lifecycle status [Section titled “Booking state vs lifecycle status”](#booking-state-vs-lifecycle-status) Every booking has an underlying **state** and a more descriptive **lifecycle status** that the console shows as the primary badge. The three states are: * **Pending** — awaiting your decision (created by a Request-to-Book flow). * **Confirmed** — locked in; the dates are blocked on the listing’s calendar. * **Cancelled** — terminated. The **lifecycle status** tells you what still needs attention: | Status | Meaning | | ---------------------- | ------------------------------------------------- | | **Awaiting decision** | A pending booking you need to confirm or decline. | | **Upcoming** | Confirmed; the stay hasn’t started yet. | | **Currently hosting** | The guest is in the stay right now. | | **Awaiting close-out** | The stay finished; mark it completed or no-show. | | **Completed** | Closed out — the stay happened. | | **No-show** | Closed out — the guest never arrived. | | **Cancelled** | Terminated before completion. | ## Booking modes [Section titled “Booking modes”](#booking-modes) How a reservation is created depends on two independent settings. **Booking flow** (set under **Settings → Booking settings**): * **Request to Book** — a storefront checkout creates a *pending* booking you review. This is the default. * **Instant Booking** — the direct-confirm alternative. Turning on **Auto-confirm bookings** makes bookings skip the pending state and confirm immediately on publish, regardless of flow. See [Booking settings](/docs/bookings/booking-settings/). **Operator mode** — a tenant runs in either **direct** mode (you rent your own properties) or **marketplace** mode (you manage bookings on behalf of property owners and settle commission to them). Marketplace mode adds owner settlement invoices and per-party payment splits. ## Close-out [Section titled “Close-out”](#close-out) When a stay’s check-out date passes, a confirmed booking moves to **Awaiting close-out**. You resolve it by choosing **Mark completed** or **Mark no-show**; a mistake can be undone with **Re-open booking**. If **Auto-complete bookings** is enabled, Reynt marks stays completed automatically a set number of days after check-out. ## Travel period vs booking period [Section titled “Travel period vs booking period”](#travel-period-vs-booking-period) Reynt distinguishes two ways of expressing the same dates, each with its own icon: * **Travel period** (🧳) — check-in to **check-out day**, counted in **nights**. This is the guest’s stay. * **Booking period** (📅) — check-in to the **last booked day** (the last night the property is occupied), counted in **days**. The bookings list shows the travel period; the detail page shows both. ## The booking detail page [Section titled “The booking detail page”](#the-booking-detail-page) Open a booking to reach its detail page, which has three tabs — **Details**, **Conversation** (the guest message thread), and **Activity**. The Details tab lays out these cards: * **Booking Information** — listing, owner, travel and booking periods, check-in/out times, guests and pets. * **Price Summary** — accommodation, add-ons, discounts, total, down payment, and any platform fee and VAT. * **Cancellation Policy** — the policy and refund tiers that apply. * **Customer** — guest contact details, communication language, and linking to a saved [customer record](/docs/customers-and-owners/customers/). * **Operations** — channel reference, estimated arrival time, the guest’s booking-page access link (regenerate / revoke), and internal notes. * **Guest registration** — the Meldeschein/Gästeblatt card, when applicable. See [Guest registration](/docs/bookings/guest-registration/). * **Payment** — the payment schedule and what each party owes or has paid. See [Payments](/docs/payments/overview/). * **Invoice** — customer and owner invoices, with buttons to create them. * **Notifications** — send guest emails (booking created/confirmed/cancelled, payment instructions). ### Activity timeline [Section titled “Activity timeline”](#activity-timeline) The **Activity** tab is a single audit feed with filter tabs — **All**, **Lifecycle**, **Emails**, **Modifications**, and **Payments** — recording every status change, email sent, modification, and money movement with who did it and when. ## Header actions [Section titled “Header actions”](#header-actions) The detail page header shows the actions available for the current state. While a booking is **pending**, **Confirm Booking** and **Cancel Booking** sit side by side — declining a request is done with **Cancel Booking**, there is no separate reject action. The confirm dialog lets you attach an optional personal **message to the customer**, shown as a highlighted block in the confirmation email. Once a booking is confirmed, **Cancel Booking** moves into the overflow menu as a destructive action, alongside **Create Draft**, **Download PDF**, **Move to another listing**, **Archive Booking**, and **Delete Permanently**. **Awaiting close-out** shows **Mark completed** / **Mark no-show** instead, and **Modify Booking** stays available throughout (until the booking is cancelled). See [Modify a booking](/docs/bookings/modify-a-booking/) and [Cancellations and refunds](/docs/bookings/cancellations-and-refunds/) for those flows. ## Archiving [Section titled “Archiving”](#archiving) **Archive Booking** hides a booking from the default list without deleting it — calendar blocks, payments, and invoices are untouched, and you can **Restore** it any time. The list has a dedicated **Archived** filter. This is separate from **Delete Permanently**, which is only available for bookings with no invoices, emails, payments, or modification history. # Modify a booking > Change dates, guests, or pricing in place with automatic charge/refund handling, move a booking to another listing, and reassign owners. You can change a confirmed or pending booking in place. Reynt recalculates the price, works out the difference, and settles it automatically as a new payment leg or a refund — paid amounts stay locked, only the remaining balance is affected. Invoices aren’t touched automatically; correct one yourself if the change affects an invoice you’ve already issued. ## Modifying a booking [Section titled “Modifying a booking”](#modifying-a-booking) Open the booking and choose **Modify Booking**. In the dialog you can change the **stay period**, **guests**, **pets**, and pricing (add-ons and line items). The listing itself is fixed here — to change it, see *Moving a booking* below. As you edit, a **Preview** panel shows the original total, the new total, and the difference: * **Additional charge** — a **Supplement** payment leg is added for the extra amount; collect it like any other payment (see [How payments work](/docs/payments/overview/)). * **Refund** — a refund obligation is recorded for the difference. If that money hadn’t been paid yet, it’s simply a credit — what’s owed drops, and there’s nothing to send back. Only the portion the guest had actually paid becomes a real payout, which you discharge by hand (see [Partial payments and refunds](/docs/payments/partial-payments-and-refunds/)). You must enter a reason and tick a confirmation before applying. * **No change** — nothing is charged or refunded. Neither case touches an invoice document — invoicing stays manual. If the booking already has an issued invoice, correct it yourself (a credit note for a downward change, a new invoice for the extra). ### Rate-drift notice [Section titled “Rate-drift notice”](#rate-drift-notice) If your new period extends past the dates the booking was originally priced against, Reynt shows a **Live rates consulted** notice — the new total uses today’s listing rates rather than the rates frozen at booking time. Changes within the original dates keep the original rates. ### Partial cancellations [Section titled “Partial cancellations”](#partial-cancellations) A modification that only *shrinks* the booking (fewer nights, fewer guests) is recorded as a **partial cancellation** and produces a refund through the same flow — there’s no separate screen for it. ### Custom pricing [Section titled “Custom pricing”](#custom-pricing) If the automatic price isn’t what you want, switch on **Override total manually** to enter your own line items and total. Reynt records exactly what you set instead of recalculating. ### Commission refund *(marketplace)* [Section titled “Commission refund (marketplace)”](#commission-refund-marketplace) When a modification produces a refund on a booking that carries commission, the same **Commission refund %** choice as on cancellations appears — **Keep**, **Split 50/50**, or **Refund** — controlling how much commission is returned. It overrides the booking’s default for this change only. ### History and notifications [Section titled “History and notifications”](#history-and-notifications) Every modification is written to the booking’s **Activity** timeline as a change-history entry with the before/after period and total, the delta, and who made the change. A **booking-modified** email can be sent on apply, or sent and re-sent later from the timeline. ## Moving a booking to another listing [Section titled “Moving a booking to another listing”](#moving-a-booking-to-another-listing) From the booking’s overflow menu, **Move to another listing** transfers a pending or confirmed booking to a different property. You choose how to price it: * **Keep current price** — the agreed total stays; no refund or charge. Future modifications will price against the new listing. * **Re-price against the new listing** — the total is recalculated at the new listing’s rates, and the difference is refunded or charged like a modification. Only eligible listings are offered. A move requires the target to have the **same owner**, **same country**, and **same currency**. In *keep price* mode the collected **city tax** must also be unchanged — switch to re-pricing if it would differ. Before you confirm, Reynt previews any calendar conflicts, house-rule issues (stay length, guest caps), and differences in cancellation policy or deposit. A re-price move settles the difference the same way a modification does (a Supplement payment leg or a refund obligation) but doesn’t touch any invoice already issued — correct it by hand if the new total makes it stale. ## Reassigning owners *(marketplace)* [Section titled “Reassigning owners (marketplace)”](#reassigning-owners-marketplace) When a property changes hands, you can move its existing bookings to a new owner. This lives on the **listing’s Owner page**, not on individual bookings: open the listing, go to **Owner**, and use **Reassign bookings**. A short wizard lets you pick the new owner, select which active bookings to move, and optionally make that owner the default for future bookings. Bookings that have already been **paid** to the current owner can’t be reassigned — they show a **Paid** badge and must be settled or refunded first. Reassigning updates each booking’s owner and regenerates the affected owner-settlement invoices. # Catalog overview > Define amenities, attributes, tags, property types, places and distances once, then reuse them across every listing. The catalog is where you define the building blocks your listings reuse — amenities, attributes, tags, property types, places and distance types. You create each item once, and it becomes available to assign to any listing. Keeping these in a shared catalog means consistent labels, icons and translations across your whole portfolio. ## The catalog pages [Section titled “The catalog pages”](#the-catalog-pages) Each catalog type has its own page, gathered under **Settings → Catalogs**: * **Amenities** — features a property offers (WiFi, pool, parking). * **Attributes** — typed facts about a property (see [Amenities, attributes and tags](/docs/listings/amenities-attributes-and-tags/)). * **Tags** — free‑form labels used as storefront filter pills. * **Property types** — apartment, house, villa, and so on. See [Property types](/docs/catalog/property-types/). * **Places** and **Distances** — locations and points of interest. See [Places and distances](/docs/catalog/places-and-distances/). Amenities, attributes, tags and distances are simple lists: each item has an ID, a per‑language label or name, an icon, and (where relevant) a **visible** or **searchable** flag that controls whether it shows on the storefront. You add, edit and delete items directly on the page. ## The global catalog [Section titled “The global catalog”](#the-global-catalog) Rather than typing every amenity from scratch, you can pull from Reynt’s **global catalog** — a curated, professionally translated library shared across the platform. On the **Amenities**, **Attributes** and **Distances** pages you’ll find two buttons: * **Add from catalog** — browse the global library, pick the items that fit your business, and import them. Each import becomes a **linked copy**: it’s yours to edit, but its additional‑language labels and default description keep coming from the catalog unless you override them. Imported items carry a small **Catalog** badge. * **Link to catalog** — already built your own list? Linking matches your existing items to the global catalog so they gain the catalog’s multilingual labels and descriptions, while your own labels are kept as overrides. When you edit a linked item, any language label or description you leave blank inherits from the catalog; anything you fill in overrides it. ## AI catalog selection [Section titled “AI catalog selection”](#ai-catalog-selection) Both flows are AI‑assisted: * In **Add from catalog**, **Suggest for my business** pre‑selects the catalog items most relevant to your properties, so you’re not scanning the whole library. * In **Link to catalog**, Reynt analyses your existing items and proposes matches — flagged as either an exact match or an AI match — for you to review and approve. See [AI overview](/docs/ai/overview/) for how AI features work across the console. ## Icons and AI icon suggestions [Section titled “Icons and AI icon suggestions”](#icons-and-ai-icon-suggestions) Amenities, attributes, property types and distances each take an **icon**, chosen from a searchable icon picker. When the item already has a name, the picker offers a **suggest** button that proposes fitting icons for you — a quick way to give every catalog entry a consistent, recognisable symbol on the storefront. # Places and distances > Organise listings by location with places, and describe proximity to points of interest with distance types. Two catalog types handle location: **places** group your listings geographically, and **distances** describe how close a property is to points of interest. ## Places [Section titled “Places”](#places) A place is a named area that listings can belong to — **at any scale**. It doesn’t have to be a town: country, region, coast, lake, island, valley, mountains, national park, city and neighbourhood are all valid types. “Lake Constance”, “Costa del Sol” and “the Cotswolds” are places just as much as “Konstanz” is. Places are organised as a hierarchy, so you can nest a neighbourhood under a city under a region. That’s where the value is: a listing under “Old Town” is also found when a guest searches “Konstanz” or “Lake Constance”. On the storefront they let guests browse from broad to specific — and your top-level places become the default storefront navigation. Manage them on the **Places** page, which uses a sidebar layout: places are listed on the left, and selecting one opens its detail panel on the right. Create or edit a place with the place editor, where you set: * **Type** — the scale (country, region, coast, lake, city, neighbourhood…). There is deliberately no pre-selected default: among other things, the type decides how far the storefront map zooms out when a guest picks this place. * **Name** — the place’s label (per language). * **Coordinates** — an optional latitude/longitude. This is the centre of the *area*, not a street address. * **Show on map** — whether the place is plotted on the storefront map. * **Description** — an optional rich‑text description (per language), shown on the storefront property pages within this area. * **Parent** — the place this one nests under, building the hierarchy. Each place shows how many listings are assigned to it. A listing is always assigned to the **most specific** place that fits — the broader ones follow automatically. Use the **Location** section of the listing detail view, which also holds the listing’s own coordinates and postal address; those belong to the listing, not to the place. ### AI place coordinates [Section titled “AI place coordinates”](#ai-place-coordinates) From the **Places** page you can run an AI action that looks up coordinates for your places automatically, saving you from finding latitudes and longitudes by hand. See [AI overview](/docs/ai/overview/). ## Distances [Section titled “Distances”](#distances) A distance type is a category of point‑of‑interest proximity — “beach”, “airport”, “city centre”, “ski lift”. You define the *types* in the catalog; the actual distance for each property is entered per listing. Manage the types on the **Distances** page. Each distance type has: * **ID** — a URL‑friendly identifier. * **Label** — the display name (per language). * **Icon** — the symbol shown next to it. * **Searchable** — whether this distance becomes a storefront search filter. Like amenities, distance types can be imported from or linked to the [global catalog](/docs/catalog/overview/#the-global-catalog). ### Distances on a listing [Section titled “Distances on a listing”](#distances-on-a-listing) On a listing’s **Distances** section you record the real numbers: pick a distance type and enter how far the property is from it (for example, 500 m to the beach), or add a one‑off custom distance for that listing only. Distance types marked **searchable** let guests filter by proximity on the storefront — see [Search and maps](/docs/storefront/search-and-maps/). # Property types > Built-in and custom property types, and where they are used across listings and city tax. A property type classifies a listing — apartment, house, villa, and so on. Reynt ships with a set of built‑in types, and you can define your own on the **Property types** catalog page. ## Built-in types [Section titled “Built-in types”](#built-in-types) Every tenant starts with a standard set of property types: house, apartment, villa, cabin, condo, cottage, bungalow, chalet, townhouse, loft, studio, and *other*. These are always available — you don’t need to create them. ## Custom property types [Section titled “Custom property types”](#custom-property-types) If the built‑in list doesn’t cover a category you use, add your own on the **Property types** page. Each custom type has: * **ID** — a URL‑friendly identifier. * **Label** — the display name (per language). * **Icon** — an optional symbol, with AI icon suggestions available once the label is set. Custom types sit alongside the built‑in ones everywhere a property type is chosen. Edit or delete them from the same page. ## Where property types are used [Section titled “Where property types are used”](#where-property-types-are-used) A listing’s property type is set on its **Property Facts** section (see [Content and media](/docs/listings/content-and-media/#property-facts)). Beyond labelling the listing, property types drive: * **City tax rules** — when you configure city (tourist) tax, you can set different rates per property type, so an apartment and a villa can be taxed differently. See [Taxes](/docs/invoices/taxes/). * **Filtering in the console** — the property type is one of the filters on the **Listings** list, helping you narrow a large portfolio. Because custom types feed both the listing form and the city‑tax tiers, adding or renaming one updates the choices in both places. # Email confirmation gate > Hold automatic guest and owner emails for review in the Mail Outbox before they send. The **email confirmation gate** lets you review automatic emails before they reach a guest. When it’s on, instead of sending a booking confirmation, payment instruction, or other operator-initiated customer or owner email straight away, Reynt renders it and parks it in the **Mail Outbox** first. Emails that acknowledge something the guest just did are never held — see [What is and isn’t held](#what-is-and-isnt-held). It’s a safety net — useful while you’re setting up templates, importing data, or simply want a human to glance at every guest email before it goes out. ## Turning it on [Section titled “Turning it on”](#turning-it-on) Enable it under **Settings → Email delivery** → **Email Confirmation Gate** (“Hold automatic emails for review before sending”). It’s a per-tenant switch and off by default. Turn it off and automatic emails send immediately again. ## Choosing what happens next [Section titled “Choosing what happens next”](#choosing-what-happens-next) With the gate on, you pick how a held email resolves: * **Wait for me** — nothing goes out until you send it from the Mail Outbox. The safest setting, and the one to start with. The cost is that every automatic email becomes a task: if nobody works the outbox, guests hear nothing. * **Send after a delay** — the email sends itself once the delay is up (15 minutes by default; anything from 1 minute to 24 hours). You get a notification the moment it’s held, with time to look at it and, if something is wrong, hold it back. The second one is the better fit once your templates have settled. It turns the gate from an approval queue into an interception window: you don’t have to do anything for the normal case, and you still get a chance to catch the unusual one. The useful action inside that window is **Hold back**, not Send — the email was going to send anyway. Holding it back stops the clock on that one email, which then waits for you exactly as it would in “Wait for me” mode. So you only have to decide *that* an email needs a closer look, not finish looking within the delay. Caution In “Send after a delay” mode, releasing emails depends on a background task. If that task stops, delayed mail stops going out — and because nobody is waiting on an approval, the silence is easy to miss. If guests report not receiving mail, check the Mail Outbox for a pile of emails past their send time. ## What is and isn’t held [Section titled “What is and isn’t held”](#what-is-and-isnt-held) Only emails **you set in motion** are held — a booking confirmation, a cancellation, a declined inquiry, an offer, a modification. These are *not* held: * **Receipts for something the guest just did** — the confirmation for a booking request, an inquiry, a contact-form message, or a received payment. The guest is waiting on that response right then, and a missing one reads as “the form didn’t work”, so it always sends immediately. * **Instant bookings** — when your booking flow is set to *instant*, a storefront booking confirms itself and its confirmation goes straight to the guest. Reviewing it would mean the guest who just paid hears nothing. * **Your inbox replies** — operator-written replies from the [Inbox](/docs/communication/inbox/) send in real time. * **Team notifications** — booking-request and contact-form alerts to your own inbox. * **Test emails** — the “send test” buttons on the Notifications hub. An automatic email that’s turned off in the [Notifications](/docs/communication/notifications-and-email/) hub is never produced in the first place, so it never reaches the outbox — the preference check happens before the gate. ## The Mail Outbox [Section titled “The Mail Outbox”](#the-mail-outbox) Open **Mail Outbox** in the main sidebar — it appears there only while the confirmation gate is on. It lists every held email with its type, recipient, subject, and — in “Send after a delay” mode — when it goes out. A row reading **Waits for you** has no clock on it: either you’re in “Wait for me” mode, or someone held that email back. For each row you can: * **Preview** — open the exact rendered email you’re about to send. * **Send** — dispatch it, unchanged, to the recipient. * **Hold back** — stop its automatic send so it waits for you. Only shown while a send is actually scheduled, and reversible by pressing Send. * **Discard** — cancel it; it is never sent (this can’t be undone). When you have a backlog, **Confirm all** and **Discard all** act on every pending email at once. If a send fails, the email stays pending so you can retry. The **Mail Outbox** nav item shows a badge with the number of emails waiting, and the top-bar notification bell surfaces the same count, so held mail doesn’t get forgotten. Once an email is sent from the outbox, it’s recorded in [Mail logs](/docs/communication/mail-logs/) like any other outgoing mail. # Inbox > A shared inbox for guest conversations — reply by email, assign, snooze, and turn a message into a booking request. The **Inbox** is your shared team inbox for guest communication. Every message — the automated emails Reynt sends and the human replies that come back — lives in one timeline, anchored to the booking or inquiry it’s about. Open it from **Inbox** in the main sidebar. ## The conversation list [Section titled “The conversation list”](#the-conversation-list) The left sidebar lists conversations, newest activity first, with an unread dot and a status badge on each. Filter the list by: * **Status** — open, pending, snoozed, or closed. * **Assignee** — assigned to me, unassigned, or a specific teammate. * **Channel** — email or contact form. * **Unread only**. Because message bodies are stored encrypted, the inbox filters rather than full-text searches; you can still filter on the plaintext subject. ## The thread [Section titled “The thread”](#the-thread) Select a conversation to open its timeline on the right. Guest and operator messages render as chat bubbles; the automated emails Reynt sent (booking confirmed, payment instructions, and so on) appear as compact system rows with a delivery badge. A **Context** panel links the conversation to its booking, request, or customer and shows the essentials (listing, dates, guests, total, payment status) so you can answer without leaving the page. If a guest’s email included attachments, each message shows them with a **Download** button. Attachments are stored securely and downloaded through the console, never exposed as public links. ## Replying [Section titled “Replying”](#replying) Type your reply in the composer and press **Send** — it’s emailed to the guest in real time (the composer shows exactly which address it goes to). A reply is never held by the [confirmation gate](/docs/communication/email-confirmation-gate/); that only applies to automatic mail. The composer also gives you: * **Internal note** — toggle this on to record a note on the conversation that is *never* sent to the guest, for your team only. * **Canned response** — insert a reusable snippet (see below). * **Draft with AI** and **Polish** — optional AI help that only fills the composer; you always review and send yourself. Drafting is grounded in the real booking, so it cites the actual dates and prices. See [AI overview](/docs/ai/overview/). Reynt can also prepare (or send) replies on its own as soon as a guest writes in, rather than waiting for you to ask. That’s off by default — see [AI replies to guests](/docs/ai/guest-replies/). If a thread has no reply address (an anonymous contact-form message with no email captured), only internal notes can be added. ## Inbound replies [Section titled “Inbound replies”](#inbound-replies) For guest replies to thread back into the inbox, turn on **Inbound email replies** under **Settings → Email delivery**. When it’s on, outgoing customer emails carry a special Reynt reply address, so a guest simply hitting “reply” lands their message in the right conversation automatically. When it’s off, replies go to your normal reply-to address and are not captured here. This is covered in [Notifications and email](/docs/communication/notifications-and-email/). ## Assign, snooze, and resolve [Section titled “Assign, snooze, and resolve”](#assign-snooze-and-resolve) Treat the inbox like a helpdesk: * **Assign** a conversation to yourself or any teammate. * **Snooze** it until later (tomorrow, in 3 days, next week, or a custom time) — it drops out of your open list and pops back when the time comes. * **Resolve** to close it, **Reopen** to bring it back, and **Mark unread** to flag it for follow-up. ### Automatic housekeeping [Section titled “Automatic housekeeping”](#automatic-housekeeping) The inbox keeps itself tidy so the open list stays about real work: * Conversations that exist only to record automated notification emails start out **closed** — they never clutter the open queue, and a guest reply reopens them instantly. * A nightly sweep closes stale threads you’re done with: pending threads with no activity for a while, and read booking threads that have been quiet since well after check-out. **Unread threads are never auto-closed.** * You can turn the sweeps off, or tune the quiet periods, under **Settings → Email delivery → Inbox**. ## Canned responses [Section titled “Canned responses”](#canned-responses) Reusable reply snippets live under **Settings → Canned Responses**. Create titled snippets there, then insert them into the composer with the **Canned response** picker. They’re inserted verbatim; use **Draft with AI** if you’d rather adapt a snippet to the specific guest. ## Create a booking request from a message [Section titled “Create a booking request from a message”](#create-a-booking-request-from-a-message) When a guest message is really a booking request, use **Create booking request** in the conversation’s Context panel. Reynt opens the [booking request](/docs/bookings/booking-drafts-and-offers/) wizard in its inquiry-capture mode — name, email, and phone pre-filled from the contact, and the guest’s message dropped in as their [customer wish text](/docs/bookings/booking-drafts-and-offers/#customer-wishes) — and links the new request back to the conversation once created, so the inquiry and the resulting offer stay part of the same thread. ## The notification bell [Section titled “The notification bell”](#the-notification-bell) The bell in the top bar summarises what needs attention across the console — new unread inbox conversations and emails waiting in the [Mail Outbox](/docs/communication/email-confirmation-gate/) — and links straight to each. The **Inbox** nav item also carries an unread count. # Mail logs > The record of every email Reynt sent, with delivery status, to debug "I never got the email" tickets. **Mail logs** is the record of every email Reynt actually sent to your customers and owners. When a guest says “I never got the confirmation,” this is where you check what happened. Open it from **Settings → Mail Logs**. ## What’s recorded [Section titled “What’s recorded”](#whats-recorded) Each row is one outgoing email, with: * **Date** it was sent. * **Type** — which email it was (booking confirmed, payment instructions, and so on). * **Recipient** — the address it went to. * **Sender** — whether it went through **your own server** or the **platform** mailer (Reynt’s fallback, used when you have no mail server configured). * **Subject**. * **Status**. * **Error message**, when a send failed. Filter the list by type or status to narrow things down. ## Delivery statuses [Section titled “Delivery statuses”](#delivery-statuses) * **Sent** — Reynt handed the email to the mail server. * **Delivered** — the receiving server accepted it for the recipient. * **Bounced** — the recipient’s server rejected it (bad address, mailbox full, blocked). It did not arrive. * **Failed** — the send itself didn’t go through. > **Delivery tracking depends on your mail transport.** On the platform mailer it is always on. On **your own Brevo or Mailjet account** it needs a one-time setup step — see below. With **SMTP** there is nothing to observe: the protocol reports nothing back once the message is handed over, so those emails stay at **Sent** even when they arrive. ## Turning on delivery tracking for your own mail account [Section titled “Turning on delivery tracking for your own mail account”](#turning-on-delivery-tracking-for-your-own-mail-account) If you send through your own Brevo or Mailjet account, that account has to tell Reynt what happened to each email. Setting it up takes a minute: 1. Go to **Settings → Emails → Mail server** and make sure your provider is configured and enabled. 2. Under **Delivery tracking**, click **Enable delivery tracking** and copy the URL that appears. 3. Paste it into your provider and select the events below. ### Brevo [Section titled “Brevo”](#brevo) Settings → Webhooks → Add a webhook, paste the URL, and tick exactly these: `delivered` · `hard_bounce` · `soft_bounce` · `blocked` · `spam` · `invalid_email` · `deferred` · `error` `delivered` is what turns an email from *Sent* into *Delivered*; the rest are the ways a send can fail. ### Mailjet [Section titled “Mailjet”](#mailjet) Account Settings → Event notifications (Event API). Mailjet takes one entry per event, so add four, each with the same URL: `sent` · `bounce` · `spam` · `blocked` **`sent` is the one people leave out, and it is the important one.** Mailjet has no separate *delivered* event — its `sent` (German: *Gesendet*) means the recipient’s server accepted the email, and that is what turns *Sent* into *Delivered*. Without it you would only ever see failures, never confirmations. Also tick **Group events** (“Events zusammenfassen”). Mailjet then batches events instead of sending one request per event, which Reynt handles either way. ### Both [Section titled “Both”](#both) Leave opens, clicks and unsubscribes switched off. Reynt discards them, so they only cost requests against your webhook. From then on, mail logs show the real delivery status instead of stopping at *Sent*, and a bounce shows the reason the receiving server gave. > The URL contains a secret — treat it like a password. If it ever leaks, use **Rotate secret** to invalidate it, then paste the new URL into your provider. Tracking stays down in between, so do the two steps together. ## Debugging delivery [Section titled “Debugging delivery”](#debugging-delivery) A typical “missing email” check: 1. Find the email by recipient and date. **No row at all** means it was never sent — check whether the notification is turned off in [Notifications](/docs/communication/notifications-and-email/), or whether it’s still waiting in the [Mail Outbox](/docs/communication/email-confirmation-gate/). 2. **Bounced** or **Failed** — read the error message; usually a wrong address or a mailbox problem. Fix the customer’s email and resend from the booking. 3. **Delivered** but the guest can’t find it — it likely landed in spam; ask them to check. If you’re testing against imported data, note that a redirected email shows the intended recipient as a `[→ guest@example.com]` prefix on the subject. ## Relationship to the Inbox [Section titled “Relationship to the Inbox”](#relationship-to-the-inbox) Guest-facing emails also appear on the booking’s timeline in the [Inbox](/docs/communication/inbox/), where each shows the same delivery badge (delivered, sent, failed, bounced). Mail logs is the complete technical record of *every* outgoing email; the inbox shows the guest-facing ones in the context of the conversation they belong to. # Notifications and email > Choose which automatic emails go out, edit their templates per language, and set up how mail is delivered. Reynt sends transactional emails at each important booking event — booking created and confirmed, payment instructions and receipts, cancellations, inquiry replies, and more. Two console areas control them: the **Notifications** hub decides *which* emails go out and *what they say*, and **Email delivery** decides *how* they’re delivered. ## The Notifications hub [Section titled “The Notifications hub”](#the-notifications-hub) Open **Settings → Notifications**. The left rail lists every notification, grouped into Requests & inquiries, Bookings, Payments, and Contact forms. Each row shows whether it’s on and who it’s for (the guest, or your team). Select one to manage it on the right: * **Delivery** — a channel toggle (email today). Turning it off is a hard disable: that automatic notification is never produced, even if a booking action asks for it. Manual resend buttons are unaffected — they always send. * **Email template** — the editable content for guest-facing emails (see below). * **Preview** — render the actual email with sample data right in the console, so you can check the result of template edits without sending anything. * **Send test email** — send yourself a copy with sample data to any address you enter, in the language you pick. A couple of rows behave slightly differently: the two team notifications (booking-request and contact-form) have no editable content — just a toggle and a test send — and **Payment instructions** is a manual-send-only email with no automatic trigger. ### The notifications [Section titled “The notifications”](#the-notifications) | Notification | Sent to | Fires when | | ------------------------------- | --------- | ------------------------------------------------------ | | Booking request received (team) | Your team | A guest submits a request or inquiry on the storefront | | Booking request confirmation | Guest | Right after that request/inquiry is submitted | | Offer / proposal sent | Guest | You send an offer from a booking request | | Inquiry declined | Guest | You decline a request or inquiry | | Booking created | Guest | A request is published as a pending booking | | Booking confirmed | Guest | A booking becomes confirmed | | Booking modified | Guest | You modify a booking and choose to notify | | Booking cancelled | Guest | You cancel a booking | | Payment received | Guest | You mark a bank transfer paid | | Refund confirmation | Guest | A refund is processed | | Contact form received (team) | Your team | A guest submits the storefront contact form | | Contact form confirmation | Guest | Same submission, auto-reply to the guest | Most booking actions (publish, confirm, cancel, modify, mark-paid) also show a “send email notification” checkbox in their dialog. When the notification is turned off in the hub, that checkbox is hidden with a note pointing back here. ## Editing email templates [Section titled “Editing email templates”](#editing-email-templates) For each guest-facing email you can customise the **Subject**, **Heading**, **Body**, and **Footer**. Leave any field empty to fall back to Reynt’s built-in default. In the body, type **`$`** to insert a variable — placeholders like the guest’s name, listing name, check-in and check-out dates, night count, guest count, totals and amounts due, currency, and payment references are filled in per email. Some templates also expose data-inclusion options (whether to include payment instructions, the schedule, receipts, check-in details, the security deposit, or a booking link). The Booking Modified email inherits these from Booking Confirmed. ### Per-language templates [Section titled “Per-language templates”](#per-language-templates) Template texts are **per language**. If you support more than one language, edit each field per locale, and pick a **Preview language** when sending a test. At send time Reynt uses the recipient’s communication language (see [Customers](/docs/customers-and-owners/customers/)) to choose the right text. Missing template languages are surfaced on the [Translations page](/docs/languages/translations-page/), so you can fill the gaps (and use AI translation) there. ## Email delivery [Section titled “Email delivery”](#email-delivery) Open **Settings → Email delivery** to control how mail is sent: * **Mail server** — your own SMTP, Mailjet or Brevo account. When configured and enabled, all your mail is sent through it. You can temporarily disable it to route through Reynt without losing your credentials. * **Delivery tracking** — on Brevo and Mailjet, a URL you paste into your provider so it reports deliveries and bounces back to Reynt. Without it your [mail logs](/docs/communication/mail-logs/) stop at *Sent*. * **Platform email fallback** — when you have no active mail server, let Reynt send on your behalf from a platform address (“Your Name via Reynt”), with replies routed to your notifications inbox. Disable it to *require* your own server. Reynt never silently sends your mail from a platform address when this is off. * **Notifications address** — the inbox that receives your team notifications and test sends. Keep it set. * **Email branding** — a brand color that themes all customer emails: the header band, buttons, and accents. (This is independent of the storefront’s [theme color](/docs/storefront/appearance-and-theming/).) * **Shared signature** — appended to the bottom of every outgoing customer email (also per-language, with `$` variables). * **Email confirmation gate** — hold automatic customer/owner mail for review before it sends. See [Email confirmation gate](/docs/communication/email-confirmation-gate/). * **Inbound email replies** — route guest replies back into the [Inbox](/docs/communication/inbox/). * **Email legal URLs** — privacy policy and terms links added to the footer of customer emails. * **Inbox auto-close** — whether (and after how many quiet days) resolved inbox conversations are closed automatically. See [Inbox](/docs/communication/inbox/) for how the sweeps behave. ## Delivery bell and logs [Section titled “Delivery bell and logs”](#delivery-bell-and-logs) The bell in the top bar links to items needing attention (unread inbox conversations, emails held in the outbox). Every email that’s actually sent is recorded in [Mail logs](/docs/communication/mail-logs/), where you can check its delivery status. # API keys > Create and revoke keys for programmatic access to the Reynt API. API keys let you call the Reynt API from your own scripts, integrations, or CI — anywhere you need programmatic access instead of logging in through the console. You manage them under **Settings → API Keys**. Each key is bound to the person who created it and inherits that person’s access. If you lose access to the tenant, every key you minted stops working — so mint keys under an account that will stick around. ## Creating a key [Section titled “Creating a key”](#creating-a-key) Click **New API Key** and fill in: * **Name** — a label so you can recognise the key later (for example, “CI deploy bot”). * **Expires** — **Expires in 90 days** (the default), **Never expires**, or **Custom date**. Choosing a custom date reveals a date picker. Submit, and Reynt shows the full key. ### Save the key immediately [Section titled “Save the key immediately”](#save-the-key-immediately) The full key is shown **only once**, right after creation, under **Bearer token**. Copy it with the **Copy** button and store it in your password manager or secret store before you close the dialog — the dialog won’t dismiss on its own while the key is visible. Reynt keeps only a hashed version; there’s no way to reveal it again. If you lose it, revoke the key and create a new one. Keys look like `rynt_…`. Send the full value as a bearer token: `Authorization: Bearer rynt_…`. ## The keys table [Section titled “The keys table”](#the-keys-table) Every key you’ve minted is listed with its: * **Name** * **Prefix** — the visible start of the key (the secret part is never shown again). * **Status** — **Active**, **Revoked**, or **Expired**. * **Last used**, **Expires**, and **Created** dates (any of which may read **Never**). ## Revoking a key [Section titled “Revoking a key”](#revoking-a-key) To retire a key, click the revoke (trash) icon on its row and confirm. Revoking is immediate and permanent: any request using that key starts failing right away, and the action can’t be undone. Revoke a key whenever it’s no longer needed or might have leaked, then mint a fresh one if you still need access. ## Who can manage keys [Section titled “Who can manage keys”](#who-can-manage-keys) Minting and revoking API keys requires an admin role. See [Members & roles](/docs/configuration/members-and-roles/). # Members & roles > Invite teammates to your tenant, assign roles, and manage access. Your tenant is a shared workspace. Everyone who works on it has their own login, so you can see who did what and remove access when someone leaves. You manage the team from **Settings → Members**. Only admins can see and open **Members** — it doesn’t appear in Settings for anyone else, and opening the link directly bounces a Member or Viewer back to the dashboard. ## The Members page [Section titled “The Members page”](#the-members-page) **Members** has two parts: * **Members** — everyone with access to this organisation, showing their name, email, role, and when they joined. * **Invitations** — invites you’ve sent that haven’t been accepted yet. This section only appears once there’s at least one pending invite; once someone accepts, they move to the **Members** list automatically. ## Inviting a teammate [Section titled “Inviting a teammate”](#inviting-a-teammate) Click **Invite Member**, then enter: * **Email** — the person’s email address. * **Role** — **Admin**, **Member**, or **Viewer** (defaults to Member). Submit, and Reynt sends them an invitation email. When they accept, they set up their own login and appear in the **Members** list. If the email already belongs to a member you’ll get an “already a member” message. ## Roles [Section titled “Roles”](#roles) Reynt uses three roles. The line between them is simple: **Member runs the business day to day; Admin also controls the account.** * **Admin** — full access to everything: listings, bookings, invoices, payments, the storefront, all settings, plus inviting members, changing roles, and minting API keys. * **Member** — everything needed to run daily operations: create and manage bookings, listings, customers, invoices, and the storefront/content catalog. A Member can’t change tenant-wide settings (**Settings** stays read-only), can’t invite or manage teammates, and can’t permanently delete a booking — only archive it. Owner records (banking and tax details) are read/update only, not create/delete. * **Viewer** — read-only access everywhere, including **Settings**. No creating, editing, or deleting anything, and no access to the team. A good fit for an accountant, a passive co-owner, or anyone who just needs visibility. Grant **Admin** sparingly — to the people who should be able to change how the account itself is configured and who has access to it. ## Changing a role or removing someone [Section titled “Changing a role or removing someone”](#changing-a-role-or-removing-someone) In the **Members** table: * **Change a role** — use the role dropdown on that person’s row. The change applies immediately. * **Remove a member** — click the remove (trash) icon and confirm. Their access ends at once. You can’t remove yourself — the remove button is disabled on your own row. Reynt also always keeps at least one admin: trying to demote or remove the tenant’s last admin is refused with an error, so a tenant can never lock itself out of its own settings and team. ## Your own account [Section titled “Your own account”](#your-own-account) Roles control what you can do *inside a tenant*. How you personally sign in — password, two-factor, passkeys, active sessions — lives on your [Account](/docs/getting-started/console-tour/) page and is managed through the secure identity portal. # Tenant settings > A map of the Settings area — every configuration tab in the console and what it controls. Everything you configure for a tenant lives under the **Settings** gear at the bottom of the sidebar. Settings opens a second sidebar organised into five groups: **Configuration**, **Billing**, **Communication**, **Catalogs**, and **Platform**. Each tab is a set of cards you edit and save independently — most changes take effect immediately. This page is a map of what each tab does and where to read more. ## Configuration [Section titled “Configuration”](#configuration) * **Identity** — your business name, logo, terminology preset (default, vacation rental, or hotel), default currency, and timezone. Also shows your operator mode (Direct or Marketplace, set when the tenant was created and not editable here) and lets you re-run the setup wizard or restore the dashboard onboarding checklist. * **Languages** — your default language and the set of languages your content and storefront support. See [Multilingual content](/docs/languages/multilingual-content/). * **Translations** — a working page listing every missing translation across your content so you can fill them in one place. See [Translations page](/docs/languages/translations-page/). * **Brand** — your social profile links (Instagram, Facebook, YouTube, X, LinkedIn, TikTok, Pinterest). * **Legal** — registered company name, address, country, VAT number, commercial-register details (representative, register court and number — required on business emails for registered companies), and legal contact, used on invoices, email footers, and legal pages. * **Booking settings** — how bookings behave: instant vs on-request, auto-confirm, default cancellation policy, check-in/out times, pets, guest categories, and guest registration. See [Booking settings](/docs/bookings/booking-settings/). * **Cancellation Policies** — create and manage the reusable policies you attach to listings and bookings. See [Cancellations & refunds](/docs/bookings/cancellations-and-refunds/). * **Storefront** — technical setup for your public site: storefront mode, the go-live publish gate, catalog and property-page options, search pagination and ranking, custom domains, map tiles, and analytics. See [Domains & SEO](/docs/storefront/domains-and-seo/) and [Search & maps](/docs/storefront/search-and-maps/). Branding and theming live on the separate **Appearance** page — see [Appearance & theming](/docs/storefront/appearance-and-theming/). * **Redirects** — URL redirects from old paths to new ones, useful when migrating from an existing site or after changing a page’s slug. See [Domains & SEO](/docs/storefront/domains-and-seo/#url-redirects). ## Billing [Section titled “Billing”](#billing) * **Subscription** — a read-only view of your current plan: status, price, listing and AI limits, billing period, and included features. * **Payments** — your bank transfer details and down payment schedule and, in marketplace mode, your platform fee and commission settings. See [Payment providers](/docs/payments/providers/). * **Invoicing** — enable invoicing, choose auto-creation behaviour, set tax modes, and edit invoice templates and PDF footer. See [Creation & numbering](/docs/invoices/creation-and-numbering/). * **Tax Rates** — per-country tax rates applied to bookings and invoices. See [Taxes](/docs/invoices/taxes/). * **References** — the prefix letters and starting numbers for booking, draft, payment, invoice, and customer reference numbers. ## Communication [Section titled “Communication”](#communication) * **Canned Responses** — reusable reply templates you insert when messaging guests and owners. * **Mail Logs** — the history of every email sent to customers and owners. See [Mail logs](/docs/communication/mail-logs/). * **Notifications** — the notification hub: for each event (booking created, payment received, and so on) set which channels fire, edit the email template, and send a test. See [Notifications & email](/docs/communication/notifications-and-email/). * **Email delivery** — mail transport and delivery: your own mail server or the platform fallback, notification address, email branding (brand color), shared signature, the confirmation gate, inbound replies, email legal links, and inbox auto-close. See [Notifications & email](/docs/communication/notifications-and-email/) and [Email confirmation gate](/docs/communication/email-confirmation-gate/). ## Catalogs [Section titled “Catalogs”](#catalogs) The reusable building blocks your listings draw on — set them up once, then assign them across your whole portfolio. See [Catalog overview](/docs/catalog/overview/). * **Amenities** — features a property offers (WiFi, pool, parking). * **Attributes** — typed facts about a property. * **Property Types** — apartment, house, villa, and so on. See [Property types](/docs/catalog/property-types/). * **Tags** — free-form labels used as storefront filter pills. * **Places** and **Distances** — locations and points of interest. See [Places and distances](/docs/catalog/places-and-distances/). ## Platform [Section titled “Platform”](#platform) * **AI** — your AI provider key, model, custom instructions, and embedding settings, which power the console’s AI features. See [AI overview](/docs/ai/overview/). * **AI Usage** — a read-only dashboard of AI token consumption, cost, and workflow history. * **API Keys** — mint and revoke keys for programmatic access to the API. See [API keys](/docs/configuration/api-keys/). * **Data Transfer** — export your tenant’s configuration, reference data, and storefront content to a file, or import from a previous export. ## Who can change settings [Section titled “Who can change settings”](#who-can-change-settings) Managing settings — and inviting teammates or minting API keys — requires an admin role. See [Members & roles](/docs/configuration/members-and-roles/). # Customers > View and manage guest profiles, their booking history, and their communication language. A **customer** is a guest — the person who made a booking or submitted an inquiry. Reynt keeps one profile per guest so their bookings, requests, invoices, payments, and conversations all hang together in one place. Open **Customers** (under the **People** group in the sidebar) to see the list. ## The customer list [Section titled “The customer list”](#the-customer-list) The list is a table with the customer’s reference, name, email, communication language, and when they were created. Click any row to open the customer’s detail page. Most customers are created automatically the first time a guest books or sends an inquiry through the storefront. You can also add one by hand with **New Customer** — useful for phone or walk-in bookings you enter yourself. ## Create or edit a customer [Section titled “Create or edit a customer”](#create-or-edit-a-customer) The editor is split into sections: * **Basic information** — first and last name. * **Contact** — email and phone. * **Address** — street, city, region, ZIP, country. * **Preferences** — the communication **Language** and any **Special requirements**. * **Notes** — internal notes, visible only to your team. Edit an existing customer from their detail page (**Edit Customer**) — the same editor, pre-filled. ## Communication language [Section titled “Communication language”](#communication-language) The **Language** field is the guest’s preferred language. It is operator-visible and editable, and it drives which language Reynt uses when it emails that guest: the per-language template texts you set up on **Settings → Notifications** are selected by this language. Set it correctly and every booking mail, payment instruction, and confirmation reaches the guest in their own language. ## The detail page [Section titled “The detail page”](#the-detail-page) The customer detail page shows their contact and address, a statistics strip (total, confirmed, and cancelled bookings, plus total spent), and their special requirements and internal notes. Below that, four tabs collect everything linked to the customer: * **Bookings** — every booking, with reference, listing, period, total, and status. * **Requests** — booking requests and inquiries not yet published. * **Invoices** — invoices raised for this customer. * **Payments** — payments and refunds recorded against their bookings. ## How customers get linked to bookings [Section titled “How customers get linked to bookings”](#how-customers-get-linked-to-bookings) A booking or request is linked to a customer when you pick that customer while creating it, or when a guest checks out on the storefront and Reynt matches (or creates) their profile by email. Inbox conversations are linked the same way — a guest’s email reply threads back to the matching customer automatically. Once linked, the booking, its invoices, its payments, and its conversation all appear on the customer’s detail page and on the customer timeline in the [Inbox](/docs/communication/inbox/). Contact details are stored securely; only your team can see a customer’s notes and special requirements. # Owners > Manage property owners, their banking and payout details, and reassign listings during a handover. An **owner** is the person or company that owns a property you manage. Owners matter in **marketplace mode**, where you connect guests with property owners and earn a commission on each booking: every listing belongs to an owner, and each booking produces a payout to that owner and, once you create one, a settlement (commission) invoice. If you run in **direct mode** (you own and manage your own properties), you can ignore owners entirely. Open **Owners** (under the **People** group) to manage them. ## The owners view [Section titled “The owners view”](#the-owners-view) Owners use a sidebar layout: the list of owners stays on the left, and the selected owner’s details fill the panel on the right. The selected owner is kept in the page URL, so you can link straight to one. Create an owner with **New Owner** — a short modal asks for the basic details (name, and whether they’re a registered company). You fill in the rest afterwards on the detail panel. ## Owner details [Section titled “Owner details”](#owner-details) The detail panel groups an owner’s information into sections you edit in place: * **Contact** — email, home and mobile phone. * **Address** — street, city, region, ZIP, country. * **Banking** — bank name, IBAN, and BIC, used for settlements. * **Mollie** — this owner’s own Mollie account, when Mollie is available on your workspace. See below. * **Payment terms** — who collects this owner’s bookings, and how their share reaches them. See below. * **Tax** — company flag, tax ID, and VAT number, used on settlement invoices. * **Notes** — internal notes for your team. ## Connecting an owner’s Mollie account [Section titled “Connecting an owner’s Mollie account”](#connecting-an-owners-mollie-account) When the owner’s share of a booking is paid through Mollie, it goes into the **owner’s own** Mollie account, not yours — so that account has to be connected before those bookings can be taken. The **Mollie** card on the detail panel is where you do it, and it shows where the owner has got to: * **Not connected** — nothing started yet. * **Invited** — a link exists, but the owner hasn’t finished. * **Awaiting Mollie** — the owner connected, and Mollie still wants identification or hasn’t enabled a payment method. You can’t charge against the account yet. * **Ready** — Mollie has cleared the account to accept payments. **Create onboarding link** generates the link. Reynt does **not** email it: an owner is a record in your workspace, not a user with a verified address, so there is no channel to send it on. You send it yourself, through whatever channel you already use with that owner. The link is the authorisation Anyone holding the link can connect a Mollie account to this owner, so send it directly to them. It **works once** and expires after **14 days**. If it goes astray, create a new one — that stops the old link working immediately. If the owner starts the connection but doesn’t finish it, the same link still works: it is only spent once a Mollie account is actually connected. An owner only needs this when their share actually arrives through Mollie. If they’re paid by bank transfer or take their share in cash, you can leave it alone — see below. ## Payment terms for one owner [Section titled “Payment terms for one owner”](#payment-terms-for-one-owner) Most agencies settle every owner the same way, and that is what **Settings → Payments** is for. But an agreement is made with a *person*, and one owner can have negotiated something different — they take their share by bank transfer while everyone else takes cash at the door, say, or they collect from the guest themselves. The **Payment terms** card on the owner’s detail panel is where that exception lives. It has two fields, and both start on **Same as your default**: * **Who collects the money** — the same three answers as your workspace default: everything to you, everything to the owner, or split (your commission to you, the rest to the owner). * **How the owner’s share arrives** — bank transfer, Mollie, or cash at check-in. Only shown when the answer above is a split, because that is the only arrangement where the owner has a leg of their own. Your commission is always paid online when the guest books; this is only about the owner’s part. Leave a field on **Same as your default** and it *follows* your workspace — including any later change you make in **Settings → Payments**. The card shows **Own agreement** or **Same as your default** at a glance, so you can tell which owners you have negotiated separately with. This is marketplace-only: in direct mode there is no owner to hold an agreement with, and the card isn’t shown. Note An offer keeps the terms it was sent with. If you change an owner’s payment terms after sending a guest an offer, that offer — and the booking it becomes — still settles the way the guest was told. New offers use the new terms. ## Settlement invoices [Section titled “Settlement invoices”](#settlement-invoices) When marketplace mode is on, you create the settlement (commission) invoice for a booking yourself — publishing doesn’t generate it automatically. On the booking’s **Invoice** card, **Create Owner Invoice** creates it for that listing’s owner (pending or confirmed bookings); **New Invoice** on **Finance → Invoices** works from scratch at any time. Your commission rate is set under **Settings → Payments**. See [Invoice creation and numbering](/docs/invoices/creation-and-numbering/). ## Owners on bookings [Section titled “Owners on bookings”](#owners-on-bookings) A booking records **which owner it belongs to** at the time it is created, and shows that owner on the booking detail page (linking to the owner’s profile). Because it’s captured on the booking, changing a listing’s owner later does not silently re-route money for bookings already made. ## Reassigning bookings during a handover [Section titled “Reassigning bookings during a handover”](#reassigning-bookings-during-a-handover) When a property changes hands — for example it’s sold to a new owner — open the listing’s **owner** page and use **Reassign bookings**. A short wizard lets you: 1. Choose the new owner. 2. Select which of the listing’s existing bookings to move. 3. Confirm — and optionally make the new owner the default for future bookings. Bookings already paid out to the current owner can’t be reassigned until they’re settled or refunded. # Console tour > A guided tour of the dashboard, navigation, calendar, command palette, and help in the Reynt console. This tour points out the parts of the console you’ll use most. Everything is tenant-scoped: the sidebar, dashboard, and pages all reflect the tenant (organisation) you’re currently in. ## The dashboard [Section titled “The dashboard”](#the-dashboard) Your landing page (**Dashboard**) is a stacked set of at-a-glance widgets: * **Overview** and **Revenue** stat cards — totals for bookings, booking requests, and listings, plus revenue figures. In marketplace mode you also see platform revenue and average platform fee. * **Booking Trends** — a chart of revenue against booking count over the last few months (the window is set in **Settings → Identity**). * **Recent Activity** — the latest bookings and requests, each linking to its detail. * **Action Required** and **Needs attention** — pending booking requests, conversations awaiting a reply, and derived alerts (for example a calendar sync or mail failure), each with a button that takes you straight to the work. * **Get Started** — the onboarding checklist for a new tenant (see [First steps](/docs/getting-started/first-steps/)). It disappears once you complete or dismiss it; you can bring it back from **Settings → Identity**. * **Upcoming check-ins** and **Listing setup** — your next arrivals and any listings that still need work. ## Navigation [Section titled “Navigation”](#navigation) The left sidebar is grouped by what you’re doing. The top cluster is the daily driver — **Dashboard**, **Inbox**, **Calendar**, **Bookings**, **Requests** (and **Mail Outbox** when the confirmation gate is on) — followed by the **Listings**, **Finance**, and **People** groups. Badges on **Inbox** and **Mail Outbox** show how many items need attention. The **Storefront** group and **Smart Search** (under Listings) only appear once you have a fully set-up listing — until then the sidebar stays focused on the operating core. Once revealed they stay visible, and both are always reachable via the command palette or direct URL in the meantime. At the bottom, the **Settings** gear opens a second sidebar with the Configuration, Billing, Communication, Catalogs, and Platform groups — see [Tenant settings](/docs/configuration/tenant-settings/). The top bar has a **View storefront** button that opens your live public site (or a preview if it isn’t live yet), the AI assistant, search, the notification bell, and the organisation picker. ## Global calendar [Section titled “Global calendar”](#global-calendar) **Calendar** shows every listing side by side — one row per property, one column per day of the selected month. Each cell is colour-coded (available, booked, pending, blocked, external calendar, no price). Hover a cell for the status, reason, and price, with links to open the booking or that listing’s own calendar. Filter by title or tags to narrow the grid. ## Command palette and search [Section titled “Command palette and search”](#command-palette-and-search) Press **Cmd/Ctrl + K** to open the command palette. Type to jump to any page — including every Settings page and anything hidden from the sidebar, such as Storefront pages or Smart Search on a fresh tenant — or search live for a listing, booking, request, customer, owner, invoice, inbox conversation, or storefront page and open it directly. There’s always an **Ask AI** option at the top, which hands your question to the assistant panel. Two shortcuts are worth knowing: * **References jump straight to the record.** Typing a booking reference like `B9001` searches bookings and requests only; a customer reference like `C1234` searches guests. The exact prefixes follow whatever you configured for each. * **`#` finds a listing by its key.** `#3` returns every listing whose key starts with `3`, exact match first, and nothing else. Use it when your keys are short — a bare `3` is below the two-character minimum, and even typed in full it would be buried under every description that happens to mention a 3. ## Ask Reynt (AI assistant) [Section titled “Ask Reynt (AI assistant)”](#ask-reynt-ai-assistant) The **Ask Reynt…** button in the top bar (shortcut **Cmd/Ctrl + J**) opens the assistant as a docked panel on the right. It can read your tenant’s data, answer questions, and propose changes that you confirm before anything happens. When you’re on a record, a small chip above the message box names it, so you can say “this booking” and skip the reference — remove the chip, or add more records with **+ Add context**, at any time. Two related things sit next to it: * **AI activity** — the icon beside the notification bell opens a tray of running and recently finished AI workflows, so you can follow progress and review results without leaving the page (or interrupting the chat). * **Help** — guidance for the page you’re on, opened by that page’s **Help** button; it slides over the chat and **Back to chat** returns you. See [The AI assistant](/docs/ai/assistant/) for what it can do. ## Contextual help [Section titled “Contextual help”](#contextual-help) Pages that have guidance show a **Help** button in the page header. It opens the assistant panel on its **Help** tab with tips specific to that page — useful on bookings, listings content, the storefront pages editor, and more. ## Notifications [Section titled “Notifications”](#notifications) The **bell** in the top bar rolls up the sidebar badges — unread inbox conversations and, when the confirmation gate is on, emails held in the Mail Outbox. Open it to jump to whichever needs you, or see “You’re all caught up”. ## Switching organisations [Section titled “Switching organisations”](#switching-organisations) If your account belongs to more than one tenant, the organisation name at the top of the sidebar is a picker. Select another organisation to switch the entire console to it, or choose **Manage** to see all your tenants. Your last choice is remembered. ## Your account [Section titled “Your account”](#your-account) The **Account** page manages how *you* sign in — your profile (name, email, language) and security (password, two-factor, passkeys, active sessions). These open the secure Zitadel account portal in a new tab. Account settings are personal; they don’t change tenant configuration. # Demo mode > See a booking go through end to end — with example content and payments that move no money — before you set anything up. Demo mode fills a new workspace with example content and switches payments onto a test rail, so you can book a stay as a guest and watch it arrive in your console. Nothing on the go-live checklist has to be answered first. It exists because the checklist asks fourteen questions and only four of them actually block anything. Demo mode is the answer to “can I see this working before I spend an afternoon on it?” ## Start it [Section titled “Start it”](#start-it) On the **Go live** page — where a new workspace lands — the first card offers it. One click: * **Example content** goes in: a furnished, priced, photographed example listing, a small catalog of amenities and attributes, a published *About* page and a headline on your homepage. * **Test payments** go on, and become your default payment method. * Your **storefront opens** in a new tab. You can only start a demo while your storefront is unpublished. On a published workspace the offer is not shown, because starting one would take your live site off the air. ## Your storefront is private while it runs [Section titled “Your storefront is private while it runs”](#your-storefront-is-private-while-it-runs) This is the trade, and it is what makes demo mode safe: while test payments are on, your public storefront serves nobody. Anyone with your address sees a maintenance page. You still reach it yourself — the **Open storefront** button hands your browser a preview pass that lifts every gate, including the review Reynt is doing on your workspace. That is why you should follow the link from the console rather than typing your address in. ## The round trip [Section titled “The round trip”](#the-round-trip) This is the part worth doing, and it takes about two minutes: 1. **Book a stay** on your own storefront, as a guest would. Use your own name and email — nothing here reaches a real person. 2. **Come back to the console.** The bell in the top bar has a new entry: your booking request. Click it. 3. **Publish the request.** It becomes a booking, with a payment attached. (If you switched your booking flow to instant, there is no request to publish — it is already a booking.) 4. **Open the checkout** from the booking’s payment card, and pay it. The test rail settles with one click and moves no money. 5. **Look at what changed** — the payment timeline, the invoice, the calendar, the dashboard. All of it is the real machinery; only the money is missing. While your workspace is waiting for Reynt’s review, emails are held — so the booking confirmation and the “pay now” link do not land in your inbox during the demo. Everything above is reachable from the console instead. ## While it runs, the checklist changes one step [Section titled “While it runs, the checklist changes one step”](#while-it-runs-the-checklist-changes-one-step) **Set up how you get paid** is replaced by **Leave demo mode to go live**. That is deliberate: the test rail is not a payment method a real guest can use, so the payment question genuinely cannot be answered while the demo is on. It comes back — unanswered — the moment you leave. ## Leaving [Section titled “Leaving”](#leaving) Leaving is always possible, and it is a step on the go-live checklist. It: * switches test payments off, * restores the payment method you had before (or the first one you have enabled, if that one is no longer available), * stops holding your storefront back — the remaining go-live steps still apply. **The example content stays.** It is yours now: rename the example listing into your own property, rewrite the *About* page, or delete them. Reynt cannot tell an example you have edited from a listing you wrote, which is exactly why it never deletes them for you. **Demo mode is a one-time decision.** Once you leave, you cannot start another one — the examples cannot be added twice, so a second demo would only take your storefront dark again. If you want a genuinely empty workspace afterwards, use **Settings → Identity → Reset workspace**, which deletes content but keeps your settings. ## Demo mode and your free trial are different things [Section titled “Demo mode and your free trial are different things”](#demo-mode-and-your-free-trial-are-different-things) Your 14-day free trial runs from the day you signed up, and it keeps running during a demo. Leaving demo mode early does not shorten it, and staying in one does not extend it — you keep whatever time is left either way, and you can go live with it. # First steps > From a fresh tenant to your first published listing and a live storefront. This is the shortest path from a brand-new tenant to a published listing on a live storefront. The **Go live** page tracks all of it for you — a new tenant lands there, it is in the sidebar, and each step opens the real settings card in place rather than sending you somewhere else. Your dashboard carries a short summary of the same thing. **In a hurry, or not sure yet?** [Demo mode](/docs/getting-started/demo-mode/) fills the workspace with example content and lets you take a booking end to end — with payments that move no money — before you answer any of this. None of the steps below block it. The checklist has two tiers: **Required** (do these to accept bookings) and **Recommended** (do these next). Here’s the order that works. **Each required step ends with a button.** A step is ticked off when you press **Confirm** (or **Save**, if you changed something) on the card the step opens — not merely when the setting happens to be right. Several of these questions have a sensible default already in place, and the checklist walks you past every one of them once so you know what you are running on rather than finding out later. If a step’s card looks correct as it stands, press Confirm and move on; nothing is written and the row closes. A couple of steps have no button of their own — adding your first listing or owner is answered by doing it, and the workspace review is ours to close, not yours. ## 1. Set your business name [Section titled “1. Set your business name”](#1-set-your-business-name) Open **Settings → Identity** and set your business name, along with your currency, timezone, and logo. This is your tenant’s identity across the console, storefront, and emails. ## 2. Add your legal information [Section titled “2. Add your legal information”](#2-add-your-legal-information) Under **Settings → Legal**, add your legal (company) name, address, country, and a legal contact email. These appear on invoices and legal pages, and the storefront won’t go live without them. ## 3. Configure a payment method [Section titled “3. Configure a payment method”](#3-configure-a-payment-method) Under **Settings → Payments**, enable bank transfer and fill in your IBAN and account holder. Without a payment method, bookings publish with no payment obligation. See [Payment providers](/docs/payments/providers/). ## 4. Set a notification email [Section titled “4. Set a notification email”](#4-set-a-notification-email) Under **Settings → Email delivery**, set the address that should receive new booking and inquiry notifications. Otherwise you won’t be emailed when guests book. See [Email delivery](/docs/configuration/tenant-settings/). ## 5. Set a cancellation policy [Section titled “5. Set a cancellation policy”](#5-set-a-cancellation-policy) Create a policy under **Settings → Cancellation Policies** and choose it as your default in **Settings → Booking settings**. See [Cancellations & refunds](/docs/bookings/cancellations-and-refunds/). ## 6. (Marketplace only) Add an owner [Section titled “6. (Marketplace only) Add an owner”](#6-marketplace-only-add-an-owner) If your tenant runs in marketplace mode, add at least one owner under **Owners** — in that mode a listing can’t publish without an assigned owner. In direct mode there are no owners and you can skip this. See [Owners](/docs/customers-and-owners/owners/). ## 7. Create your first listing [Section titled “7. Create your first listing”](#7-create-your-first-listing) Go to **Listings** and click to create one. The default flow is **AI import**: paste a URL, text, or PDF, or upload photos, and Reynt extracts the details and generates content in all your languages. Prefer to type it in? Switch to **Enter details manually**. See [Create a listing](/docs/listings/create-a-listing/). ## 8. Fill the critical items and publish [Section titled “8. Fill the critical items and publish”](#8-fill-the-critical-items-and-publish) A new listing starts as a **Draft**. The completeness bar on the listing shows what’s missing. To leave Draft and become publishable, a listing needs at least one **photo**, a **primary photo**, and **pricing** (plus an **owner** in marketplace mode). Once those are set, the **Publish** button on the listing header activates — click it to take the listing live on your storefront. See [Publishing & visibility](/docs/listings/publishing-and-visibility/). ## 9. Take your storefront live [Section titled “9. Take your storefront live”](#9-take-your-storefront-live) Publishing a listing doesn’t make your public site live on its own. Under **Settings → Storefront**, the **Publish Storefront** section lists four prerequisites: an **imprint**, a **privacy policy**, a **notification email**, and a **payment method**. Once all four are met, turn on **Storefront live**. ## 10. (Optional) Use your own domain [Section titled “10. (Optional) Use your own domain”](#10-optional-use-your-own-domain) Still under **Settings → Storefront**, the **Custom Domains** section lets you add your own domain (for example `booking.mydomain.com`). Add it, create the CNAME record shown, then click **Verify DNS**. Once active you can **Set Primary**. See [Domains & SEO](/docs/storefront/domains-and-seo/). ## 11. (Optional) Send email from your own domain [Section titled “11. (Optional) Send email from your own domain”](#11-optional-send-email-from-your-own-domain) By default Reynt sends your guest emails on your behalf from a platform address (“Your Name via Reynt”). To have them come from an address on your own domain instead, connect your own mail server under **Settings → Email delivery** — SMTP, Brevo, or Mailjet — and set the sender address to one on your domain. Besides putting your name on the envelope, this aligns SPF, DKIM, and DMARC with your domain, which is what keeps your mail out of spam folders. See [Notifications & email](/docs/communication/notifications-and-email/). Both of these last two are optional: your storefront serves and your mail goes out without either. They appear under **Recommended** on the **Go live** page once you’re live. # Welcome to Reynt > A quick orientation to the Reynt platform and what each part of the admin console does. Reynt is a rental management platform built around three ideas: **listings** (the properties you rent out), **bookings** (the reservations against them), and your **storefront** (the public website guests browse and book on). You run all of it from the admin console. ## Who uses the console? [Section titled “Who uses the console?”](#who-uses-the-console) The console is for operators — property managers, host teams, and marketplace operators. Guests never see it; they see your storefront. Each person on your team logs in with their own account, and you control what they can do from **Settings → Members** (see [Members & roles](/docs/configuration/members-and-roles/)). ## The big pieces [Section titled “The big pieces”](#the-big-pieces) The console’s left sidebar groups everything you’ll use. The top cluster is your daily driver, followed by labelled groups: * **Operate** — the **Dashboard**, the **Inbox** for guest messages, the **Calendar** across all properties, plus **Bookings** and **Requests**. If you turn on the email confirmation gate, a **Mail Outbox** appears here too. * **Listings** — every property you rent, plus **Smart Search** analytics. * **Finance** — **Payments** and **Invoices**. * **People** — **Customers**, and **Owners** if you run in marketplace mode. * **Storefront** — your public site: **Pages**, **Navigation**, **Blog**, **Media**, **Promotions**, and **Appearance**. * **Settings** (the gear at the bottom) — all tenant configuration, grouped into Configuration, Billing, Communication, Catalogs, and Platform. Catalogs holds the reusable building blocks listings draw on — **Amenities**, **Attributes**, **Property Types**, **Tags**, **Places**, and **Distances** — and Configuration includes storefront **Redirects**. See [Tenant settings](/docs/configuration/tenant-settings/). The **Storefront** group and **Smart Search** only appear in the sidebar once you have a fully set-up listing; until then they’re reachable via the command palette or direct URL. Everything under **Settings** is always visible. ## Direct vs marketplace mode [Section titled “Direct vs marketplace mode”](#direct-vs-marketplace-mode) A tenant runs in one of two modes, chosen when it’s created: * **Direct** — you manage your own properties. There are no separate owners. * **Marketplace** — you manage properties on behalf of external owners. An extra **Owners** area appears, each listing belongs to an owner, and owner settlement invoices come into play. The mode is fixed for a tenant and shown (read-only) under **Settings → Identity**. ## Multiple brands [Section titled “Multiple brands”](#multiple-brands) Each Reynt tenant is fully isolated — separate listings, guests, invoices, and branding. If you operate more than one brand, run them as separate tenants and switch between them from the organisation picker at the top of the sidebar. Ready to set up? Continue to [First steps](/docs/getting-started/first-steps/). # Invoice creation and numbering > When Reynt creates invoices, the invoice editor, how numbering works, and how to correct with credit notes. Invoices are always created and corrected by hand — Reynt never generates one automatically. Invoicing is a master toggle (**Enable Invoicing** under **Settings → Invoicing**) that’s independent of whether you take payments. ## When invoices are created [Section titled “When invoices are created”](#when-invoices-are-created) * **From a booking** — on the booking’s **Invoice** card, **Create Invoice** (direct mode) or **Create Owner Invoice** (marketplace mode) creates the **customer invoice** or the **owner settlement (commission) invoice** for that booking; both are available for pending or confirmed bookings. **Create Custom Invoice** works from any booking state. * **Manually, any time** — use **New Invoice** on the **Finance → Invoices** page to create one from scratch, for any recipient. * **Modifications and cancellations don’t create invoices** — they only move money (a refund obligation is recorded, which you discharge by hand); if the change affects an invoice you’ve already issued, correct it yourself with a credit note. See [Modify a booking](/docs/bookings/modify-a-booking/). ## Invoice recipients [Section titled “Invoice recipients”](#invoice-recipients) Every invoice has a **recipient type** (its *Target*): * **Customer** — the invoice to the guest (direct mode). * **Owner** — the commission/settlement invoice to a property owner (marketplace mode). Moving a booking to another listing and re-pricing it doesn’t regenerate this automatically — correct it by hand (a credit note plus a fresh invoice) if the settlement changes. *Vendor* also exists as a target for completeness, but the two you’ll work with are Customer and Owner. ## The invoice editor [Section titled “The invoice editor”](#the-invoice-editor) You edit an invoice on its detail page — each section has its own **Edit** modal, and editing is only possible while the invoice is a **draft** (once issued, an invoice is locked). The sections are: * **Recipient** — recipient type, name, email, and VAT number. * **Line items** — one row per charge, each with a type (*Accommodation*, *Add-on*, *Cleaning fee*, *Discount*, *Tax*), description, quantity, unit, and unit price. * **Settings** — invoice type, currency, due date, and tax options (tax country, rates, and exemption reason). * **Custom text** — free-text blocks placed above, below, or around the invoice details. Type `$` to insert template variables, or apply a booking template to populate them. A **Payment schedule** card is also shown, but it’s read-only — it reflects the booking’s payment legs rather than being edited on the invoice. ## Numbering [Section titled “Numbering”](#numbering) Invoice numbers use a per-tenant sequence: a **prefix** (default `I`, set as **Invoice Number Prefix** under **Settings → References**) plus a sequential number, formatted like `I-2026-00001`. The sequence **resets each year**. You can set a **Next invoice number** floor (also under **Settings → References**) to skip ahead — useful when migrating from another system. The next invoice takes the higher of the natural next number or your floor; it isn’t applied retroactively. There is one sequence per account — Reynt does not offer separate configurable number sequences per business unit. ## Corrections with credit notes [Section titled “Corrections with credit notes”](#corrections-with-credit-notes) Issued invoices can’t be edited. To correct one, open it and choose **Create credit note**. The credit note fully reverses the original and references it, so the audit trail most tax authorities require is preserved. Then issue a fresh invoice with the corrected line items if needed. (A downward booking modification doesn’t create one for you — check whether an issued invoice needs correcting and create the credit note yourself.) **Cancel** behaves differently by status: a draft is simply cancelled, but cancelling an issued invoice creates a separate **cancellation invoice** that reverses it — again, so the paper trail stays intact. # Payment status and PDFs > How an invoice tracks payment, and how invoice PDFs are generated and reach guests. An invoice tracks two things: where it is in its lifecycle (draft → issued → paid) and what its PDF looks like. Actual money is recorded against the **booking**, not the invoice — the invoice’s payment status follows along automatically. ## Invoice statuses [Section titled “Invoice statuses”](#invoice-statuses) * **Draft** — editable, not yet a legal document. * **Issued** — finalized and numbered; can no longer be edited. * **Partially paid** — some of the total has been received. * **Paid** — settled in full. * **Cancelled** — reversed (a draft is cancelled outright; an issued invoice is reversed with a cancellation invoice — see [Invoice creation and numbering](/docs/invoices/creation-and-numbering/)). You filter the **Finance → Invoices** list by status (and by target) to find what’s outstanding. ## How payment status is tracked [Section titled “How payment status is tracked”](#how-payment-status-is-tracked) For invoices tied to a booking, the payment status is **synced automatically** from the booking’s payments. When you record a bank transfer on the booking’s **Payment** card, the linked invoice moves to *Partially paid* or *Paid* on its own. The invoice’s **Payment** card is read-only and simply mirrors the booking’s payment summary. You can also set an invoice’s status directly with **Mark as Paid** — useful for manual or off-platform invoices that aren’t driven by a booking’s payment legs. There is no separate “record a payment on the invoice” step; collect the money on the booking (see [How payments work](/docs/payments/overview/)). ## PDFs [Section titled “PDFs”](#pdfs) Every invoice produces a PDF you can **Preview PDF** or **Download PDF** from its detail page. The PDF is built from: * The invoice’s line items and totals. * Your **custom text blocks** — the body content you arrange around the invoice details, with template variables filled in. * The **PDF footer text** — up to two extra footer columns you set as *Footer Text 1* and *Footer Text 2* under **Settings → Invoicing**. PDFs are rendered in the **buyer’s language**: the invoice freezes the guest’s booking locale (and the localized footer text) when it’s created, so the guest always gets the invoice in the language they booked in. ## How guests receive invoices [Section titled “How guests receive invoices”](#how-guests-receive-invoices) Guests access their invoice PDF through the **storefront**, using the secure link tied to their booking — the same place they manage their reservation. The invoice isn’t pushed as an email attachment; it’s available on demand for download. # Taxes and VAT > Configure VAT rates and display, plus the first-class city / tourist tax model. Reynt handles two distinct kinds of tax: **VAT** on the accommodation and services, and a separate **city / tourist tax**. They’re configured in different places and behave differently. ## VAT settings [Section titled “VAT settings”](#vat-settings) Turn VAT on and choose how it’s displayed under **Settings → Invoicing → Tax Settings**: * **Enable Tax** — the master switch. When off, all amounts are tax-free. * **Charge Tax to Customers** — lets you keep customer prices tax-free (e.g. as a small business) while still applying tax on owner settlement invoices. * **Customer Tax Mode** — *Gross* (prices include tax, the B2C default) or *Net* (tax added on top). * **Settlement Tax Mode** (marketplace only) — *Gross* or *Net* (the B2B default) for owner settlement invoices. * **Tax Exemption Text Overrides** — the notice printed on an invoice PDF when a tax exemption applies, which you can customize per reason and language. Your own VAT number comes from the **Legal Information** config; the recipient’s VAT number is entered per invoice in the editor. ## Country tax rates [Section titled “Country tax rates”](#country-tax-rates) VAT percentages live under **Settings → Tax Rates** (*Country Tax Rates*). Add a row per country with an **Accommodation Rate (%)** and a **Services Rate (%)** — for example 7% accommodation and 19% services in Germany. You can import common rates with **Add from Catalog**. When an invoice is built, Reynt resolves the country (the listing’s country, falling back to your registered country), looks up the matching rates, and applies the accommodation or services rate to each line by its category. If tax is enabled but no rate exists for the country, invoice creation is blocked until you add one. ## Tax exemptions and reverse charge [Section titled “Tax exemptions and reverse charge”](#tax-exemptions-and-reverse-charge) Each invoice can carry a **tax exemption reason** — including *reverse charge*, *export*, *exempt*, *small business*, and *margin scheme* — which shows the appropriate 0% note on the PDF. For cross-border marketplace settlement invoices, Reynt sets this automatically from geography: same-country is domestic, another EU country is reverse charge, and a non-EU property is treated as export. You can also set the reason manually on any invoice. Reynt does **not** validate VAT numbers against VIES — enter the recipient’s VAT number and choose the exemption reason yourself. ## City / tourist tax [Section titled “City / tourist tax”](#city--tourist-tax) Many cities levy a tourist tax on top of the accommodation price. This is a first-class model, configured per **place** (under **Places → City / Tourist Tax**) and overridable per listing. A rule sets: * **Basis** — *per person per night*, *per night* (a flat nightly amount), or *percentage* of the accommodation total. * **Rate tiers** — one or more rates, each optionally scoped to a **season** (recurring date window) and to specific **property types**. The most specific matching tier applies for each night. * **Night cap** — a maximum number of taxed nights (e.g. the first 10). * **Child exemption** — an age below which guests aren’t counted. * **Collection mode** — how the tax is settled: * **Added** — charged on top of the booking; it appears as a *Tourist tax* line on the invoice and a *Tourist tax* leg on the payment. * **Included** — already inside the accommodation price; shown for information only. * **Separate** — disclosed to the guest but collected outside the booking (e.g. cash on arrival or a city portal), with an optional note explaining how to pay. The tourist tax is shown to guests on the storefront during booking, and — for the *added* mode — it flows through to the invoice and the payment. In marketplace mode the added tourist tax is passed through to the owner and shown on the settlement invoice. # Multilingual content > Set the languages your business operates in and translate every customer-facing text. Reynt is multilingual end to end. You pick the languages your business supports, then every text you author — listings, catalog labels, website content, blog posts, and email templates — can be written once per language. The storefront serves each visitor their language, and guest emails and documents go out in the language the guest chose. ## Choose your languages [Section titled “Choose your languages”](#choose-your-languages) Open **Settings → Languages** to set the language set for your account. * **Supported languages** — the languages operators can translate content into. Common presets (English, German, French, Italian, Spanish, Dutch, Hungarian, and others) appear in the dropdown, and you can type any BCP-47 tag (for example `pt`, `pl`, `cs`, `sv`). * **Default language** — the fallback used for outgoing emails, invoice and booking PDFs, AI-generated content, number formatting, and any field that hasn’t been translated yet. It must be one of your supported languages. If a translation is ever missing for a language, the storefront falls back to the default language rather than showing a blank — so the default language should always be your most complete one. ### Formal vs informal German [Section titled “Formal vs informal German”](#formal-vs-informal-german) German has two register variants: `de` (informal) and `de-formal` (formal). Pick **one** — both render under the same `/de/` storefront URL, so you can’t enable both at once. The same formal/informal option is available for other languages that need it. ### Guardrails when you change languages [Section titled “Guardrails when you change languages”](#guardrails-when-you-change-languages) Two changes are confirmed before saving because they affect existing content: * **Changing the default language** — content is keyed by the current default, so after switching, any field missing a value in the new default may render blank until you translate it. * **Removing a supported language** — content already translated into that language is hidden from the storefront, but nothing is deleted. Re-add the language later to restore it. You may also see non-blocking warnings when a supported language has **no email template** (booking emails fall back to the default language) or **no storefront route** (visitors picking it see the English storefront until support is added). ## What is translatable [Section titled “What is translatable”](#what-is-translatable) Nearly every operator-authored, customer-facing text carries a value per language: * **Listings** — title, excerpt, description, amenities/prices/discount text, customer info, SEO title and description, and image labels. * **Catalog** — amenity, attribute, distance, tag, and property-type labels, plus place names and descriptions. * **Website content** — CMS page titles, slugs, content sections, menu labels, and blog posts. * **Notifications** — per-language email and notification template texts (see **Settings → Notifications**). * **Settings** — storefront SEO title and description, contact address, booking-page messages, referrer options, and partner-logo alt texts. ## Editing per language [Section titled “Editing per language”](#editing-per-language) Wherever a field is translatable, the editor shows a **language tab per supported language** — fill in each tab, or leave a language empty to fall back to the default. Fields also carry a small **AI** button that can generate or translate the text across your languages; see [Content generation and translation](/docs/ai/content-generation-and-translation/). To find everything still untranslated in one place, use the [Translations page](/docs/languages/translations-page/). ## Storefront behavior [Section titled “Storefront behavior”](#storefront-behavior) Once you support more than one language, the storefront becomes fully localized: * **Language-prefixed URLs** — every page lives under a language prefix (`/en/…`, `/de/…`), and a language switcher in the header lets visitors change language. * **Automatic first-visit language** — a new visitor is matched to their browser language (falling back to your default), and their choice is remembered for return visits. * **SEO** — each page emits `hreflang` alternates, a canonical URL, and appears in a per-language sitemap, so search engines index every language correctly. ## Customer communication language [Section titled “Customer communication language”](#customer-communication-language) Each booking records a **communication language**, so the guest’s confirmation emails, invoices, and booking PDFs are sent in the language they used. You can change it on the booking (or booking request) under **Communication language**, and each customer record carries a **Language** field used for operator-created bookings. Owner and internal operator emails always use your default language. # Translations page > Find every missing translation across your content and fill the gaps with AI review. The **Translations** page collects every missing translation value across your whole account — listings, catalog, website content, notifications, and settings — into one table, so you never have to hunt through individual editors to find what’s untranslated. Open it from the Settings area under **Settings → Translations** (it appears next to **Settings → Languages**). If your account only has one supported language, the page tells you there’s nothing to translate and links you to add more languages. ## Scan for gaps [Section titled “Scan for gaps”](#scan-for-gaps) The coverage check is thorough, so it runs only when you ask. Click **Scan now** to sweep every text; the result is cached for your session and survives navigating into an editor and back. Use **Refresh** to re-run it after you make changes. After a scan you’ll see: * A **per-language summary** — a badge per language showing how many values are still missing, plus a running total. * A **coverage table**, grouped into **Listings**, **Catalog & commerce**, **Website content**, **Notifications & emails**, and **Settings**. Each row names the entity and the fields that are missing, and which languages they’re missing in. Filter the table by area or by a single language to focus. Every row has an **Open** action that deep-links straight into the owning editor (the listing, catalog item, page, email template, or setting) so you can fix it in context. When nothing is missing, the page shows **All translations complete**. ## Fill with AI [Section titled “Fill with AI”](#fill-with-ai) Instead of translating by hand, you can let AI propose translations from your default language. * **Fill all with AI** translates every missing value; **Fill filtered** translates only what matches your current area/language filter. * Before it runs, a confirmation shows how many values and texts will be translated. **Nothing is saved yet** — the AI only proposes. * Progress is shown inline while it works. ### Review before anything is saved [Section titled “Review before anything is saved”](#review-before-anything-is-saved) When the run finishes, a **review modal** opens over the suggestions. Every proposed translation is selected by default — **deselect anything you don’t want**, then apply. Only the values you keep are written back to your content. After you apply, a **fill report** appears above the table summarizing what was applied, skipped, and suggested. If a run fails, nothing is saved (the fill only ever proposes), and you can try again. ## Email templates included [Section titled “Email templates included”](#email-templates-included) Per-language email and notification template texts are part of the sweep too, under the **Notifications & emails** group — so a missing German booking-confirmation text shows up here alongside untranslated listings, and its **Open** link takes you to the template editor in **Settings → Notifications**. # Add-ons > Optional and mandatory extras guests can book alongside a stay — cleaning, breakfast, transfers and more. Add-ons are extras a guest can book alongside the stay — a cleaning fee, breakfast, an airport transfer, bike rental. You define them per listing on the **Add-ons** section of the listing detail view. ## Creating an add-on [Section titled “Creating an add-on”](#creating-an-add-on) Click **Create** and fill in: * **Name** — what the guest sees (per language). * **Description** — an optional longer explanation (per language). * **Price** — the amount, in your tenant currency. * **Pricing type** — how the price is applied: * **Per stay** — a single flat charge for the whole booking. * **Per day** — multiplied by the number of nights. * **Per guest** — multiplied by the number of guests. * **Per guest per day** — multiplied by guests and nights. * **Per unit** — the guest chooses a quantity (up to an optional maximum). * **Mandatory** — when on, the add-on is always applied and the guest can’t opt out (use it for unavoidable charges like a compulsory cleaning fee). When off, it’s optional at checkout. * **Maximum quantity** — only for *per unit* add-ons; caps how many the guest can select. * **Tax category** — whether the add-on is taxed as accommodation or as a service, which affects how it’s handled on invoices. See [Taxes](/docs/invoices/taxes/). ## Where guests see them [Section titled “Where guests see them”](#where-guests-see-them) Optional add-ons appear during checkout on the storefront, where guests choose the ones they want (and a quantity, for per‑unit add-ons). Mandatory add-ons are added automatically. Selected add-ons carry through to the booking total, payments and the guest’s invoice. ## Editing and removing [Section titled “Editing and removing”](#editing-and-removing) Select any add-on in the table to edit it, or use **Delete** to remove it. Changes apply to future bookings; add-ons already attached to existing bookings are unaffected. # Amenities, attributes and tags > Assign amenities, attributes, tags and distances to a listing, and how each surfaces as a storefront filter. Four listing sections describe what a property offers and drive how guests filter and sort on the storefront: **Amenities**, **Attributes**, **Tags** and **Distances**. Each draws from your tenant‑wide [catalog](/docs/catalog/overview/) — you define an item once and reuse it across every listing. ## Amenities [Section titled “Amenities”](#amenities) Amenities are the features a property offers — WiFi, pool, parking, and so on. On the listing’s **Amenities** section you pick from your amenity catalog: assigned amenities sit in one list, everything else in an “available” list, and you move items between them. Each amenity carries an icon, so it renders as an icon‑and‑label on the storefront listing page, and amenities become filter options guests can search by. To add a new amenity to choose from, create it in the catalog under **Amenities** — see [Catalog overview](/docs/catalog/overview/). ## Attributes [Section titled “Attributes”](#attributes) Attributes are **typed** facts about a property, each with a value you fill in per listing. An attribute’s type controls what you enter: * **Text** / **Multi‑line text** — free text. * **Number** — a plain number. * **Distance** — a distance value. * **Size** — an area value. * **Yes/No** — a boolean. On the listing’s **Attributes** section you assign an attribute and give it a value. Because attributes are structured, the storefront can use them in sortable, comparable filters. Define the available attributes (and their types) in the **Attributes** catalog. ## Tags [Section titled “Tags”](#tags) Tags are simple labels — “ski‑in/ski‑out”, “pet‑friendly”, “sea view”. On the listing’s **Tags** section you assign tags from your tag catalog by clicking to move them between assigned and available. Tags surface as filter pills on the storefront, letting guests narrow results to a theme. Manage the tag list in the **Tags** catalog. ## Distances [Section titled “Distances”](#distances) Distances tell guests how far the property is from points of interest — “500 m to the beach”, “3 km to the airport”. On the listing’s **Distances** section you add an entry by choosing a distance type from your catalog and entering the distance, or by defining a one‑off custom distance for this listing. Distance types that are marked *searchable* become storefront filters (for example “within 1 km of the beach”). See [Places and distances](/docs/catalog/places-and-distances/). ## How they reach the storefront [Section titled “How they reach the storefront”](#how-they-reach-the-storefront) Everything you assign here feeds the storefront’s search and filtering. Which filters actually appear, and how they’re grouped, is part of your storefront setup — see [Search and maps](/docs/storefront/search-and-maps/). # Content and media > The Texts, Property Facts, Images and SEO sections — the words, numbers and photos that make a listing. Four sections of the listing detail view hold the content guests see: **Texts**, **Property Facts**, **Images** and **SEO**. Each saves on its own. ## Texts [Section titled “Texts”](#texts) The **Texts** section holds the listing’s words: * **Title** — the main heading on the storefront. * **Listing key** — the URL‑friendly identifier (see [Listings overview](/docs/listings/overview/#the-listing-key)). The console checks availability as you type. * **Excerpt** — a short summary shown on search results and listing cards. * **Description** — the full rich‑text description on the listing page. Title, excerpt and description are **per language**: each has a tab for every enabled language, so you translate content in place. Next to each field is an AI menu — generate the field from the rest of the listing, or translate what you’ve written into the other languages while preserving formatting. You can always edit the result before saving. See [AI content generation](/docs/ai/content-generation-and-translation/) and [Multilingual content](/docs/languages/multilingual-content/). ## Property Facts [Section titled “Property Facts”](#property-facts) **Property Facts** captures the structured details: * **Property type** — apartment, house, and so on (see [Property types](/docs/catalog/property-types/)). * **Cancellation policy** — which policy applies to bookings of this listing. * **Capacity** — maximum guests (and optionally a breakdown of adults, children and infants). * **Rooms** — bedrooms, bathrooms and living space (m²). * **Stay limits** — minimum and maximum stay in days (set maximum to unlimited to remove the cap). * **Pets** — allowed, not allowed, or inherit the default; plus an optional maximum number of pets. * **Searchable** — whether the listing appears in storefront search and filters. * **Featured** — flag the listing as featured for promotion on the storefront. Stay limits also live here alongside the wider [stay rules](/docs/pricing/stay-rules/). ## Images [Section titled “Images”](#images) Strong photos are one of the biggest drivers of bookings. On the **Images** section you can: * **Upload** one or more photos at once. * **Reorder** them by dragging — order is how they appear in the gallery. * **Set the cover** — mark one image as the primary/cover image. A cover is required before you can publish. * **Label** each image (its alt text) and tag it, which helps accessibility and search. ## SEO [Section titled “SEO”](#seo) The **SEO** section controls how the listing appears in search engines and link previews: * **Search title** — up to 255 characters; falls back to the listing title if left blank. * **Meta description** — up to 500 characters. Both are per language, and a live preview shows roughly how the result will look. An AI menu can draft both from the listing content. Filling them in is a nice‑to‑have on the [completeness checklist](/docs/listings/overview/#the-completeness-ring) — good for polish, not required to publish. # Create a listing > Create a listing with AI import from a URL, text, PDF or photos — or fill it in manually. From **Listings**, click **New listing**. Reynt opens the create dialog on the **AI import** flow by default, because it’s the fastest way to get a well‑filled listing. A manual wizard is one click away if you’d rather type everything yourself. ## AI import (the default) [Section titled “AI import (the default)”](#ai-import-the-default) AI import reads whatever material you already have about a property and drafts the whole listing — texts, facts, amenities, images and SEO — for you to review before anything goes live. ### 1. Add your sources [Section titled “1. Add your sources”](#1-add-your-sources) Provide any combination of the following (at least one): * **Text** — paste a description, a listing from another site, or your own notes. * **URL** — a link to an existing listing page; Reynt reads the page. * **PDF** — upload a brochure or exposé (up to 10 MB). * **Photos** — up to 10 images (JPEG, PNG, WebP or GIF, 10 MB each). These feed visual analysis, and the imported photos become the listing’s gallery. Everything you upload at once — the PDF plus all photos — has to stay under **25 MB in total**, so the per-file limits above won’t all be reachable at the same time. The form adds it up as you go and tells you before you upload. More material means a richer draft. ### 2. Confirm the facts [Section titled “2. Confirm the facts”](#2-confirm-the-facts) The second step lets you pin down details the AI must **not** invent: * **Standard price** — the base nightly rate. * **Owner** — the property owner (marketplace mode only). * **Address** — street, city, postal code and country. Anything you enter here is applied to the listing before generation, so the draft is grounded in your real numbers and address rather than guesses. ### 3. Start the import [Section titled “3. Start the import”](#3-start-the-import) Click **Start import**. The listing is created immediately and the AI works in the background — you can leave the page. A banner on the listing tracks progress and tells you when the draft is ready to review. ### 4. Review and apply [Section titled “4. Review and apply”](#4-review-and-apply) When the import finishes, open **Review and apply**. The review screen shows everything the AI produced, fully editable: * Title, excerpt, description, customer info and SEO — with a tab per enabled language, so you can adjust each translation before applying. * Property facts: type, capacity, rooms, stay limits, pets, deposit, check‑in/out times and address. * Matched amenities and tags — deselect anything that doesn’t fit. * Imported photos — set the cover and edit labels. Nothing is written to the live listing until you act. Choose: * **Apply** — save the reviewed content to the listing, staying in draft. * **Apply & Publish** — save and, if the listing meets the readiness checks, take it live in one step. ## Manual creation [Section titled “Manual creation”](#manual-creation) Prefer to start from scratch? In the create dialog, switch to the manual wizard (the pencil / “manual” link). It’s a three‑step form: 1. **Basic info** — title and listing key. 2. **Capacity** — maximum guests, bedrooms, bathrooms and living space. 3. **Pricing** — a standard nightly price. Finishing creates the listing in draft. You then fill in the rest — images, description, amenities, location — from the [detail view sections](/docs/listings/overview/). You can switch back to AI import from the wizard’s first step at any time. ## What happens next [Section titled “What happens next”](#what-happens-next) However you create it, the listing starts as a **draft** and won’t appear on the storefront until you publish it. Work down the [completeness checklist](/docs/listings/overview/#the-completeness-ring), then [publish](/docs/listings/publishing-and-visibility/). # Listings overview > What a listing is in Reynt, the sections that make it up, and how the completeness ring tracks readiness. A listing is a single bookable property. It’s the record everything else hangs off — bookings, pricing, availability, images and storefront pages all reference a listing. You manage them under **Listings**. ## The listing detail view [Section titled “The listing detail view”](#the-listing-detail-view) Opening a listing takes you to its detail view, a single page with a left‑hand section menu. There is no separate “edit” screen — every section edits in place and saves independently. The sections are: * **Overview** — a dashboard: booking stats, occupancy, upcoming check‑ins, calendar‑sync status and quick actions. * **Texts** — title, listing key, excerpt and full description (per language). See [Content and media](/docs/listings/content-and-media/). * **Property Facts** — property type, capacity, rooms, stay limits, pets, cancellation policy and visibility flags. * **Images** — upload, reorder, set the cover and add labels. * **SEO** — search title and meta description with a live preview. * **Prices**, **Discounts**, **Fees**, **Add-ons**, **Pricing Info** — everything money. See [Pricing](/docs/pricing/base-and-seasonal/) and [Add-ons](/docs/listings/addons/). * **Amenities**, **Attributes**, **Tags**, **Distances** — what the property offers and how it’s filtered. See [Amenities, attributes and tags](/docs/listings/amenities-attributes-and-tags/). * **Location** — place, coordinates and address. * **Owner** — the property owner (marketplace mode only). * **Check-in** — check‑in and check‑out times. * **Calendar** and **Unavailability** — availability at a glance and blocked periods. See [Availability](/docs/availability/block-dates/). * **External Calendars** — iCal sync with other channels. See [iCal sync](/docs/availability/ical-sync/). * **Delete listing** — permanently remove the listing. ## The listing key [Section titled “The listing key”](#the-listing-key) Every listing has a **key** — a short, URL‑friendly identifier (letters, numbers, hyphens and underscores). It’s the listing’s stable handle: it forms part of its storefront web address and is how you recognise it in lists. You set it on the **Texts** section, where the console checks in real time that the key isn’t already used by another listing. Change it later if you need to, but be aware existing links to the old address will break. ## The completeness ring [Section titled “The completeness ring”](#the-completeness-ring) While you build out a listing, a **completeness** indicator tracks how filled‑out it is. It scores every field — from the critical ones down to the nice‑to‑haves — into a single percentage and a readiness level: * **Draft** — one or more *critical* items are still missing, so the listing can’t go live yet. * **Ready** — all critical items are in place; some recommended polish is still missing. * **Complete** — every recommended item is filled in too (100% also ticks off the nice‑to‑haves). The checklist groups what’s still missing into three tiers: * **Critical** — at least one image, a designated cover image, and at least one price. In marketplace mode an assigned owner is critical too. These gate publishing. * **Recommended** — property type, a description and excerpt, country and full address, map coordinates, an assigned place, and five or more images. * **Nice to have** — bedrooms, bathrooms, living space, amenities, tags, and SEO title and description. **Map coordinates** are a special case: on tenants with map search enabled (a map tile key is configured under **Settings → Storefront**), missing coordinates count as critical — the listing shows as **Draft** and can’t be newly published until they’re set. A listing that is already live stays visible, but without coordinates it drops out of the results as soon as a guest moves the storefront map (see [Search & maps](/docs/storefront/search-and-maps/)). Each missing item links to the section that fixes it, so you can work down the list. A listing can only be published once it reaches **Ready** — see [Publishing and visibility](/docs/listings/publishing-and-visibility/). ## Creating listings [Section titled “Creating listings”](#creating-listings) New listings default to an AI‑assisted import flow, with a manual path always one click away. See [Create a listing](/docs/listings/create-a-listing/). # Publishing and visibility > How draft, published, hidden and searchable listings differ, and the readiness checks that gate going live. Two independent controls decide whether a listing appears on the storefront and whether guests can find it in search: its **published** state and its **searchable** flag. A draft listing is never visible, no matter what. ## Draft vs. published [Section titled “Draft vs. published”](#draft-vs-published) Every listing starts as a **draft**: it exists only in the console and never appears on the storefront. A draft can’t take real bookings on the public site. Publishing takes it live. Open the listing and, from the header, click **Publish**. Reynt asks you to confirm — once you do, the listing goes online and becomes publicly reachable. A published listing shows a **Visible** badge; a draft shows **Hidden**. ## Readiness checks gate publishing [Section titled “Readiness checks gate publishing”](#readiness-checks-gate-publishing) You can only publish a listing that has passed its critical [completeness checks](/docs/listings/overview/#the-completeness-ring). While any critical item is missing, the listing stays at the **Draft** readiness level and the **Publish** button is disabled — hovering it lists exactly what’s missing. The critical items are: * At least one image * A designated cover image * At least one price * An assigned owner (marketplace mode only) Once those are in place the listing reaches **Ready** and you can publish. This is enforced on the server too, so there’s no way to push an incomplete listing live. Recommended and nice‑to‑have items don’t block publishing, but filling them in makes the storefront listing look complete. ## Unpublishing [Section titled “Unpublishing”](#unpublishing) To take a live listing offline, open it and click **Unpublish** from the header. It’s removed from the storefront immediately and its badge returns to **Hidden**. Existing bookings are unaffected. You can republish at any time (subject to the same readiness checks). ## Searchable vs. visible [Section titled “Searchable vs. visible”](#searchable-vs-visible) Publishing controls whether the listing exists on the storefront at all. **Searchable** — a switch on the **Property Facts** section — controls whether a published listing turns up in storefront search and filters. Turn it off to keep a listing reachable by direct link while hiding it from browse and search results; turn it on to include it. A listing shows a **Searchable** or **Not searchable** badge accordingly. There’s also a **Featured** flag on the same section for promoting a listing on the storefront. ## Retiring a legacy listing [Section titled “Retiring a legacy listing”](#retiring-a-legacy-listing) A property you no longer rent out — an owner who left, a flat you sold — should be **archived**, not deleted. Open the listing and click **Archive** in the header. An archived listing: * goes offline immediately (archiving unpublishes it for you) * disappears from your listing list, the calendar, the listing pickers in bookings and offers, search, your dashboard and your reports * still shows on every past booking and invoice that used it, so your history and your numbers stay intact * can be brought back at any time with **Restore** — which deliberately leaves it offline, so you can check its content before publishing it again To see your archived properties, open the filters on the listings page and tick **Archived listings**. They replace the live ones for as long as the filter is on. Reynt refuses to archive a listing while a stay on it is still running or upcoming, or while an open booking request offers it — you’d lose the property from your calendar while you still need it. Finish or cancel those first. ## Deleting a listing [Section titled “Deleting a listing”](#deleting-a-listing) Deletion, in the **Delete listing** section of the detail view, is permanent and only possible for a listing that has **never** been booked or offered — a typo, a test, an abandoned draft. The moment a listing has a booking or a booking request, Reynt refuses to delete it. This is deliberate: bookings and invoices read the property’s name and address from the listing itself, so deleting it would blank out your own records. Archive it instead. # Rental registration and the data export > Declare whether a unit needs a short-term rental registration number, record the number, and export your whole portfolio to Excel to see what is still missing. EU Regulation 2024/1028 has applied since **20 May 2026**. Where a unit sits in a designated short-term rental registration area, it needs a registration number, and that number must be **shown in the listing**. Reynt gives every listing two fields for this and warns you while either is unresolved. The declaration is yours to make. Reynt never infers it from the address, because in most Member States the registration area is drawn by the region or the municipality — and only you know whether a given unit falls inside one. ## Declaring a listing [Section titled “Declaring a listing”](#declaring-a-listing) Open the listing and go to **Location**. The **Short-term rental registration** section has two fields: **Registration requirement** — your declaration, with two answers: * *In a registration area — a number is required* * *Not in a registration area — no number needed* Left empty, the listing counts as **not yet declared**, which is a distinct state from either answer and the one Reynt asks you to resolve. **Registration number** — the number itself. It may lag the declaration: you can declare a unit as requiring registration while you are still waiting for the authority to issue the number. Reynt accepts that gap and warns about it rather than blocking you. Enter the number exactly as issued, including any leading zeros. Save the section when you’re done. Reynt records the date of your declaration and shows it as *Last declared on …*. ### Hungary: the number and the accommodation type [Section titled “Hungary: the number and the accommodation type”](#hungary-the-number-and-the-accommodation-type) Hungary is the strictest case, and its rules are older than the EU Regulation. Every accommodation must be registered in **NTAK**, which issues a 10-character registration number, and Hungarian law has required since **1 October 2020** that a unit offered through a booking portal display **both the NTAK number and its statutory accommodation type** — *magánszálláshely*, *egyéb szálláshely*, *panzió*, and so on — visibly to the guest. Two practical consequences: * **Every Hungarian unit needs a number.** There is no “designated area” question — the whole country is in scope, a Balaton cottage as much as a Budapest flat. Declare *In a registration area* and enter the NTAK number. * **The number alone is not enough.** A third field, **Statutory accommodation type**, appears under the number on Hungarian listings. Pick the type from the list — it holds the nine types the register uses — or type your own if the register spells yours differently. The storefront then shows both, side by side, exactly as § 5 (4) requires. Check the same on any other portal you list on. The type is stored and displayed **in Hungarian, untranslated**, on every language version of your storefront. That is deliberate: the duty is to show the term the register records, and a translated paraphrase would not identify the unit’s type to anyone checking. **Filling many at once.** If most of your Hungarian units share a type, filter the listings list to Hungary and use **Add accommodation type to …** in the toolbar. It writes the type you pick onto every Hungarian listing that still has none, and never touches one that already carries a type — so run it for the common case, then correct the exceptions individually. **Only one number is displayed, and it is easy to pick the wrong one.** A Hungarian accommodation carries three identifiers: | Identifier | What it is | Goes in Reynt? | | -------------------------------------------- | --------------------------------------------------------------- | --------------------------- | | NTAK registration number (10 characters) | Issued by NTAK | **Yes — this is the field** | | *Nyilvántartási szám* | Issued by the notary (*jegyző*) when the provider is registered | No — administrative only | | *Adatszolgáltatási azonosító* (8 characters) | The pre-October-2020 code, still used for data reporting | No | The notary’s register is also where the statutory accommodation type is recorded, so you can read the NTAK number and the correct type off the same document. ### Countries that register countrywide [Section titled “Countries that register countrywide”](#countries-that-register-countrywide) Some Member States run a single national registry covering the whole territory — Hungary (NTAK), Italy (CIN), Portugal (AL), Greece (AMA), Croatia (eVisitor). When the listing’s country is one of these, the section says so and names the expected registry, because there the “which area?” question has no local answer: every unit in the country needs a number, whichever municipality it sits in. *Not in a registration area* is rarely the right answer for such a listing. Reynt still does not preselect the requirement for you. The declaration carries legal weight, and a prefilled statement is not a statement anyone made. Where the scheme is regional or municipal instead — Germany’s *Zweckentfremdung* rules, Austria’s Vienna and *Freizeitwohnsitz* rules, France, the Netherlands, Belgium, Spain — whether a number is needed genuinely depends on the address, and you have to check the local scheme. ### Germany: check the published list [Section titled “Germany: check the published list”](#germany-check-the-published-list) In Germany, running a registration procedure is voluntary for each *Land* and municipality. The **Bundesnetzagentur** — the national authority for the EU data exchange — publishes the list of those that have introduced one, and Reynt links straight to it from the registration section whenever a listing’s country is Germany. Look your unit’s location up in that list, then record the answer. If the area is not on it, *Not in a registration area* is the correct declaration today; the list grows as more municipalities opt in, so it is worth re-checking when you next revisit a listing. Note that the number itself always comes from the **municipality**, never from the Bundesnetzagentur. ### Austria: no registration procedure at all, for now [Section titled “Austria: no registration procedure at all, for now”](#austria-no-registration-procedure-at-all-for-now) Austria had the same choice and **no federal province has taken it up**. According to the Federal Ministry of Economy, Energy and Tourism (BMWET), the Regulation is initially not implemented in any *Bundesland*, which means there is no registration requirement for hosts and no number to show in a listing anywhere in the country. So for an Austrian listing, *Not in a registration area* is the correct declaration today, and Reynt says so in the registration section along with the date it last checked. Two things to keep in mind: * **This can change.** Each province decides for itself and may introduce a procedure later. If one does, the declarations you make now stop being true — so treat the date in the notice as a “checked on”, not a guarantee. * **Other Austrian rules still apply.** Vienna’s building-code permit for short-term letting, the Tyrolean and Salzburg *Freizeitwohnsitz* registers, the trade and private-room-letting rules — none of these are affected by the EU Regulation, and none of them issue a number that belongs in this field. Leave the registration number empty. ## Where Reynt warns you [Section titled “Where Reynt warns you”](#where-reynt-warns-you) **On the listing row.** The listings list shows a badge — *Registration not declared*, *Registration number missing*, or *Accommodation type missing* — on any listing with something outstanding. A settled listing shows no badge at all: the badge’s absence means “fine”, never “unknown”. **On the dashboard.** Two alerts count your **published** listings with an unresolved registration and link straight to them: * *… published listings have no registration declaration* * *… published listings are waiting for their registration number* Each alert clears once every published listing is resolved, and re-appears for listings you create later. **In the completeness ring.** Registration is a *recommended* completeness item. It holds a listing below **Complete**, but it does not block publishing — see [publishing and visibility](/docs/listings/publishing-and-visibility/). **To review them as a group,** open the listings list, click the filter button and set **Rental registration (EU 2024/1028)** to *Not declared*, *Number missing*, *Accommodation type missing*, or *Registration outstanding* for any of them. ## On the storefront [Section titled “On the storefront”](#on-the-storefront) Once a number is saved, the listing’s storefront page shows it as *Registration number: …*, which is what the Regulation requires. It sits as a quiet line at the foot of the page — the Regulation says the number must be displayed, not where — so it stays out of the way of what a guest is actually reading. Where an accommodation type is required and recorded, it appears on the same line after the number. Nothing is displayed while the number field is empty. ## Exporting your portfolio to Excel [Section titled “Exporting your portfolio to Excel”](#exporting-your-portfolio-to-excel) Walking through listings one at a time is fine for a handful and impractical for a few hundred. The listings list has an **Export** button that downloads your whole portfolio as an Excel workbook. The export covers **exactly the listings the list is currently showing** — so filter or search first, and the sheet matches. Filter to *Registration outstanding* and you get only the listings that still need attention. The workbook has four sheets: | Sheet | What it holds | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **README** | The file opens here: a directory of the sheets, what every column means, and which columns a future import will read back. | | **Listings** | One row per listing: identity, registration status, number and accommodation type, completeness, address, owner, capacity, stay rules, publication state, and image/price counts. | | **Prices** | Each listing’s season prices. | | **Owners** | Contact details of the owners behind the exported listings. Only included if your role can read owners; bank and tax details are never exported. | Three columns on the **Listings** sheet answer “what is missing?” directly: * **missingCritical** — items that block publishing (photos, a cover image, a price, and an owner in marketplace mode) * **missingRecommended** — items that hold the listing below **Complete**, registration among them * **missingOptional** — the last mile to 100% Sort or filter on those in Excel and you have a work list. `completenessPercent` and `completenessLevel` are computed fresh at export time, so they always reflect the listing as it stands. The **key** column identifies each listing. Leave it alone — a future import will use it to match rows back to listings. Note If your portfolio is larger than one export can carry, the README sheet says so in its first lines. Narrow the filters and export again to cover the rest — a partial export never looks complete. ### What the export is not [Section titled “What the export is not”](#what-the-export-is-not) It is a **read-only snapshot**. Editing a cell and keeping the file changes nothing in Reynt; there is no upload yet. Bulk *entry* of registration numbers is planned as a follow-up, and until it ships, numbers are entered per listing on the **Location** tab. If you are looking for the JSON export under **Data Transfer**, that is a different tool: it moves configuration and content between tenants, not listing data for reading in a spreadsheet. # How payments work > How money flows on a booking — payment legs, statuses, and the difference between direct and marketplace mode. Every confirmed booking has one payment record that tracks what the guest owes, what has been received, and how the money is split between you and (in marketplace mode) the property owner. This page explains the vocabulary you’ll see across the console; the day-to-day tasks live in [Payment providers](/docs/payments/providers/) and [Partial payments and refunds](/docs/payments/partial-payments-and-refunds/). *When* a guest can pay, what happens when they don’t, and whether unpaid dates are eventually let go are all one rule — see [When you collect](/docs/payments/when-you-collect/). ## Payment legs [Section titled “Payment legs”](#payment-legs) A booking’s total is collected in one or more **legs**. Which legs exist depends on how you’ve set up payments: * **Down payment** — a share of the total collected upfront when the booking is created. Not to be confused with the listing’s **security deposit**: a down payment is real money on the booking and counts toward the total, whereas the security deposit sits outside the payment legs entirely — see [Discounts and fees](/docs/pricing/discounts-and-fees/). * **Balance** — the remaining amount, due closer to check-in. * **Full payment** — the whole total in a single leg (when no down payment split is used). * **Supplement** — an extra charge added when a booking is modified upward. * **Tourist tax** — a city/tourist tax leg, when the listing’s place charges one. See [Taxes and VAT](/docs/invoices/taxes/). Each leg is a line on the booking’s **Payment** card and in the **Payments** list, with its own amount, due date, and status. ## Payment statuses [Section titled “Payment statuses”](#payment-statuses) A booking’s payment moves through these statuses: * **Awaiting payment** — due, but nothing received yet. * **Partially paid** — some money in (e.g. the down payment is paid but the balance isn’t). * **Paid** — the full amount is settled. * **Cancelled** — the booking was cancelled and outstanding charges voided. Individual legs (transfers) show as **Pending** or **Paid**, with a *Partially paid* badge once part of a leg has been received. ## Direct vs marketplace mode [Section titled “Direct vs marketplace mode”](#direct-vs-marketplace-mode) Your **operator mode** is set when your account is created. You can see it under **Settings → Payments**, where the *Operator Mode* section is read-only — there is no switch for it in the console. If you picked the wrong one, contact Reynt: a workspace can still be moved while it is empty. Once it has bookings, payments, invoices or guest registrations the mode is fixed for good, because refunds and reporting are derived from it. It decides whether you’re renting your own properties or operating on behalf of owners: * **Direct mode** — all money goes to you (the operator). There is no owner split and no commission. * **Marketplace mode** — the booking is split between you and the property owner. You keep a **platform commission** (the *Commission Rate*, e.g. 15%, under **Settings → Payments**) and the owner receives the rest. ## Who collects the money [Section titled “Who collects the money”](#who-collects-the-money) **Settings → Payments** asks this above the payment methods, because it isn’t a property of a method — it’s a term of your agreement with an owner. It decides who the guest’s contracting party is, who invoices them, whose VAT applies, and whether your commission is netted at source or billed afterwards. There are three answers: * **Everything to you** — the guest pays you the whole booking. You keep your commission and pay the owner their share yourself, outside Reynt. * **Everything to the owner** — the guest pays the owner the whole booking. You invoice the owner for your commission afterwards. * **Split** — the guest pays twice: your commission to you when they book, the rest to the owner. Nothing you owe the owner ever passes through your account. Under a split, one further checkbox asks whether **the owner takes their share in cash** — handed over at check-in instead of travelling on a payment method. Your commission is still paid online when the guest books; Reynt records what the owner is owed and you confirm it arrived. It’s a property of the *owner’s* leg only: your own leg is never cash, and a down payment handed over at arrival would secure nothing. Confirming is genuinely optional, and nothing pushes you to do it. A cash leg is never chased — the guest hands it over at arrival, so there is nothing to remind them about — and it is left out of *Overdue Payments* too, because a stay that has already happened would otherwise sit there as a debt forever. That is deliberate: the money went from the guest straight to the owner and never touched your account. What you are owed, the commission, arrived when the guest booked. The owner’s [settlement invoice](/docs/invoices/creation-and-numbering/) states the cash amount whether or not you confirmed it, so an owner who did not receive it has a document to query — which is where you would hear about it. In direct mode there is exactly one settlement and no owner to route to, so the question isn’t shown. Separately, each **payment method** you enable — Bank Transfer, Mollie — has its own panel, and one of them is marked **Default**: that’s the method new bookings start on. In the split arrangements the **down payment equals your commission** and goes to you, while the **balance goes to the owner**. The commission also drives the [owner settlement invoice](/docs/invoices/creation-and-numbering/). ### When one owner is different [Section titled “When one owner is different”](#when-one-owner-is-different) What you set here is your **default**, not a rule. In marketplace mode an individual owner can collect differently — see [Payment terms for one owner](/docs/customers-and-owners/owners/#payment-terms-for-one-owner). Their bookings are quoted, invoiced and settled on their own terms, from the price a guest sees on your storefront through to the payment record; everyone else keeps following your default. ## What a guest chooses [Section titled “What a guest chooses”](#what-a-guest-chooses) If you have **more than one payment method switched on**, a guest picks between them at checkout. With one method there is nothing to choose and Reynt shows no such question, which is what most workspaces see today. Two things a guest never chooses: * **Who collects the money.** That is a term of your agreement with the owner, not a checkout preference, so every option they see settles the same way. * **An option you cannot honour.** Reynt checks each method is actually payable before showing it — Mollie on an account that cannot yet accept payments simply does not appear. It re-checks when the guest submits, so an account cleared in the meantime cannot slip through. When a guest accepts an **offer** you sent, they can only pick a method that keeps the payment schedule the offer email already quoted. Otherwise the amounts they were told would change after the fact. ## Where you see payments [Section titled “Where you see payments”](#where-you-see-payments) * **Dashboard → Money** — the **Outstanding Payments** and **Overdue Payments** cards roll up what’s still owed across every booking. The figures net out any not-yet-collected price reduction from a downward modification, so they agree with what each booking’s own Payment card shows as owed rather than the original (gross) charge. Cash-on-arrival legs are **not** counted — that money never comes to you, so a stay that has already happened would sit there as a debt you cannot collect. The booking’s own Payment card still shows it. * **Booking detail → Payment card** — the money flow for one booking. Each line reads *payer → recipient via method* (e.g. the guest → Operator via bank transfer), with the total due, total paid, and remaining, and lets you mark a leg paid. A *Partially paid* badge and a “received X of Y” line appear once part of a leg is in. * **Finance → Payments** — a list of every booking payment with its **Reference**, **Provider**, **Amount**, **Status**, and **Created** date. Filter by status to find what’s outstanding. * **Payment detail** — open a payment to see the parties (payer, listing, owner), each transfer’s money flow, and the actions for recording payments, refunds, and discharging refunds. The booking’s **Activity → Payments** timeline records every individual charge, receipt, refund, and void with its cause and target, so you always have a full audit trail of the money movements on a booking. ## “A booking’s payment record doesn’t add up” [Section titled ““A booking’s payment record doesn’t add up””](#a-bookings-payment-record-doesnt-add-up) Every night we check each booking’s payment history against what it says is owed. If the two disagree, a **critical** alert appears on your dashboard naming the bookings and the amount involved. It is the only critical alert there, and the distinction is worth keeping: every other alert is a task you have not done yet, while this one says two records of the same money contradict each other. * **It is a night-old answer.** The alert prints when it was last checked — something you fixed this morning is still listed until tomorrow’s run. * **There is nothing to dismiss.** Repair the booking and the alert is gone on the next run. That is deliberate: an acknowledge button would let a real discrepancy be waved away instead of fixed. * **Open the booking’s Activity → Payments timeline** to see which entries disagree. If it is not obvious, this is worth asking support about rather than adjusting by hand. # Partial payments and refunds > Record partial payments and top-ups, handle overpayments, and discharge refunds on bank-transfer bookings. Bank-transfer bookings rarely settle in one clean payment. Reynt lets you record exactly what arrived — including part payments, top-ups, and overpayments — and handle money you need to send back. All of this happens on a booking’s **Payment** card or the **Payments** detail page. ## Partial payments [Section titled “Partial payments”](#partial-payments) When a guest pays less than a leg’s open amount, use **Record payment** and enter the amount that actually arrived. The leg stays **Pending** with a *Partially paid* badge and a “received X of Y” line, and the booking’s overall payment goes **Partially paid**. From then on, all payment instructions Reynt shows or emails the guest — the reminder, the “send instructions” email, and the EPC QR code — request the **remaining balance**, not the original figure, and can show how much you’ve already received. The guest still gets a payment-received confirmation for the partial amount. ## Top-ups [Section titled “Top-ups”](#top-ups) A partially-paid leg can be recorded against again — receipts accumulate until the leg is fully covered. Once a leg is fully **Paid**, it can’t be marked again. ## Overpayments [Section titled “Overpayments”](#overpayments) If a guest sends more than the open amount, record the full figure anyway. Reynt accepts it and the leg shows an **Overpaid by X** badge. You can then return the excess as a refund. ## Correcting a recorded receipt [Section titled “Correcting a recorded receipt”](#correcting-a-recorded-receipt) Recorded a bank-transfer receipt for the wrong amount? Every entry on the **Recorded payments** card (on the payment detail page) has a **Correct amount** action. Enter what actually arrived — the original entry stays visible, greyed out and labelled *corrected*, so the correction reads as an audit trail rather than a silent edit. * The payment’s status re-derives from the corrected figure in either direction: reducing an entry can turn **Paid** back into **Partially paid**, and raising an understated one can turn **Partially paid** into **Paid**. * Setting the amount to **0** removes the receipt entirely — use this when the money never actually arrived. * A linked invoice’s payment status re-syncs to match. * A receipt can only be corrected once. Correcting the result of an earlier correction targets that new entry, not the original. ## Ad-hoc refunds [Section titled “Ad-hoc refunds”](#ad-hoc-refunds) To return money you’ve already received — an overpayment, or a goodwill gesture — use **Record refund** on the paid or overpaid leg. Enter the amount and the party it comes from. This records a refund **obligation**; it doesn’t move money by itself. You can never record a refund for more than has actually been received on that party. Once you’ve wired the money back, settle the obligation: * Open the *Open refunds* card (on the payment detail page or the booking’s **Activity → Payments** timeline). * Choose **Mark as refunded**, and enter your bank’s transfer reference. This keeps the booking’s ledger honest about what’s still owed versus what’s already been returned. A refund can only be discharged for its full recorded amount — Reynt won’t let you settle more than the money actually held for that party, even in part. **On Mollie payments there is nothing to wire.** Where the leg was paid through your Mollie checkout, the *Open refunds* card offers a **Refund via Mollie** action instead of the manual discharge above: Reynt asks Mollie to return the money and records the discharge when it confirms. The refund still goes back through the organization that received it — there is never a clawback across organizations, so an owner-collected leg is refunded from the owner’s account, not yours. ## Refunds from cancellations and modifications [Section titled “Refunds from cancellations and modifications”](#refunds-from-cancellations-and-modifications) Refunds also arise automatically when a booking changes: * **Modifying a booking downward** (including a partial cancellation — see [Modify a booking](/docs/bookings/modify-a-booking/)) records a refund obligation for the difference (no invoice document is created or corrected automatically). * **Cancelling a booking** refunds what was paid according to the applicable cancellation policy. Whether that obligation is money you actually owe back depends on what the guest had already paid: * If the reduced amount **hadn’t been paid yet**, it’s a **credit against the charge** — what’s owed simply drops, and there’s nothing to send back. It does not appear in *Open refunds* and can’t be discharged. * If the guest **had already paid** that amount, it’s a real payout and lands in *Open refunds* for you to discharge with **Mark as refunded**, exactly like an ad-hoc refund. If they’d only paid part of what was reduced, only that paid share is payable — Reynt caps the discharge at what was actually received. The refund amounts and how the policy is applied are covered in [Cancellations and refunds](/docs/bookings/cancellations-and-refunds/) and [Modify a booking](/docs/bookings/modify-a-booking/). # Payment providers > Set up bank transfer and Mollie under Settings → Payments, and control what guests can pay with. You enable and configure payment under **Settings → Payments**. **Bank Transfer** and **Mollie** are the methods you turn on, and [who collects the money](/docs/payments/overview/#who-collects-the-money) decides how it is routed. In marketplace mode you can also have the owner take their share as cash on arrival instead of by transfer. ## Bank transfer [Section titled “Bank transfer”](#bank-transfer) Bank transfer is the primary, production-ready method. Turn on **Enable Bank Transfer**, then fill in: * **Account holder**, **IBAN**, and **BIC / SWIFT** — the account guests pay into. These are required before bank-transfer payments can be requested; the console warns you if they’re incomplete. * **Down payment** (percentage) — how much of the total the deposit is. * Three day fields decide when each leg falls due. Each one names the date it counts from: * **Down payment due (days after booking)** counts *forward* from the day the booking is created. If you take no down payment, it sets the due date of the full amount. * **Down payment at the latest (days before check-in)** counts *backwards* from arrival and caps the field above, so a booking made shortly before check-in still has to pay before the guest arrives. * **Balance due (days before check-in)** counts *backwards* from arrival. No due date is ever put in the past — a last-minute booking simply falls due immediately. (Under a marketplace split, the down payment percentage is locked to your commission rate.) The **Payment reference prefix** (default `P`) is used to build the reference guests quote on their transfer. ### What the guest sees [Section titled “What the guest sees”](#what-the-guest-sees) For each pending bank-transfer leg, Reynt shows the guest **payment instructions**: the reference, the amount, the due date, your bank details, and an **EPC QR code** (“Scan to pay”) they can scan with their banking app. Guests also receive these by email — see [Notifications and email](/docs/communication/notifications-and-email/). ### Confirming receipt [Section titled “Confirming receipt”](#confirming-receipt) Bank transfers arrive out-of-band, so you confirm them yourself. On the **Payment** card of a booking, or on the **Payments** detail page: * **Mark as Paid** records a full leg as received. * **Record payment** records a partial amount or a top-up (see [Partial payments and refunds](/docs/payments/partial-payments-and-refunds/)). * When you owe money back, the *Open refunds* card lists undischarged refunds with a **Mark as refunded** action — record it after you’ve wired the money. ## Mollie [Section titled “Mollie”](#mollie) Guests pay through a hosted Mollie checkout — card, iDEAL, Bancontact and the other methods your Mollie account has enabled. **The money goes straight to your own Mollie organization** — Reynt never holds your guests’ money and is not a party to the payment; it only creates the payment on your behalf. ### Connect your Mollie organization [Section titled “Connect your Mollie organization”](#connect-your-mollie-organization) Under **Settings → Payments**, use the **Mollie connection** card: 1. **Connect Mollie** sends you to Mollie to authorize Reynt. If you don’t have a Mollie account yet, create one there first. 2. Come back and the card shows your **Organization** and **Payment profile**, with a status: * **Ready** — Mollie payments can be offered. * **Awaiting Mollie** — connected, but Mollie has not cleared the account to accept payments yet. Finish the remaining steps in your Mollie dashboard, then hit **Re-check status**. * **Not finished** — a connection was started but never completed. Connect again. 3. Turn on **Accept Mollie payments**. This requires a connected organization that can actually accept payments. If the card says Mollie **is not set up on this installation**, no Mollie Connect app is configured for the platform — that is nothing you can fix from here; ask your platform administrator. **Disconnecting** stops new bookings from being paid through Mollie. Payments already made are unaffected and stay with your Mollie organization. ### When the guest gets the payment link [Section titled “When the guest gets the payment link”](#when-the-guest-gets-the-payment-link) **When the payment link is sent** controls timing: * **Immediately** — the guest gets the link as soon as the booking is published. * **Closer to arrival** — the link is held back until a set number of days before arrival, which is useful for bookings made far in advance. Set **Days before arrival** alongside it; availability is checked hourly. Unlike bank transfer, you do **not** confirm Mollie payments yourself — Mollie tells Reynt when the money arrives and the booking’s payment state updates on its own. Refunds are likewise executed against Mollie rather than recorded after a manual wire. ### In marketplace mode [Section titled “In marketplace mode”](#in-marketplace-mode) Whose Mollie organization each leg lands on follows [who collects the money](/docs/payments/overview/#who-collects-the-money) — the Mollie rail carries out that answer rather than restating it: | Who collects | Where the money goes | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Everything to you** | The guest pays the whole booking in one checkout, into your Mollie account. | | **Everything to the owner** | The whole booking goes to the owner’s Mollie account; you invoice your commission separately. | | **Split** | Two online payments: your commission to your account at booking, the rest to the owner’s before arrival. **The owner needs [their own Mollie account](/docs/customers-and-owners/owners/#connecting-an-owners-mollie-account).** | | **Split**, with *the owner takes their share in cash* | Your commission is paid online at booking; the guest pays the owner the rest in cash at check-in. The owner needs no Mollie account. | An individual owner can be on a different one of these to your default — see [Payment terms for one owner](/docs/customers-and-owners/owners/#payment-terms-for-one-owner). ## Test payments (demo mode) [Section titled “Test payments (demo mode)”](#test-payments-demo-mode) **Test payments** is a rail that moves no money: the guest settles the whole booking by clicking once on a checkout page Reynt hosts for you. It needs no credentials and no bank details, and every charge, receipt and refund is recorded in the ledger exactly like a real one — so invoices, modifications and settlement all behave normally. It is not a way to take payments. While it is on, **your storefront serves nobody**: the public sees a maintenance page, and you reach your own site through the console. That is what makes it safe to switch on, and it is why the go-live checklist asks you to leave demo mode rather than to configure payments. Turn it on from the **Go live** page rather than here — the card there also adds the example content that gives you something to book. See [Demo mode](/docs/getting-started/demo-mode/). ## What guests can pay with [Section titled “What guests can pay with”](#what-guests-can-pay-with) Guests are offered whichever method applies to the booking. With bank transfer they get payment instructions and a QR code; with Mollie they get a hosted checkout link; and when the owner takes their share in cash, the owner’s balance is instead collected on arrival — there’s no separate configuration for it, it follows from how that booking is settled. Which one applies is decided per booking, from that listing’s owner’s [payment terms](/docs/customers-and-owners/owners/#payment-terms-for-one-owner) where they have their own, and otherwise from your default. # When you collect > One rule for when a guest can pay, which parts of the price they are asked for, and what happens when a payment is late. Every payment method used to bring its own timing: online checkout had one setting, bank transfer was decided by which rows your booking emails happened to show. **Settings → Payments → When you collect** replaces all of that with one rule that applies to every method you have switched on. It sits above the payment methods on that page deliberately. When you collect is a term of your business, not a property of a card processor. Leaving it off is a real choice, not an unfinished one: each method keeps the timing it has today and nothing changes. ## When a guest can pay [Section titled “When a guest can pay”](#when-a-guest-can-pay) | Setting | What it means | | ------------------------------------ | ---------------------------------------------------------------------------------------------------- | | **As soon as the booking exists** | The moment a booking is published, tentative or confirmed. This is how things work with no rule set. | | **Only after I confirm the booking** | Nothing to pay while you are still deciding. The payment link appears the moment you confirm. | | **Shortly before arrival** | Payment opens a number of days before check-in, checked hourly. | The charge itself is always created when the booking is published — the price is fixed at that point either way. What this setting changes is whether the guest can act on it yet. ### What it can hold back, and what it can’t [Section titled “What it can hold back, and what it can’t”](#what-it-can-hold-back-and-what-it-cant) * **Online payment (Mollie) and test payments** — held back completely. No checkout session is opened, so there is no link to follow. * **Bank transfer** — **advisory only.** Your guest already has your IBAN and can transfer whenever they choose. The rule stops payment *links* and online checkout; it cannot stop a wire. * **Cash on arrival** — not applicable. It is due at check-in by definition. The console says this next to the setting rather than leaving you to discover it from a guest who wired the money anyway. ### Changing it later [Section titled “Changing it later”](#changing-it-later) **Loosening takes effect on its own.** Move from “only after I confirm” to “as soon as the booking exists” and the waiting bookings get their payment links within the hour. **Tightening applies to links that have not gone out yet.** A guest already holding an online payment link keeps it — we do not take a link away from someone who may be part-way through paying. If you need to stop a specific payment, cancel or change that booking rather than the rule. ## Which parts of the price you ask for [Section titled “Which parts of the price you ask for”](#which-parts-of-the-price-you-ask-for) The classic arrangement — a down payment while you decide, the balance once you confirm — is one switch: **Ask for different amounts before and after you confirm**. Pick what a tentative booking is asked for, and what a confirmed one is asked for, from *Down payment*, *Balance* and *Full amount*. It applies to every payment method, and it changes what the guest is asked for, not what the booking costs. The price and its due dates were fixed when the booking was published. Leave the switch off and each booking email decides for itself, as before. ## When a payment is late [Section titled “When a payment is late”](#when-a-payment-is-late) Once a payment passes its due date, a daily check does one of three things: | Setting | Who hears about it | | -------------------------- | ---------------------------------------------------------------------------------- | | **Nothing** | Nobody. Due dates are recorded and nothing acts on them. | | **Tell me, not the guest** | You do — an entry in your bell. No guest is ever emailed. **This is the default.** | | **Remind the guest** | You still get the bell entry, and the guest gets a reminder email. | The middle rung exists so you can watch this run on your own bookings for as long as you like before deciding a guest should hear from it. Four things about the check are worth knowing before you switch it on: * **The first run only starts the clock.** It sends nothing. A due date that passed while nobody was watching is a bill nobody sent, not a guest ignoring a reminder. * **It never reaches back.** Payments more than 30 days past due are out of scope on every run, so a catch-up after a quiet spell cannot mail about last spring. * **One booking is one conversation.** Three late payments on the same booking make one email naming the total, not three. * **It won’t chase what the guest can’t pay.** A payment your own rule has not opened yet is never chased. Guests are reminded three days before a payment is due, then once the day after it was due and again a week later. Those timings are fixed — the question worth setting is whether you chase at all and whether the guest hears it, which is the table above. You can switch the two reminder emails off individually, and edit their wording, under **Settings → Notifications**. ## Letting the dates go when nobody pays [Section titled “Letting the dates go when nobody pays”](#letting-the-dates-go-when-nobody-pays) **Release the dates if nobody pays** is the “we hold the dates until the down payment lands” arrangement. It is off unless you switch it on, and it is the only setting on this page that undoes a booking, so it is worth reading in full. Set a number of days, and a tentative booking still unpaid that long after its due date is **cancelled** and its dates freed. Cancelled, not just un-held: your cancellation policy applies, the ledger records it, and the guest gets the same cancellation email they would if you had pressed the button yourself. Freeing the dates without cancelling would leave a live booking with no room behind it, which is a double booking waiting to happen. What it will never touch: * **A booking that has paid anything at all.** Someone who paid part of it is a conversation, not a sweep. * **A confirmed booking.** Only tentative ones are eligible. * **A booking held for any other reason** — a hold waiting on your decision has no deadline. * **Anything older than the same 30-day window** the late-payment check uses. You get a bell entry the day **before** a booking is due to be released, and another when it happens. The option only appears once you have chosen to do something about late payments — if your answer there is “nothing”, you have already answered this one. ## Where you see the result [Section titled “Where you see the result”](#where-you-see-the-result) * **Dashboard → Money** — the *Overdue Payments* card. * **Your bell** — overdue payments, upcoming releases, and releases that happened. * **Settings → Payments**, at the top of the page — a plain answer to whether guests are actually being asked to pay at all, with a link to whatever is standing in the way. Five separate settings decide it and four of them never mention money, so it is worth a look after any change here. # Prices and seasonal periods > How Reynt builds a nightly rate from recurring and year-specific price periods. Reynt does not use a single base price with multipliers. Instead, each listing has a list of **price periods**, and every period carries an absolute rate per night. When a guest picks dates, Reynt looks up the period that covers each night and charges that rate. Open a listing and select the **Prices** tab to manage them. ## Price periods [Section titled “Price periods”](#price-periods) Click **Create** to add a period. Each one has: * **Season name** — optional label (e.g. “High season”), shown in the price breakdown. * **Period** — the date range the rate applies to. * **Price per night** — the nightly rate, in the listing’s currency. * **Valid from** — see [scheduling a price change](#scheduling-a-change) below. ### Recurring vs. year-specific [Section titled “Recurring vs. year-specific”](#recurring-vs-year-specific) The **Recurring** switch decides whether the period repeats every year: * **Recurring (on)** — pick a start and end **day and month** with no year. The period applies every year and is tagged **Every year** in the table. This is the default and covers most pricing. A recurring range whose end falls before its start simply wraps into the following year (e.g. 1 October – 31 March). * **Recurring (off)** — pick concrete calendar dates, so the period applies to **one year only** (tagged e.g. “2026 only”). If the range crosses a year boundary, both ends keep their year (e.g. “2026–2027 only”) — useful for a specific Christmas/New-Year window. ### Per-guest-count prices [Section titled “Per-guest-count prices”](#per-guest-count-prices) Turn on **Custom prices per guest count** to charge a different nightly rate depending on how many guests book — for example a lower rate for 2 guests than for the listing’s maximum. Leave a guest count blank to fall back to the period’s price. ## How the nightly rate resolves [Section titled “How the nightly rate resolves”](#how-the-nightly-rate-resolves) For each night of a stay, Reynt finds the price period covering that night. When periods overlap, three rules decide which one wins: 1. **Year-specific beats recurring** — a period set for a specific year always overrides a recurring one for the same dates. 2. **Most recently effective wins** — a period with a later **Valid from** date takes priority. 3. **Narrower beats broader** — a short summer window overrides a year-round period in the days they share. Use the **Price Tester** at the bottom of the tab to pick any date and confirm which period (and rate) Reynt will apply. ### Scheduling a change [Section titled “Scheduling a change”](#scheduling-a-change) On a recurring period, **Valid from** lets you schedule a rate change without disturbing existing quotes: the new price only applies to nights on or after that date. Set up next year’s higher rate today, and current bookings keep the old rate. ## Listing currency [Section titled “Listing currency”](#listing-currency) By default a listing prices in the tenant’s default currency. The **Currency** card on the Prices tab overrides it per listing (EUR, USD, CHF or GBP) — handy for a cross-border portfolio. Leave it on **Inherit tenant default** unless the property genuinely prices in another currency. ## The “from” price on the storefront [Section titled “The “from” price on the storefront”](#the-from-price-on-the-storefront) Search cards and listing pages show a single lead price derived from these periods. How it’s derived is a storefront-wide setting under **Storefront → Appearance → Listing Display → Lead Price Aggregation**: * **Average nightly rate (Ø)** — the average across the year’s periods. * **Cheapest rate (from …)** — the lowest period rate. This choice also drives what the storefront price filter and price sorting compare against. ## Related [Section titled “Related”](#related) * [Stay rules](/docs/pricing/stay-rules/) — minimum/maximum nights and arrival/departure limits. * [Discounts and fees](/docs/pricing/discounts-and-fees/) — length-of-stay discounts, early-bird offers, deposits and pet fees. # Discounts and fees > Automatic length-of-stay and early-bird discounts, security deposits, and pet fees. Beyond the nightly rate, a listing can apply automatic discounts and charge a couple of fees. Both live on the listing detail view. ## Automatic discounts [Section titled “Automatic discounts”](#automatic-discounts) Open a listing and select the **Discounts** tab. A discount reduces the price whenever its conditions match — the guest doesn’t need a code (that’s [promo codes](/docs/pricing/promo-codes/)). Each discount has: * **Summary** — the label shown on the guest’s price breakdown (e.g. “Weekly discount”). * **Description** — optional longer text shown at checkout. * **Type and value** — **Percentage**, **Fixed Amount** (once per booking), or **Fixed per Day** (per night). * **Conditions** — the rules that decide when it applies. ### Conditions [Section titled “Conditions”](#conditions) Add one or more conditions; **all of them must match** for the discount to apply. Leave the list empty and the discount **always applies**. Available conditions: * **Length of stay (nights)** — e.g. 7 nights or more. * **Number of guests** — e.g. at least 4 guests. * **Days before check-in (early bird)** — how far ahead the booking is made. * **Check-in weekday** — only for stays starting on chosen days. * **Check-out weekday** — only for stays ending on chosen days. Matched against the departure day (the morning the guest leaves), so a Saturday-to-Saturday stay counts as a Saturday check-out. Combine it with **Check-in weekday** to reward full changeover-day stays. * **Stay dates (seasonal)** — the stay overlaps a date window. * **Booking date** — the booking is made within a date window. * **Book by date (per travel year)** — an early-bird cutoff anchored to the **travel year**: the booking must be made on or before, say, 31 March of the check-in’s own year. Because it tracks the travel year rather than a fixed calendar date, a booking made far in advance always qualifies. ### Promote and expiry [Section titled “Promote and expiry”](#promote-and-expiry) Turn on **Promote on search results** to advertise a discount as a badge on storefront cards — guests may need to adjust their dates or party size to qualify. If a discount’s conditions are pinned to specific calendar years, Reynt shows its expiry date and automatically deactivates it once that date passes. ## Fees [Section titled “Fees”](#fees) Open the **Fees** tab. Reynt keeps fees deliberately minimal — there is **no cleaning fee or booking fee** field. You can set: * **Deposit** — the refundable security deposit you require for this listing. * **Pet Price** with a **Pet Price Type** — how the pet fee is charged: **Per Stay**, **Per Day**, **Per Pet**, or **Per Pet/Day**. The pet fee is charged: it appears as its own line on the price breakdown and on the invoice. The deposit is **not**. Reynt only states the amount — it is never added to the total, never invoiced, and never collected, refunded, or tracked by Reynt. Taking the deposit and returning it after check-out stays entirely your own process, outside the system. Reynt states it to the guest in two places: * **On the property page**, as its own notice beside the cancellation policy. Shown by default: the deposit is a payment obligation that appears in no price breakdown, so this is a guest’s only chance to see it before booking. To hide it, turn off **Show security deposit** under **Storefront → Website → Property detail** — see [Built-in view settings](/docs/storefront/built-in-view-settings/#property-detail). * **In the Booking Confirmed email.** You can also include it in the **Booking Created** and **Payment Instructions** emails under [Settings → Notifications](/docs/communication/notifications-and-email/). Neither says *how* the deposit is paid or returned — tell guests that yourself, in your house rules or the property description. For optional paid extras (equipment, services, packages), use [Add-ons](/docs/listings/addons/) instead of fees. ## City and tourist tax [Section titled “City and tourist tax”](#city-and-tourist-tax) City/tourist tax is **not** configured here. It’s part of your tax setup — see [Taxes](/docs/invoices/taxes/). (The Fees tab includes a per-listing override for it, but the tax itself is defined under **Invoicing**.) ## How it appears to the guest [Section titled “How it appears to the guest”](#how-it-appears-to-the-guest) At checkout and on the booking, the price breakdown lists the nightly subtotal, then each matching discount by its summary, then the pet fee if one applies. The deposit is not part of this breakdown — it is stated separately in the booking emails. A [promo code](/docs/pricing/promo-codes/) replaces automatic discounts when the guest enters a valid one. # Promo codes > Tenant-wide discount codes guests enter at checkout, with scope and usage limits. Promo codes are discount codes a guest types at checkout — for example `SUMMER5` for 5% off. Unlike [automatic discounts](/docs/pricing/discounts-and-fees/), they stay hidden until a valid code is entered. Manage them from **Storefront → Promotions**. ## Creating a code [Section titled “Creating a code”](#creating-a-code) Click **New promotion** and fill in: * **Code** — what the guest types (e.g. `SUMMER5`). Matching is case-insensitive. * **Label** — shown on the price breakdown, e.g. “Summer sale”. * **Description** — optional longer text at checkout. * **Discount type and value** — **Percentage (%)**, **Fixed amount**, or **Fixed per night**. ## Where it applies (scope) [Section titled “Where it applies (scope)”](#where-it-applies-scope) The **Applies to** setting controls which listings accept the code: * **All listings** — every listing in the account. * **Specific listings** — only the listings you pick. * **Listings with tag** — any listing carrying at least one of the chosen tags. New listings that get the tag are automatically included. ## Validity and usage limits [Section titled “Validity and usage limits”](#validity-and-usage-limits) * **Valid from / Valid until** — the redemption window. Leave either empty for no bound. (For “5% in June”, set both to June.) * **Max total uses** — a global cap across all customers. Empty means unlimited. The table shows redemptions as `used / cap`. * **Per-customer limit** — how many times one customer may use the code. Empty means unlimited. This limit is checked when the booking is **confirmed**, so a customer can enter the code and see the discount in their quote, but a repeat use beyond the limit is rejected at that final step. * **Active** — a master on/off switch, independent of the date window. ## How it interacts with automatic discounts [Section titled “How it interacts with automatic discounts”](#how-it-interacts-with-automatic-discounts) A promo code does **not** stack with a listing’s automatic discounts — a valid code **replaces** them and applies in their place. Promo codes reuse the same discount types and can carry the same kinds of eligibility conditions as automatic discounts, so a code can still require, say, a minimum length of stay. ## Where guests enter it [Section titled “Where guests enter it”](#where-guests-enter-it) Guests enter the code in the checkout flow on your storefront. If a code is invalid — wrong code, outside its window, listing out of scope, or a limit reached — the quote still returns a normal (code-free) price and surfaces the reason, rather than blocking the booking. ## Related [Section titled “Related”](#related) * [Discounts and fees](/docs/pricing/discounts-and-fees/) — automatic, code-free discounts. * [Amenities, attributes and tags](/docs/listings/amenities-attributes-and-tags/) — set the tags used by tag-scoped codes. # Stay rules > Minimum and maximum nights plus arrival/departure restrictions, listing-wide and per season. Stay rules control how long a guest can book and which days they may arrive or leave. They come in two layers: a listing-wide default and per-season overrides. There is no separate “weekend pricing” — weekdays only affect stay restrictions, not the rate. ## Listing-wide defaults [Section titled “Listing-wide defaults”](#listing-wide-defaults) Open a listing, go to the **Property Facts** tab, and set: * **Minimum Stay** — the fewest nights a guest may book. * **Maximum Stay** — the most nights a guest may book (0 = unlimited). These apply to every date unless a season rule overrides them. ## Seasonal stay rules [Section titled “Seasonal stay rules”](#seasonal-stay-rules) For rules that only apply during part of the year, open the listing’s **Stay rules** tab and click **Create**. Each rule has: * **Season** — the date range it covers. Like price periods, a rule is **Recurring** (repeats every year) or limited to a **specific year**. * **Applies on** — restrict the rule to certain weekdays. Leave on **Every day**, or pick specific days — e.g. only Saturdays to enforce Saturday-to-Saturday stays. * **Minimum stay** — nights required during this season. Leave empty to inherit the listing default. * **Maximum stay** — nights allowed during this season. Leave empty for no maximum. * **No check-in (closed to arrival)** — guests cannot start a stay on the covered dates/weekdays. * **No check-out (closed to departure)** — guests cannot check out on the covered dates/weekdays. This is matched against the **departure day** (the morning the guest leaves), not the last night they sleep over. Closed-to-arrival and closed-to-departure are how you build turnover days — for example, allow arrivals only on Fridays in peak summer. ### When rules overlap [Section titled “When rules overlap”](#when-rules-overlap) If two seasonal rules cover the same dates, Reynt resolves them like prices: * The **narrower season** wins in the days they share. * When ranges are otherwise equal, the rule with the most recent **Effective from** date wins. The editor warns you inline when a new rule overlaps an existing one. ## How the storefront enforces them [Section titled “How the storefront enforces them”](#how-the-storefront-enforces-them) Stay rules are enforced in two places automatically: * **On the booking calendar** — nights that would violate the minimum/maximum or an arrival/departure restriction can’t be selected. * **At checkout** — a stay that breaks a rule is rejected before the booking is confirmed, so an out-of-policy booking can’t slip through. You don’t publish anything separately; saving a rule takes effect on the storefront immediately. ## Related [Section titled “Related”](#related) * [Prices and seasonal periods](/docs/pricing/base-and-seasonal/) — set the nightly rate per period. * [Block dates](/docs/availability/block-dates/) — mark a listing unavailable regardless of stay rules. # Appearance and theming > Branding, theme, contact, legal, and display settings for the built-in storefront. **Storefront → Appearance** holds the visual and content settings for your built-in storefront — branding, theme, contact details, SEO, and how listings are displayed. Each section saves on its own. ## Branding [Section titled “Branding”](#branding) Set your **Storefront logo** and **Favicon**, both picked from your media library. These are the customer-facing brand marks — separate from the operator logo used on invoices and PDFs. ## Theme [Section titled “Theme”](#theme) Your storefront’s look: * **Primary color** — the brand color applied to buttons, accents, and headings. Leave empty for the default. * **Base font** — the font used for all text (default: Inter). * **Signature font** — an optional font for headings and featured text; defaults to the base font. ## SEO defaults [Section titled “SEO defaults”](#seo-defaults) Fallback SEO metadata for pages that don’t set their own: **Default meta title** (falls back to your tenant name), **Default meta description**, and a **Default OG image** shown when links are shared on social media. Individual pages and posts can override these. ## Contact channels [Section titled “Contact channels”](#contact-channels) The contact details shown in the storefront header and footer, and on the contact page: **Public phone number**, **Public email address**, and **Address**. Leave any field empty to hide it. ## Legal pages [Section titled “Legal pages”](#legal-pages) Privacy policy, terms & conditions, and the imprint are set under **Settings → Storefront**, next to the publish switch they gate — see [Domains and SEO](/docs/storefront/domains-and-seo/) and the publish checklist in [Storefront overview](/docs/storefront/overview/). ## Partner logos [Section titled “Partner logos”](#partner-logos) An optional strip of logos in the footer for partners, certifications, or affiliations. Add each logo (from your media library) with alt text and an optional link to the partner’s website; reorder as needed. ## Listing display [Section titled “Listing display”](#listing-display) Controls what guests see on listing cards and pages: * **Properties page pricing** — how prices appear on search-result cards: **None** (hidden) or **Summary** (average nightly rate). * **Detail page pricing** — how seasonal prices show on the listing page: **None**, **Summary** (average nightly rate), or **Detailed** (full seasonal breakdown). * **Place display** on cards — hide it, or show the place name, the breadcrumb (parent places), or both. * **Show distances** — pick which distance types (e.g. nearest beach) appear on result cards, or hide them all. ## Referrer options [Section titled “Referrer options”](#referrer-options) The choices in the checkout’s “How did you hear about us?” select. Add the options you want (e.g. Google, Instagram, a friend); leave the list empty to hide the field entirely. Each selection is stored on the resulting booking. ## Blog [Section titled “Blog”](#blog) Blog display options — for example, **Show published date on posts** controls whether the date appears on blog cards and post pages. See [Blog](/docs/storefront/blog/). # Blog > Write and publish blog posts for your storefront. The **Blog** editor (under **Storefront → Blog**) lets you write posts that appear on your storefront’s blog index and as individual articles. It works like the Pages editor: a sidebar of posts on the left, and the selected post’s editor on the right with a live preview. ## Posts list [Section titled “Posts list”](#posts-list) The left sidebar lists every post with its status (Draft or Published) and, on multi-language tenants, a translation-completeness badge. Use **Create post** to start a new one, or select an existing post to edit it. You can filter by status. ## Post settings [Section titled “Post settings”](#post-settings) Open a post’s **Settings** to edit: * **Title** and **URL path** (slug, e.g. `my-post` → `/blog/my-post`) — both per language. * **Status** — Draft (hidden) or Published (live). * **Published date** — shown on the post and used to order posts. It’s optional; you can set it purely to control sort order even if you hide the date on the storefront. * **Excerpt** — a short summary shown in the blog listing and search results. * **Feature image** — the main image at the top of the post and in listings. * **SEO metadata** — Meta Title (falls back to the post title) and Meta Description (falls back to the excerpt), plus an OG image for social sharing. * **Tags** — for grouping and filtering posts. ## Post content [Section titled “Post content”](#post-content) The body of a post is built from the same **sections** as CMS pages (Rich Text, Image + Text, Image Gallery, Video, and more — a subset focused on article content). Add, reorder, hide, and edit sections exactly as you do elsewhere, with per-language content and a preview-language selector. See [Custom pages and CMS](/docs/storefront/custom-pages-and-cms/) for how sections work. A live preview pane on the right shows the post as it will appear on the storefront and refreshes as you save. ## Generate a post with AI [Section titled “Generate a post with AI”](#generate-a-post-with-ai) Blog posts support AI content generation: trigger the workflow from the post’s section list to have Reynt draft article sections for you to review and edit. See [Content generation and translation](/docs/ai/content-generation-and-translation/). ## Publishing [Section titled “Publishing”](#publishing) Set a post’s status to **Published** to make it live — there’s no scheduling step. Draft posts stay hidden from the public but are visible in preview. Published posts appear on your storefront’s **Blog** index page (ordered by published date) and at their own `/blog/` URL. ## Blog display options [Section titled “Blog display options”](#blog-display-options) Control blog presentation under **Storefront → Appearance → Blog** — for example, whether the published date appears on post cards and detail pages. See [Appearance and theming](/docs/storefront/appearance-and-theming/). # Built-in view settings > The per-view options that sit beside a built-in storefront view — search cards, property detail, checkout, blog, and page texts. Most storefront settings are site-wide and live under **Settings → Storefront**. A handful configure exactly *one* screen, and those live with that screen instead: open **Storefront → Website**, select a built-in view, and expand the **Settings** block below its sections. The rule is worth keeping in mind when you go looking for something: if a setting shapes one view and nothing else, it is on that view. If it shapes the whole site, it is in Settings. Each card in the block saves on its own — change one, save it, and the rest keep their current values. The block only appears if your role can read settings, and saving needs permission to change them. ## Which views have settings [Section titled “Which views have settings”](#which-views-have-settings) | View | Settings | | ------------------- | ------------------------------------------------------------------------ | | **Properties** | Card display, catalog layout, search filters, pagination, search ranking | | **Property detail** | Which sections appear, detail-page pricing | | **Checkout** | Phone requirement, referrer options, priority countries | | **Blog** | Post display | | **Booking** | Page texts | | **Offer** | Page texts | **Home**, **Wishlist**, **Blog post** and **Contact** have no settings — they are pure content surfaces, and the Settings block does not appear on them. The **Offer** view has no content sections at all, so its Settings block opens expanded: there, the settings *are* the page. ## Properties [Section titled “Properties”](#properties) The search-results screen. Five cards: **Search Result Card Display** — what each property card shows (guests, bedrooms, bathrooms, living space, distances) and how its location reads: hidden, place name only, breadcrumb only, or name plus breadcrumb. Hidden fields are not sent to the storefront at all, so this applies to *every* property card on your site, including gallery and search sections on your own pages. Two pricing choices sit here too: * **Properties Page Pricing** — `Summary` shows a nightly rate on each card, `None` hides prices entirely. * **Lead Price Aggregation** — whether that rate is the average (“Ø X per night”) or the cheapest seasonal rate (“from X / night”). This one reaches further than the card: it also drives map markers, the detail-page summary and SEO data, and it decides what the price filter and price sorting compare against. **Catalog Layout** — with only a few properties, the full search UI (filters, map, sorting, pagination) is out of proportion. The simple layout drops it, and also changes the default navigation menu. **Search Filters** — the distance thresholds offered in the filter drawer, in meters (empty = 500 / 1000 / 2000 / 5000 / 10000; up to 20 values, deduplicated and sorted on save), and the upper bound of the price slider (0 = 500 €). **Search Result Pagination** — numbered pages with a total count, or lightweight Previous/Next. Turning the total off saves a database round-trip on large catalogs. Also sets how many properties appear per page, which drives the grid, the map markers and the pagination together. **Search Ranking** — tunes the baseline quality score behind the “recommended” sort: relative weights for completeness, popularity and recency (0–1), a popularity cap, a recency horizon in days, and per-tag boosts added on top. Featured listings always sort first regardless. The rating weight is inert until reviews ship. ## Property detail [Section titled “Property detail”](#property-detail) One card, **Property Detail Page**, controlling which sections a listing page shows: * **Show cancellation policy** — the policy card, when a policy is assigned to the listing. * **Show security deposit** — the refundable deposit notice. On by default, because Reynt never collects the deposit and it appears in no price breakdown — see [Discounts and fees](/docs/pricing/discounts-and-fees/). * **Show location map** — the map and the location card around it. Plus **Detail Page Pricing**: `None` hides seasonal prices, `Summary` shows the average nightly rate, `Detailed` shows the full seasonal breakdown. ## Checkout [Section titled “Checkout”](#checkout) **Checkout** — whether a phone number is required to book. Turn it off if you never call guests: the field stays on the form marked optional, and one less required field means fewer abandoned checkouts. This applies to your own website too, since bookings there go through the same API. **Referrer Options** — the choices in the checkout’s “How did you hear about us?” select, per language. Leave the list empty and the field disappears. **Priority Countries** — which countries sit at the top of the country dropdown in the booking form. ## Blog [Section titled “Blog”](#blog) **Post Display** — whether the published date appears on blog cards and post detail. Turning it off hides the date but keeps it settable on a post to control sort order; structured data (JSON-LD) is unaffected either way. ## Booking and Offer [Section titled “Booking and Offer”](#booking-and-offer) Both carry **Page texts**: per-language overrides of the storefront’s own wording on that page. Anything left blank keeps the built-in text, so you only fill in what you want to say differently. Fields are grouped by what they belong to — general, status messages, stay details, guest information, property information, invoice and price, offer options, actions and dialogs, status screens, notices, and errors. Some texts accept placeholders, listed under the field; texts with a singular and a plural form take both, separated by a vertical bar (`|`). The Offer view is the one to look at first: it has no content sections, so these texts are the entire page a guest sees when you send an offer. # Custom pages and CMS > Build storefront pages, built-in views, and site-wide areas from reusable content sections. The **Website** surface (under **Storefront → Website**) is where you design every screen of your storefront — and where its navigation lives, right next to the pages it links (see [Navigation](/docs/storefront/navigation/)). It’s a single view: a sidebar on the left lists everything you can edit, and the panel on the right edits the selected item. Content is assembled from a library of pre-styled **sections** — no code required. ## Three kinds of content [Section titled “Three kinds of content”](#three-kinds-of-content) The sidebar groups your storefront into three kinds of container: * **Home & custom pages** — your landing page (**Home**) and any standalone pages you create (About Us, FAQ, Terms, a local guide, a campaign page). Each custom page has its own URL and can be linked from your menus. * **Built-in views** — fixed storefront screens you can customize but not create or delete. Each one shows a **locked core section** (the search results, the checkout form, the post body) that does the page’s job; you add your own sections above or below it: * **Home** — the landing page at `/`. * **Properties** — the search results page where guests browse and filter listings. * **Property detail** — sections here appear on *every* listing page. * **Checkout** — the page guests see while completing a booking. * **Booking** — the confirmation page shown after a successful booking. * **Wishlist** — where guests see saved properties. * **Blog** — the blog index page. * **Blog post** — sections here appear on *every* post, wrapped around that post’s own sections. * **Contact** — the contact page with the inquiry form. * **Layout** — site-wide areas that appear on every page: the **announcement bar** at the very top, and the **above-footer** region. ## Sections [Section titled “Sections”](#sections) Every editable area — a page, the regions around a built-in core, a layout bar — is an ordered list of sections. Add a section, fill in its fields, reorder, and it renders on the storefront. The library includes: | Group | Sections | | -------------- | ----------------------------------------------------------------- | | Hero & banners | Hero Search, Banner, Call to Action | | Listings | Featured Listings, Listing Gallery, Listing Search, Category Grid | | Content | Rich Text, Image + Text, Image Gallery, Video, Map, Embed | | Social proof | Testimonials, Stats, Logo Cloud, Team | | How & why | Features, Incentives, Steps, FAQ, Pricing | | Engagement | Blog, Newsletter, Contact Form | A few worth calling out: * **Hero Search** — full-width banner with a search bar; ideal as the first section on the homepage. * **Featured Listings** and **Listing Gallery** — showcase a curated set of properties, filtered by place, tags, amenities, price, or availability. * **Listing Search** — an embedded search with pre-set filters so guests can browse from any page. * **Rich Text** — free-form formatted text for descriptions, policies, or announcements. * **Contact Form** — a configurable inquiry form whose submissions land in your inbox. * **Embed** — sandboxed external HTML for widgets or third-party tools. Not every section is available everywhere — blog posts and some built-in pages offer a focused subset (nothing that would pull a guest out of the checkout, for example). ### Editing a section [Section titled “Editing a section”](#editing-a-section) Choose **Add section**, pick a type, and fill in the configuration form (a friendly form per section — you never edit raw JSON). Each section has: * A **visibility** toggle — hide a section without deleting it (hidden sections still show in preview). * **Move up / move down** to reorder. * **Export / Import sections** — save a page’s sections to a JSON file and re-import them into another page (append or replace). ### Per-language content [Section titled “Per-language content”](#per-language-content) Translatable fields (titles, text, button labels) are edited per language with a tab for each locale you’ve enabled. The section editor also has a **Preview language** selector that renders the section exactly as a guest in that language would see it, including fallback behavior when a translation is empty. Leave a language blank and the storefront falls back to your default language rather than showing an empty section. ## Page settings and SEO [Section titled “Page settings and SEO”](#page-settings-and-seo) Each custom page has a settings area with: * **Title** and **Slug** (the URL path, e.g. `about-us` → `/about-us`) — both per language. * **Status** — Draft or Published. * **SEO metadata** — Meta Title, Meta Description, and an OG (social share) image. These fall back to the page title and sensible defaults when left empty. Built-in views have fixed URLs and no slug or draft state — use section visibility to hide content on them instead. Some built-in views also carry a **Settings** block below their sections, holding the options that configure only that screen — search-card fields, property-detail sections, checkout requirements, page texts. Site-wide storefront settings stay under **Settings → Storefront**; a setting that shapes exactly one view lives with that view. See [Built-in view settings](/docs/storefront/built-in-view-settings/) for what each view offers. Renaming a slug Menu links reference the page itself and follow a rename automatically. External links do not: a bookmark, a shared URL, or a link from another website keeps pointing at the old path. Finalise the slug before you share a page publicly, or add a redirect from the old path afterwards. ## Preview, draft, and publish [Section titled “Preview, draft, and publish”](#preview-draft-and-publish) * **Preview** opens your storefront in a new tab using a short-lived access token (valid about an hour). Draft pages and hidden sections are visible in preview only. The editor also shows a live preview pane you can switch between phone, tablet, and desktop widths. * Custom pages start as **Draft** and return a *page not found* to the public until you set their status to **Published**. * There’s no scheduled publishing — status changes take effect as soon as you save. Once published, the page is live immediately. ## Generate a page with AI [Section titled “Generate a page with AI”](#generate-a-page-with-ai) When you create a custom page you can choose **Generate with AI**: describe the page and Reynt drafts its content sections for you to review and refine. Or start empty and add sections manually. See [Content generation and translation](/docs/ai/content-generation-and-translation/). # Domains and SEO > Custom domains, map tiles, analytics, and search-engine settings for the storefront. **Settings → Storefront** holds the technical setup for the built-in storefront: how it’s served, custom domains, maps, analytics, and search behavior. (Visual and content settings live under **Storefront → Appearance** instead — see [Appearance and theming](/docs/storefront/appearance-and-theming/).) ## Legal pages [Section titled “Legal pages”](#legal-pages) The footer links required for a compliant site: **Privacy policy**, **Terms & conditions**, and **Imprint (Impressum)**. Each can point to an external URL or to a CMS page you’ve built. The imprint and privacy policy are required before your storefront can go live, which is why they sit directly above the publish switch. ## Publishing [Section titled “Publishing”](#publishing) **Publish storefront** controls whether your site is live. New storefronts start as a draft and return a maintenance page until you publish. Reynt blocks publishing until the imprint, privacy policy, a notification email, and a payment method are set — each unmet item in the checklist links to the setting that closes it. See the checklist in [Storefront overview](/docs/storefront/overview/). ## Custom domains [Section titled “Custom domains”](#custom-domains) By default your storefront is served on a platform domain. To use your own: 1. Under **Custom domains**, add your domain (e.g. `booking.mydomain.com`). 2. Create a **CNAME** DNS record for it pointing at your platform base domain (Reynt shows the exact target). 3. Use **Verify DNS** — the domain’s status moves from *Pending DNS* to *Active* once the record is found. 4. Set one domain as **Primary** if you have several; it becomes the canonical address for links. ## Map tiles [Section titled “Map tiles”](#map-tiles) The storefront’s maps use a tile provider (MapTiler by default), with **Streets**, **Satellite**, or **Outdoor** styles. On the default platform domain you can leave the provider key empty to use the platform default. **When you serve the storefront from your own custom domain, your own provider key is required** — the platform key only works on platform domains, so maps won’t load on a custom domain without it. ## Analytics and tracking [Section titled “Analytics and tracking”](#analytics-and-tracking) Add your **Google Analytics 4** measurement ID to track storefront traffic, and a **Google Ads** tag ID with per-goal conversion labels (checkout/booking, leads, and phone clicks) if you run ads. ## Search behavior (in brief) [Section titled “Search behavior (in brief)”](#search-behavior-in-brief) **Settings → Storefront** also tunes the search experience — covered in depth in [Search and maps](/docs/storefront/search-and-maps/): * **Search result pagination** — numbered pages with a total count, or lightweight Previous/Next; and how many properties show per page. * **Search ranking** — the quality-score weights and per-tag boosts behind the “recommended” sort. * **Distance filter values** and **search filters** — the thresholds and price-slider ceiling offered to guests. ## SEO [Section titled “SEO”](#seo) The storefront is built for search engines out of the box: * **Locale-prefixed URLs** — each language has its own URL path, and pages carry **hreflang** alternates so search engines serve the right language. * **Per-language sitemaps** using each page’s translated slug. * **Cross-language redirects** — if a guest hits a page’s slug in the wrong language, the storefront redirects to that language’s canonical URL. See [Multilingual content](/docs/languages/multilingual-content/) for how translated slugs and hreflang work. ### URL redirects [Section titled “URL redirects”](#url-redirects) Use **Settings → Configuration → Redirects** to preserve SEO when migrating from an existing site or after changing a slug. Each redirect has a **source path**, a **target path**, a **match type** (Exact or Prefix), a status code, and an enabled toggle. Old URLs then forward to the new ones instead of returning *not found*. # Navigation > Build your storefront header and footer menus. Your storefront’s menus are built on the **Website** surface (under **Storefront → Website**), where they sit alongside the pages they link to. The sidebar shows the site as a tree: the **Header** (the top navigation bar) and the **Footer** (links at the bottom of every page) as two stacked sections, followed by **Unlinked pages**, the **Guest journey** templates, and the site-wide **Layout** bars. ## The menu tree [Section titled “The menu tree”](#the-menu-tree) Each menu is a tree of items you can drag to reorder. Clicking an item opens what it points at: a page or built-in view link opens that page’s content editor, while a group or custom URL opens its own settings. The small gear on a page or view link opens the *menu entry’s* settings — its label, new-tab behavior, and removal. Menus support two levels: top-level items, and items nested inside a group. ## Menu item types [Section titled “Menu item types”](#menu-item-types) * **Page link** — points to one of your custom pages or a **built-in view** (Home, Properties, Blog, Wishlist, Contact). The item references the page itself, so it follows slug renames automatically — and the same page can be linked from several places, header and footer at once. * **Custom URL** — an internal path (e.g. `/about`) or any external website address. * **Group** — a dropdown that contains other items. Groups can be one level deep only — you can’t nest a group inside a group. Add items with the **Add** button (choose Page link, Custom URL, or Group). For any link you can toggle **Open in new tab**, typically for external URLs. ## Per-language labels [Section titled “Per-language labels”](#per-language-labels) Every menu item’s **Label** is edited per language, so your menus read correctly in each locale you’ve enabled. ## Linking pages and reordering [Section titled “Linking pages and reordering”](#linking-pages-and-reordering) * Below the two menus, **Unlinked pages** lists pages and built-in views placed in neither menu. Drag one into either tree to add it — or click it to edit its content first. * Hover an item to reveal its drag handle, then drag to reorder within the tree or to move items in and out of a group. * A link that also exists in the other menu shows a small marker — one page, several menu entries, all opening the same content. Renames are safe in menus Menu items reference pages directly (not by URL), so renaming a page’s slug updates every menu link automatically. Only **Custom URL** items store a raw path as text — those you maintain yourself. A menu link to a **draft** page is kept in the editor but hidden from visitors until the page is published. ## Fallback navigation [Section titled “Fallback navigation”](#fallback-navigation) If you haven’t configured any menu items, the storefront falls back to automatic navigation based on your top-level places, so guests can still get around while you build your menus. # Storefront overview > What the Reynt storefront is, how it is run, and what guests can do on it. The storefront is your public, customer-facing booking website: where guests search your properties, open listing pages, and book. It is a separate site from the admin console — guests never see the console, and you rarely open the storefront to work. ## Two ways to run a storefront [Section titled “Two ways to run a storefront”](#two-ways-to-run-a-storefront) Under **Settings → Storefront → Storefront mode** you choose how your public site is served: * **Built-in storefront** — Reynt hosts and renders the whole site for you. Booking links, listing links, and your website URL are derived automatically from your storefront domain. This is the default, and everything in this section applies to it. * **Custom website** — you run your own site and only use Reynt as the booking engine. You set the storefront URLs manually, and build the front end yourself against the headless SDK (a typed API client for a fully custom storefront). Content, appearance, and CMS settings in the console don’t apply in this mode. The rest of these pages assume the built-in storefront. ## What guests can do [Section titled “What guests can do”](#what-guests-can-do) * **Search** your properties by destination (a place), stay dates, and party size (adults, children, pets). See [Search and maps](/docs/storefront/search-and-maps/). * **Browse the map** of results and open a **listing detail page** with photos, description, amenities, availability, location, and pricing. * **Book** — the checkout follows the booking flow set for each listing. See [Booking lifecycle](/docs/bookings/lifecycle/). * **Save properties** to a wishlist. * **Read your blog** and any custom pages you publish (About, FAQ, local guides, terms). * **Contact you** through a built-in contact/inquiry form that lands in your [inbox](/docs/communication/inbox/). ## Content comes from three places [Section titled “Content comes from three places”](#content-comes-from-three-places) * **Listings** you manage under **Listings** — surfaced as searchable listing pages. * **CMS pages, sections, slots, and navigation** managed under **Storefront → Website** — your landing page, marketing pages, fixed content areas, and the header/footer menus. See [Custom pages and CMS](/docs/storefront/custom-pages-and-cms/) and [Navigation](/docs/storefront/navigation/). * **Storefront settings** — branding, theme, navigation, SEO, and contact details under **Storefront → Appearance**, and the technical setup plus legal pages under **Settings → Storefront**. Content changes go live within about a minute — there is no deploy step. ## Multiple languages [Section titled “Multiple languages”](#multiple-languages) The storefront is multilingual. Pages, blog posts, menu labels, and section content are all edited per language, and the storefront serves locale-prefixed URLs with the right SEO tags. See [Multilingual content](/docs/languages/multilingual-content/). ## Before you go live [Section titled “Before you go live”](#before-you-go-live) New storefronts start as a **draft** and return a maintenance page until you publish them under **Settings → Storefront → Publish storefront**. Reynt blocks the toggle until the essentials are in place: * **Imprint (Impressum)** — legally required; the site stays offline until set. * **Privacy policy (Datenschutzerklärung)** — legally required; the site stays offline until set. * **A notification email** — otherwise new bookings and inquiries aren’t emailed to you. * **A payment method** — otherwise bookings publish with no payment obligation. Set the imprint and privacy pages under **Settings → Storefront → Legal pages**, right above the publish switch (see [Domains and SEO](/docs/storefront/domains-and-seo/)), and see [Publishing and visibility](/docs/listings/publishing-and-visibility/) for getting listings live. ## Checkout [Section titled “Checkout”](#checkout) Under **Storefront → Website → Checkout** you decide what the booking form asks a guest for. * **Require a phone number** — on by default. Turn it off if you never call your guests: the field stays on the form, marked optional, and one less required field means fewer abandoned bookings. Keep it on if you rely on the phone for key handover or late arrivals. The setting applies to your own website too — bookings there go through the same API, which enforces the same rule. ## Small catalog mode [Section titled “Small catalog mode”](#small-catalog-mode) If you run only a handful of properties (roughly one to five), set **Catalog Layout** to the simple layout under **Storefront → Website → Properties**. The storefront then hides search filters, the map, sort, and pagination, and shows your properties as a clean centered card grid with just date and guest availability filters. The homepage shows a featured-property showcase instead of the full search hero. # Search and maps > How guests search your properties and how the storefront map behaves. Search is how most guests find a property. The storefront pairs a filter panel with an interactive map, both driven by the settings on the **Properties** view under **Storefront → Website** (see [Built-in view settings](/docs/storefront/built-in-view-settings/)) and by **Storefront → Appearance**. ## The filter panel [Section titled “The filter panel”](#the-filter-panel) Guests open a **Filters** drawer (it shows a badge with the number of active filters) grouped into three areas: **Essentials** * **Search term** — free-text search over your listings. * **Period** — check-in and check-out dates, with a “± flexible days” option to widen the range. * **Guests** — separate counters for **adults** (at least one), **children**, **infants**, and **pets**. Children and infants don’t have per-child age inputs; instead the labels show the age brackets you configure (a child and infant maximum age). Infants only appear if you’ve configured an infant age. Pets appear when a listing allows them. * **Price** — a dual-handle range slider. See the price ceiling below. **Location** * **Place picker** — pick from your places, shown as a hierarchy. Typing something that isn’t a place runs a free-text location search instead. * **Distance filters** — one dropdown per distance category you’ve defined (e.g. nearest beach). See below. **Features** * **Amenities** — a toggle per amenity your properties offer. * **Tags** — active tag filters appear as removable chips. The drawer footer has **Clear all** and a **Show N results** button. Above the results, a **Sort** control offers Relevance (the “recommended” sort), Price ascending/descending, Guests ascending/descending, and a “closest to …” option for each distance category. ## The map [Section titled “The map”](#the-map) Results appear on an interactive map (MapTiler tiles by default) beside the list — a sticky column on desktop, a slide-over on mobile. * **Price pills** — each property shows as a white pill with its nightly price; properties without a price show as a dot. Hovering a result card highlights its pill on the map, and vice versa. * **Clustering** — nearby pins group into a compact count badge that expands as the guest zooms in. (Clustering can be turned off per tenant.) * **Click a pill** to open a small property card anchored to the pin. * **Full result set** — the map shows every matching property, not just the current page of cards. * **Search as you move** — panning or zooming the map automatically filters results to the visible area; an active map-area filter shows as a dismissible chip in the panel. Searching a place instead frames that whole region. * **Listings without coordinates** — on first load, while the map simply frames the results, listings with no coordinates still appear in the list (they just have no pin). Once a guest pans or zooms, the map area becomes a real filter and coordinate-less listings drop out — one more reason to keep coordinates filled in (see the completeness note in [Listings overview](/docs/listings/overview/)). Maps only appear when a map provider key is configured. On a custom domain you must supply your own key — see [Domains and SEO](/docs/storefront/domains-and-seo/). ### Browsing places on the map [Section titled “Browsing places on the map”](#browsing-places-on-the-map) If you’ve enabled the map place picker and your places have map coordinates, guests can open a map view showing each place as a labeled pill and click to select one — a visual alternative to the place dropdown. ## Settings that shape search [Section titled “Settings that shape search”](#settings-that-shape-search) ### Price slider ceiling [Section titled “Price slider ceiling”](#price-slider-ceiling) Set **Price slider maximum** under **Storefront → Website → Properties → Search Filters**. The slider runs from 0 to this value (with a `+` at the top end); leave it at 0 to use the default of €500. A full-range selection applies no price filter. ### Distance filters [Section titled “Distance filters”](#distance-filters) Under **Storefront → Website → Properties → Search Filters**, set the distance threshold options (in metres) offered in the distance dropdowns. The same list applies to every distance category. Leave it empty to use the defaults (500 m, 1 km, 2 km, 5 km, 10 km); up to 20 values, de-duplicated and sorted on save. Which distance categories exist comes from your places and distance configuration — see [Places and distances](/docs/catalog/places-and-distances/). ### Search ranking (recommended sort) [Section titled “Search ranking (recommended sort)”](#search-ranking-recommended-sort) Under **Storefront → Website → Properties → Search Ranking**, tune the quality score behind the default “recommended” order: * **Weights** for profile **completeness**, recent booking **recency**, and overall **popularity** (each 0–1, relative to each other). * **Recency horizon** — how many days count as “recent”. * **Popularity cap** — the booking count beyond which extra volume no longer boosts a listing, so one popular property can’t dominate. * **Tag boosts** — award (or subtract) points for carrying specific tags. Featured listings always sort first; tag boosts and the quality score stack on top. ### Pagination [Section titled “Pagination”](#pagination) Under **Storefront → Website → Properties → Search Result Pagination**, choose numbered pages with a total count or lightweight Previous/Next, and set how many properties show per page (this drives the grid, the map markers, and the pagination together). ### Small catalog mode [Section titled “Small catalog mode”](#small-catalog-mode) If you run only a few properties, **Catalog Layout** (under **Storefront → Website → Properties**) can hide the search filters, map, sort, and pagination entirely in favor of a simple date-and-guest availability filter. See [Storefront overview](/docs/storefront/overview/).