Wie führen Sie fünf verschiedene Arten von Kundenanfragen durch einen einzigen Helpdesk?

01Das Geschäftsproblem

Ein Hersteller verkauft über ein Netz unabhängiger Distributoren. Diese Distributoren brauchen ständig etwas vom Hersteller, und die Anfragen haben nicht alle dieselbe Form:

• Eine Bestellung, die zu vereinbarten Preisen bearbeitet werden soll
• Eine Angebotsanfrage für eine Liste von Teilen, mit Mengen und einem Wunschtermin
• Eine Neuproduktanfrage – etwas, das nicht im Katalog steht und eine technische Machbarkeitsprüfung sowie die Freigabe durch sechs interne Abteilungen braucht, bevor ein Preis genannt werden kann
• Eine Materialzertifikatsanfrage für ein bestimmtes Produktionslos, um die Compliance-Akte eines Endkunden zu erfüllen
• Eine allgemeine Frage oder Beschwerde, die zu nichts davon passt

Vor dem Projekt kamen alle fünf als E-Mails und Anrufe in gemeinsame Postfächer. Nichts hatte eine Referenznummer, niemand konnte „Wo steht meine Anfrage?“ beantworten, ohne einen Menschen zu fragen, und es gab keine Möglichkeit zu sehen, wie lange etwas gedauert hatte.

Was das Unternehmen wollte, war ein Helpdesk mit:

• einer einzigen Warteschlange und einer einzigen Referenznummernserie, damit jede Anfrage in einer E-Mail zitiert werden kann;
• einem Status-Lebenszyklus, den alle verstehen, von neu bis gelöst;
• Self-Service für Distributoren – Einreicher sehen ihre eigenen Anfragen und keine anderen;
• einem Gesprächsverlauf pro Anfrage, mit strikter Trennung zwischen dem, was der Distributor sieht, und dem, was intern bleibt;
• einem Audit-Trail darüber, wer wann was geändert hat;
• und, nur für Neuproduktanfragen, einer formalen Freigabe durch mehrere Abteilungen.

Die Spannung liegt ganz in der Kombination. Einheitlichkeit ist für die Warteschlange gewünscht. Unterschiede sind im Inhalt nötig: Eine Zertifikatsanfrage braucht eine Losnummer und eine Chargennummer und kann mit einem Lieferdatum nichts anfangen; eine Angebotsanfrage braucht eine sich wiederholende Reihe von Teilepositionen, die eine allgemeine Frage nie hat.

02Warum der naheliegende Ansatz scheitert

Es gibt zwei erste Reflexe, und beide sind auf eine Weise falsch, die einen Neuaufbau kostet.

Reflex eins: eine Entität plus ein „Request Type“-Dropdown

Das ist der Reflex, weil ein Dropdown das Billigste ist, was man anlegen kann. Er scheitert an einem konkreten, strukturellen Punkt: Ein Dropdown-Wert kann kein Formular auswählen.

Coevera bindet genau ein bearbeitbares Formularlayout an jeden CustomEntityType. Es gibt keinen Mechanismus, mit dem der Wert eines benutzerdefinierten Felds das Layout wechselt. Mit einem Dropdown bekommen Sie also genau ein Formular für alle fünf Typen, mit der Vereinigung aller Felder aller Typen – in diesem Aufbau sind das 42 Felder, gezählt auf dem vereinigten Formular im verifizierten Space am 2. September 2026, von denen jeweils rund ein Dutzend auf eine bestimmte Anfrage zutreffen. Distributoren werden bei einer Bestellung nach einer Losnummer gefragt. Das Formular lässt sich nicht sinnvoll machen.

Zwei weitere Folgen, weniger offensichtlich, aber genauso schädlich:

• Veränderbarkeit. typeId wird bei der Anlage gesetzt und ist unveränderlich – die Plattform erzwingt das, keine Schutz-Automatisierung nötig. Ein Dropdown kann jeder mit Feldzugriff bearbeiten, sodass eine Bestellung mitten in ihrem Lebenszyklus unbemerkt zu einer Zertifikatsanfrage werden kann – und damit jeden Bericht ungültig macht, der auf ihr aufbaut.
• Redundanz. Jeder Datensatz trüge dann zwei Antworten auf dieselbe Frage – seine echte typeId (die existiert, ob Sie sie nutzen oder nicht) und Ihr Dropdown –, und nichts hält beide in Übereinstimmung.

Reflex zwei: fünf getrennte benutzerdefinierte Entitäten

