GTM-Ticket: Anatomie im Zeitalter autonomer Agents

Ein vages GTM-Ticket war früher Inbox-Schaden für einen Account. Heute ist es Spam at scale über tausend Accounts in einer Nacht. Das GTM-Ticket ist die kleinste Einheit deiner Go-to-Market-Maschine, und in 2026 lesen Agents es mit. Wer das ignoriert, briefed seine Agents in Garbage und bekommt Garbage zurück, schneller als je zuvor.

Ich habe in den letzten Jahren mehrere GTM-Maschinen mit aufgebaut und wieder zerlegt. Ein Muster: gescheitert sind sie fast nie an der Technologie. Gescheitert sind sie am Briefing. Wenn das Ticket schlecht ist, ist die Ausführung schlecht. Bei einem Menschen merkt man es nach drei Tagen, bei einem Agent nach drei Minuten und 800 versendeten E-Mails.

Dieser Artikel zerlegt das Ticket und baut es neu für eine Welt, in der ein Agent es liest, nicht nur dein SDR. Für Marketing, Sales und Customer Success, in Jira oder Linear.

Was du mitnimmst:

• Warum dein GTM-Ticket 2026 wie ein Prompt funktioniert.
• Die Anatomie eines agentenfähigen Tickets, Feld für Feld.
• Wie du sechs spezialisierte Agent-Rollen briefst statt einen General-Agent.
• Die vier Phasen, in denen sich ein Ticket zum ausführbaren Brief auflädt.

Die These

Das perfekte GTM-Ticket ist kein Formular, sondern ein Kontext-Container, der sich über vier Phasen anreichert, bis ein Mensch und ein Agent ihn ohne Rückfrage ausführen. GTM ist ein Produkt, kein Prozess, und das Ticket ist seine kleinste Version.

Warum ist ein GTM-Ticket heute eigentlich ein Prompt?

Ein GTM-Ticket ist heute ein Prompt, weil ein Agent es zu Output verarbeitet, ohne nachzufragen. Was im Ticket fehlt, fehlt im Ergebnis. Was im Ticket falsch ist, wird ausgespielt. Der Hebel sitzt vorne, im Brief, nicht in der Ausführung.

Das ist eine Verschiebung der Knappheit. Früher war Ausführung der Engpass: einer schreibt die Sequenz, einer baut die Liste, einer verschickt. Heute kostet Ausführung fast nichts mehr. Der Engpass ist Kontext und Führung. Eine Gartner-Erhebung unter CMOs zeigt, dass GenAI-Budgets weiter steigen, aber dieselben Teams über unklare Verantwortlichkeiten klagen. Das Problem sitzt im Brief.

Aus welchen Feldern besteht ein agentenfähiges Ticket?

Ein agentenfähiges Ticket besteht aus sieben Feldern: Ziel, Kontext, Adressat, Aktion, Constraints, Quellen, Definition of Done. Jedes Feld ist eine Antwort auf eine Frage, die der Agent sonst stellen müsste. Fehlt eine Antwort, fragt er nicht, er rateund verschickt.

So sieht das in der Praxis aus:

1. Ziel. Ein Satz. "Reaktiviere 47 schlafende Mid-Market-Accounts in DACH, Trigger: neues Pricing."
2. Kontext. Was hat sich geändert? Welche Hypothese steckt dahinter? Welche früheren Berührungen gab es?
3. Adressat. ICP, Persona, Account-Liste mit Source. Nicht "Mid-Market in DACH", sondern "diese 47 Accounts aus dieser Salesforce-View".
4. Aktion. Was soll der Agent tun? E-Mail-Sequenz, LinkedIn-Voice-Note, Call-Script, Recherche-Brief?
5. Constraints. Tonalität, Verbote, Compliance. "Du-Form, keine Superlative, keine Vergleiche mit Wettbewerbern beim Namen."
6. Quellen. Verlinkt: Pricing-Page, Release-Notes, Case Study, ICP-Doku. Der Agent liest nur, was du verlinkst.
7. Definition of Done. Wann ist das Ticket erledigt? Wer reviewt? Welcher Metrik wird gemessen?

Welche Agent-Rollen briefst du, statt einen General-Agent zu bauen?

Du briefst sechs spezialisierte Rollen, weil ein General-Agent in der Praxis mittelmässig in allem ist. Researcher, Writer, Editor, Outbound Operator, Reviewer, Logger. Jede Rolle hat ein eigenes Ticket-Template, ein eigenes Kontext-Set, eine eigene Definition of Done.

