Niemals stillschweigend im Konto eines Kunden handeln

ClickFortify arbeitet in den Systemen anderer. Um schlechten Traffic auszuschließen, muss es sich mit dem Google-Ads- oder Meta-Konto eines Kunden verbinden und dort Dinge ändern. Dieser Zugriff ist zentral für das Produkt, und er ist zugleich der Teil, mit dem ich am vorsichtigsten umgehe. Aus dieser Vorsicht ist eine Regel entstanden, die heute jeden ähnlichen Fall prägt: Wir handeln niemals stillschweigend im Konto eines Kunden.

Woher die Regel kommt

Bei der Arbeit an der Meta-Anbindung kam der Vorschlag, automatisch ein Meta Pixel anzulegen, wenn der Kunde noch keines hat. Auf den ersten Blick klang das hilfreich. Der Kunde braucht ein Pixel, wir können eines erstellen, warum also fragen?

Ich habe abgelehnt. Nicht weil ein Pixel gefährlich wäre, sondern wegen dessen, was die Abkürzung voraussetzt: dass wir besser als der Kunde wissen, was in seinem Konto existieren soll, wie es heißen soll und wo es liegen soll. Das wissen wir nicht. Es ist sein Konto.

Was wir stattdessen tun

Jeder Ablauf, der etwas im externen Konto eines Kunden bereitstellen würde, zeigt zuerst einen Prüfschritt. Dieser Schritt hat vier Teile:

• Ein bearbeitbarer Name. Wir schlagen einen vor, und der Kunde kann ihn ändern.
• Wo es angelegt wird. Das Konto oder Unternehmen, unter dem es liegen wird, klar benannt.
• Was wir damit tun. Ein ehrlicher Satz dazu, warum wir es brauchen.
• Ein Button „Erstellen“, den der Kunde selbst drückt. Nichts passiert im Hintergrund.

Standardwerte sind in Ordnung. Ein guter Standardwert spart dem Kunden Zeit, und die meisten werden ihn übernehmen. Stillschweigendes Ausführen ist nicht in Ordnung. Der Unterschied ist im Aufwand klein und in der Bedeutung groß: Mit einem Standardwert entscheidet der Kunde; ohne den Prüfschritt entscheiden wir für ihn.

Die Regel gilt nicht nur für Pixel. Sie umfasst alles, was wir im Konto eines Kunden bereitstellen könnten, sei es ein Tag, eine Zielgruppe oder eine andere Entität auf der Plattform.

// Illustrative: a change we propose, but never apply on our own
type ProposedAction = {
  kind: 'create';
  resourceType: string;  // what will be created
  name: string;          // suggested by us, editable by the customer
  parentId: string;      // the account or business it will live under
  purpose: string;       // what we will do with it, in plain words
  confirmedBy?: string;  // empty until the customer presses Create
};

Die nützliche Eigenschaft steckt im letzten Feld. Solange kein Mensch die Aktion bestätigt hat, ist sie nur ein Vorschlag.

Warum das wichtig ist

Der Kunde behält die Kontrolle über Benennung und Platzierung. Ein Werbekonto wird selten nur von einer Person oder einem Tool genutzt. Eine Ressource mit einem Namen, den niemand gewählt hat, unter einem Unternehmen, das niemand ausgesucht hat, ist bestenfalls Ballast und schlimmstenfalls Verwirrung.

Vertrauen ist das Produkt. Ein Kunde, der sein Werbekonto verbindet, leiht uns seine Schlüssel. Entdeckt er etwas, das wir ohne Nachfrage angelegt haben, lautet die nächste Frage, was wir sonst noch getan haben. Stillschweigendes Anlegen wirkt bevormundend, selbst wenn die Absicht gut ist.

Überraschungen im System eines anderen sind teuer. Das Konto des Kunden gehört nicht uns, und wir sehen nicht alles, was sonst darin passiert. Eine Änderung, die aus unserer Sicht harmlos wirkt, kann mit dem Namensschema oder dem Reporting von jemandem kollidieren.

Es erleichtert Support und Rückgängigmachen. Hat der Kunde etwas bewusst angelegt, über einen Bildschirm, der ihm sagte, wofür es ist, weiß er, woher es kommt. Will er es rückgängig machen, weiß er, wonach er suchen muss. Eine Aktion im Hintergrund überlässt es ihm, das selbst herauszufinden.

Über das Anlegen hinaus

Dieselbe Überlegung gilt für alles, was ein Produkt in einem externen System tut, nicht nur für das Anlegen von Ressourcen. Ein Ausschluss, der in ein Werbekonto geschrieben wird, ist ebenfalls eine Änderung am Setup eines anderen. Meiner Ansicht nach sollten solche Änderungen sichtbar und zuordenbar sein: Der Kunde sollte sehen können, was getan wurde und dass es von uns kam. Das ist ein Grundsatz, den ich vertrete, keine Beschreibung jedes Bildschirms, den wir haben.

Fazit

1. Behandeln Sie das externe Konto eines Kunden als seines, auch wenn Sie Schreibzugriff darauf haben.
2. Bieten Sie Standardwerte an, aber stellen Sie jedes Anlegen hinter einen Prüfschritt mit bearbeitbarem Namen, Ort, Zweck und einem ausdrücklichen Bestätigungsbutton.
3. Modellieren Sie das Bereitstellen als Vorschlag, der erst zur Aktion wird, nachdem ein Mensch ihn bestätigt hat.
4. Fragen Sie sich, ob der Kunde überrascht wäre, die Änderung später zu finden. Wenn ja, nehmen Sie sie nicht stillschweigend vor.