Dokumente in HubSpot erfassen

Portant schreibt jedes generierte Dokument als eigenen Datensatz in HubSpot auf einem Document (Dokument)-Objekt (ein HubSpot-App-Objekt, das von der Portant-App bereitgestellt wird), das mit dem Deal, Kontakt, Unternehmen, Ticket oder benutzerdefinierten Objekt verknüpft ist, aus dem der Workflow gestartet wurde.

Es geht nicht darum, dass Sie Berichte über Dokumente erstellen können. Es geht darum, dass Ihre Dokumente Ihr Geschäftsprozess sind. Ein Dokument ist ein Angebot, ein Vertrag, eine Rechnung, ein Proposal oder ein Leistungsverzeichnis. Sobald jedes davon ein Datensatz mit einem Status und einem Datum ist, werden Fragen, die Sie zuvor nicht beantworten konnten, zu gewöhnlichen HubSpot-Berichten: Wie viele Verträge wurden letzten Monat unterzeichnet, wie viele Angebote gingen pro Vertriebsmitarbeiter raus, welche Deals hatten drei Angebote und haben immer noch nicht unterzeichnet, welche Unterschriftenanfragen wurden nie geöffnet.

Zuvor enthielten die Portant-Eigenschaften eines Deals oder Kontakts nur das aktuellste Dokument, das bei jedem Durchlauf überschrieben wurde. Ein Deal mit einem Angebot, einem überarbeiteten Angebot und einem unterzeichneten Vertrag zeigte einen einzigen Satz von Werten. Dokumentdatensätze speichern alle drei.

In diesem Leitfaden:

Benennen Sie Ihre Workflows nach dem Dokumenttyp
Was Sie messen können
Empfehlenswerte Automatisierungen
Automatisierung auf Dokument- oder Deal-Ebene
Vertragsverlängerungen und Ablauf
Referenz: Was steht in jedem Datensatz
Wann Datensätze erstellt und aktualisiert werden
Anforderungen und Grenzen
Wenn Datensätze nicht angezeigt werden

Benennen Sie Ihre Workflows nach dem Dokumenttyp

Tun Sie dies zuerst, denn alles Folgende hängt davon ab.

Jeder Document-Datensatz speichert den Workflow, der ihn generiert hat. Dieser Workflow-Name ist die Grundlage dafür, in einem Bericht ein Angebot von einem Vertrag zu unterscheiden. Er ist also effektiv Ihr Dokumenttyp. Wenn Ihre Workflows "Workflow 1" und "Copy of proposal test" heißen, sind Ihre Berichte wertlos, egal wie gut Ihre Daten sind.

Benennen Sie Workflows nach dem Dokument, das sie erzeugen: Quote, Order Form, MSA, NDA, Statement of Work, Invoice, Renewal. Dann ist "Wie viele Verträge haben wir im Juli unterzeichnet" ein Filter auf ein einzelnes Feld.

Wenn Sie mehrere Dokumenttypen aus einem einzigen Workflow generieren, teilen Sie diesen auf, oder sorgen Sie dafür, dass der Ausgabename den Typ enthält, sodass Sie stattdessen danach gruppieren können.

Der Workflow-Name wird im Datensatz als Workflow (Workflow) gespeichert, und das ist das Feld, nach dem Sie gruppieren:

Was Sie messen können

Volumen nach Dokumenttyp

Gruppieren Sie Document-Datensätze nach Workflow und Erstellungsdatum, um zu sehen, was Ihr Unternehmen tatsächlich produziert hat: Angebote pro Monat, unterzeichnete Verträge pro Quartal, ausgestellte Rechnungen pro Woche. Fügen Sie den Datensatzverantwortlichen hinzu, um dasselbe Bild pro Vertriebsmitarbeiter zu erhalten, was aus "Sendet das Team Proposals" eine Zahl statt einen Eindruck macht.

