Kundenbeschwerden organisieren

Hallo zusammen,

ich möchte die Beschwerden von Kunden in SuiteCRM organisieren, ähnlich wie es mit dem Modul „Fälle“ möglich ist.

Wichtig ist mir dabei:

  • Beschwerden sollen intern bearbeitet werden.
  • Die Verknüpfung zu Ansprechpartnern, Firmen, Projekten usw. ist notwendig, damit wir die Vorgänge im Kontext sehen.
  • Die verknüpften Personen/Firmen sollen jedoch nicht automatisch benachrichtigt oder informiert werden. Es geht wirklich um eine rein interne Bearbeitung.

Meine Frage:

:point_right: Wie lässt sich das am einfachsten umsetzen?

  • Lohnt sich dafür eine eigene Modul-Erweiterung, die ähnlich wie „Fälle“ aufgebaut ist?
  • Oder gibt es eine Möglichkeit, das bestehende Modul „Fälle“ zu nutzen und die Benachrichtigungen/Workflows für externe Kommunikation zu unterbinden?
  • Hat jemand von euch schon etwas Vergleichbares umgesetzt?

Vielen Dank vorab für eure Tipps!

Viele Grüße
Andreas

Hallo Andreas,

wie kommen die Beschwerden ins System?

Falls die Fälle (inkl. Mailbox) soweit passen, lässt sich das tatsächlich nutzen.
Ihr würdet dann einfach nicht die Antwortfunktion nutzen.
Teste das gern einfach, ob das so klappt.

Falls ihr diverse weitere Felder zu Kategorisierung / Statuswerten etc. benötigt und eigene Prozesse um das Beschwerdemanagement herum habt, macht ein eigenes Modul sicherlich Sinn.

Im Prinzip nur die internen Updates verwenden und ggf. noch die Standard Templates löschen. Klingt allerdings schon etwas unpassend und somit eher ein Hinweis auf ein eigenes Modul (wegen der abweichenden Prozesse).

Ja, in mehreren Projekten.
Teilweise mit Integration zu Kundenportal, teilweise mit Feedbackloops in andere Abteilungen und auch schon mal mit einer Art AI Sentiment Analyse / Klassifizierung gekoppelt.

Im Endeffekt ist der Prozess wichtig:
Wenn deine Anforderung nah an den Fällen ist, dann gern diese nutzen und etwas anpassen.
Wenn deine Anforderungen stärker abweichen (Eingang sind nicht Emails, es werden NIEMALS Antwort / Lösungs-Emails raus geschickt, …) dann lieber über ein eigenes Modul.

Hallo Bastian,

danke für deine schnelle Rückmeldung und die Einordnung!

Bei uns ist der Anwendungsfall tatsächlich etwas „anders“ als ein klassisches Helpdesk:

  • Beschwerden kommen fast ausschließlich telefonisch oder persönlich beim Inhaber an, nur selten per Mail.
  • Typische Szenarien sind z. B. verspätete oder fehlende Abrechnungen oder dass ein Kunde das Gefühl hat, nicht gut betreut worden zu sein.
  • Die Bearbeitung läuft rein intern. Wir dokumentieren, besprechen und leiten ggf. Maßnahmen ab.
  • Zur Deeskalation verschicken wir vereinzelt eine Mail mit der Bitte um ein Gespräch, ansonsten läuft alles persönlich oder telefonisch.

Das heißt: Externe Kommunikation aus dem System heraus soll es gar nicht geben.

Dein Hinweis hilft mir deshalb sehr:

  • Wenn wir das Modul „Fälle“ nutzen, müssten wir konsequent alle Standard-Workflows/Texte rausnehmen und es auf interne Nutzung beschränken.
  • Wahrscheinlich wäre ein eigenes Modul langfristig sauberer, da der Prozess sich doch deutlich unterscheidet (kein E-Mail-Eingang, keine Antworten, sondern eher interne Ursachenforschung und Maßnahmen).

Mich würde interessieren:

Hast du vielleicht ein Beispiel, wie man so ein Modul in SuiteCRM am besten aufsetzt? Eher über den Module Builder (ähnlich wie „Fälle“) oder ist es sinnvoll, ein bestehendes Modul zu duplizieren und anzupassen?

Viele Grüße
Andreas

