Hilfe & Glossar

Delta-Prozent zeigt die prozentuale Veraenderung eines Werts gegenueber einem Vergleichszeitraum.

Visuelle Konvention:

• Gruen mit Pfeil nach oben: positive Veraenderung
• Rot mit Pfeil nach unten: negative Veraenderung
• Grau mit Pfeil zur Seite: unveraendert

Vorsicht bei kleinen Basiswerten - eine Veraenderung von 100 auf 200 EUR sind +100% und sieht dramatisch aus, ist aber operativ irrelevant.

Der Mode-Toggle entscheidet, wie alle Geldbetraege im Dashboard angezeigt werden.

• Netto: alle Werte ohne Umsatzsteuer. Standard fuer betriebswirtschaftliche Auswertungen.
• Brutto: alle Werte inklusive Umsatzsteuer. Entspricht den Beilagen aus Buchungssystemen.
• Beide: zeigt Brutto gross, Netto klein darunter.

Wichtig: Auf Tabs Revenue und Pace stammen Netto-Werte direkt aus der Apaleo-Buchung (genau). Auf Tabs Channels/Guests/Companies/Forecast/Benchmark wird Brutto pauschal mit 1/1.07 in Netto umgerechnet.

Netto ist der reine Erloes ohne Umsatzsteuer - relevant fuer GuV, BWA, Management Fee.

Brutto ist der Betrag, den der Gast tatsaechlich gezahlt hat - relevant fuer Bank-Eingaenge, Kassenabschluss.

Steuersaetze:

• 7% auf Logis (Uebernachtung)
• 19% auf Speisen, Getraenke, Parking, sonstige Erloese
• Mischbestand: Pauschalen koennen 7%- und 19%-Anteile enthalten.

Beim Drilldown klickt man eine aggregierte Kennzahl an (z.B. Gesamtumsatz Logis im Monat) und sieht die Aufschluesselung pro Property.

In Pace und Forecast geht der Drilldown noch eine Ebene tiefer: Monat -> Property -> Channel/Rateplan.

Der Property-Filter in der Sidebar steuert, welche Hotels in alle KPIs auf der Seite einfliessen.

Aktive Properties:

• SHB - Stadthotel Bernau (97 Zimmer)
• H24LB - Hotel Berlin-Lichtenberg (83 Zimmer)
• H24PHT - Parkhotel Thale (54 Zimmer)
• H24EW - Hotel Eberswalde (32 Zimmer)
• H24HF - Hotel Hochfirst (24 Zimmer)

Die Auswahl wird im LocalStorage gespeichert und ueber alle Tabs hinweg uebernommen.

Ein Snapshot ist ein eingefrorener Zustand der Datenbank zu einem bestimmten Stichtag.

Zwei wichtige Snapshots:

• Forward-Booking-Snapshot (taeglich): friert OTB-Stand ein, damit Pickup berechenbar bleibt.
• Aging-Snapshot (taeglich 06:00 UTC): friert offene Forderungen ein.

Im Dashboard wird das Snapshot-Datum immer im Tab-Header angezeigt.

Der VJ-Vergleich zeigt fuer jeden Zeitraum den entsprechenden Vorjahreszeitraum an.

VJ ist immer stichtagsgenau - z.B. bei Auswahl 1.4.-10.4.2026 wird 1.4.-10.4.2025 verglichen.

Damit sieht man, wie sich Umsatz/Auslastung gegenueber dem gleichen Saisonpunkt entwickelt hat.

Year over Year ist die englische Standardabkuerzung fuer Vorjahres-Vergleich.

In Reports von OTAs (Booking, Expedia) und internationalen Benchmark-Anbietern (STR, MKG) ist YoY der gaengige Begriff.

Average Daily Rate ist der Durchschnittspreis pro tatsaechlich verkauftem Zimmer pro Nacht.

Misst die Preisdurchsetzung - also wie hoch unsere durchschnittliche Zimmerrate ist, ohne Ruecksicht auf Auslastung.

Wichtige Unterscheidung zu RevPAR: ADR sagt nichts darueber, wie viele Zimmer leer stehen.

Schwellen H24-Portfolio:

• < 80 EUR: niedrige Preisdurchsetzung
• 90-120 EUR: typischer Bereich fuer H24-Stadthotels

• 140 EUR: Premium-Segment oder Hauptsaison-Spitzen

Auslastung misst den Anteil der verkauften Zimmer an den verfuegbaren Zimmern.

Definition verfuegbar: Anzahl Zimmer im Hotel mal Anzahl Tage im Zeitraum.

Definition verkauft: Reservierungen mit Status CheckedOut, InHouse oder Confirmed. Storno und NoShow zaehlen NICHT.

Schwellen:

• < 50%: schwach, deutet auf Pricing- oder Marketingproblem
• 60-75%: typisch fuer H24-Stadthotels

• 85%: sehr hoch, oft Hinweis auf Underpricing

Available-Nights ist die theoretische Maximalkapazitaet.

Wir rechnen mit Anzahl physisch existierender Zimmer (config.PROPERTY_ROOMS), nicht mit verkaufsoffenen Zimmern.

Aktuelle Werte (Stand Maerz 2026):

• SHB: 94 Zimmer
• H24LB: 81 Zimmer
• H24PHT: 54 Zimmer
• H24EW: 32 Zimmer
• H24HF: 24 Zimmer

Babybett ist die Logis-Subkategorie fuer Babybett-Bereitstellung. Meistens kostenfrei oder kleine Pauschale (5-10 EUR).

F&B (Food & Beverages) buendelt alle gastronomischen Erloese.

Subkategorien:

• Fruehstueck: Konten 8400000, 8300200, 8400 - meistens als Pauschale
• Gastro Speisen: Konten 8402000, 8302000, 8409 - Restaurant, Bankett
• Gastro Getraenke: Konten 8409000, 8402, 4400 - Bar, Minibar

Steuersatz 19% (Standard-MwSt). Im Gegensatz zu Logis kein reduzierter Satz.

Fruehstueck ist meistens als Pauschale pro Gast/Nacht gebucht.

Faustregel: Fruehstueck-Anteil an Gesamtumsatz haengt stark vom Hotel ab - Stadthotels mit BAR-Quote unter 50% sind typisch, Schwarzwald-Wellnesshotels mit Pauschalpaketen liegen ueber 80%.

Gastro Getraenke sammelt alle Getraenke-Umsaetze.

Marge-relevant: Getraenke haben deutlich hoehere Margen als Speisen (Wareneinsatz typisch 25-30% bei Wein/Spirituosen vs. 35-40% bei Speisen).

Gastro Speisen umfasst alle Speisen-Erloese ausserhalb Fruehstueckspauschale: a-la-carte, Bankett, Bar-Snacks, Tagungsverpflegung.

Property-Faustregel: Hotels mit eigenem Restaurant (DSH, H24HF) zeigen hier deutliche Erloese. Reine Stadthotels ohne Kueche (H24EW vollautomatisiert) zeigen 0.

Der Gesamtumsatz ist die Summe aller Erloese ueber alle Revenue-Konten und alle ausgewaehlten Properties im Zeitraum.

Quellsicht ist der Buchungssatz (Apaleo finance/v1/transactions). Jede Position einer Buchung wird einzeln aggregiert.

Buchhalterisch wichtig: Im Gegensatz zum GM-Report basiert der Gesamtumsatz auf dem Umsatzbericht - das ist die Zahl, die in BWA/GuV einfliesst.

Die Granularitaet bestimmt, in welchen Zeit-Buckets die Charts aggregieren.

Auto-Logik:

• < 60 Tage Zeitraum: Daily (jeder Tag ein Punkt)
• 60-180 Tage: Weekly (Wochenwerte)

• 180 Tage: Monthly (Monatswerte)

Haustier ist eine Logis-Subkategorie fuer den Aufpreis bei Mitnahme von Hund/Katze.

Typisch 10-25 EUR pro Nacht. Schwarzwald (H24HF) hat hohe Haustier-Quote, Stadthotels deutlich niedriger.

