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

Wenn Sie ein SaaS-Produkt mit elektronischen Signaturen erstellen, haben Sie zwei Möglichkeiten. Sie können ein Signier-Tool anhängen, das Ihre Benutzer daran erinnert, dass sie die Software eines anderen verwenden. Oder Sie können das gesamte Erlebnis als White-Label gestalten, sodass es sich nativ in Ihr Produkt einfügt.

Die meisten Entwickler denken, dass White-Labeling bedeutet, dass einfach ein Logo ausgetauscht wird. In der Praxis ist es tiefergehend als das. Ein vollständig als White-Label gestalteter E-Signatur-Ablauf umfasst benutzerdefinierte E-Mail-Domains, eingebettete Schnittstellen, Benachrichtigungskontrolle und sichere Mandantenisolation. Und für Multi-Tenant-SaaS-Produkte benötigen Sie die Fähigkeit, nicht nur für Ihre Marke, sondern auch für jede Marke Ihrer Kunden als White-Label zu fungieren.

Dieser Leitfaden behandelt alles, was Sie benötigen, um ein vollständig gebrandetes Signiererlebnis mit Firma.dev zu erstellen.

Zwei Ebenen des White-Labelings

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

Level 1: Ihre Marke. Signier-E-Mails kommen von Ihrer Domain. Die Signieroberfläche ist in Ihre App eingebettet. Ihre Kunden sehen nie den zugrunde liegenden API-Anbieter.

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

Eine Immobilienverwaltungsplattform möchte beispielsweise Level 2. Jedes Immobilienverwaltungsunternehmen auf der Plattform sendet Mietverträge von ihrer eigenen Domain (leases@acmeproperties.com), und ihre Mieter sehen die Marke der Plattform überhaupt nicht.

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

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

Kundenarbeitsbereiche: Sichere Trennung durch Design

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

• Vorlagen

• Signieranfragen und Dokumente

• Verfolgung der Umschlagnutzung

• E-Mail-Domain-Konfiguration

• API-Schlüssel (optional, für arbeitsbereichsbezogenen Zugriff)

Es gibt keine Überkreuz-Mandanten-Freigabe. Kunde A kann die Dokumente von Kunde B nicht sehen. In einem Arbeitsbereich erstellte Vorlagen erscheinen nicht in einem anderen. Nutzungsberichte werden pro Arbeitsbereich abgegrenzt.

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 Datenisolation nicht optional. Arbeitsbereiche bieten Ihnen diese Trennung, ohne selbst Mandantenisolation zu entwickeln.

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

Die vier Säulen des White-Labelings

1. Benutzerdefinierte E-Mail-Domains

Standardmäßig kommen E-Mails für Signieranfragen von der Domain von Firma.dev. Mit benutzerdefinierten E-Mail-Domains kommen sie von Ihrer.

Sie können dies auf zwei Ebenen konfigurieren:

Unternehmens-Ebene: Alle Arbeitsbereiche übernehmen Ihre Domain. E-Mails werden als documents@yourcompany.com versendet.

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 umfasst das Hinzufügen von DNS-Einträgen (SPF, DKIM, DMARC), um den Besitz zu verifizieren und die Zustellbarkeit sicherzustellen. Nach der Verifizierung ist die Domain sofort aktiv.

Für eine schrittweise Anleitung siehe Wie man E-Signatur-E-Mails und Signierungs-Links als White-Label gestaltet.

2. Benachrichtigungskontrolle

Benutzerdefinierte Domains ändern den Absender. Eine vollständige Benachrichtigungskontrolle ermöglicht es Ihnen, die E-Mails vollständig zu ersetzen.

Firma.dev sendet vier Arten von automatisierten E-Mails: Signieranfragen, Abschlussbestätigungen, Ablaufwarnungen und Stornierungsmitteilungen. Sie können jede oder alle davon pro Signieranfrage deaktivieren.

Schalten Sie sie aus, holen Sie die Signier-URLs über die API ab und senden Sie Benachrichtigungen über Ihr eigenes E-Mail-System. Dadurch können Sie:

• Ihre bestehenden E-Mail-Vorlagen und Markenstimme angleichen

