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

Wenn Sie ein SaaS-Produkt mit E-Signaturen erstellen, haben Sie zwei Möglichkeiten. Sie können ein Signatur-Tool anbringen, das Ihre Benutzer daran erinnert, dass sie jemand anderes' Software verwenden. Oder Sie können das gesamte Erlebnis als White-Label gestalten, sodass es sich einheimisch für Ihr Produkt anfühlt.

Die meisten Entwickler denken, White-Labeling bedeutet den Austausch eines Logos. In der Praxis geht es tiefer. Ein vollständig weiß gekennzeichneter E-Signatur-Fluss umfasst benutzerdefinierte E-Mail-Domains, eingebettete Schnittstellen, Benachrichtigungskontrolle und sichere Mandantentrennung. Und für Multi-Tenant-SaaS-Produkte benötigen Sie die Möglichkeit, nicht nur für Ihre Marke ein White-Label zu erstellen, sondern auch für jede Marke Ihrer Kunden.

Diese Anleitung deckt alles ab, was Sie benötigen, um ein vollständig gebrandetes Signaturerlebnis mit Firma.dev zu erstellen.

Zwei Stufen des White-Labeling

Hier ist, was die meisten E-Signatur-APIs übersehen: SaaS-Unternehmen benötigen oft White-Labeling auf zwei Ebenen.

Stufe 1: Ihre Marke. Signiere-Mails kommen von Ihrer Domain. Die Signatur-Schnittstelle ist in Ihre App eingebettet. Ihre Kunden sehen nie den zugrunde liegenden API-Anbieter.

Stufe 2: Die Marken Ihrer Kunden. Jeder Ihrer Kunden erhält sein eigenes gebrandetes Erlebnis. Ihre Benutzer sehen E-Mails von ihrer Domain, nicht von Ihrer. Dokumente und Vorlagen sind isoliert. Die Nutzung wird separat verfolgt.

Eine Immobilienverwaltungsplattform könnte beispielsweise Stufe 2 wünschen. Jede auf der Plattform befindliche Immobilienverwaltungsgesellschaft sendet Mietverträge von ihrer eigenen Domain (leases@acmeproperties.com), und ihre Mieter sehen die Marke der Plattform überhaupt nicht.

Ein HR-SaaS könnte nur Stufe 1 benötigen. Das Signaturerlebnis ist auf die HR-Plattform gebrandet, und alle Mitarbeiter der Kunden interagieren mit dieser einen Marke.

Firma.dev unterstützt beides. Der Schlüssel liegt in den Kundenarbeitsbereichen.

Kundenarbeitsbereiche: Sichere Trennung von vornherein

Kundenarbeitsbereiche ermöglichen es Ihnen, isolierte Umgebungen für jeden Ihrer Kunden zu erstellen. Jeder Arbeitsbereich hat seine eigenen:

• Vorlagen

• Signaturanfragen und Dokumente

• Umschlagsnutzungsverfolgung

• E-Mail-Domain-Konfiguration

• API-Schlüssel (optional, für arbeitsbereichsabhängigen Zugang)

Es gibt keine Überkreuz-Arbeitsbereich-Exposition. Kunde A kann die Dokumente von Kunde B nicht sehen. In einem Arbeitsbereich erstellte Vorlagen erscheinen nicht in einem anderen. Nutzungsberichte sind auf den jeweiligen Arbeitsbereich beschränkt.

Es geht 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 Datenisolierung nicht optional. Arbeitsbereiche bieten Ihnen diese Trennung, ohne die Mandantentrennung selbst zu erstellen.

Für SaaS-Plattformen, die kundenspezifische Dokumente und Workflows verwalten, sind Arbeitsbereiche die Grundlage. Sie erstellen einen Arbeitsbereich für jedes Kundenkonto, und alles fließt von dort aus.

Die vier Säulen des White-Labeling

1. Benutzerdefinierte E-Mail-Domains

Standardmäßig stammen Signaturanfrage-E-Mails von der Domain von Firma.dev. Mit benutzerdefinierten E-Mail-Domains kommen sie von Ihrer.

Sie können dies auf zwei Ebenen konfigurieren:

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

Arbeitsbereichsebene: Jeder Arbeitsbereich kann seine eigene Domain haben. E-Mails von Kunde A kommen von sign@customera.com. Die von Kunde B kommen von contracts@customerb.com.

Die Einrichtung erfordert das Hinzufügen von DNS-Einträgen (SPF, DKIM, DMARC), um das Eigentum zu verifizieren und die Zustellbarkeit sicherzustellen. Sobald sie verifiziert sind, ist die Domain sofort aktiv.

Für eine schrittweise Anleitung siehe Wie man E-Signatur-E-Mails und Signaturlinks als White-Label angepasst.

2. Benachrichtigungskontrolle

Benutzerdefinierte Domains ändern den Absender. Volle Benachrichtigungskontrolle lässt Sie die E-Mails vollständig ersetzen.

Firma.dev sendet vier Arten von automatisierten E-Mails: Signaturanfragen, Abschlussbestätigungen, Ablaufwarnungen und Stornohinweise. Sie können jede oder alle von ihnen pro Signaturanfrage deaktivieren.

Schalten Sie sie aus, rufen Sie die Signierungs-URLs über die API ab und senden Sie Benachrichtigungen über Ihr eigenes E-Mail-System. Das lässt Sie:

• Ihre bestehenden E-Mail-Vorlagen und Markenstimmen angleichen

• Timing für Erinnerungen und Nachfassaktionen steuern

• Mit Ihrer transaktionalen E-Mail-Infrastruktur integrieren (SendGrid, Postmark, Customer.io)

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

