SaaS-Erklärvideo erstellen: Workflow in 7 Schritten

1. Platzierung, Zielgruppe und eine nächste Handlung festlegen

Beginnen Sie nicht mit einer Funktionsliste. Beginnen Sie mit der Seite oder dem Kanal, auf dem das Video erscheinen wird.

Ein Erklärvideo auf der Startseite muss meist drei Fragen schnell beantworten:

• Für wen ist das Video?
• Welches Problem hilft das Produkt zu verstehen oder zu lösen?
• Was soll das Publikum nach dem Ansehen tun?

Im InvoiceFlow-Test war die Zielgruppe ein Freelancer, der Rechnungen in mehreren Tools verfolgt. Die Geschichte hatte eine Aufgabe: zeigen, wie eine Rechnung von der Erstellung über den Zahlungsstatus bis zur Monatsübersicht wandert. Der CTA war festgelegt: Sehen Sie Ihren Monat an einem Ort.

Diese Grenze verhindert, dass das Video zu einer Führung durch jedes denkbare Dashboard wird. Sie liefert zugleich einen Abnahmetest. Wenn eine Szene dem Publikum nicht hilft, diesem Weg zu folgen, gehört sie nicht in diesen Schnitt.

Die Platzierung beeinflusst auch das Tempo. Ein Startseitenvideo kann einige Sekunden lassen, damit eine Produktaktion erkennbar wird. Ein Paid-Social-Schnitt braucht eventuell schnellere Wechsel. Ein Onboarding-Video kann länger bei einzelnen Bedienelementen bleiben. Wählen Sie zuerst die Platzierung und danach die Zieldauer.

2. Ein verbindliches Quellenbriefing erstellen

Das Quellenbriefing sollte freigegebene Fakten von der kreativen Richtung trennen. Das ist nützlicher als ein langer beschreibender Prompt, weil das Videosystem erfährt, was es erklären darf und was es nicht erfinden soll.

Ein SaaS-Erklärvideo-Briefing enthält:

• Zielgruppe und Platzierung.
• Freigegebene Produktaktionen.
• Der exakte CTA.
• Beispieldaten, die konsistent bleiben müssen.
• Aussagen, Werte und UI-Bezeichnungen, die nicht erscheinen dürfen.
• Format, Sprache, Sprechertext und ungefähre Dauer.

Der freigegebene Mechanismus für diesen Test war bewusst klein:

Ein Freelancer erstellt und sendet eine Rechnung an einem Ort. Wenn die Zahlung eingeht, gelangt dieselbe Rechnung in ein gemeinsames Register. Eine Monatsübersicht zeigt bezahlte und offene Arbeit.

Auch der Beispieldatensatz war fest: Client A, INV-001, $1,200. Diese drei Werte als eine Identität zu behandeln ist wichtig. Ändert eine spätere Szene den Kunden oder die Rechnungsnummer, verfolgt das Publikum nicht mehr denselben Datensatz.

Hier hilft eine Whitelist für sichtbare Texte. Sie enthält die Wörter und Werte, die die Motion Graphics zeigen dürfen. Eine Blacklist nennt nur einige Verbote. Eine Whitelist setzt eine deutlich klarere Grenze.

TapVids SaaS-Erklärvideo-Tool kann bereitgestelltes Material in Szenen und Sprechertext strukturieren. Geben Sie genügend Produktwahrheit für die Geschichte mit, lassen Sie das Tool aber keine Lücken füllen, die Ihr Produktteam beantworten sollte.

3. Die Geschichte in sichtbare Zustandsänderungen übersetzen

Eine Szenengliederung sollte beschreiben, was sich auf dem Bildschirm verändert, nicht nur, was der Sprecher sagt.

Die InvoiceFlow-Geschichte bestand aus fünf Schritten:

Jede Zeile enthält eine Zustandsänderung. „Ein Dashboard zeigen“ ist nicht präzise genug. „Dieselbe Rechnung von Sent auf Paid ändern, wenn die Zahlung eingeht“ lässt sich im fertigen Video prüfen.