• Timing für Erinnerungen und Nachfassaktionen kontrollieren

• In Ihr transaktionales 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 aus und übernehmen die gesamte Kommunikationsschicht selbst. Beide Ansätze sind möglich.

3. Eingebettete Editoren

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

Firma.dev bietet zwei einbettbare Komponenten:

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

Editieren von Signieranfragen: Signieranfragen konfigurieren, Empfänger hinzufügen, Signierreihenfolge festlegen und Dokumente anzeigen, ohne Ihr Produkt zu verlassen.

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 sind für den Client sichtbar.

Für Produkte, bei denen die Dokumentenvorbereitung ein zentraler Workflow ist, sind eingebettete Editoren die Implementierungsarbeit wert. Ihre App fühlt sich zusammenhängend an, und Benutzer wechseln nie zur Schnittstelle eines Drittanbieters.

Siehe Wie man eine Dokumentensignatur-API in Ihrem SaaS-Produkt als White-Label gestaltet für den vollständigen Implementierungsabriss.

4. Eingebettetes Signieren

Das letzte Stück. Anstatt Unterzeichner auf eine gehostete Signierungsseite weiterzuleiten, betten Sie die Signierungsoberfläche direkt in Ihre Anwendung ein.

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

Dies ist die vollständige White-Label-Lösung. In Kombination mit benutzerdefinierten E-Mail-Domains und Benachrichtigungskontrolle begegnen Ihre Benutzer in keinem Punkt des Workflows der Marke 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 seine eigene Branding benötigt, fügen Sie Kundenarbeitsbereiche zu einem dieser Ansätze hinzu. Das Arbeitsbereichsmodell skaliert, egal ob Sie 10 Kunden oder 10.000 bedienen.

Implementierungs-Checkliste

Bevor Sie beginnen:

Definieren Sie den Umfang des White-Labelings. Welche Berührungspunkte sind am wichtigsten? E-Mails? Die Signier-Benutzeroberfläche? Vorlagenerstellung? Kartieren Sie die Benutzerreise und identifizieren Sie, wo das Branding eines Drittanbieters das Erlebnis unterbrechen könnte.

Entscheiden Sie sich für Einzelmarke vs. Multimarke. Wenn Sie pro Kunde Branding benötigen, planen Sie frühzeitig Ihre Arbeitsbereichsstruktur. Erstellen Sie einen Arbeitsbereich, wenn Sie jeden Kunden an Bord holen, und überwachen Sie alle ihre Aktivitäten in diesem Arbeitsbereich.

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

Erzeugen Sie JWTs im Backend. Legen Sie niemals API-Schlüssel dem Client offen. Verwenden Sie kurzlebige Token (1-4 Stunden) für eingebettete Komponenten.

Compliance behandeln. White-Labeling ändert nicht die rechtliche Gültigkeit von Signaturen. Firma.dev unterstützt ESIGN, UETA, eIDAS und andere Rahmenbedingungen unabhängig vom Branding. Aber wenn Sie den Firma.dev-Bildschirm mit den Bedingungen deaktivieren, stellen Sie sicher, dass Ihre eigenen Bedingungen die Zustimmung zur elektronischen Signatur abdecken.

Was das kostet

Unternehmensplattformen für elektronische Signaturen berechnen oft hohe Gebühren für White-Labeling. Manchmal ist es ein separates Add-on. Manchmal ist es hinter einer höheren Preisstufe gesperrt.

Firma.dev enthält alle White-Labeling-Funktionen auf jeder Preisstufe. Benutzerdefinierte E-Mail-Domains, eingebettete Editoren, eingebettetes Signieren, Kundenarbeitsbereiche. Alles inbegriffen.

Pay-as-you-go bei €0,029 pro Umschlag. Keine Verträge. Keine Mindestanforderungen. Keine zusätzlichen Gebühren für das Branding Ihres Signiererlebnisses.

Loslegen

Bereit zum Bauen? Der Firma.dev White-Labeling-Leitfaden in unseren Dokumenten enthält die technischen Details: API-Endpunkte, Codebeispiele und Konfigurations Optionen.

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