Der umgekehrte Reflex: Wenn die fünf Typen wirklich verschieden sind, modelliert man sie getrennt. Das ergibt saubere Formulare und verliert alles, worum das Unternehmen tatsächlich gebeten hat:

• Fünf Referenznummernsequenzen statt einer gemeinsamen Serie
• Keine gemeinsame Warteschlange. „Zeig mir alles Offene für diesen Distributor“ wird zu fünf Listenansichten, die ein Mensch im Kopf zusammenführen muss
• Fünf Feldpools, die synchron gehalten werden müssen. Status, Schweregrad, Einreicher, SLA-Ziel und ein Dutzend weitere sind allen Typen gemeinsam; jetzt existieren sie fünfmal und driften auseinander
• Keine Umwandlung an Ort und Stelle. Eine allgemeine Frage, die sich als Neuproduktanfrage herausstellt, kann nicht zu einer werden – sie muss in einer anderen Entität neu erfasst werden und verliert ihre Historie und ihre Referenznummer
• Jeder Bericht ist eine Vereinigung aus fünf Quellen, und jeder neue Typ macht daraus sechs

03Datenmodell

Eine benutzerdefinierte Entität, Case, mit fünf CustomEntityType-Datensätzen darunter. Zwei unterstützende benutzerdefinierte Entitäten und drei Erweiterungen eingebauter Entitäten.

Die Case-Entität und ihre Untertypen

Alle 42 benutzerdefinierten Felder werden einmal angelegt, auf der übergeordneten Entität. Die fünf Untertypen teilen diesen einen Feldpool; die Formulardefinition jedes Untertyps wählt die jeweils relevante Teilmenge. Diese Eigenschaft ist es, die das ganze Muster lohnend macht – 13 Felder sind allen fünf Typen gemeinsam und werden genau einmal definiert und gepflegt.

Überall, wo eine Unterscheidung nach Typ nötig ist – Formularauswahl, Automatisierungs-Trigger, gespeicherte Ansichten, API-Filter –, wird der Typ direkt über typeId oder type.name angesprochen. Kein Wrapper, kein benutzerdefiniertes Feld, keine Synchronisationslogik.

Unterstützende Entitäten

Die Entität Note ist dasselbe Muster ein zweites Mal, in kleinerem Maßstab: Statt eines benutzerdefinierten Booleans „ist intern“ trägt typeId die Sichtbarkeit. Zwei Untertypen, kein Flag, das man falsch setzen kann, und die Automatisierung filtert direkt auf den Typ. Autor und Zeitstempel kommen aus den nativen Feldern für Eigentümer und Anlage – für beides sind keine benutzerdefinierten Felder nötig.

Eingebaute Entitäten, erweitert

04Konfiguration auf Feldebene

42 benutzerdefinierte Felder auf Case, aufgeteilt in 13 gemeinsame plus einen typspezifischen Rest:

Die Feldbenennung folgt der Konvention der Plattform – benutzerdefinierte Felder tragen das Präfix cf_, Dropdown- und Lookup-Felder das Suffix _id, weil sie auf Options- oder Datensatz-UUIDs statt auf Literale verweisen, und Lookup-Felder sind nach der Beziehung benannt, die sie ausdrücken. Die Feldnamen in diesem Blueprint sind anonymisiert; Formen, Typen und Beziehungen sind wie gebaut.

Feldberechtigungen pro Rolle

Drei Rollen, und die Sichtbarkeitstrennung wird auf Feldebene erzwungen statt durch Verstecken in der Oberfläche: None, Read oder Full pro Feld und Rolle.

05Automatisierung & Logik

Neun Automatisierungsprozesse, alle auf Space-Ebene. Die ordnende Regel: ein Prozess pro Anliegen, gefiltert nach typeId. Weil alle fünf Untertypen eine Entität teilen, wird jeder Prozess einmal definiert, und ein Filterknoten früh im Graphen grenzt ihn auf die Typen ein, für die er gilt – statt fünf fast identischer Kopien.

Zwei Muster, die sich übertragen lassen

Der Einmal-Schutz. Um „wer das zuerst angenommen hat“ festzuhalten, ohne es bei jeder späteren Aktualisierung neu zu setzen, filtern Sie darauf, dass das Zielfeld leer ist, und setzen es auf den handelnden Benutzer. Die Bedingung macht den Schreibvorgang idempotent – kein eigenes Flag „Ist das schon gelaufen?“.