Hallo Andreas,

ja, klingt nach eigenem Modul, eher als nach Fällen.

Ich würde immer (es sei denn Ihr entwickelt Software / und habt auch interne Entwicklung inkl. versioning etc.) mit dem Module Builder starten und in den allermeisten Fällen ein Basic Modul nehmen:

Von der Struktur her könnte sich eine dynamische Auswahlliste anbieten:

Die interne Kommunikation kann dann über Notizen, oder über ein weiteres eigenes Modul abgewickelt werden.
Da gibt es ein cooles Feature, wenn ihr etwas am Code anpassen wollt:

Ich habe noch etwas weiteres in einem Projekt:
Das interne Modul Beschwerdemanagement (o. Ä.) ist verknüpft zu einem Modul Sentiment. Über AI werden Sentiments aus diversen anderen Modulen erstellt und generiert.

Jetzt lässt sich genau auswerten, welche:r Mitarbeiter:in was verursacht und welche Maßnahmen, wann genau Verbesserung herbeigeführt haben:

Dashboards via Metabase:

Hallo Bastian,

vielen Dank für deine Antwort! Deine Videos sind sehr informativ und ich konnte eine Menge mitnehmen. Wir sind eine Marketing-Agentur und reine Anwender.

Mit deinen Informationen aus den Videos habe ich mir Gedanken für die Umsetzung gemacht. Ich hoffe, es ist nicht zu umfangreich. Wie würdest du meinen Ansatz einschätzen?

Eigenes SuiteCRM‑Modul „Beschwerden“ (rein intern, ohne externe Benachrichtigungen).

Name & Typ

  • Modulname: Beschwerden
  • Typ: Custom Module (Basic), mit Beziehungen (Anrufe, Aufgaben, Meetings) aktiviert
  • Tab/Navigation: sichtbar nur für interne Rollen

Kernfelder (mit API‑Namen & Typ)

  • Beschwerde-Nr. case_number (Auto-Increment, Anzeige-feld, read-only)
  • Titel/Zusammenfassung name (Text 255)
  • Eingangskanal channel_c (Dropdown: Telefon, Persönlich, E-Mail, Sonstiges)
  • Eingangsdatum received_on_c (Datum/Zeit)
  • Beschwerdeführer (frei) complainant_text_c (Varchar 255) – falls kein Kontakt verknüpft ist
  • Kontakt (optional) contact_id (Relate: Contacts)
  • Firma account_id (Relate: Accounts)
  • Projekt project_id (Relate: Projects)
  • Betroffene Leistung service_c (Dropdown, z. B. Social Media, Website, Print, Beratung, Abrechnung)
  • Kategorie category_c (Dropdown: Abrechnung, Kommunikation, Qualität, Verzögerung, Sonstiges)
  • Ursache (intern) root_cause_c (Dropdown: Fristversäumnis, fehlende Rückmeldung, falsche Rechnung, unklare Zuständigkeit, Kapazität, Prozessfehler)
  • Schweregrad severity_c (Dropdown: Niedrig, Mittel, Hoch, Kritisch)
  • Priorität (intern) priority_c (Dropdown: Niedrig, Mittel, Hoch)
  • Betrag strittig (€) disputed_amount_c (Währung)
  • Frist/Nächster Stichtag due_date_c (Datum/Zeit)
  • Verantwortlich (Owner) assigned_user_id (Standard, Benutzer)
  • Team team_id (Teams)
  • Status status_c (Dropdown – siehe Statusmodell)
  • Kurzbeschreibung (intern) description (Langtext)
  • Erwartung des Kunden (wahrgenommen) customer_expectation_c (Langtext)
  • Nächster Schritt (intern) next_step_c (Text 255)
  • Eskalationsstufe escalation_level_c (Dropdown: 0, 1, 2, Geschäftsführung)
  • Vertraulich confidential_c (Checkbox)
  • Anhänge/Dokumente via Standard-Documents-Relation
  • Audit aktivieren (für Status, Beträge, Fristen, Verantwortlich)

Statusmodell (Dropdown)

  1. Neu
  2. In Prüfung (Ursachenklärung intern)
  3. In Klärung mit Team (Maßnahmen definieren)
  4. Lösung vorbereitet (Deeskalationsgespräch/Anruf terminiert)
  5. In Nachverfolgung (wirksamkeitskontrolle intern)
  6. Geschlossen – gelöst
  7. Geschlossen – abgelehnt (z. B. unbegründet)
  8. Geschlossen – gegenstandslos