Einige Teams verwenden benutzerdefinierte Domains mit den E-Mail-Vorlagen von Firma.dev. Andere schalten alles ab und kontrollieren die gesamte Kommunikationsschicht. Beides funktioniert.

3. Eingebettete Editoren

Das Unterzeichnerlebnis sollte sich nicht wie eine Weiterleitung zu einem anderen Produkt anfühlen. Eingebettete Editoren ermöglichen es Ihnen, den gesamten Workflow in Ihre Anwendung zu integrieren.

Firma.dev bietet zwei einbettbare Komponenten:

Vorlagen-Editor: Lassen Sie Ihre Benutzer (oder die Benutzer Ihrer Kunden) direkt in Ihrer App Vorlagen erstellen und bearbeiten. Dokumente hochladen, Signaturfelder platzieren, Unterzeichnerrollen definieren. Alles innerhalb Ihrer Benutzeroberfläche.

Signaturanfrage-Editor: Signaturanfragen konfigurieren, Empfänger hinzufügen, Unterzeichnungsreihenfolge festlegen und Dokumente ohne Verlassen Ihres Produkts sehen.

Beide Editoren verwenden JWT-Authentifizierung. Ihr Backend generiert ein kurzlebiges Token, und das Frontend lädt die Komponente mit diesem Token. Keine API-Schlüssel werden an den Client weitergegeben.

Für Produkte, bei denen die Dokumentenvorbereitung ein zentraler Workflow ist, lohnen sich eingebettete Editoren die Implementierungsbemühungen. Ihre App fühlt sich kohärent an, und Benutzer wechseln nie zu einer Drittanbieter-Schnittstelle.

Siehe Wie man eine Dokumentensignatur-API als White-Label in Ihr SaaS-Produkt integriert für eine vollständige Implementierungsübersicht.

4. Eingebettete Unterzeichnung

Das letzte Puzzlestück. Anstatt Unterzeichner auf eine gehostete Signierungsseite umzuleiten, betten Sie die Unterzeichnungsschnittstelle direkt in Ihre Anwendung ein.

Benutzer unterzeichnen Dokumente, ohne Ihre Domain zu verlassen. Sie sehen Ihre Kopfzeile, Ihre Navigation, Ihr Design. Die Unterzeichnungsoberfläche erscheint als nahtloser Teil Ihres Produkts.

Dies ist die vollständige White-Label-Lösung. Kombiniert mit benutzerdefinierten E-Mail-Domains und Benachrichtigungskontrolle begegnen Ihre Benutzer zu keinem Zeitpunkt im Workflow der Marke von Firma.dev.

Die richtige Herangehensweise wählen

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

Wenn Sie ein Multi-Tenant-SaaS entwickeln, bei dem jeder Kunde sein eigenes Branding benötigt, fügen Sie Kundenarbeitsbereiche zu jeder dieser Herangehensweisen hinzu. Das Arbeitsbereichsmodell skaliert, egal ob Sie 10 Kunden oder 10.000 bedienen.

Implementierungs-Checkliste

Bevor Sie beginnen:

Definieren Sie Ihren White-Labeling-Umfang. Welche Berührungspunkte sind am wichtigsten? E-Mails? Die Signierungs-Benutzeroberfläche? Vorlageerstellung? Verfolgen Sie die Benutzerreise und identifizieren Sie, wo das Branding Dritter das Erlebnis unterbrechen würde.

Entscheiden Sie sich für Einzelmarke vs. Mehrmarke. Wenn Sie ein brandingspezifisches Branding benötigen, planen Sie frühzeitig Ihre Arbeitsbereichsstruktur. Erstellen Sie einen Arbeitsbereich, wenn Sie jeden Kunden onboarden, und legen Sie alle ihre Aktivitäten auf diesen Arbeitsbereich fest.

Richten Sie DNS-Einträge ein. Benutzerdefinierte E-Mail-Domains erfordern SPF-, DKIM- und DMARC-Einträge. Koordinieren Sie sich mit Ihrem Operationsteam oder den IT-Teams Ihrer Kunden, wenn Sie arbeitsbereichsabhängige Domains einrichten.

Generieren Sie JWTs im Backend. Geben Sie keine API-Schlüssel an den Client weiter. Verwenden Sie kurzlebige Tokens (1-4 Stunden) für eingebettete Komponenten.

Erfüllen Sie die Compliance-Anforderungen. White-Labeling ändert nicht die rechtliche Gültigkeit von Signaturen. Firma.dev unterstützt ESIGN, UETA, eIDAS und andere Frameworks unabhängig vom Branding. Wenn Sie den Begriffsbildschirm von Firma.dev deaktivieren, stellen Sie sicher, dass Ihre eigenen Bedingungen die Zustimmung zur E-Signatur abdecken.

Was kostet das

Enterprise-E-Signatur-Plattformen erheben oft Premium-Gebühren für White-Labeling. Manchmal ist es ein separates Add-On. Manchmal ist es hinter einer höheren Preiskategorie gesperrt.

Firma.dev beinhaltet alle White-Labeling-Fähigkeiten auf jeder Preiskategorie. Benutzerdefinierte E-Mail-Domains, eingebettete Editoren, eingebettete Unterzeichnung, Kundenarbeitsbereiche. Alles inklusive.

Pay-as-you-go für $0.029 pro Umschlag. Keine Verträge. Keine Mindestmengen. Keine zusätzlichen Gebühren für das Branding Ihres Signierungserlebnisses.

Loslegen

Bereit zu bauen? Der Firma.dev White-Labeling-Leitfaden in unserer Dokumentation enthält die technischen Details: API-Endpunkte, Codebeispiele und Konfigurationsoptionen.

Oder steigen Sie direkt ein. Holen Sie sich Ihren API-Schlüssel und beginnen Sie, in Stunden zu integrieren, nicht in Wochen.