01 · Das Problem
Fulfillment beginnt mit einer Rückfrage.
Das Projektteam erhält Name, Paket und Deadline. Warum der Kunde gekauft hat, welche Grenzen besprochen wurden und welche Erwartung gesetzt wurde, bleibt im Vertriebstool.
Problem gelöst, nicht nur verbunden
Zwischen unterschriebenem Deal und erster Lieferung entsteht oft eine zweite Wahrheit. Genau dort gehen Zusagen, Herkunft und Gesprächskontext verloren.
01 · Das Problem
Das Projektteam erhält Name, Paket und Deadline. Warum der Kunde gekauft hat, welche Grenzen besprochen wurden und welche Erwartung gesetzt wurde, bleibt im Vertriebstool.
02 · Die Ursache
Beim Close wird ein neues Projekt angelegt. Aus dem Lead wird eine Karte, aus dem Gespräch ein Briefing und aus der Historie ein Link. Jede Kopie kann veralten.
03 · Die Kosten
Teams suchen Informationen, Kunden erklären Zusammenhänge erneut und nicht dokumentierte Zusagen tauchen erst in der Umsetzung auf. Das kostet Zeit und Vertrauen.
04 · Der übliche Umweg
Zapier, Make und Briefing-Vorlagen können Daten kopieren. Sie müssen jedoch gepflegt werden und trennen weiterhin Ursprung, Verlauf und Folgearbeit in mehrere Systeme.
05 · Wenn nichts getrennt ist
In introscale hängen Projekt und Aufgaben weiter an Lead, Deal und Firma. Das Team beginnt mit dem vorhandenen Kontext, statt ihn nachzubauen.
06 · Der Beweis
Projektaufgaben referenzieren Lead, Deal, Projekt und Firma. Übergabe, Kommunikation und UTM-Herkunft bleiben über dieselbe Identität nachvollziehbar.
Technisch nachvollziehbar
Eine Aufgabe kann Lead, Deal, Projekt, Firma und Ursprung gemeinsam referenzieren.
project_tasks · lead_id · deal_id · project_id · company_id · originZeitpunkt und Notizen sind am Vorgang gespeichert.
project_leads.handover_at · handover_notesDie Lead-ID verbindet den Vertriebsverlauf mit der Folgearbeit.
lead_idUTM-Felder bleiben an der ursprünglichen Funnel-Einreichung nachvollziehbar.
funnel_submissions.utm_*Weiterlesen
Häufige Fragen
Vom ersten Eingang bis zur Übergabe und Folgearbeit, auf einer Datenbasis.