Beziehungen

  • 1:n zu Accounts , Contacts , Projects (Relate/Subpanel)
  • Aktivitäten: Calls, Meetings, Tasks (für interne Bearbeitung & Gesprächsprotokolle)
  • Documents: Belege, Rechnungen, Memos
  • Optional: Custom „Maßnahmen“‑Child‑Modul (CAPA)
    • Felder: action_name, owner, due_date, action_status (Offen, In Arbeit, Erledigt), effectiveness_check(Checkbox/Datum)

Layouts (Studio)

  • EditView/QuickCreate: kompakt (Titel, Firma/Kontakt, Projekt, Kategorie, Ursache, Schweregrad, Priorität, strittiger Betrag, Frist, Verantwortlich, Status, Nächster Schritt, Vertraulich)
  • DetailView: zusätzlich Eingangskanal/-datum, Erwartung des Kunden, Beschreibung, Eskalationsstufe
  • Subpanels (unter Beschwerde): Aktivitäten, Maßnahmen (Custom), Dokumente, Verlauf/Audit
  • ListView Filter: Status ≠ geschlossen; Kategorie; Verantwortlich; Schweregrad; „überfällig“ (Frist < heute)

Dashboards & Berichte

  • Listen: offene Beschwerden nach Status
  • Diagramme:
    • Anzahl nach Kategorie (Monat)
    • Durchschnittliche Lösungszeit (nach Schweregrad)
    • Überfällige Fälle je Verantwortlichem
    • Top‑Ursachen (Pareto 80/20)
  • Standardreports (monatlich/vierteljährlich):
    • „Offene & überfällige Beschwerden“
    • „Abrechnungsbedingte Beschwerden (strittige Summe)“
    • „Qualitäts- vs. Kommunikationsprobleme“
    • „Maßnahmen-Umsetzung & Wirksamkeit“

Prozess-Hinweise

  • Erfassung: Telefon/Personalbeschwerde sofort als Beschwerde anlegen (QuickCreate), kurzer Call mit Gesprächsnotiz anhängen
  • Deeskalation: Termin/Call aus „Beschwerde“ anlegen – ohne E‑Mail‑Automatik; wenn nötig eine einzelne manuelle Deeskalationsmail außerhalb des Moduls (oder nur über Templates ohne Auto‑Versand)
  • Lessons Learned: Nutzung des Maßnahmen‑Child‑Moduls + „Wirksamkeitskontrolle“
  • Audit: Immer aktiv, um spätere Diskussionen sauber zu dokumentieren

Umsetzung (kurz): Nächste Schritte

  1. Module Builder: Modul „Beschwerden“ anlegen, Felder erstellen, Beziehungen aktivieren (Accounts, Contacts, Projects, Documents, Activities).
  2. DeployStudio: Layouts, Subpanels, Suchfilter, Dropdown‑Werte pflegen.
  3. Security: Rollen & Teams, E‑Mail‑Aktionen entfernen/verbieten, Templates deaktivieren.
  4. Workflows: Fristen, Eskalation, Wirksamkeitskontrolle.
  5. Dashboards/Reports konfigurieren.
  6. Testdaten durchspielen (Neu → Gelöst, Eskalation, strittige Beträge).

Sehr gründlich, sehr sauber.

Im Endeffekt muss es zu eurem Prozess passen.
Auf den ersten Blick sieht alles recht schlüssig aus.

Aktuell gibt es noch ein paar Bugs in den Berichten und

scheint nicht zu funktionieren in den neuen 8er Versionen (Bugticket: Report Group by date: y-m doesn't work anymore in SuiteCRM 8.8 · Issue #644 · SuiteCRM/SuiteCRM-Core · GitHub )

Hallo @BastianHammer,

deine Hinweise haben uns sehr weitergeholfen. Wir haben die Anregungen direkt aufgegriffen und das Modul heute eingerichtet. Die Abläufe sind jetzt so abgebildet, wie wir es uns vorgestellt haben, und das Handling funktioniert reibungslos.

Beste Grüße
Andreas

1 Like