PriceLabs richtig einstellen: Warum der Autopilot allein Geld kosten kann

Autopilot ist eine Berechnung, keine Preisstrategie

Montagmorgen, 14 freie Nächte in den nächsten 30 Tagen, ein Stadtfest in sechs Wochen und drei Lücken zwischen bestehenden Buchungen: PriceLabs kann für jede Nacht einen Preis liefern. Es weiß aber nicht automatisch, welche Reinigungskosten eine Ein-Nacht-Buchung verursacht, ob Zimmer 12 wegen Baustellenlärm schwächer verkauft werden muss oder welche Gruppenanfrage noch nicht im PMS blockiert ist.

Genau deshalb kann ein technisch funktionierender Autopilot Geld kosten: Ein zu hoher Base Price bremst schwache Zeiten, ein zu niedriger Mindestpreis verkauft unter Deiner wirtschaftlichen Grenze, eine starre Mindestaufenthaltsregel lässt Lücken unverkäuflich und ein vergessener Override fixiert Preise länger als gedacht. Das ist kein Argument gegen Dynamic Pricing. Es ist ein Argument für ein kontrolliertes System.

Für Betriebe ab etwa zehn Einheiten oder kleine Hotels empfiehlt sich ein Dreiklang:

1. Leitplanken aus dem eigenen Betrieb definieren.
2. Regeln in PriceLabs nachvollziehbar abbilden und im PMS prüfen.
3. Abweichungen jede Woche bearbeiten.

Die folgenden Einstellungen sind Beispiele. Übernimm keine Prozentwerte oder Eurobeträge ungeprüft.

1. Den Base Price als Jahresmitte verstehen

PriceLabs beschreibt den Base Price als durchschnittlichen Übernachtungspreis über das ganze Jahr. Auf diesen Ausgangswert wendet das System Faktoren für Nachfrage, Saison und Marktbedingungen an. Der Base Price ist also weder Spitzenpreis noch Preisuntergrenze. PriceLabs bietet dafür im Pricing Dashboard ein Hilfswerkzeug; nach einer stabilen Laufzeit kann das System außerdem eine Empfehlung anzeigen. Solche Hinweise werden laut Anbieter nicht automatisch übernommen. Offizielle Erklärung zum Base Price.

Als wirtschaftlichen Plausibilitätscheck kannst Du vor dem Setup Deinen kostenbasierten Basispreis als Ausgangspunkt berechnen. Der Rechner zeigt einen Direkt- und einen Portalpreis; prüfe anschließend in PriceLabs und Deinem PMS, welche Provisionen oder kanalabhängigen Aufschläge bereits berücksichtigt werden. Markt- und Nachfragesignale kommen danach hinzu.

Leite Deinen Startwert nicht aus dem besten Samstag im Jahr ab. Prüfe stattdessen je Einheitentyp:

• realisierten Netto-Zimmerpreis beziehungsweise Netto-Übernachtungspreis der letzten zwölf Monate,
• Qualitäts- und Lageunterschiede gegenüber dem tatsächlich relevanten Vergleichsmarkt,
• enthaltene Leistungen, Reinigungsgebühr, Vertriebskosten und Steuern,
• neue oder renovierte Einheiten ohne belastbare Historie,
• geblockte Nächte, die Auslastung und Empfehlungen verzerren können.

Beispiel, nicht Empfehlung: Drei gleich große Apartments starten mit 115 Euro Base Price. Das ruhigere Apartment mit Balkon erhält 125 Euro, das Erdgeschoss an der Straße 105 Euro. Nach zwei Wochen vergleichst Du Buchungstempo, erzielten Preis und Marktposition — nicht nur die Auslastung. Ändere nicht gleichzeitig Base Price, Mindestpreis und Last-minute-Regel. Sonst weißt Du nicht, welche Änderung gewirkt hat.

2. Mindest- und Höchstpreis aus Grenzen ableiten

Der Mindestpreis ist keine gefühlte Schmerzgrenze. Rechne zuerst, was eine zusätzliche Buchung verursacht: variable Reinigung und Wäsche, verbrauchsabhängige Kosten, Vertrieb, Zahlungsgebühren, gegebenenfalls Frühstück oder Rezeption sowie den operativen Aufwand kurzer Aufenthalte. Gemeinkosten und Zielmarge gehören in eine bewusste betriebliche Entscheidung; eine einzige Formel passt nicht zu jedem Haus.

PriceLabs empfiehlt ausdrücklich, neben dem Base Price einen Mindestpreis zu setzen. Bei belegungsabhängigen Anpassungen begrenzen Mindest- und Höchstpreis die berechneten Preise. Dokumentation zu belegungsabhängigen Anpassungen.

Der Höchstpreis hat eine andere Aufgabe: Er schützt vor offensichtlich unplausiblen Raten und möglichen Fehlern. Setzt Du ihn zu niedrig, deckelst Du aber gerade die Nächte, in denen außergewöhnliche Nachfrage sichtbar wird.

