Proof of Concept Software: Ablauf in der Salesforce-Sandbox

Ein Proof of Concept von Funnel Economics läuft in einer Sandbox Ihrer Salesforce-Umgebung. Etwa vier Wochen führen zum ersten Ergebnis und zur Go/No-Go-Entscheidung. Die Historie der Opportunities wird dafür lesend aus Ihrer Produktiv-Org geholt. Während der Sandbox-Phase wird in der Produktiv-Org kein Paket installiert und nichts geschrieben. Dort legt Ihr Administrator genau zwei Dinge an.

Wie der Proof of Concept abläuft

Funnel Economics startet in die Beta-Phase. In der Beta setzen Sie es zunächst gegen eine Salesforce-Sandbox ein.

Dieser Leitfaden beschreibt den Weg für Salesforce-Administration und IT: was in Ihrer Umgebung entsteht, welche Daten wohin gehen und wie der Proof of Concept endet.

Warum eine Sandbox allein nicht reicht

Funnel Economics rechnet auf der Historie der Opportunities. Genau diese Historie fehlt in einer Salesforce-Sandbox. Eine Partial-Copy-Sandbox kopiert die Stufenhistorie nicht.

Eine Full-Copy-Sandbox kopiert nur die letzten 180 Tage der Stufenhistorie. Das ist zu kurz für die Zeitreihen, auf denen die Auswertung steht.

Der Proof of Concept holt die Historie deshalb lesend aus Ihrer Produktiv-Org. Alles nach dem Einlesen ist das gewöhnliche Produkt: Aggregate, Auditdaten, Dashboards und KI-Kommentare.

Vier Schritte bis zur Go/No-Go-Entscheidung

Der technische Ablauf dauert etwa vier Wochen und hat vier Schritte.

1. Workshop zur Stufenzuordnung. Die Stufenzuordnung legt fest, welche Stufen Ihres Vertriebsprozesses die Auswertung kennt.
2. Anbindung der Sandbox. Das Paket wird in der Sandbox installiert, und die Sandbox wird mit Ihrer Produktiv-Org verbunden.
3. Validierung.
4. Übergabe mit Go/No-Go. Das erste Ergebnis liegt vor, und die Go/No-Go-Entscheidung fällt.

Die vier Wochen sind nicht die Dauer des Proof of Concept, sondern sein erster Abschnitt. Danach läuft die Evaluation in der Sandbox weiter, für den Rest des sechsmonatigen Engagements.

Drei Läufe, von Hand gestartet

Eine Zeitplanung gibt es im Proof of Concept nicht. Drei Läufe werden von Hand gestartet, in fester Reihenfolge: Historie laden, Aggregate neu bilden, Auditdaten erneuern. Nach einem abgebrochenen Lauf wird vollständig neu geladen, nicht fortgesetzt.

Welche Voraussetzungen Sie mitbringen

Das Beta-Programm ist auf höchstens fünf Unternehmen begrenzt. Zwei technische Voraussetzungen gelten für jedes: eine Sandbox und ein eigenes Anbieterkonto für das Sprachmodell. Die Kosten des Sprachmodells tragen Sie über dieses Konto.

Welche Sandbox geeignet ist

Die Sandbox muss eine Kopie Ihrer Produktiv-Org sein. Die Zuordnung der Historie läuft über die Record-Id, und eine Kopie behält die Ids der Produktiv-Org. Reine Entwickler-Sandboxen tragen keine Opportunity-Daten und scheiden deshalb aus.

Ein Opportunity Type und eine Teilmenge

Der Proof of Concept bildet genau einen Funnel ab, also genau einen Opportunity Type. An ihm hängen Zykluslänge und Modellzuordnung.

Geladen wird eine Teilmenge ausgewählter Opportunities. Die Obergrenze liegt bei 5.000 Opportunities; darüber startet kein Lauf.

Empfohlen sind höchstens 2.500 Opportunities; darüber läuft es, aber merklich langsamer.

Die Teilmenge muss außerdem in zugeordneten Stufen liegen. Liegen Opportunities in Stufen, die die Stufenzuordnung nicht abdeckt, weist die Einrichtung die Auswahl ab und nennt die Stufen.

Eine überzeugende Auswahl enthält Deals, die der Sponsor des Proof of Concept in Ihrem Unternehmen wiedererkennt, etwa eine Region mit vertrauten Zahlen. Sie enthält genug Historie für einen Verlauf, nicht nur ein Quartal.

Was Ihr Team vorab klärt