Der Sprechertext sollte ebenso fokussiert bleiben. Die mittleren Zeilen des freigegebenen Skripts lauteten:

An einem Ort erstellen und senden Sie eine Rechnung.

Wenn Zahlungen eingehen, gelangen sie in ein gemeinsames Register.

Die Bilder zeigen den Mechanismus, während der Sprecher die Orientierung hält. Nennt ein Satz drei Produktaktionen, wird die Szene oft zu einer Ansammlung winziger Karten.

4. Den Plan prüfen, bevor ein Render verbraucht wird

Prüfen Sie vor der Generierung Szenentabelle und Skript gemeinsam. Achten Sie auf Timing, Kontinuität, unbelegte Sprache und Textdichte.

Nutzen Sie diese Checkliste vor dem Rendern:

• Hat jede Szene genau eine Hauptidee?
• Bleiben die Beispieldaten über alle Szenen hinweg gleich?
• Hat jede gesprochene Aussage eine sichtbare Aktion als Beleg?
• Ist eine Zeile für die zugewiesenen Sekunden zu lang?
• Ist der CTA exakt und keine Paraphrase?
• Ist die Hauptoberfläche in einem 16:9-Bild groß genug, um eingebettet lesbar zu bleiben?

In diesem Lauf enthielt der erste Problemtext ungefähr 39 Wörter für eine sechssekündige Szene. Das ließ sich bei normalem Tempo nicht verständlich sprechen. Wir ersetzten ihn durch: Rechnungen und Zahlungsstatus können über getrennte Tools verteilt sein.

Auch den Schluss ersetzten wir durch den exakten CTA. Diese Skriptänderungen funktionierten. Das endgültige Transkript enthielt alle fünf freigegebenen Zeilen in der richtigen Reihenfolge.

Damit war der Render noch nicht korrekt. Skriptabnahme und Videoabnahme sind getrennte Prüfungen.

5. Das Video generieren und den echten Schnitt prüfen

Der erzeugte Schnitt hatte 1280 × 720 Pixel bei 30 fps und Mono-AAC-Audio. Die gemessene Dauer betrug 16,83 Sekunden. Alle fünf Sprecherzeilen waren vorhanden, doch das geplante Timing wurde auf fünf Kapitel mit jeweils 1,9 bis 4,9 Sekunden komprimiert.

Die Szene zum Erstellen und Senden wirkte zunächst sauber. Die Hauptkarte war groß genug, und der freigegebene Kunde, die Rechnung, der Betrag und die Schaltfläche waren sichtbar.

Bei genauerem Hinsehen zeigte die Szene außerdem Draft, Feldbezeichnungen und früher in der Animation einen Zwischenstand von $0.00. Diese Inhalte lagen außerhalb der Whitelist. Das macht das Bild nicht vollständig unbrauchbar, zeigt aber, dass der Render die freigegebene Datengrenze nicht eingehalten hat.

Der schwerwiegendere Kontinuitätsfehler erschien in der nächsten Szene. Das Register änderte den Datensatz zu Acme Corp und #INV-2024-001.

Der Betrag blieb $1,200, aber ein übereinstimmender Wert reicht nicht. Das Publikum sieht eine andere Rechnung. Der beabsichtigte Zusammenhang von Erstellen über Senden bis Bezahlen ist unterbrochen.

Die Monatsübersicht ergänzte weitere unbelegte Ergebnisse: $0, FULLY SETTLED und NO OUTSTANDING.

Diese Zusätze wirken harmlos, verändern aber die Aussage. „Bezahlte und offene Arbeit zeigen“ beweist weder, dass nichts offen ist, noch dass alles vollständig beglichen wurde.

Prüfen Sie ein fertiges Erklärvideo deshalb als Abfolge und nicht als Sammlung attraktiver Einzelbilder. Sehen Sie es einmal ohne Pause an und kontrollieren Sie danach jede Mechanikszene auf exakte Namen, Werte, Zustandsänderungen und Übergänge.