Beispiel, nicht Empfehlung: Für einen Einheitentyp liegen Base Price, Minimum und Maximum bei 120, 82 und 310 Euro. Im Kalender prüfst Du anschließend je vier typische Daten: schwacher Dienstag, normaler Freitag, Ferienwochenende und Großveranstaltung. Ein plausibles Ergebnis in der Monatsansicht reicht nicht; die Extremfälle müssen passen.

3. Saisonlogik nicht doppelt stapeln

PriceLabs berücksichtigt Saisonabhängigkeit bereits in der Standardberechnung. Eigene saisonale Profile sind für zusätzliche Kontrolle gedacht, etwa in sehr saisonalen Märkten, bei kleinen Vergleichsgruppen oder eingeschränkter Preisflexibilität. Der Anbieter warnt, dass ein saisonaler Base Price zusätzlich zum Saisonfaktor wirken und Preise dadurch zu hoch oder zu niedrig treiben kann. Dokumentation zu saisonalen Preisprofilen.

Bevor Du ein eigenes Profil anlegst, beantworte drei Fragen:

• Welcher konkrete Fehler im Kalender soll behoben werden?
• Reicht eine Anpassung der Saisonempfindlichkeit oder einer Preisgrenze?
• Soll die Regel jährlich wiederkehren oder betrifft sie nur ein bestimmtes Jahr?

Beispiel, nicht Empfehlung: Statt pauschal „Sommer plus 25 Prozent“ einzutragen, prüfst Du zunächst Juli und August wochenweise. Vielleicht ist nur der Mindestpreis in den Ferien zu niedrig, während der bestehende Saisonfaktor die Nachfrage bereits sinnvoll abbildet. Dann veränderst Du nicht zusätzlich den Base Price.

4. Mindestaufenthalte vom Kalender her denken

Minimum Stay ist kein statischer Wert für das gesamte Jahr. PriceLabs unterstützt Standardregeln sowie besondere Regeln für Wochentage, Last minute, weit im Voraus liegende Daten, angrenzende Buchungen und sogenannte Orphan Gaps. Einstellungen können auf Listing-, Gruppen- oder Account-Ebene liegen. Wichtig: Bei Mindestaufenthalten gilt auf mehreren Ebenen nicht „alles addiert sich“. Die spezifischere Ebene kann das vollständige Regelset der allgemeineren Ebene ersetzen. Offizielle Übersicht der Mindestaufenthalte.

Eine brauchbare Logik beginnt mit dem operativen Ziel:

• Wie kurz darf ein Aufenthalt regulär sein?
• Welche Anreisetage tragen zwei oder drei Nächte?
• Wann lohnt eine kurze Buchung trotz zusätzlichem Turnover?
• Welche Regel verhindert neue, schwer verkäufliche Lücken?

Orphan Gaps bewusst freigeben

Eine Drei-Nächte-Regel kann eine freie Zwei-Nächte-Lücke zwischen Buchungen unbuchbar machen. PriceLabs kann den Mindestaufenthalt für solche Lücken an deren Länge anpassen oder darunter setzen. In der dokumentierten Hierarchie kann die Orphan-Regel andere Mindestaufenthaltsregeln übersteuern, wenn sie zu einem kürzeren Aufenthalt führt.

Beispiel, nicht Empfehlung: Standard sind drei Nächte. Für Lücken von ein bis drei Nächten erlaubst Du exakt die Lückenlänge; eine einzelne Nacht jedoch nur, wenn der Mindestpreis den zusätzlichen Turnover trägt. Prüfe danach nicht nur, ob die Lücke buchbar ist, sondern auch An- und Abreise sowie die im PMS sichtbare Restriktion.

5. Lead Time: Last minute und weit im Voraus trennen

Freie Nächte in fünf Tagen brauchen eine andere Entscheidung als freie Nächte in neun Monaten. PriceLabs bietet für Last-minute-Preise feste, prozentuale, schrittweise und marktgetriebene Varianten; je nach Algorithmus und Ebene unterscheiden sich verfügbare Optionen. Offizielle Last-minute-Dokumentation. Für weit entfernte Termine gibt es Far-out-Regeln. PriceLabs begründet den Aufschlag damit, nicht zu früh zu niedrigen Preisen zu verkaufen, wenn zukünftige Nachfrage und noch nicht angekündigte Events unsicher sind. Offizielle Far-out-Dokumentation.

Baue keine Rabattspirale. Formuliere stattdessen ein messbares Ziel pro Buchungsfenster:

• 0–7 Tage: Restnächte verkaufen, aber nicht unter die operative Untergrenze.
• 8–30 Tage: Buchungstempo gegenüber Plan und Markt beobachten.
• 31–90 Tage: Saison- und Wochentagseffekte nicht mit hektischen Eingriffen überlagern.
• weit im Voraus: Frühbuchungen nur zu einem Preis annehmen, der das gebundene Inventar rechtfertigt.

Beispiel, nicht Empfehlung: Du testest für vier Wochen einen moderaten Last-minute-Abschlag innerhalb von sieben Tagen und lässt den Mindestpreis unverändert. Bewertet werden zusätzliche Buchungen, erzielter Preis und Aufenthaltslänge gegenüber den vier Vorwochen und einem passenden Vorjahreszeitraum. Ein besserer Auslastungswert allein beweist noch keinen besseren Deckungsbeitrag.