Logis ist der reine Uebernachtungserloes - was der Gast fuer das Zimmer bezahlt, ohne Fruehstueck und ohne Extras.

In Apaleo ist das die Konto-Familie RevenueAccommodation_8300000 und Varianten. Steuersatz 7% (reduzierter Satz fuer Hotelbeherbergung in Deutschland).

Subkategorien:

• Logis (Standard): Konten 8300000, 4300
• Haustier: Konto 8300001 / 4301
• Babybett: spezielle Babybett-Konten

Logis ist der wichtigste Erloesblock und Basis fuer ADR und RevPAR.

Logis-Netto ist der Logis-Erloes ohne die 7%ige Hotel-Logis-Umsatzsteuer.

Im Dashboard wird Logis-Netto als Basis fuer ADR und RevPAR verwendet, weil dies die international vergleichbare Standard-Konvention ist (STR, HotStats, alle Benchmark-Anbieter rechnen mit Netto).

No-Show ist die schwerste Form von Buchungs-Verlust: Gast erscheint nicht, hat aber auch nicht storniert.

Vorgehen typisch:

1. Hotel haelt Zimmer reserviert bis Mitternacht
2. Bei Nicht-Erscheinen wird Buchung als NoShow markiert
3. Gemaess Tarif wird die erste Nacht oder die volle Buchung berechnet
4. Konto RevenueNoShow wird mit dem berechneten Betrag bebucht

Hohe No-Show-Rate (>3%) deutet auf schlechte Garantie-Konfiguration hin.

Parkplatz ist ein klassischer Add-On-Erloes. Bei Stadthotels mit eigener Tiefgarage relevant (SHB, H24LB).

Pricing-Faustregel: 12-18 EUR pro Nacht in Berlin/Brandenburg.

Raumvermietung umfasst die Vermietung von Tagungsraeumen und Veranstaltungsraeumen.

Property-Bezug: Fuer Hotels mit grossem Eventbusiness (DSH, SHB) ein relevanter Posten. H24EW/H24PHT haben kaum Tagungsbusiness.

Revenue per Available Room ist die wichtigste Hotellerie-Kennzahl. Sie kombiniert ADR und Auslastung in einer einzigen Zahl.

Vorteil gegenueber ADR: RevPAR steigt nur, wenn entweder Preis ODER Auslastung steigt. Hohe ADR mit leeren Zimmern bringt also kein hohes RevPAR.

Schwellen:

• < 40 EUR: schwache Performance
• 50-80 EUR: typisch fuer H24-Stadthotels

• 100 EUR: starkes Hotel oder Hochsaison

Aequivalenzformel: RevPAR = ADR * Auslastung-Quote

Room-Nights zaehlt jede verkaufte Zimmernacht einzeln.

Beispiel: 1 Reservierung 5 Naechte fuer 2 Personen = 5 Room-Nights (nicht 10 - Personen sind irrelevant).

Bei der Berechnung wird der Zeitraum der Reservierung mit dem ausgewerteten Zeitraum geschnitten.

Sonstige Erloese sind alle Nebenerloese, die nicht in Logis oder F&B fallen.

Subkategorien:

• Parkplatz: 8406000, 8401
• Raumvermietung: 8405000
• Stornogebuehren: 2742510, 2748, 4204
• Bikeverleih: nur H24HF
• Badeparadies: nur H24HF

Stornogebuehren entstehen, wenn ein Gast nach Storno-Frist absagt und gemaess Tarif-Regel eine Gebuehr faellig wird.

Konto-Familie RevenueCancellationFees in Apaleo. Wird in der Auswertung als eigene Kategorie ausgewiesen, NICHT in Logis aggregiert.

In Channel-Cost wird Stornogebuehren-Anteil pro-rata pro Channel umgelegt.

Zeigt, wie viele Tage die hartnaeckigste offene Forderung schon ueberfaellig ist.

Werte ueber 90 Tage sind kritisch - ab dann sinkt die Eintreibungs-Wahrscheinlichkeit deutlich.

Die Aging-Buckets gruppieren offene Forderungen nach Alter (gemessen ab Faelligkeitsdatum).

Wilhelm-Spec aus AR-Automation:

• 0-10 Tage: noch im Toleranzbereich, normaler Mahnlauf reicht
• 11-21 Tage: 1. Mahnung sollte gelaufen sein
• 22-30 Tage: 2. Mahnung, Telefon-Nachfass empfohlen
• 31-40 Tage: kritisch, persoenliche Eskalation
• >40 Tage: Inkasso-Pruefung, Abschreibungs-Risiko

Echte Verteilung Mai 2026 alle Properties:

• 0-10: 28 Rechnungen, ca. 11.094 EUR
• 11-21: 25 / ca. 8.252 EUR
• 22-30: 4 / ca. 1.011 EUR
• 31-40: 4 / ca. 3.027 EUR

• 40: 51 / ca. 23.867 EUR (kritisch)

40-Bucket bei ca. 50% des Bestands ist normal - viele Apaleo-Restposten und Storno-Reibungsverluste sammeln sich dort.

Bank-Match ist der Kern der AR-Automation: Bankeingaenge werden automatisch zu offenen Apaleo-Rechnungen zugeordnet.

Mechanik (vereinfacht):

1. Bankeingang via sevDesk-Sync abholen
2. Verwendungszweck (VWZ) parsen
3. Suche in Apaleo nach passender Reservierung/Folio
4. Bei eindeutiger Zuordnung: AUTO_RESERVATION oder andere Klassifikation
5. Bei Unklarheit: in Inbox zur manuellen Bearbeitung
6. Mit Hinweisen aber ohne Match: Wizard schlaegt Optionen vor

Der Pilot laeuft seit 03.05.2026 ausschliesslich auf H24LB.

Jeder Bankeingang im System hat einen Status:

• auto_resolved: System hat eindeutig zugeordnet, keine menschliche Pruefung noetig
• inbox_open: System hat Treffer-Vorschlaege, wartet auf manuelle Bestaetigung
• inbox_resolved: war in Inbox, wurde manuell bearbeitet
• no_match: keine Apaleo-Reservierung gefunden, gehoert wahrscheinlich anderswohin

Bankbetrag ist der tatsaechlich auf dem Bankkonto eingegangene Geld-Betrag in EUR.

Kein Brutto/Netto-Konzept - das ist der Wert, den die Bank meldet. Wenn Apaleo eine 119 EUR Brutto-Rechnung hat und der Gast 119 EUR ueberweist, ist Bankbetrag 119 EUR.

Wichtig fuer Match: 1 Bank-Tx = 1 Folio-Payment, exakter Betrag, kein Splitting.

Channel-Cost zeigt fuer jeden Buchungskanal die Wirtschaftlichkeit nach Abzug von Provisionen und Cancellations.

Berechnung pro Channel:

1. Brutto = SUM(stays.total_gross_amount) je channel_code
2. Netto = Brutto / 1,07 (Pauschal-Annahme)
3. Provision = Netto * Heuristik-Satz
4. Cancellation-Share = pro-rata-Anteil der Stornogebuehren-Erloese
5. Net-Net = Netto - Provision - Cancellation-Share

Heuristische Provisions-Saetze:

• Direct: 0%
• ChannelManager (Sammelkanal): 15%
• Booking.com: 17%
• Expedia: 20%
• HRS: 13%
• Sonstige: 10%

Diese Heuristiken sind Naeherungen - echte Provisionen variieren je Vertrag.

Davon ueberfaellig zaehlt nur die Rechnungen, deren Faelligkeitsdatum (due_date) bereits in der Vergangenheit liegt.

Faelligkeitsdatum = Rechnungsdatum + Zahlungsziel (typisch 14 oder 30 Tage). Eine Rechnung vom 1.4. mit Zahlungsziel 14 Tage ist seit 16.4. ueberfaellig.

Eine hohe Quote ueberfaelliger Forderungen ist ein Frueh-Indikator fuer Zahlungsausfaelle und sollte unter 30% des Gesamtbestands bleiben.

Die Inbox sammelt alle Bankeingaenge, fuer die das System Vorschlaege hat, aber keine eindeutige Auto-Zuordnung.