Die Eigentümerschaft bleibt, wo sie ist. Der Distributor, der den Case eingereicht hat, bleibt über dessen ganze Lebensdauer Eigentümer des Datensatzes; der interne Analyst wird in einem eigenen Lookup-Feld erfasst. Der Reflex ist, die Eigentümerschaft bei der Annahme auf den Analysten zu übertragen – aber die Eigentümerschaft steuert den Zugriff des Distributors auf seinen eigenen Datensatz. Eine Neuzuweisung würde dem Einreicher die Sicht auf seine eigene Anfrage nehmen.

06Grenzen & Kompromisse

Freigabeprozesse können keine benutzerdefinierte Entität als Ziel haben

Nur einer der fünf Typen – Neuproduktanfragen – braucht eine formale Freigabe, von sechs Abteilungen. Das Muster, das funktioniert, ist ein Proxy auf Quote:

1. Ein Case vom Typ Neuproduktanfrage wird angelegt.
2. Ein Prozess erzeugt ein verknüpftes Quote unter einem eigenen Quote-Typ, der für Freigaben reserviert ist.
3. Der Freigabeprozess läuft auf diesem Quote, nativ, mit der Standard-Freigabeoberfläche und dem Audit-Trail – Schwellenwert, Datensatzsperre und Freigeberrolle wie bei jedem Quote konfiguriert.
4. Das Quote trägt einen Lookup zurück auf den Case; die Plattform pflegt die Rückverknüpfung automatisch.
5. Bei der Entscheidung schreibt ein zweiter Prozess das Ergebnis in den Case-Status zurück.
6. Das Quote kann danach archiviert werden.

Warum Quote und nicht Opportunity, obwohl beide eine Freigabe tragen können:

• Semantische Passung. Eine Neuproduktanfrage ist eine Preisentscheidung – „Können wir das herstellen, und zu welchem Preis?“. Genau das modelliert Quote. Opportunity als Deal ist der falsche Rahmen.
• Keine Verschmutzung der Pipeline. Opportunity-Proxys würden in der Deal-Pipeline erscheinen und Prognosen und Umsatzberichte verfälschen. Ein Quote liegt in seinem eigenen Quote-Typ, aus dem Weg.
• Der Preis wird nativ erfasst. Die Positionen des Quote sind der vorgeschlagene Preis – ein benutzerdefiniertes Preisfeld auf dem Case ist also gar nicht nötig.
• Eingebauter Ablauf. Quote hat ein natives Ablaufdatum, nützlich, um eine Freigabeanfrage zeitlich zu begrenzen.

Zwei Rollup-Felder auf dem Case zeigen den Zustand des Proxys – Freigabestatus und Ablehnungsgrund –, abgeleitet aus dem verknüpften Quote statt gespeichert. Für diese ist keine Rückschreiblogik nötig; die Plattform aktualisiert sie, wenn sich das Quote ändert.

Eingebaute Notizen konnten keine zweistufige Sichtbarkeit abbilden

Die Anforderung ist ein einziger Verlauf, in dem manche Einträge für den Distributor sichtbar und manche streng intern sind. Die eingebaute Notizfunktion hat keine Sichtbarkeitsdimension, daher wurde der Verlauf zu einer benutzerdefinierten Entität mit zwei Untertypen. Ein Preis, den man ausdrücklich nennen sollte: Der Case hat daher sowohl eingebaute Notizen als auch einen benutzerdefinierten Notizverlauf, und die eingebauten müssen von den Formularen ferngehalten werden, damit es nicht zwei konkurrierende Orte zum Schreiben gibt.

Freitextfelder können keine Verteilerlisten steuern

Das Feld für zu benachrichtigende Kontakte begann als Textbereich, in den E-Mail-Adressen getippt wurden. Es wurde durch einen Mehrfachauswahl-Lookup auf Contact ersetzt, weil die Automatisierung Adressen nicht zuverlässig aus Freitext herauslesen kann, um eine Empfängerliste zu bilden. Wenn der Wert eines Felds verarbeitet und nicht nur gelesen werden muss, muss er eine typisierte Referenz sein.

Weitere Einschränkungen in diesem Aufbau