6. Events prüfen, Overrides mit Ablaufdatum versehen

Marktdaten können Nachfrageereignisse erkennen, aber nicht jede lokale Besonderheit korrekt bewerten. Führe deshalb einen Veranstaltungskalender für Messen, Festivals, Schulferien, Firmenveranstaltungen und bekannte Sperrungen. Vergleiche die empfohlenen Preise mit Buchungstempo, Vorjahr und verfügbaren Wettbewerbern. Bei kleinen Märkten ist ein scheinbarer Ausschlag besonders prüfpflichtig.

Mit Date-Specific Overrides kannst Du für einzelne Daten Preise, Mindestaufenthalte sowie An- und Abreiseregeln verändern. Overrides sind auch auf Gruppen- oder Account-Ebene möglich; feste Preis-Overrides können andere dynamische Anpassungen verdrängen. PriceLabs bietet außerdem ein Ablaufkriterium für Overrides. Offizielle Dokumentation zu Date-Specific Overrides.

Nutze Overrides sparsam und dokumentiere immer:

• Anlass und betroffene Einheitengruppe,
• erwartetes Buchungsfenster,
• Preis- und Restriktionsänderung,
• verantwortliche Person,
• Prüfdatum oder Ablauf,
• Ergebnis nach dem Event.

So wird aus „plus 40 Prozent zur Messe“ eine prüfbare Entscheidung statt einer dauerhaften Altlast.

7. Ab zehn Einheiten: Gruppen statt Kopien

Bei zehn, zwanzig oder fünfzig Einheiten wird Einzelpflege zum Fehlerrisiko. PriceLabs unterstützt Anpassungen auf Account-, Gruppen-, Untergruppen- und Listing-Ebene. Nach der dokumentierten Hierarchie hat die spezifischere Ebene Vorrang. Gruppen können zum Beispiel nach Stadt, Lage oder Einheitentyp aufgebaut werden. Dokumentation zu Gruppen und Hierarchie.

Baue wenige verständliche Gruppen, etwa „City Studio“, „City Apartment“ und „Hotel Doppelzimmer“. Abweichungen auf Listing-Ebene sind Ausnahmen und brauchen einen Grund. Einmal pro Monat exportierst oder protokollierst Du, welche Listings lokale Regeln tragen. Sonst bleiben renovierte Zimmer, Eigentümervorgaben oder alte Tests unbemerkt außerhalb des Standards.

Aktiviere die Synchronisierung erst, nachdem Du Stichproben im PriceLabs-Kalender geprüft hast. Kontrolliere danach im PMS und auf mindestens einem Verkaufskanal Preis, Mindestaufenthalt und Verfügbarkeit für dieselben Testdaten. Eine korrekte Empfehlung, die nicht wie erwartet übertragen wird, ist betrieblich trotzdem falsch.

Der 30-Minuten-Wochencheck

Ein fester Termin ist wirksamer als gelegentliches Nachschauen. Für einen kleinen Betrieb reicht als Startpunkt oft diese Reihenfolge:

1. Datenqualität: neue Listings, blockierte Daten, Stornos und fehlende Buchungen prüfen.
2. Nächste 14 Tage: freie Nächte, Orphan Gaps, Mindestpreise und Last-minute-Regeln kontrollieren.
3. 15 bis 90 Tage: Auslastung, Pickup und erzielten Preis je Einheitentyp mit Plan, Vorperiode und Vorjahr vergleichen.
4. Events und Ferien: neue Termine ergänzen, bestehende Overrides prüfen, abgelaufene löschen.
5. 90 Tage plus: auffällig frühe Buchungen und ungewöhnlich hohe oder niedrige Empfehlungen untersuchen.
6. PMS-Stichprobe: mindestens ein schwaches Datum, ein Wochenende und ein Event über die gesamte Übertragungskette kontrollieren.
7. Änderungslog: pro Woche höchstens wenige gezielte Änderungen mit Hypothese und Prüftermin festhalten.

Monatlich folgt der tiefere Check: Base Price, Kostenuntergrenze, Maximalpreis, Gruppenstruktur, Saisonprofile und Performance nach Buchungsfenster. Damit bleibt PriceLabs automatisiert, aber nicht unbeaufsichtigt.

Gute Automatisierung hat einen Eigentümer

PriceLabs richtig einzustellen heißt nicht, jede Funktion einzuschalten. Es heißt, für jeden Einheitentyp eine plausible Basis, wirtschaftliche Grenzen, passende Aufenthaltsregeln und einen kontrollierten Umgang mit Events zu definieren. Der Algorithmus berechnet. Dein Betrieb entscheidet, was plausibel und profitabel ist.

Kein Setup garantiert mehr Umsatz oder Gewinn. Märkte, Daten, Kosten und Vertrieb ändern sich. Wer jedoch Beispiele testet, Änderungen einzeln protokolliert und den Wochencheck ernst nimmt, erkennt Fehlsteuerungen früher — bevor der Autopilot sie auf den ganzen Kalender verteilt.