Typische Faelle:

• Mehrere Treffer-Kandidaten (z.B. 2 Reservierungen mit gleichem Betrag im Zeitraum)
• VWZ ist mehrdeutig
• Sammel-Avis (eine Bank-Tx fuer mehrere Rechnungen)

Bearbeitet wird die Inbox ueber das Tool-Hub-UI seit 04.05.2026.

Jeder Bankeingang erhaelt eine Klassifikation.

Wichtige Typen:

• AUTO_RESERVATION: eindeutige Reservierungs-Zuordnung via VWZ
• ADYEN_SETTLEMENT: Sammelueberweisung von Adyen (Online-Zahlungs-Provider) - 100-500 Einzelbuchungen
• EXTERNAL_AVIS: Avis-Pattern erkannt - DHME, Vonovia
• GROSSKUNDE: Stammkunde mit eigenem Avis-Pattern
• NO_MATCH: keine Apaleo-Reservierung passt
• GELDTRANSIT: Bargeld-Einzahlung, Konten 1360/1370

Klassifikationen werden NICHT aus der Inbox gefiltert - auch FullyPaid-Apaleo-Rechnungen erscheinen, weil sonst stille Drift entsteht.

Ein Multi-Property-Debitor ist ein Kunde (Firma oder Privatperson), der gleichzeitig in mehreren H24-Hotels offene Rechnungen hat.

Wichtig fuer Konsolidierung: Bei zentraler Mahnung muessen alle Properties einbezogen werden, sonst fragmentierte Kommunikation.

Net-Net ist der echte Beitrag eines Buchungskanals nach Abzug aller direkten Channel-Kosten.

Sequenz: Brutto -> Netto (MwSt raus) -> Net-Net (Provision + Cancellation-Anteil raus)

Direct-Buchungen haben Net-Net = Netto, weil keine Provision faellig wird. Booking.com mit 17% Provision hat deutlich niedrigeres Net-Net trotz oft hoeherer Brutto-Volumen.

Offene Forderungen ist die Summe aller noch nicht bezahlten Rechnungs-Brutto-Betraege.

Quelle: aging_snapshot in der Datenbank h24_debitor (befuellt taeglich 06:00 UTC durch die AR-Automation-Pipeline). Eingang sind alle Apaleo-Invoices, die noch nicht in sevDesk als bezahlt markiert sind (closed_at IS NULL).

Die Zahl ist ein Snapshot-Wert vom heutigen Morgen - nicht live.

Bank-Match Pilot ist seit 03.05.2026 ausschliesslich fuer H24LB aktiv.

Warum Pilot: Die AR-Automation braucht pro Property:

• sevDesk-Bankkonto-Sync (laeuft)
• Apaleo-Folio-Routing-Korrektheit
• VWZ-Pattern-Lernkurve
• Inbox-Workflow-Schulung

Andere Properties bekommen die Funktion nach Pilot-Auswertung. Das Aging zeigt aber alle Properties.

Top-Debitoren zeigt die Schuldner mit den hoechsten offenen Betraegen.

Aufschluesselung:

• Firmen (recipient_type = company): identifiziert ueber recipient_company_id
• Privatpersonen: gruppiert ueber recipient_name

Aufklappbar pro Debitor: alle einzelnen offenen Rechnungen mit Faelligkeitsdatum, Aging-Bucket und Betrag.

80/20-Regel gilt - meist sind 5-10 Debitoren fuer >50% des offenen Bestands verantwortlich.

Verwendungszweck (VWZ) ist das Freitext-Feld einer SEPA-Ueberweisung - typischerweise 140 Zeichen.

Was Gaeste typisch reinschreiben:

• Reservierungs-ID aus Buchungsbestaetigung
• "Reservierung TT.MM.YYYY"
• Gastname + Anreisedatum
• Manchmal nichts Verwertbares

VWZ-Anreicherung ist Pflicht-Stage im AR-Automation: Bei Match-Misserfolg IMMER VWZ nach Datum/Firma/Gastname/Gruppe/Reservierungs-ID durchsuchen UND in Apaleo aktiv nach Folios + Routings + Zielfolios suchen, BEVOR NO_MATCH zugewiesen wird.

VWZ-Datum schlaegt Tx-Datum - bei Vorauszahlungen ist das Anreisedatum aus VWZ der primaere Suchschluessel.

Im Tool-Hub-UI beantwortet die Buchhaltung Wizard-Fragen, wenn das System unsicher ist.

Beispiele:

• "Welche dieser 3 Reservierungen war gemeint?" -> User waehlt eine
• "Ist das eine Doppelzahlung?" -> Ja/Nein
• "Soll Differenz als Bankgebuehr verbucht werden?" -> Ja/Nein

Antworten landen in wizard_responses und werden als Trainingsdaten fuer Klassifikations-Verbesserung genutzt.

Avg Daily Pickup ist der Durchschnitt der taeglichen Buchungseingaenge ueber die letzten 14 Tage.

Wird als Trend-Approximation fuer die Forecast-Hochrechnung verwendet.

Wenn negativ (mehr Stornos als Neubuchungen): wird auf 0 geclamped.

Das Confidence-Band zeigt die Unsicherheit der Forecast-Hochrechnung.

Konvention:

• Low: OTB + Expected_Pickup * 0,80
• Mid (= Forecast): OTB + Expected_Pickup * 1,00
• High: OTB + Expected_Pickup * 1,20

Damit ergibt sich ein realistischer Bandbereich, statt einer truegerisch genauen Einzelzahl.

Expected Pickup ist die geschaetzte Pickup-Summe fuer den Rest des Monats.

Berechnung: Avg_Daily_Pickup * Tage_bis_Monatsende.

Beispiel: Wenn am 11.5. der Avg_Daily_Pickup bei 1.800 EUR liegt und noch 20 Tage bis Monatsende sind, ist Expected_Pickup = 36.000 EUR.

Forecast Total ist die Hochrechnung des Logis-Netto-Erloeses zum Monatsende.

Berechnung:

1. OTB heute = was schon gebucht ist
2. Avg Daily Pickup = (OTB_heute - OTB_vor_14_Tagen) / 14
3. Days Remaining = Tage bis Monatsende
4. Expected Pickup = Avg_Daily_Pickup * Days_Remaining
5. Forecast Total = OTB heute + Expected Pickup

Lineare Hochrechnung - keine Saisonalitaets-Korrektur, keine Wochentag-Gewichtung.

Forward Booking sind alle Reservierungen mit arrival_date in der Zukunft.

Eine Forward-Booking-Snapshot-Pipeline laeuft taeglich und friert pro Snapshot-Tag und target_month den Stand ein:

• snapshot_date = wann eingefroren
• target_month = welcher Anreise-Monat gemeint ist
• room_nights, logis_net_amount, booking_count

So entsteht eine Zeitreihe, in der man pro target_month sehen kann, wie der OTB-Stand sich ueber Tage verbessert (= Pickup).

On-the-Books beschreibt den Buchungsstand zu einem Stichtag - also "was haben wir heute schon im Buch fuer den Mai".

OTB-Werte:

• Logis-Netto im Buch
• Room-Nights bereits gebucht
• Booking-Count Anzahl Reservierungen

OTB ist ein Snapshot - wird taeglich um Mitternacht eingefroren. Pickup ist die Differenz zwischen heutigem und gestrigem OTB.

OTB naechste 90 Tage zeigt den OTB-Stand fuer den gesamten 90-Tage-Horizont (heute bis heute+90).

Praktisch fuer schnellen Ueberblick: wie sieht der naechste Quartals-Buchungsbestand aus?

Pickup 7d zeigt, wie viele Buchungen in den letzten 7 Tagen eingegangen sind.

Berechnung: OTB-Wert heute MINUS OTB-Wert vor 7 Tagen, beide bezogen auf denselben target-Horizont.

Pickup-Faustregel:

• Stadthotel im Schnitt: 5-10% des Monats-Logis pro Woche dazu
• Hochsaison: bis 15%
• Negativer Pickup: mehr Stornos als Neubuchungen - Warnsignal