6. Schwache Ergebnisse ablehnen und renderspezifisch überarbeiten

Die richtige Antwort auf einen fehlerhaften ersten Schnitt ist nicht immer „besser machen“. Diese Anweisung lässt dem System Raum, Skript, Stil und Daten erneut zu verändern.

Trennen Sie die Überarbeitung in vier Sperren:

Timing-Sperre. Weisen Sie jeder Szene eine feste Dauer zu. Für die nächste Version verlangten wir 6, 8, 8, 9 und 4 Sekunden, insgesamt 35 Sekunden. Die letzten vier Sekunden waren für den CTA reserviert.

Identitätssperre. Geben Sie den einzigen zulässigen Datensatz an: Client A, INV-001, $1,200. Dieselbe Zeile muss von Sent zu Paid wechseln.

Sperre für sichtbaren Text. Listen Sie die erlaubten Wörter und Werte auf und entfernen Sie ausdrücklich die im realen Schnitt gefundenen Fehler. Das ist stärker als eine Wiederholung des ursprünglichen Briefings, weil es auf beobachtete Fehler reagiert.

Kompositionssperre. Legen Sie ein lesbares Größenziel fest. Die Hauptoberfläche sollte 55 bis 70 Prozent des Bildes einnehmen, ohne winzige schwebende Karten und ohne einen zweiten Datensatz als Ablenkung.

Dieses Muster lässt sich wiederverwenden:

Behalten Sie das aktuelle Transkript unverändert. Rendern Sie dieselben fünf Szenen mit festen Dauern neu. Verwenden Sie nur einen Datensatz: [Kunde], [Rechnung], [Betrag]. Zeigen Sie an diesem Datensatz den Wechsel von [Status A] zu [Status B]. Zeigen Sie ausschließlich diesen freigegebenen Text: [Whitelist]. Entfernen Sie diese beobachteten Fehler: [tatsächliche falsche Bezeichnungen und Werte]. Halten Sie den exakten CTA für [Sekunden].

Das CTA-Bild selbst war klar, sein Kapitel dauerte jedoch nur 1,9 Sekunden und damit kürzer als gefordert.

Genehmigen Sie keinen Schnitt nur wegen eines guten letzten Bildes. Genehmigen Sie ihn erst, wenn der gesamte Pfad korrekt und lesbar bleibt.

Der nächste Render zeigt, warum auch eine Überarbeitung einen eigenen Abnahmetest braucht. Der korrigierte Schnitt behielt den freigegebenen Datensatz in der Rechnungsszene und führte diese Identität ins Register weiter.

Das Register verwendete anschließend dieselbe Rechnung, statt zu einem zweiten fiktiven Kunden zu wechseln. In der überarbeiteten Monatsübersicht erschien der Datensatz unter Paid work. Die Kategorie Outstanding work blieb sichtbar, ohne erfundene Summe oder die Aussage „vollständig beglichen“.

Das sind relevante Verbesserungen. Die Sperren für sichtbaren Text und Identität funktionierten. Die Timing-Sperre funktionierte nicht.

TapVids Projektchat beschrieb die Überarbeitung als 35-Sekunden-Render mit Szenen von 6, 8, 8, 9 und 4 Sekunden. Die heruntergeladene MP4 maß 16,833 Sekunden, und der Player zeigte weiterhin den komprimierten Schnitt mit fünf Kapiteln. Die Datei war neu: Prüfsumme und Größe unterschieden sich vom vorherigen Render. Die Revision änderte die Bilder, übernahm aber nicht das verlangte Tempo.

Damit eignet sich die letzte Version als Nachweis für die Überarbeitung, aber noch nicht als final freigegebenes Startseitenvideo. Wenn ein Editor meldet, eine Vorgabe sei angewendet worden, prüfen Sie exportierte Dauer, Kapiteltiming und vollständige Wiedergabe, bevor Sie die Datei als veröffentlichungsfähig einstufen.

7. Exportieren und an der Platzierung testen

