RevOps RACI: Verantwortungsmatrix für Revenue Operations
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
RevOps scheitert, wenn alle zustimmen, dass die Arbeit wichtig ist, aber niemand sich einig ist, wer die Entscheidung verantwortet.
Wer genehmigt eine neue Lifecycle-Phase? Wer verantwortet das Quellfeld? Wer entscheidet, ob sich eine Lead-Routing-Regel ändert? Wer löst einen Streit zwischen Marketing-Attribution und Finance-Reporting?
Ein RevOps-RACI beantwortet diese Fragen, bevor sie politisch werden.
Brauchen Sie das Basismodell, siehe RACI-Matrix und RACI vs. RASCI vs. DACI.
PMI beschreibt RACI als eine Methode, um Verantwortung und Rechenschaftspflicht zu klären, damit Arbeit nicht zwischen Teams verloren geht. Bei RevOps ist diese Klarheit wichtig, weil die Arbeit Marketing, Sales, Customer Success, Finance, Daten und Systeme übergreift.
Forresters Modell der RevOps-Verantwortlichkeiten erinnert nützlich daran, dass RevOps von Natur aus breit angelegt ist. Ein RACI verhindert, dass diese Breite zu Mehrdeutigkeit wird.
Wichtige operative Fakten
- Ein RevOps-RACI sollte wiederkehrende Entscheidungen abbilden, nicht nur Projektaufgaben. Die schwierigen Fragen betreffen meist Definitionen, Datenverantwortung, Systemänderungen, Forecast-Regeln, Übergaben und Executive-Reporting.
- Jede Entscheidung braucht einen rechenschaftspflichtigen Verantwortlichen. Gemeinsamer Input ist gesund. Geteilte Rechenschaftspflicht erzeugt oft Verzögerung und politische Eskalation.
- RevOps sollte nicht für Ergebnisse rechenschaftspflichtig gemacht werden, ohne Autorität zu haben. Verantwortet RevOps die Datenqualität, muss es Feld- und Workflow-Änderungen genehmigen, ablehnen oder eskalieren können.
- Ein RACI funktioniert am besten in Kombination mit dem Einstellungsmandat. Die erste RevOps-Einstellung braucht Entscheidungsrechte, die zur Verantwortungsmatrix passen.
Was RACI bei RevOps bedeutet
| Rolle | Bedeutung |
|---|---|
| Verantwortlich (Responsible) | Erledigt die Arbeit |
| Rechenschaftspflichtig (Accountable) | Verantwortet die endgültige Entscheidung oder das Ergebnis |
| Konsultiert (Consulted) | Liefert Input vor der Entscheidung |
| Informiert (Informed) | Muss nach der Entscheidung Bescheid wissen |
RevOps muss oft für das System rechenschaftspflichtig sein, auch wenn ein anderes Team für die lokale Umsetzung verantwortlich ist.
Diese Unterscheidung ist wichtig. Sales-Manager sind vielleicht verantwortlich dafür, Mitarbeiter zum Erfassen der nächsten Schritte zu coachen. RevOps ist vielleicht rechenschaftspflichtig für die Stage-Definition, Pflichtfelder, Dashboard-Regeln und den Überprüfungsrhythmus, die diese nächsten Schritte nutzbar machen. Finance wird vielleicht konsultiert, weil dieselben Opportunity-Daten in die Planung einfließen.
Deshalb braucht das Design eines RevOps-RACI mehr Sorgfalt als ein normales Projekt-RACI. Das Ergebnis ist nicht nur eine Projektlieferung. Es ist ein dauerhaftes Betriebsmodell. Wo Entscheidungsrechte landen, hängt auch davon ab, ob Sie zentralisiertes oder eingebettetes RevOps betreiben.
Kern-RACI für RevOps
| Entscheidung oder Prozess | Verantwortlich | Rechenschaftspflichtig | Konsultiert | Informiert |
|---|---|---|---|---|
| Definitionen des Umsatz-Lifecycles | RevOps | CRO | Marketing, Sales, CS, Finance | GTM-Teams |
| Governance der Lead-Quellen | Marketing Ops | RevOps | Finance, Sales | Marketing und Sales |
| Regeln für Lead-Routing | RevOps oder Sales Ops | RevOps | Sales-Manager, Marketing | SDRs und AEs |
| MQL-Definition | Marketing Ops und RevOps | CMO und CRO | Sales, SDR-Leitung | Marketing und Sales |
| Akzeptanzkriterien für SQL | Sales Ops und RevOps | VP Sales | Marketing, SDR-Leitung | Sales und Marketing |
| Kriterien der Opportunity-Stage | Sales Ops | VP Sales | RevOps, Finance | Sales-Team |
| Regeln der Forecast-Kategorie | RevOps | CRO | Sales, Finance | Führungsteam |
| Felder für die Übergabe nach gewonnenem Abschluss | RevOps und CS Ops | COO oder CRO | Sales, CS | Sales und CS |
| Definitionen des Executive-Dashboards | RevOps-Analytics | RevOps | Finance, GTM-Führung | Führungsteam |
| CRM-Feldänderungen | Systemverantwortlicher | RevOps | Betroffene Fachbereiche | Feldnutzer |
Diese Tabelle ist ein Ausgangspunkt. Passen Sie sie an Ihre Unternehmensstruktur an.
So bauen Sie ein RevOps-RACI auf
Beginnen Sie mit Entscheidungen, nicht mit Abteilungen.
Ein schwaches RACI beginnt mit einer Liste von Teams und fragt: "Was verantwortet jedes Team?" Das spiegelt meist die bestehende Politik wider. Ein stärkeres RACI beginnt mit den wiederkehrenden Entscheidungen, die Reibung erzeugen:
- Was gilt als qualifizierter Lead?
- Wann kann ein Deal in Stage 3 wechseln?
- Wer kann ein neues Pflichtfeld anlegen?
- Welcher Bericht ist die verlässliche Quelle für die Pipeline?
- Wer genehmigt Routing-Änderungen?
- Wer entscheidet über Forecast-Kategorien?
- Welche Daten müssen von Sales zu CS übergehen?
- Wer verantwortet die Taxonomie der Churn-Gründe?
Weisen Sie nach der Auflistung der Entscheidungen Rollen zu.
Wählen Sie für jede Entscheidung einen rechenschaftspflichtigen Verantwortlichen. Identifizieren Sie dann, wer die Arbeit macht, wer Input liefern muss und wer informiert werden muss. Gibt es zwei rechenschaftspflichtige Verantwortliche, halten Sie inne und lösen Sie das auf. Gemeinsamer Input ist in Ordnung. Geteilte Rechenschaftspflicht bedeutet meist, dass niemand die endgültige Entscheidung treffen kann.
Erstellen Sie zuerst das Entscheidungsinventar
Das nützlichste RevOps-RACI beginnt mit einem Entscheidungsinventar.
Listen Sie die wiederkehrenden Entscheidungen auf, die Verwirrung stiften:
| Entscheidungsbereich | Beispielentscheidung | Warum sie ein RACI braucht |
|---|---|---|
| Lifecycle | Was macht aus einem Lead einen MQL oder SQL? | Beeinflusst Marketing, Sales, Reporting und Finance |
| Routing | Welcher Owner erhält einen Lead, wenn Kontoverantwortung und Gebiet kollidieren? | Beeinflusst Reaktionszeit und Fairness gegenüber Mitarbeitern |
| Datenfelder | Wann sollte ein CRM-Feld verpflichtend werden? | Beeinflusst Nutzeraufwand und Reporting-Qualität |
| Forecast | Welche Evidenz ist für Commit erforderlich? | Beeinflusst Vertrauen der Führung und Planung |
| Übergabe | Was muss abgeschlossen sein, bevor CS einen gewonnenen Deal übernimmt? | Beeinflusst Onboarding und Kundenvertrauen |
| Dashboards | Welche Kennzahlendefinition erreicht die Führung? | Beeinflusst Board-Reporting und Managemententscheidungen |
| Automatisierung | Wer genehmigt einen Workflow, der Owner oder Status ändert? | Beeinflusst Systemverhalten und Nutzervertrauen |
Das Inventar sollte auf echter Reibung basieren, nicht auf theoretischer Vollständigkeit. Ziehen Sie Beispiele aus dem letzten Quartal heran: umstrittene Berichte, gescheiterte Übergaben, unordentliche Feldanfragen, Forecast-Uneinigkeiten, Routing-Ausnahmen und Dashboard-Neubauten. Das sind die Entscheidungen, die das RACI zuerst klären sollte.
Sobald das Inventar existiert, gruppieren Sie Entscheidungen nach Risiko. Risikoarme Entscheidungen können schnell mit RevOps und einem Systemverantwortlichen getroffen werden. Risikoreiche Entscheidungen brauchen Finance, fachliche Führung oder Genehmigung durch die Geschäftsleitung.
| Risikostufe | Beispiel | Entscheidungsmodell |
|---|---|---|
| Niedrig | Eine Berichtsansicht umbenennen oder Feld-Hilfetext bereinigen | RevOps entscheidet, Nutzer werden informiert |
| Mittel | Einen Workflow-Alert oder ein optionales Feld hinzufügen | RevOps rechenschaftspflichtig, betroffene Teams konsultiert |
| Hoch | Definition der Forecast-Kategorie oder erforderliche Übergabefelder ändern | Executive- oder Fachverantwortlicher rechenschaftspflichtig, RevOps steuert den Prozess |
| Kritisch | Umsatzkennzahl ändern, die im Board-Reporting verwendet wird | Finance und Umsatzführung genehmigen, RevOps dokumentiert und setzt um |
Diese Risikosicht verhindert, dass das RACI jede kleine Änderung verlangsamt. Sie verhindert auch, dass Änderungen mit großer Wirkung durch beiläufige Anfragen passieren.
RACI nach Umsatz-Lifecycle
Ein hilfreiches RevOps-RACI bildet Verantwortung über den gesamten Lifecycle ab:
| Lifecycle-Bereich | Rechenschaftspflichtiger Verantwortlicher | Rolle von RevOps |
|---|---|---|
| Definition der Zielkonten | Marketing- oder GTM-Führung | Konsultiert bei Datenmodell und Segmentierung |
| Lead-Erfassung | Marketing Ops | Konsultiert bei Quell- und Attributionsfeldern |
| Lead-Qualifizierung | CMO und CRO | Verantwortlich für die gemeinsame Definitions-Governance |
| Lead-Routing | RevOps | Rechenschaftspflichtig für Routing-Logik und SLA-Reporting |
| Opportunity-Erstellung | Sales-Führung | Konsultiert bei erforderlichen Kriterien und Felddesign |
| Opportunity-Stages | VP Sales | Konsultiert oder verantwortlich für Prozess-Governance |
| Forecast-Prozess | CRO | Verantwortlich für Rhythmus, Datenqualität und Regeln |
| Übergabe nach gewonnenem Abschluss | RevOps oder COO | Rechenschaftspflichtig für Workflow und Vollständigkeit |
| Verlängerungsforecast | CS-Leitung oder CRO | Konsultiert bei Datenmodell und Reporting |
| Expansions-Pipeline | Sales- oder CS-Führung | Verantwortlich für Auslöserregeln und Reporting |
Diese Sicht hilft Führungskräften zu verstehen, warum RevOps nicht nur eine Sales-Support-Funktion sein kann. Dasselbe operative System umspannt die gesamte Reise.
RACI für CRM- und Reporting-Änderungen
CRM-Änderungen sind der Punkt, an dem unklare Verantwortung teuer wird.
Nutzen Sie ein separates RACI für Systemänderungen:
| Art der Änderung | Verantwortlich | Rechenschaftspflichtig | Konsultiert | Informiert |
|---|---|---|---|---|
| Neues Feld | Systemverantwortlicher | RevOps | Anfragendes Team, Finance bei Kennzahlenbezug | Betroffene Nutzer |
| Pflichtfeld | RevOps | RevOps und Fachführung | Sales-Manager, CS-Manager, Systeme | Feldnutzer |
| Workflow-Automatisierung | Systemverantwortlicher | RevOps | Betroffene Fachbereiche, IT/Sicherheit | Manager und Nutzer |
| Dashboard-Kennzahl | RevOps-Analytics | RevOps | Finance, GTM-Führung | Führungsteam |
| Integration | Systeme oder IT | Systemführung | RevOps, Daten, betroffener Fachbereich | Nutzer und Führungskräfte |
| Änderung des Objektmodells | Systeme und RevOps | RevOps plus Executive Sponsor | Finance, Daten, betroffene Führungskräfte | GTM-Teams |
Das verhindert den häufigsten Fehler: dass ein Fachbereich gemeinsame Datenstrukturen für einen lokalen Bedarf ändert.
Regeln zur Konfliktlösung
Selbst ein gutes RACI beseitigt nicht jeden Konflikt.
Ergänzen Sie Eskalationsregeln:
- Betrifft der Streit nur einen Fachbereich, entscheidet die fachliche Führung.
- Betrifft der Streit gemeinsame Daten, entscheidet oder empfiehlt RevOps.
- Betrifft der Streit Forecast, Planung oder Board-Reporting, müssen sich RevOps und Finance vor dem Launch abstimmen.
- Betrifft der Streit die Kundenerfahrung über Teams hinweg, entscheidet der CRO oder COO.
- Betrifft der Streit Kompromisse auf Unternehmensebene, entscheidet der Executive Sponsor.
Eskalationsregeln sind wichtig, weil RevOps oft zwischen starken Führungskräften mit berechtigten Bedürfnissen steht. Das RACI sollte den Entscheidungsweg sichtbar machen, bevor der Konflikt persönlich wird.
Regeln zur Nutzung des RACI
Ein rechenschaftspflichtiger Verantwortlicher. Mehrere konsultierte Personen sind in Ordnung. Mehrere rechenschaftspflichtige Verantwortliche erzeugen Stillstand.
Fachliche Führungskräfte verantworten weiterhin die Leistung. RevOps kann das System verantworten, aber der Sales-Leiter verantwortet weiterhin die Vertriebsleistung, und der CS-Leiter verantwortet weiterhin die Umsetzung der Bindung.
Entscheidungsrechte müssen zur Verantwortung passen. Machen Sie RevOps nicht für Datenqualität rechenschaftspflichtig, wenn es die Feld-Governance nicht durchsetzen kann.
Nach Organisationsänderungen überprüfen. Ein RACI veraltet, wenn sich Teams, Systeme oder GTM-Motions ändern.
Häufige RACI-Fehler
Zu viele rechenschaftspflichtige Verantwortliche. Das ist der häufigste Fehler. Sind zwei Führungskräfte rechenschaftspflichtig, hat keine ein klares Mandat.
RevOps verantwortlich, aber nicht befugt. Machen Sie RevOps nicht für Datenqualität rechenschaftspflichtig, wenn es geringwertige Felder nicht ablehnen, Stage-Kriterien nicht ändern oder Übergaberegeln nicht durchsetzen kann.
Finance zu spät informiert. Erscheint eine Kennzahl im Board-Reporting, sollte Finance meist konsultiert werden, bevor sich Definitionen ändern.
Eingebettete Ops-Teams folgen unterschiedlichen Regeln. Marketing Ops, Sales Ops und CS Ops können nah an ihren Fachbereichen bleiben, aber gemeinsame Definitionen brauchen ein Governance-Modell.
Das RACI wird bei der Aufnahme nicht genutzt. Kommen Anfragen weiterhin als "Kannst du das bauen?" an, wird RevOps zur Ticket-Warteschlange. Die Aufnahme sollte fragen, welche Entscheidung die Anfrage betrifft und wer rechenschaftspflichtig ist.
Überprüfungsrhythmus
Überprüfen Sie das RevOps-RACI vierteljährlich und früher nach größeren Änderungen.
Auslöser sind unter anderem:
- Neuer CRO, CMO, CS-Leiter, CFO oder COO
- Neue GTM-Motion
- Neues CRM oder größere Systemänderung
- Akquisition oder Aufteilung einer Geschäftseinheit
- Wechsel vom Fokus auf Neugeschäft zum Fokus auf Expansion
- Wiederholte Streitigkeiten über denselben Verantwortungsbereich
Ein RACI ist kein statisches Dokument. Es ist eine Arbeitsvereinbarung. Nutzen Führungskräfte es nicht mehr, driftet Verantwortung zurück in informelle Macht und wiederholte Debatten.
Meeting-Modell
Das RACI sollte in wiederkehrenden operativen Meetings genutzt werden, nicht in einem Ordner abgelegt.
Nutzen Sie es in:
- Review der RevOps-Roadmap
- Review der Systemänderungen
- Review der Forecast-Governance
- Review der Funnel-Definition
- Review der Lead-Qualität
- Review der Übergabe nach gewonnenem Abschluss
- Review der Dashboard-Definition
Jedes Meeting sollte dieselben Verantwortungsfragen beantworten:
- Welche Entscheidung treffen wir?
- Wer ist rechenschaftspflichtig?
- Wer muss vor der Entscheidung konsultiert werden?
- Wer muss nach der Entscheidung informiert werden?
- Welche Daten oder Evidenz sind erforderlich?
- Was ändert sich im System nach der Entscheidung?
Das macht das RACI praktisch. Führungskräfte müssen kein Dokument auswendig lernen. Sie brauchen die Gewohnheit, Verantwortungssprache zu nutzen, wenn sich das Umsatzsystem ändert.
Beispiel: Änderung des Lead-Routings
Angenommen, Sales möchte Enterprise-Leads direkt an erfahrene AEs weiterleiten, während Marketing sie zuerst zur Qualifizierung an SDRs weiterleiten möchte.
Ohne RACI wird das zu einer Debatte über Vorlieben.
Mit einem RACI:
- RevOps ist verantwortlich, die Routing-Logik und die SLA-Auswirkung abzubilden.
- Der CRO ist rechenschaftspflichtig für die Entscheidung zum Umsatz-Workflow.
- Marketing, SDR-Leitung, Sales-Manager und Finance werden konsultiert.
- SDRs, AEs und Marketing-Kampagnenverantwortliche werden nach der Änderung informiert.
RevOps kann dann die operative Wirkung testen: Reaktionszeit, Akzeptanzrate, Konversionsrate, Kapazität der Owner und Reporting-Änderungen. Das RACI entscheidet nicht über die Strategie, aber es macht den Entscheidungsweg klar.
Beispiel: neues Pflichtfeld
Pflichtfelder sind eine häufige Reibungsquelle.
Sales widersetzt sich vielleicht, weil Felder den Workflow der Mitarbeiter verlangsamen. Marketing möchte vielleicht mehr Segmentierungsdaten. CS braucht vielleicht Übergabekontext. Finance braucht vielleicht saubereres Reporting.
Ein RACI hilft, den Wert eines Feldes von seiner Verantwortung zu trennen:
- Das anfragende Team ist verantwortlich zu erklären, welche Entscheidung das Feld unterstützt.
- RevOps ist rechenschaftspflichtig für die Feld-Governance.
- Systeme sind verantwortlich für die Konfiguration.
- Betroffene Manager werden konsultiert.
- Nutzer werden mit klaren Rollout-Hinweisen informiert.
RevOps sollte das Feld nur genehmigen, wenn es eine echte Entscheidung oder einen echten Workflow unterstützt. Unterstützt das Feld nur gelegentliche Neugier, sollte es optional bleiben oder an einen anderen Erfassungspunkt wechseln.
Autorität muss zur Rechenschaftspflicht passen
Ein RACI kann auf dem Papier sauber aussehen und trotzdem scheitern, wenn Autorität fehlt.
Häufige Diskrepanzen:
| RACI-Zuweisung | Fehlende Autorität |
|---|---|
| RevOps rechenschaftspflichtig für CRM-Datenqualität | RevOps kann Feldanfragen nicht ablehnen |
| Sales rechenschaftspflichtig für Stage-Genauigkeit | Manager prüfen keine Stage-Nachweise |
| Finance konsultiert bei Board-Kennzahlen | Finance sieht Definitionen erst, nachdem Dashboards gebaut wurden |
| CS verantwortlich für Churn-Gründe | CS hat keine genehmigte Taxonomie oder keinen Review-Rhythmus |
| Marketing verantwortlich für Quellqualität | Quellregeln werden bei der Opportunity-Konvertierung überschrieben |
Beheben Sie die Autoritätslücke, bevor Sie die Matrix veröffentlichen. Ist RevOps rechenschaftspflichtig für Governance, müssen Führungskräfte akzeptieren, dass RevOps geringwertige Anfragen pausieren, Definitionen verlangen und Konflikte eskalieren kann. Verantworten fachliche Führungskräfte das Verhalten, müssen sie es in ihren Teams überprüfen. Wird Finance bei Planungskennzahlen konsultiert, braucht Finance einen Sitz am Tisch, bevor die Kennzahl live geht, nicht danach.
Das RACI sollte auch festlegen, was passiert, wenn der rechenschaftspflichtige Verantwortliche nicht entscheidet. Blockiert zum Beispiel ein Lifecycle-Streit das Reporting länger als zwei Wochen, muss vielleicht der CRO oder COO die endgültige Entscheidung treffen. Ohne Eskalation benennt das RACI zwar Verantwortung, löst aber keine festgefahrenen Entscheidungen.
Wie das RACI mit dem Mandat zusammenhängt
Das RevOps-Mandat definiert den Auftrag. Das RACI definiert, wer innerhalb dieses Auftrags handelt.
Nutzen Sie das Mandat, um zu beantworten: "Gehört das zum Scope von RevOps?"
Nutzen Sie das RACI, um zu beantworten: "Wer entscheidet, wer erledigt die Arbeit, wer liefert Input, und wer wird benachrichtigt?"
Zusammen schaffen sie operative Disziplin. Getrennt sind sie schwächer. Ein Mandat ohne RACI ist zu weit gefasst. Ein RACI ohne Mandat klärt vielleicht Aufgaben, verfehlt aber den Zweck der Funktion.
Leichtgewichtige Version für kleine Teams
Kleine Unternehmen brauchen keine riesige Verantwortungsmatrix.
Beginnen Sie mit fünf Entscheidungen:
- Lifecycle-Definitionen
- Lead-Routing
- Regeln der Opportunity-Stage
- Forecast-Kategorien
- Anforderungen an die Übergabe nach gewonnenem Abschluss
Benennen Sie für jede einen rechenschaftspflichtigen Verantwortlichen und eine RevOps-Rolle. Das reicht aus, um Verwirrung zu reduzieren, ohne das Unternehmen zu verlangsamen.
Fügt das Unternehmen Segmente, Motions, Systeme und Ops-Spezialisten hinzu, erweitern Sie das RACI. Das Modell sollte mit der Komplexität wachsen.
Checkliste zur RACI-Reife
Testen Sie die Matrix vor der Veröffentlichung an jüngsten Konflikten.
Wählen Sie drei echte Beispiele aus dem letzten Quartal:
- Eine umstrittene Lead-Definition
- Eine Änderung der Forecast-Regel
- Eine Uneinigkeit bei der Dashboard-Kennzahl
- Eine Anfrage nach einem Pflichtfeld
- Ein Fehlschlag bei der Übergabe nach gewonnenem Abschluss
- Eine Routing-Eskalation
Fragen Sie für jedes Beispiel, ob das RACI den Entscheidungsweg offensichtlich macht. Können Führungskräfte immer noch nicht sagen, wer rechenschaftspflichtig ist, ist die Matrix nicht bereit.
Testen Sie auch, ob der rechenschaftspflichtige Verantwortliche die Autorität zum Handeln hat. Ein RACI, das Rechenschaftspflicht ohne Autorität zuweist, erzeugt Frustration. Ist RevOps rechenschaftspflichtig für Feld-Governance, muss es Feldänderungen genehmigen, ablehnen oder eskalieren können. Ist Sales rechenschaftspflichtig für Stage-Genauigkeit, brauchen Manager einen Überprüfungsrhythmus und Konsequenzen bei schlechter Hygiene.
Der letzte Test ist die Nutzbarkeit. Das RACI sollte auf wenige Seiten passen und leicht zu überfliegen sein. Ist die Matrix so detailliert, dass niemand sie nutzt, beginnen Sie kleiner und konzentrieren Sie sich auf die Entscheidungen, die die meiste Umsatzreibung erzeugen.
Sobald die Matrix live ist, verweisen Sie bei jeder bedeutenden System- oder Prozessänderung darauf. Diese wiederholte Nutzung macht aus Verantwortung ein Dokument zu operativem Verhalten und reduziert wiederholte Debatten.
So bleibt das RACI leichtgewichtig
Das RACI sollte detailliert genug sein, um Konflikte zu lösen, aber nicht so detailliert, dass niemand es öffnet.
Nutzen Sie drei Ebenen:
| Ebene | Was sie abdeckt | Überprüfungsrhythmus |
|---|---|---|
| Executive-Entscheidungen | Forecast-Definitionen, Board-Kennzahlen, Lifecycle-Modell, größere Systemänderungen | Vierteljährlich oder bei Strategieänderungen |
| Operative Entscheidungen | Routing, Übergaben, Feld-Governance, Dashboard-Definitionen, SLA-Regeln | Monatlich oder über die Aufnahme |
| Administrative Entscheidungen | Bereinigung von Berichten, Feld-Hilfetext, Ansichtsänderungen, kleinere Workflow-Anpassungen | Nach Bedarf |
Dieses geschichtete Modell hilft kleinen Unternehmen, übermäßigen Prozess zu vermeiden, während größere Teams genug Kontrolle erhalten. Eine kleine Berichtsbereinigung sollte kein Lenkungskomitee erfordern. Eine Änderung der Forecast-Kategoriedefinitionen sollte nicht innerhalb eines Tickets passieren.
Das beste Zeichen dafür, dass das RACI funktioniert, ist nicht, dass Menschen es ständig zitieren. Es ist, dass weniger Entscheidungen stocken, weil alle den Weg bereits kennen.
Aufnahmefragen für das RACI
Nutzen Sie das RACI in dem Moment, in dem eine Anfrage bei RevOps eingeht.
Statt nur zu fragen "Was soll gebaut werden?", sollte die Aufnahme fragen:
- Welche Geschäftsentscheidung betrifft diese Anfrage?
- Welches Feld, welcher Workflow, welches Dashboard oder welche Übergabe ändert sich?
- Wer ist rechenschaftspflichtig für das Geschäftsergebnis?
- Wer muss vor der Umsetzung konsultiert werden?
- Welche Teams müssen nach dem Launch informiert werden?
- Muss Finance die Definition prüfen?
- Betrifft die Änderung Executive-Reporting oder Forecast?
- Was passiert, wenn die Anfrage abgelehnt oder verschoben wird?
Diese Fragen bremsen schwache Anfragen ab, bevor sie zu Systemarbeit werden. Ein Team, das ein neues Dashboard anfragt, hat vielleicht keine Kennzahlendefinition. Eine Führungskraft, die ein Pflichtfeld anfragt, weiß vielleicht nicht, wer den Wert verantwortet. Ein Manager, der eine Routing-Ausnahme anfragt, hat vielleicht Kapazität oder Reporting-Auswirkung nicht bedacht.
Der Aufnahmeprozess sollte nicht schwerfällig sein. Er kann ein kurzes Formular oder eine Checkliste im RevOps-Backlog sein. Wichtig ist, dass jede bedeutende Anfrage mit einem rechenschaftspflichtigen Verantwortlichen und einem Entscheidungsweg verbunden ist.
Das schützt auch die Kapazität von RevOps. Ohne Aufnahmedisziplin verbringt das Team Zeit damit, lokale Fixes zu bauen, die gemeinsame Komplexität erzeugen. Mit RACI-basierter Aufnahme kann RevOps erklären, warum manche Anfragen schnell laufen, manche Konsultation brauchen und manche nicht gebaut werden sollten.
Anzeichen, dass das RACI funktioniert
Achten Sie auf Verhaltensänderungen:
- Feldanfragen kommen mit Owner, Definition und Geschäftsgrund an.
- Dashboard-Streitigkeiten werden über vereinbarte Regeln der verlässlichen Quelle gelöst.
- Änderungen der Forecast-Regel beziehen Sales, Finance und RevOps vor dem Launch ein.
- Fehlgeschlagene Übergaben führen zu Änderungen der Verantwortung, nicht nur zu Erinnerungen.
- Teams wissen, wer entscheidet, bevor das Meeting beginnt.
- RevOps verbringt weniger Zeit damit, wiederholte Debatten zu moderieren.
Das RACI ist erfolgreich, wenn Entscheidungen schneller und klarer werden. Es sollte Meeting-Zeit reduzieren, Nacharbeit senken und Eskalation weniger persönlich machen.
RACI-Entscheidungspaket
Nutzen Sie ein Entscheidungspaket, wenn Verantwortung umstritten ist.
| Punkt | Was zu erfassen ist |
|---|---|
| Entscheidung | Was entschieden werden muss |
| Geschäftliche Auswirkung | Warum die Entscheidung wichtig ist |
| Verantwortlich | Wer die Arbeit macht |
| Rechenschaftspflichtig | Wer das Ergebnis verantwortet |
| Konsultiert | Wer Input geben muss |
| Informiert | Wer Sichtbarkeit braucht |
| Eskalation | Wer den Konflikt löst |
Das verhindert, dass das RACI zu einem statischen Dokument wird. Es wird nützlich, wenn Führungskräfte es zur Klärung echter operativer Entscheidungen nutzen.
FAQ
Braucht RevOps ein RACI?
Ja, sobald mehrere Teams von demselben Umsatzsystem abhängen. Ohne RACI werden Übergaben und Datenverantwortung informell.
Wer sollte für die Prognosegenauigkeit rechenschaftspflichtig sein?
Die Sales-Führung verantwortet meist das Forecast-Ergebnis. RevOps verantwortet Forecast-Prozess, Definitionen, Datenqualität und Überprüfungsrhythmus. Finance ist ein wichtiger konsultierter Partner.
Reicht RACI für Entscheidungsfindung aus?
Manchmal. Bei Entscheidungen mit hohem Einsatz ist DACI vielleicht besser, weil es den Entscheidungstreiber und den Genehmiger explizit definiert.
Mehr erfahren

Senior Operations & Growth Strategist
On this page
- Was RACI bei RevOps bedeutet
- Kern-RACI für RevOps
- So bauen Sie ein RevOps-RACI auf
- Erstellen Sie zuerst das Entscheidungsinventar
- RACI nach Umsatz-Lifecycle
- RACI für CRM- und Reporting-Änderungen
- Regeln zur Konfliktlösung
- Regeln zur Nutzung des RACI
- Häufige RACI-Fehler
- Überprüfungsrhythmus
- Meeting-Modell
- Beispiel: Änderung des Lead-Routings
- Beispiel: neues Pflichtfeld
- Autorität muss zur Rechenschaftspflicht passen
- Wie das RACI mit dem Mandat zusammenhängt
- Leichtgewichtige Version für kleine Teams
- Checkliste zur RACI-Reife
- So bleibt das RACI leichtgewichtig
- Aufnahmefragen für das RACI
- Anzeichen, dass das RACI funktioniert
- RACI-Entscheidungspaket
- FAQ
- Braucht RevOps ein RACI?
- Wer sollte für die Prognosegenauigkeit rechenschaftspflichtig sein?
- Reicht RACI für Entscheidungsfindung aus?
- Mehr erfahren