Der vollständige Leitfaden für White-Label-E-Signaturen für SaaS

Wenn Sie ein SaaS-Produkt mit elektronischen Signaturen entwickeln, haben Sie zwei Möglichkeiten. Sie können ein Signatur-Tool hinzufügen, das Ihre Benutzer daran erinnert, dass sie die Software eines Drittanbieters verwenden. Oder Sie können das gesamte Erlebnis mit einem White-Label versehen, so dass es sich wie ein nativer Bestandteil Ihres Produkts anfühlt.

Die meisten Entwickler denken bei White-Labeling an den Austausch eines Logos. In der Praxis geht das jedoch tiefer. Ein vollständig als White-Label gestalteter E-Signatur-Ablauf umfasst benutzerdefinierte Logos, Farbthemen, E-Mail-Domains, benutzerdefinierte E-Mail-Vorlagen, die Steuerung von Benachrichtigungen und eingebettete Schnittstellen. Und für mandantenfähige SaaS-Produkte müssen Sie in der Lage sein, das White-Labeling nicht nur für Ihre eigene Marke, sondern auch für die Marken jedes einzelnen Ihrer Kunden anzubieten.

Dieser Leitfaden deckt alles ab, was Sie benötigen, um ein vollständig markenangepasstes Signatur-Erlebnis mit Firma.dev aufzubauen.

Zwei Ebenen des White-Labelings

Dies ist der Punkt, den die meisten E-Signatur-APIs übersehen: SaaS-Unternehmen benötigen White-Labeling oft auf zwei Ebenen.

Ebene 1: Ihre Marke. Signatur-E-Mails kommen von Ihrer Domain. Die Signaturschnittstelle zeigt Ihr Logo und Ihre Farben. Das Ganze ist in Ihre App eingebettet. Ihre Kunden sehen den dahinterstehenden API-Anbieter nie.

Ebene 2: Die Marken Ihrer Kunden. Jeder Ihrer Kunden erhält sein eigenes Marken-Erlebnis. Deren Benutzer sehen E-Mails von deren Domain, nicht von Ihrer. Die Benutzeroberfläche für das Signieren zeigt deren Logo und Farbpalette. Dokumente und Vorlagen sind isoliert. Die Nutzung wird separat erfasst.

Eine Plattform für Immobilienverwaltung könnte beispielsweise Ebene 2 wünschen. Jedes Immobilienverwaltungsunternehmen auf der Plattform sendet Mietverträge von seiner eigenen Domain (leases@acmeproperties.com), und deren Mieter sehen das Logo und Branding dieses Unternehmens während des gesamten Signaturprozesses.

Eine HR-SaaS benötigt möglicherweise nur Ebene 1. Das Signatur-Erlebnis ist auf die HR-Plattform gebrandet, und alle Mitarbeiter ihrer Kunden interagieren mit dieser einzigen Marke.

Firma.dev unterstützt beides. Der Schlüssel dazu sind Customer Workspaces.

Customer Workspaces: Sichere Trennung durch Design

Mit Customer Workspaces können Sie isolierte Umgebungen für jeden Ihrer Kunden erstellen. Jeder Workspace verfügt über eigene:

• Vorlagen

• Signaturanfragen und Dokumente

• Nachverfolgung der Umschlag-Nutzung

• Logo- und Farbthemen

• E-Mail-Domain-Konfiguration

• E-Mail-Vorlagen

• API-Schlüssel (optional, für Zugriff auf Workspace-Ebene)

Es gibt keine workspaceübergreifende Offenlegung. Kunde A kann die Dokumente von Kunde B nicht sehen. Vorlagen, die in einem Workspace erstellt wurden, erscheinen nicht in einem anderen. Nutzungsberichte sind auf den jeweiligen Workspace beschränkt.

