Werkvertrag: was eine eigene Buchungsplattform als geschuldetes Werk ausmacht

Ein Werkvertrag verpflichtet den Auftragnehmer, einen vereinbarten Erfolg herzustellen, und den Auftraggeber, dieses Ergebnis nach der Billigung zu bezahlen. Für einen Betrieb, der Buchungen oder Bestellungen künftig über einen eigenen Kanal statt über Portale abwickeln will, ist das die naheliegende Form: Geschuldet ist die funktionierende Plattform, nicht die Zeit, die jemand daran sitzt.

Werkvertrag im BGB: Pflichten beider Seiten

§ 631 BGB beschreibt zwei Leistungen, die sich gegenüberstehen. Der Unternehmer stellt das versprochene Werk her; das kann eine Sache sein oder, wie das Gesetz sagt, ein anderer durch Arbeit herbeizuführender Erfolg. Der Besteller entrichtet die vereinbarte Vergütung. Bei individuell entwickelter Software wird in der Praxis überwiegend dieses Recht vereinbart; wie ein Gericht einen Einzelfall einordnet, hängt allerdings vom Zuschnitt des Auftrags ab.

• Unternehmer: liefert frei von Sach- und Rechtsmängeln (§ 633 BGB) und organisiert dafür Arbeit, Personal und Prüfschritte selbst.
• Besteller: nimmt das mangelfreie Ergebnis ab (§ 640 BGB), zahlt mit der Billigung (§ 641 BGB) und wirkt dort mit, wo das Werk ohne ihn nicht entstehen kann (§ 642 BGB).

Der letzte Punkt wird bei Plattformen gern unterschätzt. Ohne Zugang zum Kalendersystem, zur Warenwirtschaft oder zum Konto beim Zahlungsanbieter kann niemand eine Buchungsstrecke bauen, die mit diesen Programmen spricht.

Die Buchungsplattform als Werk: was sich beschreiben lässt

Ein Werk muss so benannt sein, dass beide Seiten am Ende dasselbe prüfen. Bei einem eigenen Vertriebskanal zerfällt es meist in Bausteine, die jeder für sich greifbar sind:

• die Buchungs- oder Bestellstrecke — Leistung wählen, freie Kapazität sehen, bezahlen, Bestätigung erhalten;
• die Anbindung an vorhandene Programme — jedes System mit Namen, den übertragenen Daten und der Richtung, in der sie fließen;
• der Abgleich mit den Portalen — welche Belegungen und Preise zwischen eigenem Kanal und Portal synchron gehalten werden;
• die App — mit den Funktionen und Geräteklassen, die tatsächlich geliefert werden;
• die Verwaltung — Preise, Sperrzeiten und Stornoregeln, die Mitarbeiter des Betriebs selbst pflegen.

Kein Werk ist dagegen „mehr Direktbuchungen“. Wie viele Kunden den neuen Kanal nutzen, hängt von Angebot, Saison und Werbung ab und lässt sich nicht herstellen. Herstellen lässt sich das Instrument, über das diese Buchungen laufen. Wie aus den Bausteinen prüfbare Sätze werden, zeigt der Artikel zur Leistungsbeschreibung.

Erfolg oder Tätigkeit: wo die Form nicht trägt

Nicht jede Arbeit rund um einen neuen Kanal ist ein Werk. Soll zuerst geklärt werden, ob sich der Umstieg von den Portalen überhaupt lohnt, welche Programme angebunden werden können und welche Buchungsregeln gelten, steht am Anfang eine Analyse. Ihr Ergebnis ist offen, deshalb passt dafür der Dienstvertrag, bei dem eine sorgfältige Tätigkeit geschuldet ist.

Umgekehrt verliert ein Vertrag seinen Charakter, wenn er zwar einen Erfolg nennt, im Alltag aber nur Stunden abgerufen werden: jede Woche neue Zurufe, kein festgelegter Umfang, keine Prüfung. Dann fehlt, was einen Werkvertrag ausmacht — ein Ergebnis, an dem sich Vergütung und Haftung festmachen lassen. Laufende Weiterentwicklung wird deshalb sauberer in einzelnen Paketen vergeben, jedes mit eigenem Umfang und eigener Abnahme.

Typische Lücken im Werkvertrag einer Plattform

1. Ein Portal als Maßstab. „Wie bei dem großen Buchungsportal“ ist keine Beschreibung. Portale bestehen aus Hunderten Funktionen, von denen ein Betrieb wenige braucht; welche, muss im Vertrag stehen.
2. Unklare Mitwirkung. Wer beantragt den API-Zugang beim Portal, wer verifiziert das Konto beim Zahlungsanbieter, wer liefert Fotos und Texte? Offene Fragen dieser Art verschieben Termine, ohne dass eine Seite etwas falsch gemacht hat.
3. Betrieb nach dem Livegang. Das Werk endet mit der Billigung. Hosting, Updates und die Anpassung an geänderte Portalschnittstellen brauchen eine eigene Vereinbarung.
4. Rechte und Zugänge. Offen bleibt oft, ab wann der Betrieb den Code nutzen darf und auf wessen Namen Domain, App-Store-Konto und Zahlungskonto laufen.

Wie wir Plattformaufträge zuschneiden

Bei Lotpfad Digital beginnt ein Auftrag für einen eigenen Kanal mit der Frage, welche Bausteine der Betrieb wirklich braucht und in welcher Reihenfolge sie live gehen sollen. Jeder Baustein bekommt im Angebot seine Prüfkriterien, bevor gebaut wird; geliefert wird in Etappen, die einzeln geprüft werden. Domain, Zahlungs- und Portalkonten laufen auf den Betrieb, und mit vollständiger Bezahlung gehen die Nutzungsrechte am eigens erstellten Code auf ihn über. Wie das für App und Weboberfläche aussieht, beschreibt die Seite App-Entwicklung, die Logik dahinter die Seite Softwareentwicklung.