Buchungs-Widget auf der eigenen Website: worauf es technisch ankommt

Holzschild mit der Aufschrift Reserved auf einem Restauranttisch

Ein paar Mal im Jahr werde ich gefragt, wie man Buchungen auf die eigene Website bekommt: ein Restaurant will Tische online vergeben, eine Praxis Termine, ein Handwerksbetrieb Beratungsgespräche. Die Antwort der Anbieter ist immer dieselbe, nämlich eine Zeile Code zum Einfügen. Das stimmt auch, nur entscheidet sich in dieser einen Zeile mehr, als die meisten vor der Unterschrift prüfen: wie schnell die Seite bleibt, wer die Daten der Kunden bekommt und wem am Ende die Buchung gehört.

Script-Tag, iframe oder fremde Seite

Technisch gibt es drei Wege. Beim Script-Tag lädt die Seite ein Skript des Anbieters, das die Buchungsmaske in einen leeren Container zeichnet. Das fügt sich optisch am besten ein, weil das Widget die Schriften und Farben der Seite übernehmen kann, gibt dem fremden Skript aber vollen Zugriff auf die Seite.

Ein iframe kapselt die Buchungsmaske in ein eigenes Fenster. Das ist die sicherere Variante, sieht öfter nach Fremdkörper aus und macht Probleme mit der Höhe: Wächst der Inhalt, wächst der Rahmen nicht automatisch mit, und man scrollt in einem Kasten.

Der dritte Weg ist ein Link auf eine Seite des Anbieters. Am einfachsten umzusetzen, und die schlechteste Variante für den Betrieb, weil die Besucher die eigene Website verlassen. Wenn diese Seite dann noch ein Marktplatz mit Konkurrenzangeboten ist, hat man Werbefläche für andere bezahlt.

Was das Widget mit der Ladezeit macht

Jedes eingebundene Werkzeug bedeutet eine zusätzliche Verbindung zu einer fremden Domain, und die kostet Zeit, bevor auch nur ein Byte Inhalt fließt: Namensauflösung, Verbindungsaufbau, Verschlüsselung. Drei Dinge sollte man deshalb prüfen.

  • Lädt das Skript mit async oder defer? Sonst hält es den Aufbau der Seite an, und die Besucher sehen für einen Moment nichts.
  • Bleibt der Platz reserviert? Ein Widget, das erst nach zwei Sekunden erscheint und den Text nach unten schiebt, ärgert nicht nur die Besucher, sondern zählt auch als Layoutverschiebung in den Kennzahlen, die Google für die Bewertung heranzieht.
  • Wie viel kommt tatsächlich über die Leitung? Der Netzwerk-Tab der Entwicklerwerkzeuge zeigt das in zehn Sekunden. Alles jenseits einiger hundert Kilobyte für eine Buchungsmaske ist reichlich.

Wer mehrere Anbieter testet, sollte das auf dem Telefon im Mobilfunknetz tun, nicht im WLAN am Schreibtisch. Der Unterschied ist erheblich.

Wer die Daten bekommt

Sobald das Widget lädt, kennt der Anbieter die IP-Adresse des Besuchers, und mit der Buchung bekommt er Name, Telefonnummer und oft eine Notiz zu Allergien oder Anlass. Das sind Daten der Kunden, verarbeitet von einem Dritten im Auftrag des Betriebs. Dafür braucht es einen Vertrag zur Auftragsverarbeitung nach Artikel 28 DSGVO, und den sollte man vor dem Vertragsabschluss sehen und nicht auf Anfrage hinterhergeschickt bekommen.

Zwei Fragen gehören dazu: Wo stehen die Server, und wer ist der Vertragspartner? Ein Anbieter mit Rechenzentrum in Frankfurt, dessen Mutterkonzern in den USA sitzt, ist etwas anderes als ein deutsches Unternehmen mit deutschen Servern. Und die eigene Datenschutzerklärung muss das Werkzeug benennen, sonst fehlt der Hinweis genau an der Stelle, an der Daten fließen.

Das Preismodell entscheidet mehr als der Funktionsumfang

Zwei Modelle sind verbreitet. Beim Festpreis zahlt man monatlich einen Betrag, egal wie viele Buchungen zusammenkommen. Bei der Provision zahlt man pro vermitteltem Gast, häufig verbunden mit einem Eintrag im Portal des Anbieters. Das klingt zunächst fair, ist aber ein anderes Geschäft: Ein volles Haus wird teurer, und die eigenen Stammkunden, die ohnehin gekommen wären, kosten plötzlich Geld, wenn sie über das Widget buchen.

Der zweite Punkt ist die Bindung. Zwölf Monate Laufzeit sind in dieser Branche üblich, monatliche Kündbarkeit nicht. Wie schnell aus einem Werkzeug eine Dauermiete wird, habe ich hier schon einmal ausführlicher beschrieben.

Der Ausstieg gehört vor den Einstieg

Vor der Anmeldung sollte klar sein, wie man wieder herauskommt. Lassen sich die Kundendaten als Datei exportieren, oder liegen sie nur in einer Oberfläche, aus der man sie abtippen kann? Was passiert mit Buchungen, die nach dem Kündigungstermin liegen? Und was, wenn der Anbieter selbst aufhört? Bei smarten Geräten habe ich beschrieben, was passiert, wenn der Hersteller die Cloud abschaltet. Bei einem Buchungssystem trifft es nicht den Wohnzimmerschalter, sondern den Umsatz des nächsten Wochenendes.

In eigener Sache

Weil ich in diesem Text Anforderungen aufliste, gehört die Offenlegung dazu: Ich baue selbst so ein System. Tavolo ist ein Reservierungssystem für Restaurants mit Festpreis statt Provision pro Gast, Widget für die eigene Website statt Marktplatz-Listing, Servern in Deutschland und monatlicher Kündbarkeit. Genau die Punkte also, an denen ich bei fremden Systemen hängengeblieben bin. Was dort gerade entsteht, steht im Entwicklungsblog, inklusive der Fehler, die mir dabei unterlaufen sind.

Wer selbst vor der Entscheidung steht: Die Kriterien oben lassen sich in einer halben Stunde durchgehen, bevor man irgendwo unterschreibt. Das ist deutlich weniger Aufwand als ein Umzug ein Jahr später.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

d1L Technik Blog: Web, IoT, Smartphones, Hardware und Software
Datenschutzübersicht

Wir verwenden Cookies, um Ihnen die bestmögliche Erfahrung auf unserer Website zu bieten.