Hierbei geht es nicht nur um Organisation. Es geht um Sicherheit und Compliance. Wenn Sie Unternehmenskunden bedienen oder in regulierten Branchen (Gesundheitswesen, Finanzen, Recht) tätig sind, ist Datenisolation keine Option, sondern Pflicht. Workspaces bieten Ihnen diese Trennung, ohne dass Sie die Mandantenisolierung selbst entwickeln müssen.

Für SaaS-Plattformen, die kundenspezifische Dokumente und Workflows verwalten, sind Workspaces das Fundament. Sie erstellen einen Workspace für jedes Kundenkonto, und alles andere baut darauf auf.

Die sechs Säulen des White-Labelings

1. Visuelles Branding

Die sichtbarste Ebene des White-Labelings. Mit Firma.dev können Sie das Erscheinungsbild des Signatur-Erlebnisses sowohl auf Unternehmens- als auch auf Workspace-Ebene steuern.

Benutzerdefinierte Logos. Laden Sie Ihr Firmenlogo (PNG oder JPEG, bis zu 2 MB) hoch, damit es in Signatur-E-Mails und in der Signaturschnittstelle angezeigt wird. Bei mandantenfähigen Produkten kann jeder Workspace ein eigenes Logo haben, das den Standard des Unternehmens überschreibt. Wenn ein Workspace-Logo entfernt wird, wird automatisch wieder auf das Firmenlogo zurückgegriffen.

Farbthemen. Passen Sie die gesamte Farbpalette des Signatur-Erlebnisses mithilfe von Hex-Werten an. Sie steuern sechs Einstellungen: primäre Akzentfarbe, primärer Vordergrund (Text auf Schaltflächen), Seitenhintergrund, Textfarbe, Karten-/Panel-Hintergrund und Rahmenfarbe. Wie Logos können auch Farben auf Unternehmensebene festgelegt und pro Workspace überschrieben werden.

Firma.dev-Branding ausblenden. Aktivieren Sie show_custom_branding_only auf Unternehmensebene, um das gesamte Firma.dev-Branding vollständig aus dem Signatur-Erlebnis zu entfernen. In Kombination mit einem benutzerdefinierten Logo und Farbthema werden Ihre Benutzer niemals einen Hinweis darauf sehen, dass eine Drittanbieter-API im Spiel ist.

Anzeigeeinstellungen. Nehmen Sie Feineinstellungen für zusätzliche Details vor, z. B. ob Signaturzeichnungsrahmen und Wasserzeichen für Teildokumente angezeigt werden sollen. Diese Einstellungen sind auf beiden Ebenen verfügbar, und Workspace-Einstellungen erben von den Unternehmenseinstellungen, wenn sie auf Null gesetzt werden.

All dies folgt einer kaskadierenden Hierarchie: Die Workspace-Einstellung hat Vorrang, gefolgt von der Unternehmenseinstellung und schließlich den Standardeinstellungen von Firma.dev. Das bedeutet, dass Sie ein unternehmensweites Branding festlegen und dieses für bestimmte Workspaces selektiv überschreiben können. Siehe das White Labeling Guide für die vollständige API-Referenz.

2. Benutzerdefinierte E-Mail-Domains

Standardmäßig werden E-Mails mit Signaturanfragen von der Domain von Firma.dev gesendet. Mit benutzerdefinierten E-Mail-Domains kommen sie von Ihrer eigenen.

Sie können dies auf zwei Ebenen konfigurieren:

Unternehmensebene: Alle Workspaces erben Ihre Domain. E-Mails werden als documents@yourcompany.com versendet.

Workspace-Ebene: Jeder Workspace kann eine eigene Domain haben. Die E-Mails von Kunde A kommen von sign@customera.com. Die von Kunde B kommen von contracts@customerb.com.

