Videoproduktion für SaaS-Unternehmen
Software ändert sich schneller als Video. Ein SaaS-Film wird gegen ein bewegliches Interface geplant — und gegen Screens voller Daten, die niemand sehen darf.
Worum es geht
Das erste Liefergut eines SaaS-Drehs ist kein Material, sondern eine Demo-Umgebung: ein Tenant voller fiktiver, aber plausibler Daten — denn echte Kundennamen, Kennzahlen oder Dokumente auf dem Screen sind ein DSGVO-Vorfall, kein Schönheitsfehler. Das Interface selbst wandert — Releases zwischen Aufnahme und Veröffentlichung ändern Buttons und Layouts. Der Plan pinnt deshalb einen UI-Stand, friert Feature-Flags für den Demo-Tenant ein und plant Re-Capture-Fenster. Die Besetzung ist verteilt: Gründer, Kundinnen und Produktleute sitzen in verschiedenen Städten — Remote-Aufnahme-Kits, Licht-Anleitung und konsistente Kadrage werden Teil der Pre-Production. Und die Geschichte muss dem entsprechen, was das Produkt sichtbar tut — ein versprochener Workflow, den der Screen nicht zeigt, wirkt wie Fiktion.
Branchenroutine schlägt Allgemeinwissen: Wer die typischen Freigabewege und Auflagen des Feldes kennt, plant realistischer als jemand mit mehr Drehtagen, aber ohne Branchenerfahrung.
Was hier anders läuft
Die Punkte, an denen sich das von anderen Fällen unterscheidet:
- Ein eigener Demo-Tenant mit fiktiven Daten entsteht vor dem Dreh — echte Kundendaten auf dem Screen sind ein Datenschutz-Vorfall
- UI-Stände werden gepinnt: Feature-Flags für die Demo-Umgebung eingefroren und ein Re-Capture-Fenster vor der Veröffentlichung eingeplant
- Screen-Recordings folgen einer Spezifikation — Auflösung, Cursorverhalten, Timing — damit Captures aus verschiedenen Wochen zusammenschneiden
- Remote-Mitwirkende nehmen mit verschickten Kits und Live-Regie auf; ihre Kadrage und ihr Licht sind geplant, nicht erhofft
- Produktaussagen decken sich mit sichtbaren Workflows — das Skript wird gegen den aktuellen Build geprüft
Was der Plan liefern muss
Ein Produktionsplan ist für dieses Gewerk dann brauchbar, wenn er das hier hergibt:
- Ein Demo-Umgebungs-Briefing — Daten, Nutzer, Feature-Flags — geliefert vor dem Capture-Tag
- Eine Capture-Spezifikation und einen UI-Versions-Pin, mit Re-Capture-Slot vor dem Launch
- Einen Remote-Aufnahmeplan pro Person mit Kit, Kadrage und Regie-Call
Typische Stolperstellen
Was in der Praxis am häufigsten schiefgeht:
- Die Demo auf dem Live-Account eines Kollegen voller Kundennamen aufnehmen
- Einen Launch-Film veröffentlichen, dessen UI zwei Releases alt ist
- Remote-Interviews in fünf Formaten, drei Kadragen und einem unbrauchbaren Ton ankommen lassen
Mit TillyGen
TillyGen zerlegt ein SaaS-Briefing in Screen-Szenen, Live-Szenen und Remote-Szenen — jede mit Capture-Spezifikation und UI-Versions-Vermerk — damit der Film am Launch-Tag noch zum Produkt passt.
Ändert sich eine Randbedingung, wandern die Folgen durch den ganzen Plan: betroffene Einstellungen werden markiert, die Disposition wird neu erzeugt, und niemand arbeitet weiter mit einer Fassung von gestern.
Häufige Fragen
Können wir die Demo im Produktivsystem aufnehmen?
Nein — baue zuerst einen Demo-Tenant mit fiktiven Daten. Echte Namen, Zahlen und Dokumente auf dem Screen sind ein Datenschutzproblem und datieren das Material, sobald ein Kunde kündigt.
Was passiert, wenn sich die UI nach dem Dreh ändert?
Plane es ein: Pinne den aufgenommenen Stand, beobachte den Release-Kalender und halte ein Re-Capture-Fenster vor der Veröffentlichung. Screen-Szenen sind versionierte Assets, keine einmaligen Takes.
Wie bekommen wir brauchbare Interviews von Remote-Gründern?
Schicke ein kleines Kit, lege eine einseitige Setup-Anleitung bei und führe die Session live — Kadrage, Licht und Ton geprüft, bevor aufgenommen wird. Konsistenz kommt aus dem Plan, nicht von den Teilnehmenden.
Wie lange dauert die Einarbeitung in TillyGen?
Ein erstes Projekt lässt sich in unter einer Stunde anlegen. Es gibt keine Einrichtungsphase, in der erst Vorlagen und Felder konfiguriert werden müssen, bevor das Werkzeug etwas ausgibt.
Lassen sich die Ergebnisse exportieren?
Ja — als PDF für die Crew, als CSV für nachgelagerte Systeme und über die API für alles Automatisierte. Der Plan bleibt dabei die Quelle; die Exporte sind Ansichten davon.