Das Logo zu tauschen sind die leichten 20 %. White-Label scheitert an den Nähten — Absender-Adresse, Beleg-Fußzeile, Dashboard-URL, Favicon. Hier ist die vollständige Liste, wo ein Anbietername durchsickert.
Jede Plattform mit Enterprise-Tarif behauptet White-Label-Support, und für die meisten heißt das eine Sache: Du kannst dein Logo hochladen. Das deckt den Kopfbereich der Seite ab, die ein Gast neunzig Sekunden ansieht — also etwa 20 % der Fläche, auf der der Name deines Anbieters auftauchen kann.
Die anderen 80 % sind, wo es schiefgeht, und es geht zu einem vorhersehbaren Zeitpunkt schief: nicht beim Launch, sondern drei Wochen später, wenn dein Kunde eine Bestellbestätigung an seinen Steuerberater weiterleitet und jemand einen Namen in der Fußzeile bemerkt, von dem er nie gehört hat.
Hier ist die vollständige Inventur, grob geordnet danach, wie schnell sie auffällt.
Die Domain. Wenn der Storefront unter dein-anbieter.app/irgendein-slug liegt, ist alles andere egal. Es muss der eigene Hostname des Restaurants sein — also ein CNAME, den der DNS-Anbieter des Restaurants akzeptiert, und ein automatisch bereitgestelltes Zertifikat. Kein Support-Ticket, kein manueller Zertifikats-Upload, kein Ablaufdatum im Kalender.
Der Absender der Transaktionsmails. Das ist das häufigste Leck und das schädlichste, weil E-Mail das eine Artefakt ist, das weitergeleitet wird. Kommen Bestätigungen von noreply@anbieter.com, sieht das Restaurant aus wie der Wiederverkäufer von irgendwas. Und der Antwortpfad zählt genauso wie der Absender: Wenn ein Gast auf eine Bestätigung antwortet, um nach einem Allergen zu fragen, muss diese Nachricht beim Restaurant landen — nicht im unbeobachteten Postfach eines Anbieters.
Der PDF-Beleg. Belege werden gedruckt, abgelegt und an Buchhaltung und Steuerberater gegeben. Ein Anbieter-Logo in der Fußzeile eines Dokuments, das in der Buchhaltung eines Kunden landet, ist ein Gespräch, das du nicht führen willst. Diese Naht wird leicht übersehen, weil im Build-Team niemand jemals das PDF öffnet.
Die Dashboard-URL. Das Personal deines Kunden loggt sich jeden Tag ein. Tippt es dafür die Domain eines Anbieters, ist dieser Anbieter in seinem Kopf die Plattform — und du bist der, der sie eingerichtet hat. Genau die falsche Reihenfolge, wenn du derjenige sein willst, bei dem verlängert wird.
Das Favicon. Sechzehn Pixel, und es sitzt den ganzen Tag im Browser-Tab neben dem Logo des Kunden. Verschwindend klein und sofort sichtbar — eine schlechte Kombination, um sie falsch zu machen.
Die 404- und Fehlerseiten. Niemand gestaltet sie, und alle sehen irgendwann eine. Eine anbieter-gebrandete Fehlerseite ist die Naht, die genau dann auftaucht, wenn jemand schon genervt ist.
Die DNS-Einträge. Jede kompetente IT-Person bei deinem Kunden liest sie. Darauf kommen wir zurück, denn das ist die ehrliche Ausnahme.
Unser White-Label-Add-on kostet $49 im Monat zusätzlich zu Pro, und es existiert, um diese Liste zu schließen — nicht, um ein Logo-Feld freizuschalten. Konkret entfernt es das „Powered by Margord“ aus jedem Storefront, verlegt das Dashboard auf deinen eigenen Hostnamen, stellt Bestellbestätigungen auf einen gebrandeten Absender mit eigenem Favicon um und ergänzt eine Studio-Microsite — ein einseitiges Verzeichnis deiner Restaurants, jedes mit Logo, Namen und „Jetzt bestellen“-Link, auf deiner eigenen Domain.
Letzteres ist das Stück, das nicht nur das Branding, sondern das Verkaufsgespräch verändert. Es gibt einem Studio etwas zum Zeigen: eine Seite, die wie ein Portfolio lebender Kunden aussieht, auf der eigenen Domain, die sich selbst aktualisiert, sobald Restaurants dazukommen. Ohne sie beschreibst du deine Arbeit; mit ihr zeigst du sie.
Die Preisform ist ebenfalls Absicht. Es liegt außerhalb des Basis-Tarifs, weil viele Studios es wirklich nicht brauchen — wenn du unter eigenem Namen launchst und deine Kunden genau wissen, wer ihre Seite gebaut hat, wäre es sinnlos, dafür zu zahlen, uns zu verstecken. Und es sind $49 statt eines „Enterprise, sprechen Sie uns an“-Gesprächs, weil grundlegende Professionalität hinter einem Vertriebstermin zu verstecken eine eigene Art von Zumutung ist.
Der DNS-Eintrag ist sichtbar. Der CNAME eines Restaurants zeigt auf unsere Infrastruktur, und wer dig auf den Hostnamen ausführt, sieht, wohin er auflöst. Keine Konfiguration ändert das, und jeder Anbieter, der dir etwas anderes erzählt, ist entweder verwirrt oder lügt.
Das gehört klar gesagt, weil der Reflex ist, es als Produktlücke zu behandeln. Ist es nicht — so funktioniert das Internet, und es gilt für jeden White-Label-Dienst im Web. Agenturen verkaufen Hosting seit dreißig Jahren auf dieser Grundlage weiter.
Entscheidend ist, dass die Antwort leicht ist, wenn es aufkommt. „Wir betreiben die Bestellplattform auf spezialisierter Infrastruktur“ ist ein völlig normaler Satz für ein Studio, und ein Kunde, der technisch genug ist, einen DNS-Eintrag zu lesen, ist technisch genug zu wissen, dass jede Agentur das so macht. Das Problem war nie, dass es einen Subunternehmer gibt. Es ist, von ihm überrascht zu werden — es aus einer Beleg-Fußzeile zu erfahren statt von dir.
Das Ziel von White-Label ist also keine Täuschung. Es ist, dass Gäste, Personal und Steuerberater deines Kunden eine kohärente Marke sehen — und dass die Infrastrukturfrage in einem Termin aufkommt, in dem du die Antwort schon gerahmt hast.
Bei welcher Plattform du auch prüfst, diese eingeschlossen: Geh das in dieser Reihenfolge durch, bevor du einen Kunden darauf setzt.
From- und Reply-To-Header, nicht nur den Text.dig auf den Storefront-Hostnamen aus, damit du die Antwort kennst, bevor dein Kunde fragt.Die meisten Plattformen scheitern irgendwo zwischen drei und fünf. Das kostet etwa zehn Minuten und ist deutlich günstiger, als es von deinem Kunden zu erfahren.
Sei unter den ersten Studios auf Margord. Keine Kreditkarte nötig.