Die Einrichtung umfasst das Hinzufügen von DNS-Einträgen (SPF, DKIM, DMARC), um die Inhaberschaft zu verifizieren und die Zustellbarkeit zu gewährleisten. Der Prozess ist API-gesteuert: Fügen Sie die Domain hinzu, verifizieren Sie die Inhaberschaft mit einem TXT-Eintrag, schließen Sie den Vorgang ab, um Ihre Sende-DNS-Einträge zu erhalten, und verifizieren Sie diese anschließend. Nach der Verifizierung ist die Domain sofort aktiv.

Eine Schritt-für-Schritt-Anleitung finden Sie unter How to White-Label Your E-Signature Emails and Signing Links.

3. Benutzerdefinierte E-Mail-Absenderadresse

Neben der Domain können Sie auch den lokalen Teil der Absenderadresse steuern. Standardmäßig verwenden E-Mails von einer benutzerdefinierten Domain support@yourdomain.com. Legen Sie mit email_local_part einen anderen Wert fest, wie z. B. noreply, signing oder documents.

Die vollständige Absenderadresse setzt sich aus drei Komponenten zusammen: dem Absendernamen (der Person, die die Signaturanfrage initiiert hat), dem lokalen Teil und der Domain. Jede Komponente wird über eine Fallback-Kette aufgelöst, wobei die Workspace-Einstellungen Vorrang vor den Unternehmenseinstellungen haben, die wiederum Vorrang vor den Standardwerten von Firma.dev haben.

Wenn Sie beispielsweise email_local_part auf noreply setzen und Ihre verifizierte Domain sign.acmecorp.com ist, werden E-Mails als Jane Smith <noreply@sign.acmecorp.com> gesendet.

4. Benutzerdefinierte E-Mail-Vorlagen

Firma.dev versendet im Laufe des Signatur-Lebenszyklus 11 Arten von automatisierten E-Mails: Signatureinladungen, Benachrichtigungen für den nächsten Unterzeichner, Erinnerungen zum erneuten Senden, normale Erinnerungen, Ablaufbenachrichtigungen, Stornierungsbenachrichtigungen, Ablehnungsbenachrichtigungen (sowohl an Unterzeichner als auch an Admins), Abschlussbestätigungen und Warnungen bei Identitätsänderungen von Unterzeichnern.

Sie können die Betreffzeile und den HTML-Inhalt jedes E-Mail-Typs anpassen, mit dynamischen Platzhaltern für Unterzeichnerdetails, Dokumenteninformationen und das Team-Branding. Platzhalter wie {{signer_name}}, {{signing_link}}, {{company_logo}} und {{team_name}} ermöglichen es Ihnen, Vorlagen zu erstellen, die sich völlig nativ in Ihr Produkt einfügen.

Vorlagen folgen der gleichen kaskadierenden Hierarchie wie alles andere. Legen Sie unternehmensweite Vorlagen für Konsistenz fest und überschreiben Sie bei Bedarf bestimmte Vorlagen pro Workspace. Sie können auch die integrierten Standardvorlagen von Firma.dev als Ausgangspunkt abrufen, die in 9 Sprachen verfügbar sind, darunter Englisch, Spanisch, Französisch, Deutsch und Portugiesisch.

Weitere Details finden Sie unter Custom Email Templates for Your E-Signature API.

5. Steuerung von Benachrichtigungen

Benutzerdefinierte Domains und Vorlagen ändern das Branding von E-Mails. Mit der vollständigen Steuerung von Benachrichtigungen können Sie diese ganz ersetzen.

Die automatisierten E-Mails von Firma.dev können pro Signaturanfrage mit vier booleschen Einstellungen deaktiviert werden: send_signing_email, send_finish_email, send_expiration_email und send_cancellation_email. Schalten Sie einige oder alle davon aus.

Wenn E-Mails deaktiviert sind, rufen Sie die Signatur-URLs über die API ab und senden Benachrichtigungen über Ihr eigenes System. Dies ermöglicht Ihnen:

• Ihre bestehende E-Mail-Infrastruktur zu nutzen (SendGrid, Postmark, Customer.io)