• Ein Feld muss auf dem Formular sein, um zu funktionieren. Berechnete und KI-befüllte Felder, die im Formularlayout eines Datensatzes fehlen, tun stillschweigend nichts – sie rechnen nicht und sie melden keinen Fehler. Die Zugehörigkeit zum Formular ist funktional, nicht kosmetisch.
• Sequenzen lassen sich nicht jährlich zurücksetzen. Der native Sequenzzähler erhöht sich bei jeder Anlage und hat keinen Jahres-Reset. Ein Jahr lässt sich als Präfix in die Nummer einbauen, aber der Zähler selbst läuft durchgehend.
• Prozesse auf Space-Ebene brauchen sitzungsauthentifizierte Anmeldedaten. Persönliche API-Zugangsdaten werden beim Schreiben von Space-Prozessen abgelehnt, obwohl sie sie lesen können.

Bekannte Lücken in diesem Aufbau

Berichtet statt weggelassen:

• Die Rückschreibung der Freigabe behandelt nur den Zweig „freigegeben“. Ein abgelehnter Proxy lässt den Case in seinem Arbeitszustand, ohne automatische Weitergabe – für das Ergebnis „abgelehnt“ ist ein paralleler Filter nötig.
• Der Prozess für Audit-Notizen löst bei jeder Case-Aktualisierung aus statt nur bei Statuswechseln; er braucht eine Bedingung auf geänderte Felder, damit er nicht mehr so viel Rauschen erzeugt.
• SLA-Zieldaten werden manuell gesetzt. Ihre Ableitung aus dem Schweregrad wurde entworfen und bewusst zurückgestellt.

07Verifizierung

Untertyp-Designs scheitern leise – ein Formular, das sich rendert, ein Prozess, der Erfolg meldet, und ein Unterscheidungsmerkmal, das mit dem Falschen verdrahtet ist. Was tatsächlich geprüft wurde:

• Feldinventar pro Entität zurückgelesen. Jedes Feld nach der Anlage erneut aus der API gelesen und anhand des API-Namens, nicht der Bezeichnung, mit der Spezifikation abgeglichen. Drei Felder hatten Namen, die von der Spezifikation abwichen, und eines war stillschweigend gar nicht angelegt worden – beides in der Oberfläche nicht sichtbar.
• Anzahl und Identität der Untertypen. Bestätigt, dass unter der Case-Entität fünf Untertypen existieren und kein verwaister sechster – die Falle mit dem automatischen Standard aus §3 zeigt sich genau hier.
• Unveränderlichkeit des Unterscheidungsmerkmals. Versucht, typeId an einem bestehenden Datensatz zu ändern, und bestätigt, dass die Plattform das verweigert.
• Feldzugriff pro Rolle, als jede Rolle getestet. Nicht aus der Konfiguration abgelesen – angemeldet und bestätigt, dass die Felder, die für einen Distributor unsichtbar sein sollen, tatsächlich fehlen.
• Jeder Prozess als aktiviert bestätigt und sein Knotengraph zurückgelesen. Zwei Prozesse waren aktiviert, endeten aber an Platzhalterknoten – sie meldeten Erfolg und taten nichts. Das ist die Prüfung, die die Lücke bei der Rückschreibung der Freigabe gefunden hat.
• Ein vollständiger Durchlauf pro Untertyp in der Oberfläche: anlegen, durch den Lebenszyklus führen, bestätigen, dass Notizen und E-Mails ankommen, und bestätigen, dass die Distributor-Ansicht nur zeigt, was sie zeigen soll.

Was auf eine Regression hindeuten würde: Cases, die mit leerem oder falschem Untertyp erscheinen; das Feld für den zuständigen Analysten, das sich nach der ersten Annahme ändert; Notizen, die als intern geschrieben wurden und einen Distributor erreichen; Neuproduktanfragen ohne verknüpften Freigabe-Proxy.

Verwandte Blueprints

• Blueprint 003 — Wie modellieren Sie etwas, für das Ihr CRM kein Objekt hat? — die Platzierungsentscheidung, die dieser Blueprint anwendet: Feld, Untertyp, verknüpfter Datensatz oder neue Entität.
• Blueprint 004 — Wie verhindern Sie, dass Angebote und Rabatte ohne Freigabe verschickt werden? — der Freigabeprozess, den dieser Blueprint mit einem Proxy-Quote umgeht, und was die Schwellenwertsperre tatsächlich sperrt.
• Blueprint 006 — Wie richten Sie eine Dokumentnummerierung ein, die den Produktivbetrieb übersteht? — die eine Referenznummernserie, auf der die Warteschlange läuft, und was ein gelöschter Datensatz mit ihr macht.
• Blueprint 011 — Wie halten Sie Hunderte von CRM-Automatisierungen wartbar? — ein Prozess pro Anliegen, was die nach typeId gefilterte Automatisierung auch ein Jahr später lesbar hält.