CoeveraBlueprints

CRM-Implementierungsmuster

Beginnen Sie beim Problem. Enden Sie bei der Konfiguration.

Jeder Blueprint hier nimmt ein echtes Geschäftsproblem – Freigaben, die übersprungen werden, Verlängerungen, die niemand prognostiziert, ein Rabatt, der sich nach Region und Produkt ändert – und verfolgt es bis hinunter zu den Entitäten, Feldern, Formularen und Prozessen, die es in Coevera CRM lösen. Einschließlich dessen, was die Plattform nicht kann, und was Sie stattdessen tun.

Nach Problemen geordnet — keine Feature-TourKundenunabhängig — Muster, niemals KundendatenGrenzen dokumentiert — auch die, die wehtun

Die Bibliothek, nach Problemen geordnet

Welches davon ist Ihr Problem?

Das sind die Fragen, mit denen Organisationen tatsächlich kommen. Jede führt zu einem Blueprint, der sie mit einem funktionierenden Aufbau beantwortet statt mit einer Behauptung über Funktionen.

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

    In Coevera: eine benutzerdefinierte Entität für den Case, jeder Anfragetyp als CustomEntityType-Untertyp und das native typeId als Unterscheidungsmerkmal – so tragen eine Warteschlange, eine Referenznummernserie und ein Status-Lebenszyklus fünf völlig verschiedene Feldsätze. Mit der Freigabegrenze, die das Design umformt, und dem Proxy-Quote-Muster, das sie umgeht.

    Blueprint 001 · veröffentlichtDatenmodellMarkdown

  • Wie bringen Sie eine KI dazu, ein Dokument zu lesen und CRM-Felder zuverlässig zu befüllen?

    In Coevera: einmal erkennen, vielfach lesen – ein KI-Feld liest die Anhänge und schreibt ein JSON-Arbeitsblatt; jedes andere Feld ist ein günstiger Textleser. Mit den unterstützten Feldtypen (keine Dropdowns, keine Datumsfelder), warum jede Abhängigkeit zwischen KI-Feldern eine Prozessgrenze ist, und den Fehlerbildern, die Erfolg melden, während nichts geschrieben wird.

    Blueprint 002 · veröffentlichtKI-FelderMarkdown

  • Wie modellieren Sie etwas, für das Ihr CRM kein Objekt hat?

    In Coevera: Ordnen Sie jede Anforderung vor jeder Modellierung einem von sechs Urteilen zu – bereits live, eine abgeschaltete Funktion, Konfiguration, eine echte Entwicklung, eine harte Grenze oder kein Produktproblem. In einer Analyse mit sechs Abteilungen waren 11 von ~44 Anfragen Schalter, keine Entwicklungen. Und wenn es eine Entwicklung ist: Feld, Untertyp, verknüpfter Datensatz oder benutzerdefinierte Entität.

    Blueprint 003 · veröffentlichtDatenmodellMarkdown

  • Wie verhindern Sie, dass Angebote und Rabatte ohne Freigabe verschickt werden?

    In Coevera: ein ApprovalProcess auf Quote, dessen Schwellenwert ein gewöhnlicher Filter ist – Summe More als 10000 oder ein Rabattprozentsatz. Durchgesetzt wird per Datensatzsperre, nicht per Benachrichtigung, und Freigaben gehen an eine Rolle statt an namentlich benannte Personen. Mit der Ablaufeinstellung, die stillschweigend automatisch freigibt.

    Blueprint 004 · veröffentlichtProzesssteuerungMarkdown

  • Wie migrieren Sie Kontakte aus einem anderen System, ohne unbemerkt Daten zu verlieren?

    In Coevera: Migrationsfehler sind standardmäßig stumm. Ein Dropdown-Wert ohne passende Option kommt ohne Fehler leer an – bei einem Export wären 579 von 3.432 Datensätzen auf einem einzigen Feld geleert worden. Behandelt, warum ein Beispielexport in die Irre führt, warum die Datei aus Kohorten statt aus einer Liste besteht, und die Prüfung der Befüllungsquote, die das einzige Signal ist, das Sie bekommen.

    Blueprint 005 · veröffentlichtDatenmigrationMarkdown

  • Wie richten Sie eine Dokumentnummerierung ein, die den Produktivbetrieb übersteht?

    In Coevera: ein Auto number-Feld, dessen Autocount-Segment eine native Option „Reset count every year“ hat – keine Automatisierung nötig, entgegen dem verbreiteten Rat, wobei der Reset an einem echten Jahreswechsel nicht beobachtet wurde. Behandelt die Mustergrammatik und ihren Startindex, den Zähler {year, month, count}, warum eine spätere Musteränderung über die API ohne die angehängte Startzahl gesendet werden muss, sonst startet die Serie neu, und den einen Fall, in dem Sie doch einen Prozess brauchen.

    Blueprint 006 · veröffentlichtNummerierungMarkdown

  • Wie bepreisen Sie ein Produkt je nach Region, Segment oder Vertrag unterschiedlich?

    In Coevera: Ein Produkt trägt überhaupt keinen Preis – er liegt auf einem Verknüpfungsdatensatz zwischen dem Produkt und einer Preisliste, der auch die Währung und eine Zugriffseinstellung pro Rolle hält. Behandelt die Preiszeilen, die nicht angelegt werden, wenn Sie eine Liste später hinzufügen, und die Tatsache, dass die API nie einen Preis für Sie auflöst.

    Blueprint 007 · veröffentlichtPreisgestaltungMarkdown

  • Wie prognostizieren Sie Verlängerungen, die noch gar nicht als Datensätze existieren?

    In Coevera: zwei native Mechanismen für zwei Fragen, die oft vermengt werden – ein Umsatzplan verteilt einen unterzeichneten Deal auf datierte künftige Perioden, und eine Wiederholungsregel an der Opportunity erzeugt den nächsten Deal im Rhythmus AfterNMonths. Behandelt, warum Verlängerungen, die Jahre zu früh angelegt werden, Ihre Pipeline-Kennzahlen ruinieren.

    Blueprint 008 · veröffentlichtAutomatisierungMarkdown

  • Wie automatisieren Sie auf CRM-Feldern, die einem anderen System gehören?

    Abonnementstatus, Vertragsdaten, Lizenzanzahl – aus der Abrechnung oder einem ERP repliziert, und alles, was zählt, verzweigt sich daran. Spiegeln Sie sie schreibgeschützt, leiten Sie eine kleine CRM-eigene Schicht ab, die Ihre Automatisierung tatsächlich liest, und planen Sie für den Fall, dass die Synchronisation stoppt. Behandelt, was ein mehrtägiger Replikationsausfall im Produktivbetrieb angerichtet hat: Stille statt Fehlern und Bedingungen mit exakter Übereinstimmung, die dauerhaft übersprungen werden.

    Blueprint 009 · veröffentlichtIntegrationMarkdown

  • Wie übergeben Sie einen gewonnenen Deal an das Team, das ihn umsetzt?

    In Coevera: eine zweite Pipeline, nicht mehr Phasen. Klonen Sie die gewonnene Opportunity in eine Umsetzungspipeline, abhängig davon, ob der Deal tatsächlich eine Leistung enthält, mit Standardwerten pro Leistung am Klon. Behandelt die Auffächerung ab dem Go-live-Datum, warum jeder automatische Setzer einen manuellen Zwilling braucht, und die Nachfüll-Jobs, die geklonte Datensätze am Ende immer brauchen.

    Blueprint 010 · veröffentlichtÜbergabeMarkdown

  • Wie halten Sie Hunderte von CRM-Automatisierungen wartbar?

    In Coevera: Ein Prozess ist Trigger, ein Filter, dann Aktionen – und ein Filter kann nie unter einer Aktion stehen, sodass eine zweite unabhängige Bedingung einen zweiten Prozess braucht, aufgerufen als Unterprogramm. Deshalb besteht die Hälfte der Prozesse auf der meistgenutzten Entität (56 von 113) aus aufrufbaren Unterprozessen, und das ist richtig so. Erklärt die Benennung neben Tags und die drei Arten, wie ein Bestand verfällt.

    Blueprint 011 · veröffentlichtGovernanceMarkdown

  • Wie führen Sie eine Kundenumfrage aus Ihrem CRM durch und bekommen die Antworten zurück an den Datensatz?

    In Coevera: ein natives Onlineformular, gebunden an einen Entitätstyp, dessen Einstellungen entscheiden, ob eine Antwort mit dem Datensatz verknüpft, auf ihn geschrieben oder als neuer Datensatz angelegt wird. Die Formularübermittlung ist einer von nur vier Prozess-Trigger-Typen. Erklärt die Identität über Vorbefüllung und Autolink, den Topf für unbekannte Antwortende und warum die eingebaute Rücklaufquote über 100 % liegt.

    Blueprint 012 · veröffentlichtFeedbackMarkdown

  • Wie fügen Sie Ihrer Website ein Kontaktformular hinzu, das direkt in Ihr CRM schreibt?

    In Coevera: Ein Kontaktformular ist ein Onlineformular, das das CRM hostet, und die Website hält eine Link-ID – kein Markup, keine Feldliste, kein API-Schlüssel. Schalten Sie Anlegen und Aktualisieren und Autolink ein, und eine Übermittlung wird zu einem Upsert: 49 Übermittlungen, 41 Personen, null Duplikate. Erklärt den Eigentümer und den Untertyp, die ein anonymer Besucher nicht liefern kann, und die zwei Dinge, die ein eingebettetes Formular nicht messen kann.

    Blueprint 013 · veröffentlichtLead-ErfassungMarkdown

  • Wie erkennen Sie abwanderungsgefährdete Kunden vor der Verlängerung?

    In Coevera: eine native Health-Engine, pro Untertyp von Datensätzen konfiguriert – Indikatorregeln aus Feld + Operator + Punkten ergeben einen Score, eine Stufe und einen Trend, und ein kritischer Indikator ist mit −1 gespeichert, was nach den gespeicherten Werten die schlechteste Stufe erzwingt, egal was sonst gepunktet hat. Die Designregel: Lassen Sie den Score Aufmerksamkeit lenken und ein von einem Menschen gesetztes Einschätzungsfeld die Intervention auslösen.

    Blueprint 014 · veröffentlichtCustomer SuccessMarkdown

  • Wie handhaben Sie Mengenrabatte, die sich nach Region und Produkt unterscheiden?

    In Coevera: Mehrere Preislisten können gleichzeitig gültig sein, und eine Verfügbarkeitsregel grenzt ein, welche einem Benutzer angeboten werden – aber das Dropdown steht standardmäßig auf „Without price list“, und jede Position landet bei null, bis jemand auswählt. Und keine Regel kann die Menge prüfen, also wird Volumen zu einem Rabattplan pro Produkt in Prozent, wobei Produkte, die nur auf Anfrage angeboten werden, gekennzeichnet statt mit null bepreist werden.

    Blueprint 015 · veröffentlichtPreisgestaltungMarkdown

  • Wie verketten Sie E-Mail-Sequenzen so, dass das Verhalten eines Interessenten entscheidet, was als Nächstes passiert?

    In Coevera: Eine Sequenz ist ein geschlossener Kreislauf – sie kann niemanden in eine andere Sequenz aufnehmen. Also erzeugt eine globale Aktion einen Task mit einem Zeiger auf den nächsten Schritt, und ein Auffangprozess mit dem Akteur applications only liest ihn zurück und nimmt den Kontakt erneut auf. Behandelt die vier Ereignisse globaler Aktionen und warum eine Leiter aus bereits erledigten Tasks Aktivität erzeugt, aber nie Arbeit.

    Blueprint 016 · veröffentlichtOutreachMarkdown