• Das Timing für Erinnerungen und Nachfassaktionen selbst zu steuern

• Benachrichtigungen basierend auf Ihrer eigenen Geschäftslogik auszulösen

• Signaturbenachrichtigungen in bestehende Kommunikationsabläufe mit Kunden zu integrieren

Einige Teams nutzen benutzerdefinierte Domains und Vorlagen, während Firma.dev die Zustellung übernimmt. Andere schalten alles aus und besitzen die gesamte Kommunikationsschicht selbst. Beides funktioniert.

6. Eingebettete Erlebnisse

Das Signatur-Erlebnis sollte sich nicht wie eine Weiterleitung zu einem anderen Produkt anfühlen. Mit eingebetteten Schnittstellen können Sie den gesamten Workflow in Ihre Anwendung integrieren.

Firma.dev bietet drei einbettbare Komponenten:

Signaturschnittstelle. Betten Sie den Signatur-Ablauf ein, sodass Empfänger Dokumente unterzeichnen können, ohne Ihre App zu verlassen. In Kombination mit individuellem Branding und show_custom_branding_only sehen Benutzer Ihr Logo, Ihre Farben und Ihre Navigation während des gesamten Prozesses.

Vorlagen-Editor. Ermöglichen Sie es Ihren Benutzern (oder den Benutzern Ihrer Kunden), Vorlagen direkt in Ihrer App zu erstellen und zu bearbeiten. Laden Sie Dokumente hoch, platzieren Sie Signaturfelder, definieren Sie Unterzeichnerrollen – alles innerhalb Ihrer Benutzeroberfläche.

Editor für Signaturanfragen. Konfigurieren Sie Signaturanfragen, fügen Sie Empfänger hinzu, legen Sie die Reihenfolge der Unterschriften fest und zeigen Sie eine Vorschau der Dokumente an, ohne Ihr Produkt zu verlassen.

Alle drei verwenden die JWT-Authentifizierung. Ihr Backend generiert einen kurzlebigen Token, und das Frontend lädt die Komponente in einem Iframe mit diesem Token. Es werden keine API-Schlüssel für den Client offengelegt.

Für Produkte, bei denen die Dokumentenvorbereitung ein zentraler Workflow ist, lohnen sich die eingebetteten Editoren aufgrund des Implementierungsaufwands. Ihre App fühlt sich nahtlos an, und Benutzer müssen nicht zu einer externen Schnittstelle wechseln. Siehe das Embeddable Signing Guide für vollständige Implementierungsdetails.

Die Einstellungen-Hierarchie

Alle Branding- und Konfigurationseinstellungen in Firma.dev folgen einer kaskadierenden Hierarchie:

1. Workspace-Einstellung (höchste Priorität)

2. Unternehmenseinstellung

3. Firma.dev-Standardwert (niedrigste Priorität)

Dies ermöglicht es Ihnen, unternehmensweite Standards festzulegen und diese pro Workspace zu überschreiben. Auf Workspace-Ebene bedeutet das Setzen eines Werts auf null "vom Unternehmen erben". Dies gilt für Logos, Farben, E-Mail-Domains, E-Mail-Vorlagen, Absenderadressen und Anzeigeeinstellungen.

Für mandantenfähige Produkte ist diese Hierarchie äußerst leistungsfähig. Legen Sie das Branding Ihrer Plattform auf Unternehmensebene fest, und lassen Sie dann jeden Kunden-Workspace bei Bedarf seine eigene Identität definieren.

Den richtigen Ansatz wählen

Nicht jedes Produkt benötigt ein vollständiges White-Labeling. So können Sie sich entscheiden:

Wenn Sie ein mandantenfähiges SaaS aufbauen, bei dem jeder Kunde sein eigenes Branding benötigt, fügen Sie Customer Workspaces zu einem dieser Ansätze hinzu. Das Workspace-Modell skaliert, egal ob Sie 10 oder 10.000 Kunden bedienen.