Das spiegelt einen Befund der HBR-Studie zur GenAI-Arbeit: AI-Output wird besser, wenn die Aufgabe scharf abgegrenzt ist. "Schreibe eine Outbound-E-Mail" ist unscharf. "Schreibe als Outbound-Writer in 80 Wörtern eine E-Mail an einen CTO im DACH-Mittelstand, Quelle ist dieser Brief, Constraint ist diese Tonalität" ist scharf.

In welchen vier Phasen reift ein Ticket?

Ein Ticket reift in vier Phasen: CAPTURE, BRIEF, RUN, MEASURE. CAPTURE hält die rohe Idee fest, BRIEF reichert sie zu einem Kontext-Container an, RUN ist die Ausführung, MEASURE schliesst den Loop. Erst nach BRIEF darf ein Agent ran.

Der häufigste Fehler in 2026 ist, in CAPTURE zu starten und sofort RUN zu drücken. Das passiert, weil ein Agent nicht zurückfragt. Ein menschlicher SDR hätte gemerkt, dass die Liste noch nicht stimmt. Der Agent verschickt.

Deshalb braucht es ein Compliance-Gate zwischen BRIEF und RUN. Ein Mensch reviewt, ob alle sieben Felder befuellt sind. Erst dann geht das Ticket in die Pipeline. Bei HubSpot, Salesforce oder Apollo sieht das technisch gleich aus: das Ticket ist die Wahrheit, das Tool ist nur die Ableitung.

Das Compliance-Gate, das die meisten unterschätzen

Das Compliance-Gate ist nicht Bürokratie, es ist die Versicherung gegen einen 800-Mails-Fehlschuss. Drei Prüfungen: Stimmt die Liste? Stimmt der Brief mit dem ICP überein? Verstösst die Aktion gegen Compliance (Datenschutz, Tonalität, Wettbewerbsrecht)? Drei Fragen, drei Minuten. Wer das nicht macht, lernt es nach dem ersten Vorfall.

Hochzeit zum Schluss: das Resultat

In einem aktuellen Setup habe ich erlebt, dass ein neu eingeführter Ticket-Standard die Bearbeitungszeit pro Outbound-Welle von zwei Tagen auf vier Stunden gesenkt hat. Drei Personen plus sechs Agents. Die Response-Rate stieg, weil die Briefs schärfer wurden, nicht weil der Agent besser wurde. Das ist die Pointe: AI verdoppelt nicht den Output, sie verstärkt den Input. Ein scharfer Brief verzehnfacht, ein vager Brief verschlimmert.

Was du heute tust

✅ Was glänzt. Wenn du das Ticket als Container behandelst, skalierst du Qualität, nicht nur Volumen. Drei Leute fahren, wofür früher dreissig nötig waren.

❌ Was nicht glänzt. Wer den Brief überspringt, baut sich eine Spam-Maschine. Der Schaden ist sofort sichtbar.

⚠️ Warnung. Tool-Wahl ist sekundär. Wer Jira gegen Linear tauscht, ohne das Briefing zu fixen, schickt schlecht gebriefte Tickets nur schneller raus.

Die tiefere Einsicht: AI verkauft nicht für dich. Sie skaliert nur, wie gut oder schlecht du briefst. Der Hebel sitzt im Ticket, nicht im Tool. Genau da, wo wir am Anfang hingeschaut haben.

Ein konkreter nächster Schritt. Abonniere den Newsletter, dort liefere ich pro Ausgabe ein konkretes GTM-Ticket-Template, das du am gleichen Tag einsetzen kannst.

Häufige Fragen

Was unterscheidet ein GTM-Ticket von einem klassischen Sales-Task?

Ein Sales-Task beschreibt eine Aktion ("Call XY am Dienstag"). Ein GTM-Ticket beschreibt einen Kontext mit Ziel, ICP-Bezug, Constraints und Definition of Done. Das Ticket ist agentenfähig, der Task nicht.

Wie viele Felder braucht ein Ticket mindestens?

Sieben: Ziel, Kontext, Adressat, Aktion, Constraints, Quellen, Definition of Done. Weniger funktioniert in der Praxis nicht, mehr ist Bürokratie.

Brauche ich dafür ein neues Tool?

Nein. Jira, Linear, Notion oder ClickUp reichen. Wichtig ist nicht das Tool, sondern dass das Ticket-Template alle sieben Felder erzwingt und vor der Ausführung reviewt wird.

Wer reviewt das Ticket im Compliance-Gate?

Ein Mensch mit GTM-Verantwortung, in kleinen Teams die Foundern oder Head of GTM, in grösseren ein dedizierter Operator. Drei Fragen, drei Minuten.

Was passiert, wenn ich das Gate weglasse?

Du verschickst Spam at scale. Der Agent fragt nicht zurück. Ein einziger schlecht gebriefter Lauf kann eine Domain-Reputation oder ein ganzes ICP-Segment für Monate verbrennen.