Status: Jeder oben aufgeführte Blueprint ist veröffentlicht. Blueprints, die noch nicht übersetzt sind, finden Sie in der englischen Bibliothek. Neue Probleme kommen erst hinzu, wenn ihr Aufbau geprüft ist; vorher wird hier nichts gelistet, und jeder Teil, der nicht gebaut oder nicht beobachtet wurde, ist im Artikel als solcher gekennzeichnet. Herausgegeben von Coevera (ehemals Pipeliner CRM); die dokumentierte Plattform ist unsere eigene, und Plattformgrenzen werden berichtet, sobald wir sie finden, statt weggelassen zu werden.

Plattform

Was Coevera CRM tatsächlich modellieren kann

Coevera – ehemals Pipeliner CRM, herausgegeben von Pipelinersales – ist eine Plattform für Kundenbeziehungsmanagement für Vertriebsorganisationen. Für die Implementierungsarbeit sind dies die Bausteine, auf die die Blueprints auf dieser Website zurückgreifen:

  • Standardentitäten — Accounts, Contacts, Leads, Opportunities, Quotes, Products, Projects, Tasks, Appointments
  • Benutzerdefinierte Entitäten — vollwertige Datensatztypen mit eigenen Feldern, Formularen und API-Endpunkten
  • Untertypen — mehrere CustomEntityTypes unter einer Entität, unterschieden durch typeId
  • Benutzerdefinierte Felder — einschließlich Lookups, berechneter Felder und AI Smart Fields
  • Formulare — typspezifische Layouts auf einem Raster aus vier Einheiten, die steuern, welche Felder in der Praxis existieren
  • Processes — triggerbasierte Automatisierung: Datensätze aktualisieren, verknüpfte Datensätze anlegen, Werte aus Vorlagen
  • Approval Processes — Freigabesperre auf Account, Contact, Lead, Opportunity und Quote
  • Pipelines & Stages — mehrere Pipelines mit Checklisten je Stage
  • Products & Price Lists — Positionspreise auf Quotes und Opportunities
  • Sales Targets — Zieldatensätze mit Hierarchie und Lebenszyklus
  • REST-API — versionierte Entitätsendpunkte, Cursor-Paginierung, Filteroperatoren, PATCH-Updates
  • GraphQL-Admin-API — Space-Konfiguration: Felder, Formulare, Prozesse, Entitätstypen