Implementierungs-Checkliste

Bevor Sie beginnen:

Definieren Sie Ihren White-Labeling-Umfang. Welche Kontaktpunkte sind am wichtigsten? Logos und Farben? E-Mails? Das Signatur-UI? Die Erstellung von Vorlagen? Erstellen Sie eine Map der User Journey und identifizieren Sie, wo ein Drittanbieter-Branding das Erlebnis stören würde.

Entscheiden Sie sich für Single-Brand vs. Multi-Brand. Wenn Sie pro Kunde ein eigenes Branding benötigen, planen Sie Ihre Workspace-Struktur frühzeitig. Erstellen Sie einen Workspace, wenn Sie einen neuen Kunden onboarden, und ordnen Sie alle seine Aktivitäten diesem Workspace zu.

Richten Sie zuerst das visuelle Branding ein. Laden Sie Ihr Logo hoch und konfigurieren Sie Ihr Farbthema auf Unternehmensebene. Das dauert nur wenige Minuten und verbessert sofort das Signatur-Erlebnis für alle Benutzer.

Fügen Sie Ihre E-Mail-Domain hinzu. Registrieren Sie Ihre Domain, fügen Sie die DNS-Einträge hinzu und verifizieren Sie diese. Dies ist für die meisten Produkte die Änderung mit der größten Wirkung, da es das Erste ist, was Empfänger wahrnehmen.

Passen Sie E-Mail-Vorlagen an. Rufen Sie die Standardvorlagen ab, passen Sie Text und HTML an Ihre Markenstimme an und legen Sie diese auf Unternehmens- oder Workspace-Ebene fest.

Planen Sie Ihre Strategie für eingebettete Elemente. Wenn Sie Elemente einbetten, entscheiden Sie, welche Komponenten Sie benötigen. Nur das Signieren? Auch die Vorlagenbearbeitung? Die einbettbare Signaturschnittstelle ist der am häufigsten gewählte Ausgangspunkt. Editoren für Vorlagen und Signaturanfragen bieten einen Mehrwert bei Produkten, bei denen die Dokumentenvorbereitung zum Kern-Workflow gehört.

Testen Sie den vollständigen Ablauf. Senden Sie eine Signaturanfrage über alle Touchpoints hinweg. Überprüfen Sie den E-Mail-Absender, den E-Mail-Inhalt, die Signaturschnittstelle und die Abschlussbenachrichtigung. Stellen Sie sicher, dass sich jeder Schritt wie Ihr eigenes Produkt anfühlt.

Die vollständige technische API-Referenz mit Codebeispielen für jedes hier behandelte Feature finden Sie im Firma.dev White Labeling Guide.

Was das kostet

Enterprise-E-Signatur-Plattformen verlangen oft hohe Gebühren für White-Labeling. Manchmal ist es ein separates Add-on. Manchmal ist es nur in einer höheren Preisstufe verfügbar.

Firma.dev enthält alle White-Labeling-Funktionen in jeder Preisstufe. Benutzerdefinierte E-Mail-Domains, eingebettete Editoren, eingebettetes Signieren, Customer Workspaces. Alles inklusive.

Nutzungsbasierte Abrechnung mit €0,029 pro Umschlag. Keine Verträge. Keine Mindestbeträge. Keine zusätzlichen Gebühren für das Branding Ihres Signatur-Erlebnisses.

Erste Schritte

Firma.dev enthält alle White-Label-Funktionen in jedem Tarif. Keine Premium-Pläne, keine Feature-Barrieren. Zahlen Sie 0,029 € pro Umschlag (~3¢ USD) und erhalten Sie Zugriff auf Logos, Farben, benutzerdefinierte Domains, E-Mail-Vorlagen, eingebettete Schnittstellen und Customer Workspaces.

Starten Sie mit Firma.dev kostenlos, keine Kreditkarte erforderlich.