Umwandlung von Angebot zu Unterschrift

Zwei Zählwerte nebeneinander, erstellte Angebote versus unterzeichnete Verträge im gleichen Zeitraum, ergeben eine dokumentenbasierte Abschlussrate, die unabhängig davon ist, wie sorgfältig jemand die Deal-Phasen pflegt. Verfolgen Sie sie pro Vertriebsmitarbeiter oder pro Vorlage, um herauszufinden, welche Angebote tatsächlich konvertieren.

Wie lange das Unterzeichnen wirklich dauert

Jeder Datensatz enthält den Erstellungszeitpunkt des Dokuments und wechselt zu Signed (Unterzeichnet), wenn der letzte Unterzeichner fertig ist. Die Zeitspanne dazwischen ist Ihre tatsächliche Unterschriften-Durchlaufzeit, und genau dort warten Deals meist still vor sich hin. Vergleichen Sie sie über verschiedene Dokumenttypen hinweg: Ein NDA, der elf Tage dauert, ist ein anderes Problem als ein MSA, der elf Tage dauert.

Deals mit mehreren Angeboten und keinem unterzeichneten Vertrag

Das ist der Bericht, den die meisten Teams nicht haben. Suchen Sie nach Quelldatensätzen mit mehreren Document-Datensätzen aus Ihrem Angebot-Workflow und keinem unterzeichneten Vertrag. Jeder davon ist ein Deal, der neu verhandelt, rabattiert oder ins Stocken geraten ist. Die Anzahl der Angebote ist ein guter Näherungswert dafür, wie viel Reibung er mit sich trägt. Es ist gleichzeitig eine Warteschlange für die Rabattprüfung und ein Coaching-Signal.

Deals, deren Phase nicht zur Dokumentlage passt

Da Dokumente und Deals nun separate Datensätze sind, können Sie sie gegenseitig prüfen:

Als Closed Won markierte Deals ohne unterzeichneten Vertrag, was eine Lücke bei der Umsatzrealisierung und bei Prüfungen darstellt.
Deals, die in der Angebots- oder Verhandlungsphase stehen, bei denen aber noch nie ein Proposal erstellt wurde, was einer Pipeline entspricht, die noch gar nicht existiert.

Beides ist unsichtbar, wenn der einzige Nachweis eines Dokuments eine Eigenschaft ist, die überschrieben wird. Hier ist der Deal als Closed Won markiert, während das aktuellste Angebot noch auf Pending (Ausstehend) steht:

Ob der Unterzeichner das Dokument überhaupt geöffnet hat

Jeder Datensatz verfolgt, wie oft die Unterschriftenanfrage geöffnet wurde und wann sie zuletzt angesehen wurde. Das teilt ein vages Problem in zwei mit unterschiedlichen Lösungsansätzen auf:

Gesendet, nie geöffnet. Falsche Adresse oder im Spam gelandet. Jemand muss erneut senden oder anrufen, und es hilft nicht, dieselbe Inbox weiter zu verfolgen.
Fünfmal geöffnet, noch nicht unterzeichnet. Der Empfänger hat es gelesen und irgendetwas hält ihn zurück. Das ist ein Einwand, und das bedeutet: heute noch anrufen.

Welche Vorlagen tatsächlich verwendet werden

Das nach Workflow gruppierte Volumen zeigt, welche Vorlagen ihren Zweck erfüllen und welche seit einem Jahr nicht mehr genutzt wurden. Stellen Sie die ungenutzten ein. Die Kurzliste, die Ihr Team durchscrollt, wird kürzer.

Sinnvolle Automatisierungen

Dokumentdatensätze können in HubSpot-Workflows eingetragen und wie jeder andere Datensatz verzweigt werden, sodass Dokumentaktivitäten echte Prozesse antreiben können und nicht nur Berichte. Empfehlenswerte Automatisierungen:

Vertrag unterzeichnet, Lieferung starten. Der Status wechselt zu Signed (Unterzeichnet), also benachrichtigen Sie den Verantwortlichen, verschieben Sie die Deal-Phase, erstellen Sie die Onboarding-Aufgaben und übergeben Sie an das Lieferteam. Das unterzeichnete PDF ist bereits im Datensatz vorhanden.
Eine Generierung ist fehlgeschlagen. Der Status wechselt zu Error (Fehler), also benachrichtigen Sie denjenigen, der für den Dokumentbetrieb zuständig ist. Ohne diese Automatisierung bleibt ein Fehler unbemerkt: Der Vertriebsmitarbeiter geht davon aus, dass der Kunde das Angebot erhalten hat, während der Kunde darauf wartet.
Gesendet, aber nach zwei Tagen nicht geöffnet. Der Status ist Signature Requested (Signatur angefordert) und die Anzahl der Aufrufe ist weiterhin null, also erstellen Sie eine Anrufaufgabe. Dies ist die ertragreichste Automatisierung auf der Liste, da sie Zustellbarkeitsprobleme erkennt, die sonst als mangelndes Kundeninteresse ausgelegt werden.
Mehrfach gelesen und noch nicht unterzeichnet. Die Aufrufanzahl liegt über drei, ohne dass eine Signatur vorliegt, also weisen Sie dem Vertriebsmitarbeiter eine Aufgabe zu, ihn anzurufen und den Einwand zu benennen.
Ausstehende Signatur einfordern. Der Status ist seit länger als üblich Signature Requested (Signatur angefordert) oder Partially Signed (Teilweise unterzeichnet), also eskalieren Sie planmäßig und nicht erst, wenn jemand daran denkt.
Benachrichtigung beim Versand eines hochpreisigen Dokuments. Lesen Sie dazu den nächsten Abschnitt, da der Wert im Deal und nicht im Dokument liegt.
Verlängerung steht bevor. Siehe Vertragsverlängerungen weiter unten.

Automatisierung auf Dokumentebene oder auf Deal-Ebene

Wählen Sie die Ebene danach, welche Felder Sie benötigen.

Führen Sie den Workflow auf dem Document-Objekt (Dokumentobjekt) aus, wenn Sie eine dokumentgenaue Granularität benötigen: dieses Angebot, seinen Status, seine Aufrufanzahl und wann es gesendet wurde. Das gilt für die meisten der oben genannten Automatisierungen. Ein Workflow auf Dokumentebene trägt Portant Document-Datensätze ein und verzweigt nach Document Status (Dokumentstatus), sodass die Automatisierung für einen unterzeichneten Vertrag eine einzige Eintragungsbedingung darstellt:

Führen Sie ihn auf dem deal (Deal) aus, wenn die Regel von Deal-Feldern wie Betrag, Pipeline oder Phase abhängt, und verwenden Sie die Portant-Dokumentstatuseigenschaft im Deal als Auslöser. „Den Manager benachrichtigen, wenn ein Angebot über 50.000 versendet wird" ist eine Deal-seitige Regel, da der Document-Datensatz den Status und die Links des Dokuments enthält, jedoch nicht seinen monetären Wert.

Wenn der eigene Wert des Dokuments berichtsfähig sein soll, übertragen Sie ihn mit HubSpot capture fields (HubSpot-Erfassungsfelder) in eine Eigenschaft zurück, oder belassen Sie den Betrag im Deal und lassen Sie die Verknüpfung diesen weitertragen.

Vertragsverlängerungen und Ablauf

Verlängerungen sind das Wertvollste auf dieser Seite, und sie benötigen ein Feld, das der Document-Datensatz nicht hat: ein Enddatum. Datensätze enthalten das Erstellungsdatum eines Dokuments, nicht das Ablaufdatum der Vereinbarung. Es gibt zwei Möglichkeiten, dieses Datum zu erhalten:

Ableiten. Wenn ein Dokumenttyp eine Standardlaufzeit hat, legen Sie ein Verlängerungsdatum aus dem Erstellungsdatum zuzüglich dieser Laufzeit mithilfe eines HubSpot-Workflows oder einer berechneten Eigenschaft fest, und lösen Sie dann Verlängerungsaufgaben davon aus.
Erfassen. Wenn die Laufzeit pro Deal verhandelt wird, lassen Sie den Unterzeichner sie ausfüllen und schreiben Sie sie mit HubSpot capture fields (HubSpot-Erfassungsfelder) zurück.

Verwechseln Sie dies nicht mit dem signature link expiry (Ablauf des Signaturlinks), der steuert, wie lange ein unsignierter Signaturlink aktiv bleibt. Dabei geht es darum, das Dokument unterzeichnet zu bekommen. Hier geht es um die eigene Laufzeit der Vereinbarung nach der Unterzeichnung.

Mit diesem Datum erhalten Sie eine Verlängerungspipeline aus bereits generierten Dokumenten: Verträge, die in den nächsten 90 Tagen ablaufen, Vereinbarungen mit automatischer Verlängerung, die sich ihrem Kündigungsfenster nähern, und Kunden, deren einzige unterzeichnete Vereinbarung vor Monaten abgelaufen ist.

Das ist auch das, was das Objekt zu einer praktikablen, schlanken Vertragslebenszyklusverwaltung macht. Jede Vereinbarung ist ein Datensatz mit einem Status, einem unterzeichneten PDF, einem Signaturverlauf und einem Verlängerungsdatum, alles durchsuchbar in dem CRM, das Ihr Team bereits nutzt, ohne ein separates CLM-Tool. Es bietet keine Klauselbibliotheken oder Überarbeitungsfunktionen, aber um zu wissen, was Sie unterzeichnet haben, mit wem und was zur Verlängerung ansteht, reicht es aus.

Ein weiterer erwähnenswerter Anwendungsfall: Da jeder Datensatz eigene Zeitstempel, Links und einen Signaturverlauf führt, haben Sie einen Prüfpfad pro Vereinbarung. Das ist genau das, was Sie brauchen, wenn die Beschaffungsabteilung nach der unterzeichneten Kopie fragt oder wenn ein Kunde bestreitet, welche Version er zugestimmt hat.

Referenz: Was in jedem Datensatz enthalten ist

Jedes Dokument öffnet sich als eigener Datensatz, mit den Portant-Eigenschaften im linken Bereich und dem Quelldatensatz unter Deals.

Das Property-Label (Eigenschaftsbezeichnung) ist das, was Sie in Report-Buildern und Workflow-Filtern auswählen, und es erscheint auf dem Datensatz. Der interne Name ist dieselbe Eigenschaft, auf die sich die API, Exporte und Integrationen von HubSpot beziehen. Da sie voneinander abweichen, werden hier beide aufgeführt: Die Signierfelder erscheinen insbesondere auf dem Bildschirm als "Signable Document" und in der API als signature_request.

Property label	Inhalt	Internal name
Document Name	Dokumentname (Standard: "Portant Document")	`a1323181_document_name`
Workflow	Der Workflow, der es erstellt hat, also Ihr Dokumenttyp	`a1323181_workflow_name`
Document Status	Dokumentstatus	`a1323181_document_status`
Document Created Time	Zeitpunkt der Dokumenterstellung	`a1323181_document_created`
Document Link	Link zum Dokument (Google Docs oder OneDrive)	`a1323181_document_link`
PDF Link	Link zur PDF-Datei	`a1323181_pdf_link`
PDF Files	Die generierte PDF-Datei, als Anhang beigefügt	`a1323181_pdf_files`
Signable Document Link	Link zur Signaturanforderung	`a1323181_signature_request_link`
Signable Document View Count	Wie oft der Unterzeichner es geöffnet hat	`a1323181_signature_request_view_count`
Signable Document Last Viewed Date	Wann der Unterzeichner es zuletzt geöffnet hat	`a1323181_signature_request_last_view_date`