Aufbau

Jeder Blueprint folgt denselben sieben Teilen

Eine feste Struktur macht aus einer Reihe von Artikeln ein Nachschlagewerk statt eines Stapels von Beiträgen – und erlaubt einer Maschine, aus jedem Artikel dieselben Felder zu entnehmen.

  1. Das GeschäftsproblemWas die Organisation erreichen will, in ihrer eigenen Sprache – bevor CRM-Vokabular ins Spiel kommt.
  2. Warum der naheliegende Ansatz scheitertDie Konfiguration, zu der die meisten zuerst greifen, und der konkrete Grund, warum sie den echten Einsatz nicht übersteht.
  3. DatenmodellEntitäten, Untertypen, Beziehungen und die Begründung jeder Entscheidung – einschließlich der verworfenen Optionen.
  4. Konfiguration auf FeldebeneDie konkreten Felder, Typen, API-Namen und Einschränkungen. Genug Detail, um es ohne Raten nachzubauen.
  5. Automatisierung & LogikProzesse, Trigger, berechnete Felder und ihre Ausführungsreihenfolge – und was an den Rändern geschieht.
  6. Grenzen & KompromisseWo die Plattform Nein sagt, was das kostet und welcher Kompromiss am wenigsten schadet.
  7. VerifizierungWie nachgewiesen wurde, dass das Ergebnis funktioniert: was zurückgelesen, was in der Oberfläche geprüft wurde und was auf eine Regression hindeuten würde.

