← Zurück zum Journal

Produkttyp im CRM: Das Berichtsfeld, das Ihr CPQ nicht ersetzen kann

Produkttyp im CRM: Das Berichtsfeld, das Ihr CPQ nicht ersetzen kann
Wichtige Erkenntnis
CPQ-Tools verfolgen einzelne SKUs und Positionen. Sie machen diese Arbeit gut. Allerdings verursachen sie ein Berichtsproblem: zu viel Granularität und keine Daten bei frühen Deals, bei denen noch kein Angebot existiert. Ein Produkttypfeld im CRM sitzt über der Angebots-Ebene und löst beide Probleme. Es bietet konsistente, kategoriebasierte Pipeline-Berichte vom ersten Tag des Deal-Lebens an, unabhängig davon, was das Angebots-Tool enthält.

Die wichtigsten Erkenntnisse

  • Produkttyp im CRM ist ein übergeordnetes Kategoriefeld auf dem Opportunity-Datensatz. Es funktioniert neben CPQ-Tools, nicht statt ihrer.
  • CPQ-Daten sind zu granular für Pipeline-Berichte. Daher gruppieren die meisten Teams sie manuell in Tabellenkalkulationen, was langsam und fehleranfällig ist.
  • Early-Stage-Deals haben selten ein Angebot angehängt. Ohne ein Produkttypfeld sind diese Opportunities für produktbezogene Berichte unsichtbar.
  • Produktportfolios verändern sich durch Umbenennungen, Zusammenführungen und Einstellungen. Da Angebots-Tools oft außerhalb der Vertriebsoperationen kontrolliert werden, können diese Änderungen Berichte, die auf CPQ-Daten basieren, silent beschädigen.
  • Dies ist Teil 2 der Magical Fields-Serie. Teil 1 behandelt Opportunity-Typund Teil 3 behandelt Sales Motion.

Was Produkttyp im CRM tatsächlich bedeutet

Produkttyp im CRM ist ein einfaches Dropdown-Feld auf dem Opportunity-Datensatz. Es klassifiziert jeden Deal nach seiner übergeordneten Produktkategorie. Konkret ist es kein Angebots-Feld. Stattdessen sitzt es eine Ebene über der CPQ-Schicht und beantwortet eine andere Frage: Zu welchem Bereich des Portfolios gehört dieser Deal?

Ein Softwareunternehmen könnte beispielsweise Kategorien wie Produktivität, Infrastruktur und Sicherheit verwenden, anstatt einzelne Produkte aufzulisten. Das Feld ist schnell auszufüllen und erfordert keinen Angebots-Schritt. Infolgedessen deckt es jede Opportunity ab, sobald der Vertreter sie erstellt.

Das Problem mit der Abhängigkeit von CPQ-Daten für Produktberichte

CPQ-Tools machen eine Sache gut: Sie erfassen genau, was ein Kunde auf Positionsebene kaufen wird. Diese Detailtiefe ist für Preisgestaltung und Rechnungsstellung unverzichtbar. Sie erzeugt jedoch ein Problem bei der Pipeline-Berichterstellung.

Wenn Sie eine Produktansicht aus Angebotsdaten erstellen, arbeiten Sie mit Dutzenden oder Hunderten einzelner SKUs. Um sie in etwas Aussagekräftiges zu gruppieren, benötigen Sie benutzerdefinierte Joins oder höherwertige CRM-Lizenzen, die objektübergreifende Berichte freischalten. Viele CRM-Plattformen beschränken diese Funktionalität auf ihre teuersten Tarifen. Daher exportieren kleinere Teams Daten nach Excel und gruppieren sie manuell, was langsam, fehleranfällig und schwer zu automatisieren ist.

Es gibt auch ein zweites Problem, das Angebotsdaten überhaupt nicht lösen können: Opportunities in frühen Phasen. Oben im Trichter haben die meisten Deals noch kein angehängtes Angebot. Der Vertriebsmitarbeiter weiß ungefähr, an welchem Produktbereich der Kunde interessiert ist, aber die formale Angebotserstellung hat noch nicht begonnen. Ohne ein Produkttyp-Feld fallen diese Opportunities vollständig aus der produktstufigen Berichterstellung heraus.

Wie ein Produkttyp-Feld im CRM beide Probleme löst

Ein Produkttyp-Dropdown im Opportunity-Datensatz löst beide Probleme auf einmal. Vertreter wählen die Kategorie aus, wenn sie die Opportunity erstellen. Da sich das Feld im Opportunity-Datensatz selbst befindet, erscheint jeder Deal vom ersten Tag an in Produktberichten, unabhängig davon, ob ein Angebot vorhanden ist.