Im Pace-Tab kann man tief drilldownen:

1. Monat-Ebene: Tabelle mit 12 Zukunfts-Monaten, jeder mit OTB-Logis und Pickup
2. Property-Ebene: Klick auf Monat zeigt OTB pro Property
3. Channel/Rateplan-Ebene: Klick auf Property zeigt OTB pro Channel + Rateplan

Damit kann man z.B. herausfinden: Mai Bernau ist 5% unter VJ - und der Drilldown zeigt, dass Booking.com schwaechelt waehrend Direct stark ist.

WINTER und 4STERNE sind Apaleo-Rate-Plans im Hotel Parkhotel Thale (H24PHT), die einen speziellen Arrangement-Workflow ausloesen.

Wenn eine Reservierung auf einem dieser Rate-Plans angelegt oder geaendert wird, sendet eine Webhook-Pipeline eine farbcodierte E-Mail an den Thale-Operativ-Verteiler:

• Blau: neue Buchung
• Rot: Storno

So bekommt das Thale-Team Bescheid, dass ein Wellness-/Erlebnispaket vorbereitet werden muss.

Ein Rateplan ist ein Apaleo-Konditionspaket - kombiniert Preisrahmen, Stornoregeln, Verpflegung.

Beispiele:

• BAR (Best Available Rate): Standard-Tarif, voll storno, ohne Verpflegung
• NRF (Non-Refundable): Rabatt 10%, keine Stornierung moeglich
• WINTER: Saisontarif fuer Winter-Spezialangebote
• 4STERNE: Bezeichnung fuer Drittanbieter-Booking-Pfad

Im Pace-Drilldown wichtig fuer Pricing-Analyse.

Im Pace-Tab vergleicht der VJ-Vollmonat den Forecast Total mit dem Vorjahres-Vollmonat-Logis-Netto.

Anders als der stichtagsgenaue VJ-Vergleich auf der Revenue-Seite, vergleicht Pace gegen den abgeschlossenen Vollmonat des Vorjahrs.

Sinnhaft, weil OTB+Forecast die Schaetzung fuer das Monatsende sind und man wissen will: schlagen wir den Vorjahres-Wert?

Aktiv-Quote zeigt, wieviel Prozent der jemals beschaeftigten Mitarbeiter heute noch aktiv sind.

Niedrige Quoten (<60%) bei Saisonbetrieben normal. Bei Stadthotels sollte die Quote ueber 75% liegen - sonst hohe Fluktuation.

Aktive Mitarbeiter sind alle Personen, die in Gastromatic als is_active=true gefuehrt werden.

Beinhaltet alle Beschaeftigungs-Typen:

• Festanstellung (Vollzeit/Teilzeit)
• Minijobs (520 EUR)
• Werkstudenten
• Aushilfe / Saisonkraefte

Nicht enthalten:

• Gekuendigte/abgemeldete (is_active=false)
• Geplante Stellen ohne Person ("No Name")

Quelle ist die taegliche Gastromatic-Sync.

BOA (Buro of Administration) ist die zentrale Buchungs- und Service-Organisation aller H24-Hotels.

Aufgaben:

• Reservierungs-Mails beantworten
• Telefonate annehmen (NFON-Telefonanlage)
• Rechnungen klaeren
• Beschwerden eskalieren

3 Arbeitsplaetze, derzeit ca. 5 BOA-Mitarbeiter.

Lohnquote ist die Personalkostenquote.

Branchen-Faustregel:

• Vollautomatisiertes Apartmenthotel (H24EW): 8-15%
• Hybrid-Stadthotel (SHB): 25-35%
• Wellness-/Restaurant-Hotel (H24HF): 35-45%
• Klassisches 4-Sterne mit Service: 40%+

Aktuell noch nicht aktiv im Dashboard, weil daily_shifts leer.

Gastromatic nutzt eigene Standortnamen (location_name), die nicht direkt mit den H24-Property-Codes uebereinstimmen.

Mapping:

• Bernau -> SHB
• Lichtenberg -> H24LB
• Eberswalde -> H24EW
• Thale -> H24PHT
• Hochfirst -> H24HF
• Sonnenberg -> HOTSOBRG
• Dsh -> DSH
• Teltow -> H24TELTOW

Die Locations Boa und Mgmt sind keine Properties (BOA ist die Buchungszentrale, Mgmt die Geschaeftsfuehrung).

Schichten-Daten kommen aus der daily_shifts-Tabelle in h24_gastromatic.

Aktueller Stand: Tabelle ist leer (Sync laeuft nicht). Sobald die Pipeline aktiv wird, fuettert sie taeglich:

• Geplante Schichten pro Mitarbeiter
• Geplante vs. Ist-Stunden
• Soll-Personalkosten pro Property
• Quote zur Logis-Erloes-Basis

Sobald Daten kommen, wird automatisch das Lohnquote-KPI im Dashboard sichtbar.

'No Name' in einem Stellenplan ist KEINE fehlende Stelle, sondern eine eingeplante aber noch unbesetzte Position.

Das heisst:

• Im Strukturvergleich voll zaehlen (Soll-Headcount)
• Nicht als "fehlt" interpretieren
• Wird besetzt sobald Bewerbung erfolgt

Stunden Soll vs Ist vergleicht die geplante Schicht-Dauer mit der tatsaechlich erbrachten Arbeitszeit.

Differenz = Ueberstunden (positiv) oder Minderstunden (negativ).

Wichtig fuer Lohnabrechnung: Stundenkonten muessen ausgeglichen sein.

Churn Risk identifiziert Gaeste, die wahrscheinlich abgewandert sind oder es bald sind.

Kriterien:

• Mindestens 2 Stays in der Historie
• Letzter Stay >= 90 Tage her (default, parametrisierbar)
• E-Mail-Adresse vorhanden

Sortierung nach CLV-Score absteigend - die wertvollsten Gefaehrdeten zuerst.

Aktion: typisch eine personalisierte E-Mail mit Special-Offer.

Customer Lifetime Value ist ein gewichteter Score, der den oekonomischen Wert eines Gastes ueber die gesamte Beziehungsdauer abbildet.

Eingangsfaktoren (gewichtet):

• Lifetime Revenue: Hauptfaktor
• Total Stays: Anzahl Aufenthalte
• Lifetime Nights: Naechte total
• Recency: wie lange der letzte Stay her ist (juenger = besser)
• Loyalty: Multi-Property-Bonus

Berechnung erfolgt im CRM-Reconciliation-Cron (03:00). Hoechste CLV-Werte typisch im VIP-Segment.

Im Dashboard wichtig fuer Top-Gaeste-Sortierung und Churn-Risk-Priorisierung.

Revenue per Stay = Lifetime_Revenue / Total_Stays.

Zeigt durchschnittliche Buchungsgroesse - wichtiger als Lifetime Revenue allein, weil ein Gast mit 1 grossem Stay (z.B. Familienevent) anders bewertet werden sollte als einer mit 10 Single-Naechten.

Das Gast-Segment ist eine Klassifizierung des Gastes basierend auf Aufenthaltshistorie und Lifetime-Revenue.

5 Stufen (mit echter Verteilung Mai 2026):

• einmalig: 1 Stay - ca. 14.550 Profile, Avg-Revenue 187 EUR
• wiederkehrend: 2-3 Stays - ca. 2.093 Profile, Avg-Revenue 458 EUR
• high_value: hoher Revenue, mittlere Stays - ca. 1.010 Profile, Avg 752 EUR
• stammgast: 4+ Stays - ca. 788 Profile, Avg 775 EUR
• vip: Top-Tier - ca. 394 Profile, Avg 1.997 EUR

Segmente werden taeglich um 03:00 vom CRM-Reconciliation-Cron aktualisiert.

High Value ist eine Segment-Stufe fuer Gaeste mit hohem Lifetime-Revenue, unabhaengig von Stay-Anzahl.

Beispiel: Geschaeftsgast mit 1 Aufenthalt fuer 1.500 EUR (Suite + Catering + Tagung) ist High Value, obwohl nur 1 Stay.