Durch Scrollen im Eigenschaftenbereich werden die Signierfelder und der Workflow angezeigt, der das Dokument erstellt hat.

Statuswerte, dieselbe Gruppe, die von der Portant-Eigenschaft Document Status für Deals und Kontakte verwendet wird: Pending, Error, Draft, Approved, Signature Requested, Partially Signed, Signed, Sent und Completed.

Es gibt keine Eigenschaft für Dokumenttyp, Betrag oder Ablaufdatum. Der Typ ergibt sich aus dem Workflow-Namen, und Betrag sowie Ablaufdatum stammen aus dem Deal oder aus erfassten Feldern, wie oben beschrieben.

Wann Datensätze erstellt und aktualisiert werden

Ein Datensatz wird erstellt, wenn zum ersten Mal eine Dokumentausgabe erzeugt wird, und anschließend direkt aktualisiert, während das Dokument den Lauf durchläuft. Ein Dokument entspricht für seine gesamte Lebensdauer einem Datensatz, sodass das Zählen von Datensätzen dem Zählen von Dokumenten entspricht.

Der Status folgt dem Arbeitsfortschritt: Ein zur Prüfung ausstehender Entwurf wird zu Draft, dann zu Approved, dann zu Signature Requested, dann zu Partially Signed oder Signed, sobald Unterzeichner tätig werden, und zu Sent, sobald die E-Mail versendet wird. Ein Workflow ohne Prüf- oder Signierschritt endet bei Completed.

Ein Workflow, der in einem Lauf mehrere Ausgaben erzeugt, erstellt einen Datensatz pro Ausgabe, der jeweils mit demselben Quelldatensatz verknüpft ist.

Voraussetzungen und Einschränkungen

Die Portant-App muss in Ihrem HubSpot-Portal installiert sein, mit den Berechtigungen für das Dokumentobjekt, die beim Verbinden von HubSpot erteilt werden. Siehe Install the Portant app in HubSpot.
Datensätze werden erstellt, wenn Dokumente generiert werden. Vor der Verfügbarkeit von Document Records generierte Dokumente werden daher nicht angezeigt. Es gibt keine rückwirkende Befüllung, was bedeutet, dass Ihre Berichte den Verlauf ab dem Zeitpunkt aufbauen, an dem Sie beginnen, und nicht rückwirkend erfasst werden.
Die PDF-Datei wird dem Datensatz nur dann angehängt, wenn der Workflow so konfiguriert ist, dass Dateien in HubSpot hochgeladen werden. Anhänge am Quelldatensatz werden unter View created documents in HubSpot behandelt. Wenn sie angehängt ist, befindet sie sich als Datei auf dem Datensatz:

Welche benutzerdefinierten Berichts- und Dashboard-Funktionen verfügbar sind, hängt von Ihrem HubSpot-Abonnement ab.

Wenn Datensätze nicht angezeigt werden

Die Berechtigungen, die es Portant ermöglichen, Document Records zu schreiben, werden beim Verbinden von HubSpot erteilt. Eine Verbindung, die vor der Einführung dieser Funktion autorisiert wurde, verfügt daher möglicherweise nicht über diese Berechtigungen. Durch eine erneute Verbindung wird die HubSpot-Berechtigungsabfrage erneut ausgeführt: Folgen Sie dazu Reconnect HubSpot, generieren Sie dann ein neues Dokument und überprüfen Sie die Verknüpfungen des Quelldatensatzes.

Wenn Dokumente weiterhin normal generiert werden, aber kein Document Record erscheint, kopieren Sie einen support code und öffnen Sie ein Support-Ticket mit Ihrer HubSpot-Portal-ID, damit wir die Verbindung von unserer Seite aus prüfen können.