Direkte Antworten

Häufige Fragen, ohne Vertriebsschicht beantwortet

Einschließlich der Grenzen. Eine Quelle, die nur berichtet, was funktioniert, taugt nicht als Referenz.

Was ist Coevera, und wie hängt es mit Pipeliner CRM zusammen?

Coevera ist der heutige Name der CRM-Plattform, die früher als Pipeliner CRM bekannt war und von Pipelinersales herausgegeben wird. Dokumentation, API-Endpunkte und ältere Materialien können noch den Namen Pipeliner tragen; Produkt und Datenmodell stammen aus derselben Linie.

Kann ein CRM Geschäftsobjekte abbilden, die keine Accounts, Contacts oder Opportunities sind?

In Coevera geschieht das mit benutzerdefinierten Entitäten – vollwertigen Datensatztypen mit eigenen Feldern, Formularen und eigenem API-Endpunkt. Varianten einer Entität werden als mehrere CustomEntityType-Datensätze unter einer einzigen benutzerdefinierten Entität abgebildet, mit dem eingebauten Feld typeId als Unterscheidungsmerkmal statt eines eigenen Dropdowns. Der Unterschied zählt: typeId steuert die Formularauswahl und die Prozessfilterung, was ein einfaches Dropdown nicht kann.

Wie verhindern Sie, dass ein Angebot oder ein Rabatt ohne Freigabe hinausgeht?