Unterschied zu Stammgast: Stammgast braucht mindestens 4 Stays - High Value reicht hoher Einmal-Revenue.

Lifetime Nights zaehlt alle Uebernachtungen eines Gastes ueber seine gesamte Historie.

Beispiel: Gast war 5x da, jeweils 2 Naechte = Lifetime Nights = 10.

Faustregel: Lifetime Nights > 20 = Stammgast.

Lifetime Revenue ist der Gesamt-Brutto-Erloes eines Gastes ueber alle Aufenthalte in allen H24-Hotels.

Wird taeglich aus stays-Tabelle aggregiert: SUM(total_gross_amount) je guest_profile_id.

Wichtig fuer Segment-Zuordnung und Churn-Priorisierung - VIP-Faelle (Lifetime > 5.000 EUR) sollten persoenlich angesprochen werden.

Nationalitaeten-Mix zeigt die Top-15 Herkunftslaender, basierend auf der Nationalitaet des primaeren Reservierungs-Gasts.

Quelle: reservation_guests.nationality_code (ISO-2-Code), gefiltert auf guest_role=primary.

Wichtig fuer Marketing-Steuerung: hoher Anteil aus DE/AT/CH = klassische DACH-Maerkte. Ploetzlich hoher PL/UA-Anteil deutet auf neue Werbekanaele oder Geschaefts-Anbindung hin.

New vs Returning zaehlt pro Monat:

• New = erstmaliger Stay (first_stay_date = month)
• Returning = mindestens ein vorheriger Stay (first_stay_date < month)

Die Wiederkehrer-Quote (returning / total) ist ein Loyalty-Indikator. Branchenwerte:

• < 15%: schwache Bindung, viel Walk-In/OTA
• 20-30%: gut, Direktbucher und Loyalty-Programm wirken

• 40%: sehr loyal, eher untypisch fuer Stadthotels

Rebooking Candidates sind Gaeste, deren letzter Aufenthalt vor 6+ Monaten war UND im selben Kalendermonat wie heute stattfand.

Logik: Wer letztes Jahr im Mai bei uns war (Wellness-Wochenende, Geschaefts-Termin, Kongress), kommt vielleicht dieses Jahr auch im Mai wieder.

Sortierung nach CLV-Score - die wertvollsten zuerst kontaktieren.

Die Segment-Schwellen sind regelbasiert (kein Machine-Learning):

• einmalig: total_stays = 1
• wiederkehrend: total_stays in [2, 3] AND lifetime_revenue < ~500
• high_value: lifetime_revenue >= 1.000 unabhaengig von Stays-Count
• stammgast: total_stays >= 4 AND lifetime_revenue >= 500
• vip: total_stays >= 4 AND lifetime_revenue >= 2.000

Schwellen werden im CRM-Reconciliation-Service definiert.

Stammgast ist die loyale Mittel-Klasse - 4+ Stays mit mittlerem Lifetime-Revenue (typisch 500-1.500 EUR).

Diese Gruppe ist die operative Basis fuer Wiederholungs-Buchungen. Gut behandelte Stammgaeste werden zu VIPs, vernachlaessigte werden zu Churn-Faellen.

Top-Gaeste zeigt die wertvollsten Gaeste nach CLV-Score.

Spalten:

• Name + E-Mail
• Firma (falls Geschaefts-Gast)
• Segment (vip, stammgast, etc.)
• Total Stays + Lifetime Nights
• Lifetime Revenue
• CLV-Score
• Properties (in welchen Hotels war Gast)
• Bevorzugter Channel + Bevorzugter Room-Type
• Letzter Stay

Praktisch fuer VIP-Pflege und persoenliche Marketing-Ansprache.

VIP ist die hoechste Segment-Stufe - kombiniert hohe Stay-Anzahl mit hohem Revenue.

Aktuell ca. 394 VIP-Profile mit Avg-Lifetime-Revenue 1.997 EUR. Diese Gruppe rechtfertigt eigene Kommunikations-Workflows: persoenliche Anrede, Upgrade-Garantien, Direktkontakt zur GF bei Beschwerden.

Cancellation Rate misst den Anteil stornierter Buchungen.

Schwellen:

• < 15%: gesund
• 15-25%: ueblich bei OTA-lastiger Distribution

• 30%: Warnsignal - entweder NRF-Anteil zu niedrig oder Pricing zu aggressiv

Storno-Rate haengt stark vom Tarif-Mix ab. Hotels mit hohem NRF-Anteil (Non-Refundable, ca. 10% Rabatt) haben strukturell niedrigere Storno-Quote.

Channel Trend zeigt die Direct/OTA-Verteilung pro Monat ueber die letzten 12 Monate.

Praktisch fuer Strategie-Bewertung: zeigt eine Direct-Marketing-Kampagne im Monat X tatsaechlich Wirkung im Monat X+1?

Saisonale Effekte: Hochsaison hat oft niedrigere Direct-Quote weil OTA-Last-Minute-Bucher dominieren. Off-Season hoehere Direct-Quote.

Channel-Mix zeigt die Verteilung der Buchungen nach Vertriebskanal.

Apaleo unterscheidet Channel-Codes wie:

• Direct: Direktbuchung (Telefon, Mail, Website)
• ChannelManager: Sammelkanal fuer alle ueber den Channel-Manager (DiRS) angebundenen OTAs
• BookingCom, Expedia, HRS: einzelne OTAs (selten direkt verbucht)
• Unbekannt: kein channel_code gesetzt

Bei H24 ist die OTA-Anbindung fast vollstaendig ueber ChannelManager.

ChannelManager ist in Apaleo der Sammel-Channel-Code fuer Buchungen, die ueber den Channel-Manager kommen.

Bei H24 ist das DiRS-Channel-Manager, der zentral an Booking.com, Expedia, HRS und weitere OTAs verteilt. Apaleo gruppiert diese unter ChannelManager statt nach OTA aufzuschluesseln.

Konsequenz: Im Channel-Mix dominiert ChannelManager numerisch. Wer einzelne OTA-Performance braucht (Booking vs Expedia), muss im Channel-Manager-Backend nachschauen.

Direct umfasst alle direkt vom Gast initiierten Buchungen - ohne OTA-Vermittler:

• Buchung via Hotel-Website (eigene Booking-Engine)
• Telefon-Reservierung (BOA)
• E-Mail-Anfrage
• Walk-In an der Rezeption

Vorteile: keine Provision, voller Datenzugriff (Email, Stammkunden-Pflege, Cross-Sell), bessere Margen.

Direct-Prozent ist der Anteil der Direktbuchungen.

Warum wichtig: Direct-Buchungen sind provisionsfrei und damit profitabler. Jede 1% mehr Direct-Quote bedeutet bei H24-Volumen ca. 6.000-10.000 EUR/Jahr Mehr-Marge.

Schwellen:

• < 25%: schwach, Direktbuchungs-Anreize fehlen oder Website unbrauchbar
• 30-45%: typisch fuer H24-Stadthotels (April 2026 ca. 32%)

• 50%: sehr stark, oft Wellness-/Spezialhotels mit Stammgaeste-Anteil

Steigerung typisch ueber: bessere Website-UX, Direkt-Booking-Anreize, aktive E-Mail-Pflege der Stammgaeste.

Lead Time misst die Vorausbuchungs-Zeit.

Buckets im Dashboard:

• 0 (Same Day): Walk-In oder Kurzfrist-Notbuchung
• 1-7 Tage: Last-Minute (typisch OTA)
• 8-14 Tage: Naheliegend
• 15-30 Tage: mittel
• 31-60 Tage: voraus
• 60+ Tage: Langfrist (typisch Direkt-Geschaeftsbuchungen, Tagungen, Familienfeiern)

Faustregel: hoher Same-Day-Anteil = OTA-getrieben. Hoher 60+-Anteil = Geschaefts-/Eventgaste-Mix.

Length-of-Stay (LOS) zeigt die Verteilung der Aufenthaltsdauer.

Aufschluesselung: 1, 2, 3, 4, 5, 6, 7+ Naechte.