Die Zykluslänge wird in Quartalen angegeben. Sie kommt von den Leuten, die die Deals führen, denn sie bestimmt das Fenster der Auswertung. Variiert der Zyklus je Segment, gilt der überwiegende.

Aus der Zykluslänge entstehen zwei Modelle dieser Länge, PERFORM und BUILD. Was die zwei Modelle unterscheidet, beschreibt das Whitepaper BUILD und PERFORM im Vergleich.

Ziele für den gezeigten Zeitraum gehören ebenfalls dazu. Ohne Ziele zeigt der Proof of Concept Pipeline, aber keine Leistung gegen Plan.

Wer den Proof of Concept aufsetzt, ist Administrator oder Analyst und bekommt dafür eine Berechtigungsgruppe zugewiesen. Dieselbe Gruppe braucht jeder, der einen Lauf oder den Verbindungstest startet. Endnutzer sehen nichts Neues.

Was in Ihrer Produktiv-Org angelegt wird

Während der Sandbox-Phase wird in der Produktiv-Org kein Paket installiert und nichts geschrieben. Das Paket wird nur in der Sandbox installiert.

In der Produktiv-Org legt Ihr Administrator während der Sandbox-Phase genau zwei Dinge an.

1. Einen Integrationsbenutzer mit Leserechten, nach dem Prinzip der geringsten Rechte und ohne Oberflächenzugang.
2. Eine External Client App mit Client-Credentials-Fluss, die als dieser Benutzer läuft.

Mehr entsteht dort nicht: keine Metadaten, keine Felder, keine Automatisierung.

Während der Sandbox-Phase entstehen in Ihrer Produktiv-Org genau zwei Dinge: ein Integrationsbenutzer mit Leserechten und eine External Client App. Beide deaktivieren Sie am Ende wieder.

Die Eingrenzung auf die Sandbox-Phase ist Absicht. Nach einer Migration in die Produktion gilt dort dasselbe wie für jede Installation; das Kapitel zur Migration beschreibt es.

Welche Daten wohin gehen

Die Sandbox treibt den Lauf. Sie geht die ausgewählten Opportunities durch und fragt die Produktiv-Org über die Salesforce-REST-API nach deren Historie.

Die Historie bleibt in Ihrer Salesforce-Umgebung: Sie geht von der Produktiv-Org in eine Sandbox desselben Unternehmens. Die Historie verlässt dabei die Produktiv-Org, und die Produktiv-Org wird dabei nur gelesen.

Dieser Satz gilt für die Historie auf dem Weg von der Produktion in die Sandbox. Für KI-Kommentare und für Strategist gilt er nicht. Beide haben einen eigenen Datenweg, und das nächste Kapitel beschreibt ihn.

Fehlt eine Opportunity in der Kopie, werden ihre Zeilen übersprungen und gezählt; die Zusammenfassung des Laufs nennt die Zahl. Eine unvollständige Kopie führt so zu einem kleineren Ergebnis, nicht zu einem stillen.

Strategist und KI-Kommentare in der Sandbox

Der Proof of Concept ist kein Sonderfall. Er ist die Konstruktion des Produkts in einer Sandbox, mit denselben Zusagen und denselben Grenzen.

KI-Kommentare in Core

Funnel Economics Core rechnet in der Salesforce-Org, in der es installiert ist; im Proof of Concept ist das Ihre Sandbox. Für Dashboard-Kommentare kann Core ein Sprachmodell aufrufen. Diese KI-Datenübertragung ist standardmäßig aus und wird je Org und je Nutzer freigeschaltet; das Paket maskiert personenbezogene Werte vor dem Aufruf.

In Ihrer Sandbox ist die Freischaltung eine Entscheidung Ihrer Datenschutzverantwortlichen, keine des Proof of Concept.

Funnel Economics Strategist

Funnel Economics Strategist ist ein optionales Zusatzmodul. Der aufbereitete Kontext läuft über einen von uns betriebenen Dienst zum Sprachmodell Ihrer Wahl.

Nutzen Sie Strategist im Proof of Concept, wird es an die Sandbox angebunden. Der Salesforce-Zugriff von Strategist ist ausschließlich lesend.

Namen von Vertriebsmitarbeitern und Opportunities sowie Datensatz-Links gehen bewusst mit: Eine Antwort mit Platzhaltern wäre unbrauchbar. Strategist maskiert oder pseudonymisiert sie nicht. Das ist eine Entscheidung, keine Lücke. Für den Proof of Concept gilt dieselbe Entscheidung wie für jede Installation.

Verträge und Kontrollen

