Agent Experience Optimization: Wie KI-Buchungsagenten Ihre Dienste finden (oder übersehen)

Samstag, 8:14 Uhr morgens. Ein Kunde fragt seinen KI-Assistenten: „Finde mir heute Vormittag eine Yogastunde im Stadtzentrum, unter 30 Euro, Anfänger willkommen."

Der Agent öffnet keinen Browser. Er fragt sechs ihm bekannte Anbieter ab, sortiert die vier aus, die keine Echtzeit-Verfügbarkeit anbieten, und schließt zwei in die engere Auswahl ein — klare Preise, passendes Niveau, freier Slot um 10:15. Er bucht einen, zahlt die Anzahlung und legt die Bestätigung mit korrekter Zeitzone in den Kalender des Kunden.

Auf dieser Shortlist standen Sie nicht. Nicht, weil Ihr Studio schlechter ist. Sondern weil der Agent Sie nicht sehen konnte.

Das ist das neue Spiel. SEO sorgte dafür, dass Menschen, die in Google tippen, Unternehmen finden. Agent Experience Optimization (AEO) sorgt dafür, dass autonome KI-Agenten Sie über API-Aufrufe finden. Die Regeln sind andere. Den meisten Unternehmen ist das noch nicht aufgefallen.

AEO ist das neue SEO

Zwanzig Jahre lang hieß Auffindbarkeit „Ranking in einer Suchmaschine". Sie haben Titel optimiert, Überschriften strukturiert, Backlinks aufgebaut, um die obersten drei blauen Links gekämpft. Die Währung war Aufmerksamkeit — Menschen, die eine Seite scannen.

Agenten scannen keine Seiten. Sie rufen Funktionen auf. Ein KI-Buchungsassistent liest Ihren Hero-Bereich nicht, bewundert Ihre Fotos nicht, bemerkt Ihre Testimonials nicht. Er fragt: „Welche Dienste bieten Sie an? Was ist zwischen 9 und 11 am Samstag verfügbar? Wie sind Ihre Stornierungsbedingungen?" — und erwartet maschinenlesbare Antworten in Millisekunden.

Wenn die Antwort verlangt, dass ein Mensch ein Kalender-Widget interpretiert, existieren Sie nicht. Wenn Ihre Preise in einem PDF vergraben sind, existieren Sie nicht. Wenn Ihre „Echtzeit-Verfügbarkeit" einmal pro Nacht aktualisiert wird, existieren Sie nicht.

AEO ist die Disziplin, Ihre Buchungsinfrastruktur für Maschinen genauso mühelos lesbar zu machen, wie Ihre Website es für Menschen ist.

Was einen Dienst agent-readable macht

Vier Dinge braucht jeder AEO-fähige Buchungsdienst. Lassen Sie eines davon weg, und die Agenten lassen Sie weg.

1. Strukturierte Dienstdaten

Agenten müssen wissen, was Sie verkaufen — in maschinenlesbarer Form. Nicht „60-minütiger energetisierender Morgenkurs mit unserer preisgekrönten Trainerin" als fließender Text, sondern ein typisiertes Objekt: name, duration, price, currency, category, prerequisites, language, format (vor Ort/online), location, tags. Dieselben Felder für jeden Agenten, mit denselben Namen, jedes Mal.

Im offenen Web wurde dafür schema.org entworfen. Service, Reservation, OfferCatalog, LocationFeatureSpecification — eingebettet als JSON-LD, ermöglichen sie Crawlern und Agenten, Ihr Angebot zu verstehen, ohne das Layout zu parsen. API-seitig lebt dieselbe Struktur im Datenmodell Ihres Buchungssystems.

Wenn Sie nicht in einer einzigen Anfrage programmatisch „Gib mir den vollständigen Service-Katalog als JSON" beantworten können, ist Ihr Agent-Readability-Score null.

2. Live, maschinenlesbare Verfügbarkeit

Eine Buchungsseite, die für einen Menschen live aussieht (weil sie über JavaScript lädt), ist für einen Agenten ohne Browser-Engine oft unsichtbar. Agenten brauchen einen öffentlichen Verfügbarkeits-Endpunkt: bei gegebenem Service, Standort und Zeitraum gibt er offene Slots zurück.

GET /availability?serviceId=...&from=...&to=... mit einem JSON-Array von Slot-Objekten — Startzeit, Endzeit, Kapazität, Zeitzone — das ist der Vertrag. Statische HTML-Kalender, „Bitte anrufen", manuell synchronisierte Tabellen über Nacht: für Agenten alles wertlos.

Echtzeit heißt Echtzeit. Wurde ein Slot vor dreißig Sekunden gebucht, muss die nächste Agentenabfrage das widerspiegeln.

3. Stabile Identifier und IANA-Zeitzonen