Faustregeln pro Property-Typ:

• Stadthotel Geschaefts-Mix (SHB): hoher 1-2-Nachte-Anteil (Mo-Mi)
• Stadthotel Tourismus-Mix (DSH): 2-4 Nachte typisch (Wochenend-Trips)
• Wellness/Schwarzwald (H24HF): 3-7 Naechte typisch (Wellness-Aufenthalte)

No-Show Rate zaehlt Buchungen mit Status NoShow.

Schwellen:

• < 1%: sehr gut
• 1-3%: typisch

• 3%: Warnsignal - Garantie-Konfiguration pruefen, evtl. Vorauszahlungspflicht erweitern

Hohe No-Show-Rate kostet doppelt: Zimmer war reserviert (kein Walk-In moeglich) und Gast zahlt nicht oder nur erste Nacht.

OTA = Online Travel Agency. Klassische Vertreter: Booking.com, Expedia, HRS, Hotels.com, agoda.

Bei H24 laufen OTAs ueber den Channel-Manager (DiRS), der zentral Verfuegbarkeiten und Preise an alle OTAs verteilt.

OTA-Vorteile: Reichweite, Mobile-Conversion. Nachteile: 15-22% Provision, Loyalty-Verlust.

Attach Rate zeigt fuer jeden Service, bei welchem Anteil aller Stays er mitgebucht wurde.

Beispiel: Wenn Fruehstueck bei 60 von 100 Stays gebucht wird, ist die Attach Rate 60%.

Schwellen je Service:

• Fruehstueck: 50-80% typisch
• Parking: 15-35% (Stadthotels mit eigener Tiefgarage)
• Pet: 1-5% (Schwarzwald hoeher)
• Extra Bed: 2-8%

Niedrige Attach Rate = Cross-Sell-Potenzial ungenutzt.

Fruehstueck als Service unterscheidet sich von der Logis-Subkategorie Fruehstueck:

• Service: separat zur Reservierung dazugebucht (Add-On, in stay_services)
• Logis-Subkategorie: in Pauschale enthalten oder Apaleo bebucht direkt das F&B-Konto

Faustregel: Hotels mit hohem Tarif-Inklusiv-Fruehstueck (Wellness-Pakete) haben niedrigen Service-Attach-Anteil aber hohen Logis-Subkat-Erloes.

Parking als Service wird in Hotels mit eigener Tiefgarage als Add-On angeboten.

Pricing in H24-Portfolio:

• SHB Bernau: Tiefgaragenplatz, Tagespauschale
• H24LB Berlin-Lichtenberg: ebenfalls Garage
• H24EW Eberswalde: meist kostenfrei (kein Engpass)
• H24PHT Thale, H24HF Hochfirst: kostenfreie Aussen-Stellplaetze

Property-spezifische Attach Rates zeigen, wie ein Service in einzelnen Hotels laeuft.

Praktisch fuer Cross-Property-Lernen: wenn SHB eine Parking-Attach-Rate von 35% hat und H24LB nur 12%, lohnt sich ein Blick auf den Booking-Flow in Lichtenberg.

Service-Kategorien sind die typischen Add-On-Services in Hotels:

• Breakfast / Fruehstueck: separates Fruehstueck (wenn nicht in Tarif)
• Parking: Tiefgarage, Aussenparkplatz
• Pet / Haustier: Hund/Katze
• Extra Bed: Zustellbett, Babybett
• Late Check-out: Zimmer bis 14:00 statt 11:00
• Early Check-in: Zimmer ab 9:00 statt 15:00
• Wellness: Massagen, Pool-Eintritte (vor allem H24HF)

Service-Umsatz ist der Brutto-Erloes aus separat gebuchten Services - also alles was nicht in der Logis-Pauschale enthalten ist.

Quelle: stay_services-Tabelle, die alle Apaleo-Service-Buchungen pro Reservierung sammelt.

Wichtig: Wenn Fruehstueck im Tarif enthalten ist (Pakete), wird es NICHT in stay_services erfasst - sondern direkt in Logis aggregiert.

booker_company ist das Apaleo-Feld fuer die Firmen-Bezeichnung der Buchung.

Quelle: Buchungs-Eingabe in Apaleo. Wenn der Bucher seine Firma angibt, wird sie hier gespeichert. Sonst leer.

Wichtig: nicht jede Geschaefts-Buchung hat booker_company gesetzt. Wer als Privatperson bucht und vom Arbeitgeber erstattet wird, erscheint hier nicht.

Multi-Property-Firmen haben Buchungen in mindestens 2 H24-Hotels.

Praktisch fuer Account-Management: solche Firmen sind reife Cross-Sell-Kandidaten. Ein gemeinsamer Rahmenvertrag ueber alle 5 Hotels rechnet sich oft.

Im Dashboard markiert durch die properties-Spalte mit mehr als einem Property-Code.

Naechte/Buchung zeigt die Durchschnitts-LOS einer Firma.

Faustregeln:

• 1.0-1.5 Naechte: klassischer Geschaefts-Tagestermin (Mo-Mi-Verkehr)
• 2.0-3.0 Naechte: laengere Geschaefts-Trips, Workshops

• 4 Naechte: Tagungen, Trainings-Camps, Projekt-Einsaetze

Hohe Naechte/Buchung = Firma bringt mehr Logis pro Vorgang = effizientere Account-Bearbeitung.

Ein Rahmenvertrag ist eine bilateral vereinbarte Vertriebs-Konstellation zwischen H24 und einer Firma.

Typische Komponenten:

• Negotiated Rate: eigener Firmen-Tarif (oft 10-20% unter BAR)
• Zahlungsziel: 14, 30 oder 60 Tage netto
• Storno-Konditionen: oft kulanter als BAR
• Volumen-Mindestvereinbarung: jaehrliches Buchungs-Soll
• Management-Reporting: Quartals-Statistik

Bei H24 typisch fuer Konzern-Kunden mit hohem Volumen (Vonovia, DHME, regional grosse Bauunternehmen).

Top-Firmenkunden sind die wichtigsten Geschaefts-Stammkunden, sortiert nach Gesamt-Brutto-Umsatz.

Quelle: stays.booker_company - das ist das Firmen-Feld aus der Apaleo-Reservierung. Wenn nicht explizit gesetzt, zaehlt die Reservierung als Privatperson.

Praktisch fuer Account-Management: Top-Kunden sollten regelmaessig kontaktiert werden, gerade in den schwachen Monaten (typisch Januar, August). Top-10-Firmen verantworten oft 20-30% des Geschaeftsumsatzes.

Umsatz/Buchung = Lifetime_Revenue / Anzahl_Buchungen einer Firma.

Indikator fuer Buchungs-Volumen pro Vorgang. Firmen mit hohem Wert sind oft Tagungs-Bucher (mehrere Zimmer + Tagungsraum + F&B).

Day-of-Week Pattern zeigt die typische Wochentag-Verteilung von Auslastung und Rate.

Klassische Stadthotel-Kurve:

• Mo-Mi: hohe Auslastung, mittlere Rate (Geschaefts-Mix)
• Do: oft Spitze (Geschaefts + Wochenend-Anreise)
• Fr-Sa: hoehere Rate (Wochenend-Tarife), variable Auslastung
• So: niedrigste Auslastung - typischer Reparatur-Tag

Praktisch fuer Pricing-Strategie: schwache Tage (typisch So) brauchen Pickup-Specials, Spitzen-Tage Yield-Optimierung.

Forward Occupancy zeigt die erwartete Auslastung in den kommenden 30, 60 und 90 Tagen.

Berechnung: belegte Zukunftsnaechte / verfuegbare Zukunftsnaechte je Horizont.

Praktische Lesart:

• 30d Forward: was haben wir heute schon im Buch fuer den naechsten Monat
• 60d Forward: zeigt mittlere Sicht
• 90d Forward: Strategie-Sicht

Pace-Vergleich beantwortet: "Wo stehen wir 30 Tage vor Mai-Beginn im Vergleich zu 30 Tage vor Mai-Beginn 2025?"