Für unsere Strecke ist ein Auftragsverarbeitungsvertrag erforderlich; wir bereiten ihn vor. Das Sprachmodell verarbeitet die Daten unter Ihrem eigenen Vertrag mit dem Anbieter.

Dort empfehlen wir dringend einen Enterprise-Vertrag samt Auftragsverarbeitungsvertrag, der die Nutzung für Training ausschließt; das ist eine Empfehlung, keine Voraussetzung. Der Ausschluss muss aus Ihrem Vertrag mit Ihrem Anbieter kommen.

Strategist braucht eine Autorisierung je Nutzer, die Ihr Salesforce-Administrator steuert und widerrufen kann.

Die Kontrollen sind die Freischaltung je Org und die Berechtigung je Nutzer; die serverseitige Prüfung dieser Berechtigung ist gebaut und wird mit dem Endpunkt des Pakets wirksam, den sie braucht.

Der KI-Schalter und das Permission Set des Pakets stoppen Strategist noch nicht – die serverseitige Prüfung ist gebaut, aber nicht in Kraft.

Beide Datenwege mit ihren Kontrollen beschreibt das Whitepaper Trust Boundary für KI auf Salesforce-Daten. Die kurze Fassung für die Freigabe steht auf der Seite KI-Datenschutz: Was Ihre Salesforce-Org verlässt.

Die Migration in die Produktion ist Ihre Entscheidung

Innerhalb des sechsmonatigen Engagements können Sie in Ihre Salesforce-Produktions-Org migrieren. Die Entscheidung liegt bei Ihnen.

Technisch ist die Migration vor der AppExchange Security Review möglich. Die Migration hängt nicht an der Review: Ob Sie ohne bestandene Review migrieren, entscheiden Sie.

Nach der Migration gilt in der Produktion dasselbe wie für jede Installation. Core schreibt nur seine eigenen Package-Objekte, nie Standardobjekte wie Opportunities.

Sie nehmen Entscheidungen mit, keine Daten

Der Proof of Concept ist kein Migrationswerkzeug, und er wird nicht zur Installation. In der Produktion wird neu installiert, und die Historie kommt dann aus der Org selbst. Eine Verbindung bleibt nicht zu pflegen.

Hinüber nehmen Sie fünf Entscheidungen: den Opportunity Type, die Zykluslänge, die Stufenzuordnung, die SLAs und die Regionsstruktur. Schreiben Sie die Entscheidungen am Ende des Proof of Concept auf, solange die Begründung frisch ist.

Wie der Stand der Review ist

Die AppExchange Security Review ist nach der Beta-Phase geplant. Ein Termin oder eine Zusage folgt daraus nicht, und eine Migration setzt die Review nicht voraus.

Drei Fehlerbilder, die Sie vorab kennen sollten

Das erste Fehlerbild hat eine Ursache in Salesforce selbst. Der Zugriff der External Client App hängt an einem Berechtigungssatz und kann nicht aus einem Profil kommen.

Das zweite Fehlerbild ist das teuerste, weil es wie ein Datenbefund aussieht. Die Feldhistorie wird nicht abgewiesen, sondern verborgen: Es kommen weniger Zeilen und keine Fehlermeldung. Wer auffällig dünne Historie sieht, prüft zuerst die Leserechte und erst danach die Daten.

Wie der Proof of Concept endet

Ein Proof of Concept hat ein Ende. Ihn still weiterlaufen zu lassen ist die schlechteste Variante: Die Sandbox driftet, und die Verbindung bricht beim nächsten Refresh.

• Bei Erfolg wird in der Produktion neu installiert, und Sie schreiben die Entscheidungen auf. Die zwei Dinge aus der Sandbox-Phase deaktivieren Sie auch dann.
• Ohne Erfolg deaktivieren Sie in der Produktiv-Org die zwei angelegten Dinge. Mehr ist dort nicht entstanden.
• In jedem Fall wird die Evaluation in einer Sandbox abgeschaltet, die stehen bleibt. So startet kein Lauf gegen eine Verbindung, die niemand beobachtet.

Zurückzunehmen sind am Ende genau die zwei Dinge aus der Produktiv-Org: External Client App deaktivieren, Integrationsbenutzer deaktivieren. In der Sandbox ist nichts zurückzunehmen.

Alle Datenwege, die Kontrollen und ihr Stand stehen auf der Seite Security & Trust. Welche Fragen die Auswertung im Alltag beantwortet, beschreibt die Seite Vertriebscontrolling für RevOps: eine prüfbare Zahl je Stage. Für alles Weitere fragen Sie uns direkt.