Agenten räsonieren nicht über Ihre Daten — sie referenzieren sie. Jedes Projekt, jeder Service, jeder Standort und jeder Slot brauchen eine stabile, dauerhafte ID. Die Umbenennung eines Services darf seine ID nicht verändern. Eine Regionsmigration ebenfalls nicht.

Und jedes Zeitfeld muss eine explizite IANA-Zeitzone tragen — Europe/Berlin, America/New_York, niemals nur „+02:00" oder lokale Zeit ohne Kontext. Warum, haben wir im Zeitzonen-Beitrag erklärt. Wenn ein Agent einer Kundin in Tokio einen Therapeuten in Berlin für „15:00 Uhr" bucht, hat er keinen Spielraum zum Raten.

4. Transparente Preise und Richtlinien

Versteckte Gebühren, „Preis auf Anfrage", Anzahlungsregeln in den AGB versteckt — Agenten graben das nicht aus. Steht der Preis nicht als Zahl in der Antwort, behandelt der Agent Ihren Service als „Preis unbekannt" und reiht ihn unter klareren Konkurrenten ein.

Dasselbe gilt für Stornierung, Anzahlungen, Voraussetzungen, Altersgrenzen, Ausrüstung. Was ein menschlicher Gast vor der Buchung fragen würde, fragt auch der Agent — über Ihre API. Steht die Antwort nicht in einem strukturierten Feld, verlieren Sie den Slot.

Die MCP-Schicht: Wie Agenten tatsächlich mit Ihnen sprechen

Selbst mit allen vier Säulen bleibt ein Integrationsproblem. Jeder Agent in freier Wildbahn — Claude, ChatGPT, Gemini, Copilot, die nächsten zehn noch unbekannten Plattformen — bräuchte sonst einen eigenen Adapter, um mit Ihrer API zu sprechen.

Hier verändert das Model Context Protocol (MCP) die Mathematik. MCP ist ein offener Standard (ursprünglich von Anthropic vorgeschlagen, mittlerweile breit adaptiert), der einem Agenten erlaubt, sich mit einem Server zu verbinden, „Was kannst du?" zu fragen und eine selbstbeschreibende Liste von Operationen zurückzubekommen. Keine Sonderintegration. Kein Prompt Engineering pro Plattform.

Den Timerise MCP-Server haben wir in einem eigenen Deep-Dive beschrieben — 16 Tools, die den gesamten Buchungslebenszyklus abdecken, eingebunden unter /mcp. Für AEO zählt: Ein MCP-kompatibles Buchungssystem wird von einem Agenten in Sekunden onboardet. Ein Nicht-MCP-System verlangt, dass ein Entwickler von Hand ein Tool-Manifest schreibt, bevor der Agent es nutzen kann. Raten Sie, welches auf Shortlists landet.

Wenn schema.org die agent-lesbare Karte Ihrer Services ist, ist MCP die agent-lesbare Karte Ihrer Capabilities.

Wie Agenten Anbieter tatsächlich entdecken

Eine berechtigte Frage: Woher weiß ein Agent überhaupt, dass Ihr Studio existiert?

Heute dominieren vier Einstiegswege, und Sie sollten in mindestens zweien sichtbar sein:

• Marketplace-Plattformen mit öffentlichen Katalogen. Treatwell, ClassPass, Eventbrite, Booksy, Mindbody — Agenten beziehen über Partner-APIs bereits Live-Verfügbarkeit von dort. Dort gelistet zu sein, macht Sie für jeden Agenten auffindbar, der die Plattform integriert.
• Suchmaschinen, die strukturierte Daten verarbeiten. Googles /Reservation-Schema und entsprechende Bing/Apple-Pendants werden zunehmend von KI-Assistenten gelesen. Ihre Services mit ordentlichem JSON-LD auszuzeichnen, bleibt der billigste Weg, in Antworten allgemeiner KI-Suche zu landen.
• MCP-Registries. So wie npm Pakete listet und der App Store Apps, entstehen Verzeichnisse von MCP-Servern, in denen Agenten Buchungs-Backends nach Domain oder Kategorie nachschlagen. Ihren MCP-Endpunkt zu registrieren wird zum Äquivalent davon, 2005 eine Sitemap bei Google einzureichen.
• Hand-off aus bestehenden Kanälen. Ein Kunde fügt Ihren Buchungslink in seinen KI-Assistenten ein — „Buch mir das". Der Agent ruft den Link auf, findet (oder findet nicht) einen MCP-Endpunkt oder eine typisierte Verfügbarkeits-API und macht weiter. Dieser Pfad belohnt Unternehmen, deren Buchungsseite maschinenlesbare Haken bereitstellt — auch wenn der Einstiegspunkt menschlich war.

Sind Sie in keinem der vier präsent, haben Agenten keinen Weg zu Ihnen.

Die AEO-Checkliste (diese Woche)

Konkrete Schritte, die etwas bewegen — keiner verlangt einen Stack-Umbau:

1. Auditieren Sie Ihren Service-Katalog. Jeder Service bekommt: Name, Dauer, Preis, Währung, Kategorie-Tag, 1-2 Sätze Beschreibung — geschrieben fürs Matching, nicht fürs Marketing. Vage Titel wie „Premium-Paket" verlieren jeden Vergleich.
2. Stellen Sie einen öffentlichen Verfügbarkeits-Endpunkt bereit. Hat Ihr Buchungsanbieter keinen, ist das das Migrationssignal. Agenten scrapen kein Widget.
3. Fügen Sie schema.org/Service und schema.org/Reservation JSON-LD auf Ihren Buchungsseiten ein. Fünfzehn Minuten Arbeit, langfristiger Nutzen für KI-Suche.
4. Setzen Sie explizite IANA-Zeitzonen auf jeden Service und jeden Slot. Werfen Sie „local time" überall raus — eine stille Bug-Fabrik.
5. Machen Sie Richtlinien maschinenlesbar. Stornofrist, Anzahlungshöhe, Voraussetzungen, Sprache — Felder, keine Absätze.
6. Registrieren Sie Ihren MCP-Endpunkt, wenn Ihr Buchungssystem MCP unterstützt. Wenn nicht, fragen Sie Ihren Anbieter, wann.
7. Taggen Sie Services mit Intent-Keywords („anfängerfreundlich", „outdoor", „kinderfreundlich", „rollstuhlgerecht"). Agenten matchen lange auf Tags, bevor sie Beschreibungen parsen.
8. Verifizieren Sie, dass Ihre Echtzeit-Verfügbarkeit wirklich Echtzeit ist. Öffnen Sie zwei Browserfenster, buchen Sie in einem einen Slot, aktualisieren Sie das andere. Verzögerung = unsichtbar im entscheidenden Moment.
9. Tracken Sie Agententraffic separat. Versehen Sie programmatische API-Aufrufe mit einem eigenen User-Agent oder Auth-Scope, um zu sehen, wie viel Ihres Buchungsvolumens schon heute von Agenten kommt. Die meisten Betreiber sind überrascht.

Wo Timerise ins Bild passt

Timerise wurde API-first gebaut, lange bevor AEO einen Namen hatte, weil wir glaubten, die Buchungsschicht würde irgendwann häufiger von Software konsumiert als von Menschen. Konkret:

• Die GraphQL-API liefert einen vollständig typisierten Service-Katalog und Live-Verfügbarkeit — agent-readable per Konstruktion.
• Der MCP-Server unter /mcp exponiert 16 Buchungs-Tools an jeden MCP-kompatiblen Agenten — ohne Integrationscode.
• IANA-bewusste Zeitzonen-Behandlung sorgt dafür, dass grenzüberschreitende Buchungen nicht in die Local-Time-Falle laufen.
• Strukturierte Richtlinien (Anzahlungen, Stornofristen, Voraussetzungen, Formularfelder) leben als erstklassige Daten, nicht als Freitext-Disclaimer.
• Stabile IDs auf Projekten, Services, Standorten, Slots und Buchungen machen es für Agenten sicher, Ihre Daten über die Zeit zu referenzieren.

Nichts davon ist eine aufgesetzte Marketingschicht. Es ist die zugrundeliegende Form des Systems. Wenn Sie einen Service bauen, der 2026 und danach für Agenten auffindbar sein muss, ist das das Substrat, das Sie wollen.

Das Fenster ist offen — kurz

Jede frühere Distributionsverschiebung hatte ihr Fenster. Unternehmen, die ihr Google-Business-Profil vor der Konkurrenz öffneten, gewannen die lokale Suche. Die, die Live-Verfügbarkeit per API vor der Konkurrenz exponierten, gewannen Marketplace-Integrationen. Die, die sich vor der Konkurrenz als AEO-ready markieren, gewinnen die erste Welle KI-vermittelten Buchungstraffics.

Das Fenster bleibt offen, bis die Plattformen, die KI-Buchungen vermitteln, beginnen, ihre Default-Anbieter festzulegen — und sind diese Defaults erst einmal verhärtet, wird der Aufstieg dorthin ein jahrelanger Kampf. Gerade jetzt hören sie noch zu. Gerade jetzt sind Ihr Service-Katalog, Ihr Verfügbarkeits-Endpunkt und Ihr MCP-Server das Vorsprechen.

Zeigen Sie sich lesbar, und die Agenten finden Sie. Bleiben Sie unsichtbar, und Ihre Mitbewerber kassieren die Buchungen, die früher Ihr Telefon klingeln ließen.

---

Timerise ist API-first gebaut, mit nativer MCP-Unterstützung, IANA-Zeitzonen und maschinenlesbaren Servicedaten — dem Substrat, das KI-Agenten brauchen. Wenn Sie sehen möchten, wie AEO für Ihr Unternehmen aussieht — starten Sie ein Brief, öffnen Sie den Chat in der Ecke oder schreiben Sie uns an hello@timerise.ai.