Fundamentaler Unterschied zu reinem VJ-Vergleich (der vergleicht stichtagsgenau, nicht relativ).

Aktuell noch nicht voll implementiert, weil dazu Vorjahres-Snapshots auf relative Tage erforderlich sind.

Pickup und Pace werden oft verwechselt:

• Pickup: Differenz zwischen heutigem OTB und vergangenem OTB (z.B. vor 7 Tagen). Misst Neugeschaeft.
• Pace: Vergleich heutigen OTB mit OTB des Vorjahres zum gleichen relativen Tag (z.B. "85 Tage vor Anreise"). Misst, ob wir besser/schlechter als Vorjahr buchen.

Im Dashboard heisst der Tab Pace, die KPI ist Pickup. Echtes Pace-Reporting (Vorjahresvergleich auf relativen Tag) wuerde Vorjahres-Snapshots brauchen.

Im Forecast-Tab dient die Rebooking Candidates-Liste als Aktions-Inspiration:

Wer letztes Jahr im Mai bei uns war, kommt vielleicht dieses Jahr im Mai wieder. Sortierung nach CLV-Score - wertvollste zuerst kontaktieren.

Praktisch fuer Saison-getriggerte E-Mail-Kampagnen.

Der Saisonkalender definiert pro Property die Saisonzeiten - relevant fuer Pricing und Verfuegbarkeits-Strategie.

H24-Faustregel:

• Stadthotels (SHB, H24LB, H24EW): Geschaeftssaison Mar-Jun + Sep-Nov. Schwach: Jul/Aug, Dez/Jan.
• Schwarzwald (H24HF): Wintersaison Dez-Mar (Skifahren), Sommersaison Jul-Sep (Wandern). Schwach: Apr/Mai/Nov.
• Thale (H24PHT): Harz-Wandersaison Apr-Okt, Wellness-Wintersaison Dez-Feb.

Wird im RM-Pipeline-Skript gepflegt.

Seasonality Index ist ein normalisierter Index der monatlichen Stay-Anzahl.

Berechnung: Stays_im_Monat / Avg_Stays_aller_Monate * 100.

Lesart:

• Index 100: Durchschnittsmonat
• Index 130: 30% ueberdurchschnittlich (klassisch September fuer Stadthotels)
• Index 70: 30% unterdurchschnittlich (klassisch Januar)

Typische DACH-Hotellerie-Kurve:

• Jan/Feb: 70-85
• Mar-Jun: 100-120
• Jul/Aug: 90-110 (Sommerloch in Stadthotels, Spitze in Resort-Hotels)
• Sep/Okt: 130-145 (Stadt-Spitze: Messen, Tagungen)
• Nov: 110-125
• Dez: 70-90

Yield Management (auch Revenue Management) ist die dynamische Anpassung von Preisen und Verfuegbarkeiten basierend auf Forecast und Nachfrage.

Bei H24 laeuft das ueber RateBoard als Revenue-Management-Tool, ergaenzt durch eigene Daten aus Apaleo. Das Reporting Dashboard liefert die Trend-Daten (Pickup, Pace, Seasonality), die Entscheidungen treffen Revenue-Manager.

Aggressives Yielding kann kurzfristig RevPAR steigern, langfristig aber Stammgaeste vergraulen.

Benchmark fuer voll-/teilautomatisierte Apartmenthotels (typisch H24EW):

• Auslastung: 75-85% (effiziente Yield-Steuerung)
• ADR: 80-110 EUR (Mid-Scale, Apartments oft Premium)
• Lohnquote: 8-15% (kein Restaurant, kein Lobby-Service)
• Direct %: 25-35%
• LOS: 2-4 Naechte (laenger als klassisches Stadthotel)

Apartmenthotels sind durch Vollautomatisierung deutlich profitabler je RevPAR-Punkt - niedrige Fixkosten.

Benchmark-Werte fuer Stadthotels (Mid-Scale, 3-4-Sterne, DACH-Region):

• Auslastung: 70-80% (Jahresdurchschnitt)
• ADR: 90-130 EUR netto
• RevPAR: 60-90 EUR netto
• Direct %: 30-40%
• Cancel %: 15-25% (OTA-getrieben)
• Lead Time Median: 14-21 Tage
• LOS Median: 1.5-2.0 Naechte

Quellen: STR Hospitality Index, MKG Consulting Hotel Benchmarks. H24-Stadthotels (SHB, H24LB) sollten in dieser Range liegen.

Benchmark fuer Wellness-/Resort-Hotels (typisch H24HF Schwarzwald):

• Auslastung: 65-75% (Saison-getrieben)
• ADR: 130-200 EUR (Pakete inkl. HP/Wellness)
• LOS: 3-5 Naechte (klassisches Wellness-Wochenende oder -Woche)
• Direct %: oft 50%+ (Stammgaeste, hohe Loyalty)
• Cancel %: 10-15% (oft NRF-Pakete)

Wichtig: Wellness-RevPAR ist nicht direkt mit Stadthotel-RevPAR vergleichbar, weil Pakete F&B/Wellness mitenthalten.

Color-Coding zeigt schnell, welche KPIs gut/mittel/kritisch laufen.

Konvention im Benchmark-Tab:

• Gruen: Wert ueber Wohlfuehl-Schwelle
• Gelb: im Akzeptanz-Bereich
• Rot: unter kritischer Schwelle

Beispiel-Schwellen:

• RevPAR: gruen >60, gelb 40-60, rot <40
• Auslastung: gruen >75%, gelb 60-75%, rot <60%
• Direct %: gruen >35%, gelb 25-35%, rot <25%
• Cancel %: gruen <15%, gelb 15-25%, rot >25%

Gross Operating Profit ist das operative Ergebnis vor Pacht, Tilgung und Steuern.

Berechnung: Gesamtumsatz Netto - Wareneinsatz - Personalkosten - Energie/Reinigung/laufende OPEX.

Branchen-Benchmark:

• < 20%: schwach, Kostenstruktur pruefen
• 25-35%: typisch fuer Stadthotels
• 35-45%: gut, vollautomatisierte Hotels oder gute Marge

• 50%: ausgezeichnet, oft Wellness-Hotels mit hohen Pakete

Im Reporting Dashboard noch nicht direkt ausgewiesen - kommt mit Personal-/OPEX-Daten in spaeterer Phase.

Net-Avg-Rate per Night = AVG(stay.total_gross_amount / stay.nights).

Naeherung der ADR auf Basis stays-Tabelle (nicht transactions). Vorteil: pro Room-Type/Property aufschluesselbar. Nachteil: Brutto-basis, nicht so sauber wie ADR aus Logis-Netto / Room-Nights.

Die Property-Scorecard ist die zentrale Cross-Property-Vergleichstabelle.

Spalten je Property:

• Total Stays
• Total Nights
• Total Revenue (Brutto)
• Auslastung %
• ADR
• RevPAR
• Avg CLV
• Direct %
• Cancel %

Praktisch fuer Benchmarks: ist H24EW eigentlich besser oder schlechter als SHB im Vergleich? Bei verschiedenen Property-Typen (Stadt vs. Wellness vs. Apartment) lohnt es sich, Branchen-Benchmarks pro Typ heranzuziehen.

Room-Type Performance zeigt fuer jede Zimmer-Kategorie (Apaleo unit_group) Buchungen, Naechte, Revenue und Avg-Rate.

Praktisch fuer Pricing- und Renovierungs-Entscheidungen:

• Suiten mit niedriger Buchungs-Anzahl aber hoher ADR: nicht zwingend Problem (klassische Yield-Logik)
• Standard-Doppelzimmer mit niedriger Auslastung: Pricing pruefen, Marketing ankicken
• Junior-Suiten (oft Apaleo unit_group "JS") mit hohem Cancel-Anteil: Storno-Konditionen pruefen

BOA Response Quality ist die LLM-basierte Bewertung jeder einzelnen BOA-Mitarbeiter-Antwort an Gaeste.

Pipeline:

1. Tilebot-Routing-Block leitet Gast-Nachricht an menschlichen Operator (BOA-Mitarbeiter)
2. BOA antwortet
3. LLM-Eval-Worker (Sentiment-Listener) scort die Antwort auf 4 Achsen
4. Ergebnis landet in boa_response_eval (h24_qm_scores)

Aggregation pro Mitarbeiter zeigt Durchschnittswerte fuer Hoeflichkeit, Vollstaendigkeit, Sachlichkeit, Deeskalation. Plus Trend ueber 30 Tage.

Praktisch fuer Coaching und Performance-Pflege.

Chats Count zaehlt die Anzahl Konversationen pro Property pro Tag.

Wird taeglich um 04:00 UTC vom KPI-Rollup-Cron in kpi_daily_rollup geschrieben. Quelle: conversations-Tabelle in h24_tiledesk.

Vergleich mit Vortag/Vorwoche zeigt, ob Anfrage-Volumen steigt.

Completeness misst, ob die BOA-Antwort alle Fragen des Gasts adressiert hat.

Beispiel: Gast fragt "Wie sind die Fruehstuecks-Zeiten und gibt es Fruehstuecks-Buffet?"

• 5: beide Fragen beantwortet
• 3: nur eine Frage beantwortet
• 1: ausweichende Antwort, keine konkreten Infos

Niedrige Completeness = Gast muss nachhaken = mehr Aufwand fuer alle.

Correctness misst die sachliche Richtigkeit der Antwort.

Falsche Infos (z.B. falsche Check-in-Zeit, falsche Ratenangaben, falsche Stornoregeln) sind operativ kritisch - Gast kommt mit falschen Erwartungen an, Reklamation programmiert.

Niedrige Correctness = Coaching, Wissensbasis pruefen, Templates updaten.

Deeskalation misst die Faehigkeit der BOA-Antwort, eine kritische Situation zu entschaerfen.

Nur relevant bei Beschwerden, Reklamationen, negativem Sentiment.

• 5: empathisch, anerkennend, Loesungs-orientiert, Kompensations-Angebot
• 3: korrekt aber distanziert
• 1: defensiv, schuldzuweisend, ohne Empathie

Niedrige Deeskalation bei Beschwerden = Eskalations-Risiko, Gast geht zu Bewertungsplattform.

Escalation Rate misst, wie viele Konversationen mindestens einmal eskaliert wurden.

Berechnung: Escalations / Total Chats * 100.

Faustregel:

• <2%: gesund
• 5-10%: erhoeht - Ursachen-Analyse (welche Themen eskalieren?)

• 10%: kritisch - Prozess-Review

Hohe Escalation Rate kann viele Ursachen haben: schlechte FAQ-Qualitaet, ueberlasteter Operator-Pool, unklare Prozesse, problematische Buchungs-Welle.

Das Eskalations-Log sammelt alle Eskalations-Events aus der KI-QM-Pipeline.

Eskalations-Typen:

• sla_breach: SLA ueberschritten, automatischer SLA-Watcher-Trigger
• operator_select: Bot hat manuelle Operator-Bearbeitung angefordert
• manual: Mitarbeiter hat manuell eskaliert
• negative_sentiment_spike: ploetzlich stark negative Stimmung erkannt

Wichtig fuer Service-Verbesserungs-Workflows: regelmaessige Eskalations-Reviews zeigen Schwachstellen.

Failed Delivery Rate zeigt den Anteil der Nachrichten, die Meta/WhatsApp NICHT zustellen konnte.

Ursachen:

• Empfaenger hat WhatsApp deinstalliert
• Nummer fehlerhaft erfasst
• Empfaenger hat blockiert
• Tarif-/Compliance-Problem

5% = systematische Investigation noetig.

Politeness ist die erste der 4 QM-Achsen.

Skala 1-5:

• 5: warm, persoenlich, hoeflich (Anrede, Dank, freundlicher Ton)
• 3: neutral, korrekt aber distanziert
• 1: unfreundlich, kurz angebunden, ohne Anrede

LLM-Modell bewertet jede BOA-Antwort einzeln basierend auf Sprachstil. Werte unter 3 sollten zu Coaching fuehren.

Quality Avg Score ist der aggregierte Schnitt der 4 Quality-Achsen (Politeness, Completeness, Correctness, Deescalation) ueber alle BOA-Antworten einer Property an einem Tag.

Skala 1-5:

• >4,5: ausgezeichnet
• 3,5-4,5: gut
• 2,5-3,5: verbesserungswuerdig
• <2,5: kritisch - Coaching erforderlich

Resolution Time P50 ist die Median-Zeit zwischen Conversation-Start und -Close.

Misst nicht nur die Antwortzeit (P50/P95 Antwortzeit), sondern den gesamten Loesungs-Lifecycle.

Beispiel: Gast fragt nach Rechnung - BOA antwortet sofort, schickt Rechnung 30 Min spaeter, Conversation wird nach Bestaetigung closed. Resolution Time = 35 Min.

Resolution Time P95 ist das 95. Perzentil der Loesungs-Zeit.

Hohe Werte bei P95 bei moderatem P50 deuten auf "Hardcase"-Probleme hin: einzelne Faelle dauern extrem lange (Beschwerden mit Eskalation, juristische Klaerungen, Kompensations-Verhandlungen).

Response Time P50 ist die Median-Antwortzeit (50. Perzentil): die Haelfte aller BOA-Antworten kam schneller, die Haelfte langsamer.

Median statt Mittelwert, weil ein einzelner Ausreisser (z.B. Antwort nach 12h) den Mittelwert verzerrt. Median bleibt robust.

Faustregel:

• <120s (2 Min): exzellent
• <600s (10 Min): gut
• <3.600s (1h): akzeptabel

• 3.600s: zu langsam

Response Time P95 ist das 95. Perzentil: nur 5% aller BOA-Antworten waren noch langsamer.

Wichtiger als der Median fuer Service-Level-Bewertung - er zeigt, wie schlecht der schlechteste Fall war (ohne reine Ausreisser).

Faustregel:

• <600s: sehr gut
• <1.800s (30 Min): ok

• 3.600s (1h): SLA-relevant - kritisch

Sentiment Avg ist der durchschnittliche Sentiment-Wert einer Konversation.

Skala -1 bis +1:

• +0,5 bis +1: positiv, freundlich, danke
• 0: neutral, sachliche Frage
• -0,5 bis -1: negativ, frustriert, beschwerdefuehrend

Pro Gast-Nachricht wird ein Sentiment-Score erstellt (LLM-Eval), pro Conversation der Avg gebildet.

Die Sentiment-Heatmap visualisiert die Stimmung der Gast-Nachrichten ueber Zeit.

Achsen:

• X-Achse: Wochentag (Mo-So)
• Y-Achse: ISO-Wochen rueckwaerts
• Farbe: avg sentiment_avg (rot = negativ, gruen = positiv)

So sieht man Muster: ist Sonntag-Abend besonders negativ? Steigt das negative Sentiment um Feiertage?

Quelle: conversations.sentiment_avg in h24_tiledesk, gefuettert vom Sentiment-Listener.

Der SLA-Watcher ist ein Heartbeat-Service (5-min-Cron, critical-flow), der alle eingehenden Gast-Nachrichten gegen SLA-Zeiten prueft.

Wenn eine Nachricht laenger als SLA-Schwelle ohne Antwort bleibt:

• Eintrag in escalation_log mit reason = sla_breach
• Optional Alert via Telegram/Matrix

Standard-SLA bei H24:

• Tagsueber: 30-60 Minuten Antwortzeit
• Nachts: variabel (Notfall-Eskalation)

Sebastian-Direktive: critical heartbeat 5min - Watcher darf nie laenger als 5min ausfallen.

Templates Success Rate misst den Anteil erfolgreich zugestellter WhatsApp-Templates.

Templates sind vorab von Meta genehmigte Nachrichten-Vorlagen - Pflicht ausserhalb des 24h-Service-Windows.

Probleme bei Erfolgsrate <95%:

• Template nicht mehr genehmigt
• Empfaenger-Nummer ungueltig
• Format-Fehler in Variablen-Substitution