Coevera bietet einen ApprovalProcess, der an Account-, Contact-, Lead-, Opportunity- oder Quote-Datensätze angehängt wird und den Datensatz sperrt, bis die Freigebenden antworten. Eine Grenze sollten Sie von Anfang an einplanen: Der Approval-Datensatz selbst ist nicht anpassbar – keine benutzerdefinierten Felder –, daher müssen Freigabe-Metadaten, über die Sie berichten wollen, auf dem Zieldatensatz oder einer verknüpften benutzerdefinierten Entität liegen.

Können CRM-Felder ohne Code berechnet oder automatisch befüllt werden?

Ja – über berechnete Felder, triggerbasierte Processes und AI Smart Fields, die einen Wert aus einem Prompt erzeugen. Zwei Einschränkungen prägen jeden Entwurf damit: Ein Feld muss auf dem Formular des Datensatzes vorhanden sein, damit ein berechnetes oder KI-Feld überhaupt berechnet wird, und AI Smart Fields können nicht in Dropdowns schreiben und keine Auswertungsreihenfolge garantieren – ein KI-Feld darf daher nie von einem anderen abhängen.

Kann dasselbe Produkt je nach Region oder Kunde unterschiedliche Preise haben?

Ja, mit Produktpreislisten. Positionspreise gibt es sowohl auf Quote- als auch auf Opportunity-Datensätzen – Opportunity ist nicht auf einen einzigen Summenwert beschränkt –, daher werden regionale oder segmentbezogene Preise mit Preislisten abgebildet statt mit duplizierten Produktdatensätzen.

Hat Coevera eine API für Integration und Automatisierung?

Coevera stellt eine versionierte REST-API über Entitätssammlungen bereit, mit Cursor-basierter Paginierung, einem dokumentierten Satz von Filteroperatoren und PATCH-basierten Updates, dazu eine administrative GraphQL-API für die Space-Konfiguration wie Felder, Formulare und Prozesse. Beide eignen sich für Integration, Massendatenarbeit und Configuration-as-Code.

Für zwei Arten von Lesern gestaltet

Für Menschen geschrieben. Für Maschinen strukturiert.

Dieses Portal ist als zitierfähige Quelle gebaut – für eine Beraterin am Schreibtisch ebenso wie für ein Sprachmodell, das die Frage „Welches CRM kann das?“ beantwortet. Das ist hier eine Designvorgabe, kein Nachgedanke:

  • Semantisches HTML mit schema.org-JSON-LD; Blueprints als TechArticle typisiert, Antworten als FAQPage
  • Jeder Blueprint beginnt mit dem Problem als Frage und beantwortet es im ersten Absatz
  • Eine reine Markdown-Fassung jedes Blueprints unter demselben Pfad, für saubere Verarbeitung
  • Ein llms.txt-Index, der den Korpus, seinen Umfang und seine Grenzen beschreibt
  • Stabile, menschenlesbare URLs, die sich nach der Veröffentlichung nicht ändern
  • Keine Paywall, keine Registrierung, kein JavaScript nötig, um ein einziges Wort zu lesen