Die Berichterstellung wird dann zu einer Abfrage eines einzelnen Felds statt eines Joins über mehrere Tabellen. Wenn Sie beispielsweise wissen möchten, wie viele offene Deals in diesem Quartal in der Kategorie Infrastructure vorhanden sind, filtern Sie nach einem Feld und Sie sind fertig. Sie benötigen keine objektübergreifenden Berichtslizensen oder manuelle Exporte.

Ein praktisches Beispiel

Stellen Sie sich ein Unternehmen mit acht Produkten in drei Kategorien vor: Produktivität (vier Tools), Serverprodukte (zwei Plattformen) und Betriebssystem (zwei Editionen). Jede Kategorie hat ihre eigene Go-to-Market-Strategie, ihre eigene Verkaufszyklus-Länge und ihre eigenen Ziele. Ohne ein Produkttypfeld erfordert ein Pipeline-Bericht nach Kategorie eine Abfrage des Angebotssystems und eine Gruppierung nach Produktname. Mit dem Feld erledigt ein Filter die Arbeit.

Jede dieser drei Kategorien verhält sich auch in der Pipeline unterschiedlich. Produktivitätsdeals können schneller abgeschlossen werden, da Käufer die Produkte gut kennen. Serverprodukte erfordern oft eine längere technische Validierung. Folglich führt die gemeinsame Gruppierung dieser in Berichten zu Durchschnittswerten, die keine von ihnen genau beschreiben.

Was dies für die Konsistenz der Berichterstattung im Laufe der Zeit bedeutet

Produktportfolios ändern sich. Unternehmen benennen Produkte um, fusionieren sie, stellen sie ein oder teilen sie in neue SKUs auf. In den meisten Unternehmen steht das Angebotssystem unter der Kontrolle von Finanzen, Produktmanagement oder Marketing. Wenn diese Teams Änderungen vornehmen, verschieben sich die Produktnamen in den Angebotsdaten. Auf CPQ-Positionen basierende Berichte gehen dann stillschweigend kaputt oder beginnen, Deals unterschiedlich zu gruppieren, ohne dass jemand es bemerkt.

Der Produkttyp im Opportunity-Record bleibt stabil, da Sales Operations ihn kontrolliert. Wenn sich das Portfolio ändert, aktualisiert das Team die zulässigen Werte des Feldes. Historische Daten bleiben intakt, da die Kategorie bei jeder alten Opportunity widerspiegelt, worum es bei diesem Deal zum damaligen Zeitpunkt ging. Daher bleiben Multi-Jahr-Trendberichte genau, auch bei erheblichen Portfolioänderungen.

Profi-Tipp: Halten Sie die Produkttypliste kurz. Vier bis sechs Kategorien sind normalerweise ausreichend. Je granularer die Liste ist, desto mehr dupliziert sie das, was das Angebotssystem bereits tut. Das Ziel ist eine High-Level-Ansicht, die die Berichterstattung schnell nutzen kann, kein zweiter SKU-Katalog.

Zwei Szenarien, in denen sich der Produkttyp im CRM bewährt

Szenario 1: Die frühe Pipeline-Phase

Ein Vertriebsmitarbeiter erstellt im Januar zehn neue Chancen. Keine davon hat noch ein Angebot. Im CPQ-Tool sind alle zehn leer. Der Vertriebsmitarbeiter weiß jedoch, dass sechs Produktivitätsdeals und vier Infrastrukturdeals sind. Mit einem Produkttypfeld erscheinen diese zehn Chancen korrekt im Januar-Pipeline-Bericht nach Kategorie. Ohne dieses Feld bleiben diese Deals für die Produktberichterstattung unsichtbar, bis der Vertriebsmitarbeiter ein Angebot hinzufügt, was Wochen dauern kann.

Szenario 2: Die Änderung des Produktportfolios

Das Produktteam benennt eine Schlüsselplattform im Angebotserstellungstool von "Enterprise Suite" in "Business Suite" um. Alle neuen Angebote verwenden den neuen Namen. Historische Angebote zeigen immer noch den alten Namen. Infolgedessen teilt jeder Bericht, der nach Produktname gruppiert wird, das, was ein Produkt war, in zwei Einträge auf. Da die Vertriebsbetriebsstelle die Kategorien des Produkttypfelds kontrolliert, wirkt sich eine Produktnamensänderung im Angebotserstellungstool nicht darauf aus. Die Berichterstattung läuft ohne Unterbrechung weiter.