Sobald eine Version die Inhaltsprüfung besteht, exportieren und untersuchen Sie die tatsächliche Datei. Prüfen Sie Dauer und Auflösung, statt nur der Editoranzeige zu vertrauen.

Vor der Veröffentlichung prüfen:

• Das Seitenverhältnis passt zur Platzierung.
• Sprechertext und Untertitel sagen dasselbe.
• Untertitel bleiben synchron und verdecken keine wichtigen Bedienelemente.
• Produktbezeichnungen sind in der echten Einbettungsgröße lesbar.
• Dieselben Beispieldaten bleiben in jeder Szene erhalten.
• Der CTA ist exakt formuliert und lange genug sichtbar.
• Wasserzeichen, Untertitel und Auflösung passen zum Zielkanal.

Für barrierefreie aufgezeichnete Medien sollten Untertitel die gesprochenen Informationen wiedergeben und synchron bleiben. Die Untertitel-Richtlinie der W3C Web Accessibility Initiative erklärt ihre Bedeutung für Menschen, die den Ton nicht hören können.

Sehen Sie das Video zuletzt auf der Seite an, auf der es erscheinen soll. Eine im großen Editor lesbare Szene kann in einer Startseitenspalte oder auf Mobilgeräten zu klein sein. Vereinfachen Sie dann die Komposition oder erstellen Sie einen platzierungsspezifischen Schnitt.

Wiederverwendbares Briefing für SaaS-Erklärvideos

Übernehmen Sie diese Struktur für Ihr nächstes Projekt:

Erstellen Sie ein [Dauer] langes SaaS-Erklärvideo im Format [Seitenverhältnis] für [konkrete Zielgruppe] aus diesem freigegebenen Material: [Quelle einfügen oder anhängen]. Das Publikum soll [einen Produktpfad] verstehen und diese Handlung ausführen: [CTA]. Zeigen Sie diese sichtbaren Zustandsänderungen: [Szenenaktionen]. Verwenden Sie nur diese Beispielnamen, Werte und Status: [Whitelist]. Fügen Sie keine Aussagen, Summen, Integrationen, Ergebnisse oder Kundendaten hinzu. Geben Sie Szenenplan und Sprechertext vor dem Rendern zur Prüfung zurück.

Prüfen Sie anschließend in dieser Reihenfolge: Quellenbriefing, Szenenaktionen, Sprechertext, erster Render, vollständige Wiedergabe, Dateimetadaten und Platzierung. So lässt sich leichter erkennen, ob ein Problem aus Quelle, Skript oder Renderer stammt.

Wenn Sie bereits Produkttexte oder ein Skript haben, können Sie mit TapVids KI-Erklärvideo-Generator beginnen und das verbindliche Quellenbriefing während der Prüfung neben dem Projekt behalten.

Ein SaaS-Erklärvideo erstellen, das wirklich veröffentlicht werden kann

Der sicherste Ablauf ist einfach: Behandeln Sie jedes generierte Video als Entwurf, bis die exportierte Datei dieselben Prüfungen wie das Skript besteht. Das Quellenbriefing kontrolliert die Produktwahrheit. Der Szenenplan macht jede wichtige Aussage sichtbar. Die Schlussprüfung bestätigt Identität, Zustandsänderungen, Timing, lesbaren Text, Untertitel und CTA in der tatsächlichen MP4.

Unser Test zeigt außerdem, dass die Qualität einer Überarbeitung wichtiger ist als die Anzahl der Versuche. Der zweite Render korrigierte den Beispieldatensatz und entfernte unbelegte Ergebnisbezeichnungen, ignorierte aber weiterhin den verlangten 35-Sekunden-Plan. Das bestätigt, dass jede Revision eine vollständige Artefaktprüfung benötigt.

Wenn Sie ein SaaS-Erklärvideo-Tool einsetzen, geben Sie freigegebenes Material und präzise Vorgaben vor und behalten Sie die redaktionelle Freigabe bei einem Menschen. So entsteht ein Video, das ein echtes Produkt erklärt, ohne generierte Details versehentlich zu Produktversprechen zu machen.

Häufige Fragen