Schnelle Fakten

  • Der Produkttyp im CRM ist ein Feld auf Kategorieebene im Opportunity-Datensatz. Er befindet sich über der CPQ-Schicht und umfasst jeden Deal, auch solche, bei denen der Vertriebsmitarbeiter noch kein Angebot beigefügt hat.
  • CPQ-Tools verfolgen einzelne SKUs und Positionen. Da die Pipeline-Berichterstattung typischerweise Daten auf Kategorieebene benötigt, erfordert die alleinige Verwendung von CPQ zusätzliche Gruppierungsschritte und oft höhere CRM-Lizenzstufen, um objektübergreifende Abfragen zu unterstützen.
  • Viele CRM-Plattformen beschränken objektübergreifende Berichterstattung auf höhere Lizenzstufen. Ein Produkttypfeld im Opportunity-Datensatz beseitigt diese Abhängigkeit, indem die Daten dort platziert werden, wo sie am einfachsten abgefragt werden können.
  • Early-Stage-Chancen haben häufig keine Produkte im Angebotserstellungstool. Ein Produkttypfeld stellt sicher, dass diese Deals ab dem Moment, in dem ein Vertriebsmitarbeiter die Chance erstellt, korrekt in Berichten auf Produktebene erscheinen.
  • Angebotstools werden üblicherweise von Finance-, Produkt- oder Marketing-Teams gesteuert. Wenn diese Teams Produkte umbenennen oder umstrukturieren, werden Berichte, die auf CPQ-Positionen basieren, unterbrochen. Ein von Sales Operations verwaltetes Produkttypfeld bleibt bei Portfolioänderungen konsistent.
  • Dies ist Teil 2 der Magical Fields-Serie. Teil 1 behandelt Opportunity Type und Teil 3 behandelt Sales Motion.

Häufig gestellte Fragen

  • Was ist ein Produkttypfeld in CRM und wie unterscheidet es sich von CPQ?
    Produkttyp in CRM ist eine übergeordnete Kategorie-Dropdown auf dem Opportunity-Datensatz. CPQ-Tools verfolgen einzelne Produkte und Preise auf Positionsebene. Die beiden dienen unterschiedlichen Zwecken: CPQ verwaltet, was ein Kunde kauft und zu welchem Preis, während der Produkttyp der Pipeline zeigt, zu welchem Bereich des Portfolios ein Deal gehört.
  • Warum kann ich nicht einfach CPQ-Angebotsdaten für Produktberichte verwenden?
    CPQ-Daten funktionieren auf SKU-Ebene, was für Pipeline-Berichte zu granular ist. Das Gruppieren in Kategorien erfordert benutzerdefinierte Joins oder höherwertige CRM-Lizenzen. Es übersieht auch frühe Deals, bei denen noch kein Angebot vorhanden ist. Ein Produkttypfeld vermeidet beide Probleme, da es sich auf dem Opportunity-Datensatz selbst befindet.
  • Wie viele Kategorien sollte ein Produkttypfeld enthalten?
    Vier bis sechs sind normalerweise ausreichend. Das Ziel ist ein übergeordneter Überblick für schnelle Berichte, kein Replikat des Produktkatalogs. Wenn Sie mehr als sechs benötigen, sind die Kategorien wahrscheinlich zu granular und beginnen zu duplizieren, was CPQ bereits verfolgt.
  • Was passiert mit Produkttypdaten, wenn sich das Portfolio ändert?
    Da Sales Operations das Produkttypfeld verwaltet, kümmern sie sich um Updates der Kategorieliste. Historische Opportunities behalten ihre ursprüngliche Kategorie, sodass Trendberichte präzise bleiben. Im Gegensatz dazu brechen Berichte, die auf CPQ-Produktnamen basieren, zusammen, sobald das Angebotstool einen Produktnamen oder eine Struktur ändert.
  • Ist der Produkttyp in CRM wichtig, wenn wir nur ein Produkt verkaufen?
    Noch nicht. Allerdings expandieren die meisten Unternehmen, die mit einem Produkt beginnen, irgendwann. Das Feld früh hinzuzufügen kostet fast nichts. Es nachträglich über Hunderte historischer Opportunities einzubauen kostet erheblich mehr Zeit und liefert weniger genaue Daten.

Das Argument für die Hinzufügung des Produkttyps im CRM von Anfang an

Der Produkttyp im CRM ist kein komplexes Feld. Es ist ein kurzes Dropdown-Menü mit vier bis sechs Werten. Allerdings bietet es etwas, das Quotierungstools nicht können: stabile, konsistente, kategoriebasierte Berichterstattung vom ersten Tag des Deals bis zum letzten.

Richten Sie es ein, bevor Sie die erste Opportunity erstellen. Halten Sie die Kategorieliste kurz und stabil. Stellen Sie sicher, dass Sales Operations es verwaltet, nicht das Produkt- oder Finanzteam. Wenn Sie diese drei Dinge tun, wird dieses Feld Ihre Berichterstattungsanforderungen zuverlässig für Jahre erfüllen, durch Produktumbenennungen, Portfolioänderungen und CRM-Lizenz-Upgrades.

Teil 3 dieser Serie behandelt Sales Motion, das dritte Feld, das diese Berichterstattungsgrundlage vervollständigt. Wenn Sie Hilfe bei der Strukturierung des Feldaufbaus für Ihr spezifisches CRM benötigen, Kontakt aufnehmen.