TAXONOMY_3.2_DRAFT.md 5.7 KB
Zammad Taxonomie 3.2 – Entwurf
Status: DRAFT Basis: Taxonomie 3.2.1 + Ergebnisse des 4.259-Ticket-Laufs
1. Ziel
Die Taxonomie soll nicht nur das primäre Kundenanliegen erkennen, sondern zusätzlich:
- weitere gleichzeitig vorhandene Anliegen
- konkrete Sachverhalte und Problemarten
- positive bzw. abgeschlossene Zustände
- relevante Produkt-/Versand-/Zahlungsinformationen
erfassen.
Grundregel:
PRIMARY INTENT = Was ist das hauptsächliche Anliegen des Kunden?
SECONDARY INTENTS = Welche weiteren eigenständigen Anliegen liegen vor?
TAGS = Konkrete Fakten, Zustände, Ursachen, Produkteigenschaften oder Vorgangsstatus.
2. PRIMARY INTENTS
VERSANDSTATUS LIEFERVERZUG ADRESSÄNDERUNG REKLAMATION TRANSPORTSCHADEN FEHLLIEFERUNG RECHNUNG ZAHLUNG WIDERRUF RETOURE PFLANZENBERATUNG SORTENBERATUNG PFLEGEFRAGE BESTANDSANFRAGE VORBESTELLUNG B2B GROSSHANDEL SONSTIGES
Zusätzliche Primary Intents aus der Auswertung:
- nur aufnehmen, wenn sich aus realen Tickets ein eigenständiger Bedarf ergibt
- keine freien Modellkategorien wie KUNDENSERVICE, ALLGEMEIN, KUNDENANFRAGE etc.
3. SECONDARY INTENTS
Secondary Intents werden nur vergeben, wenn ein tatsächlich eigenständiges zweites Anliegen vorhanden ist.
Beispiele:
REKLAMATION + FEHLLIEFERUNG REKLAMATION + PFLANZENBERATUNG REKLAMATION + TRANSPORTSCHADEN RECHNUNG + ZAHLUNG VERSANDSTATUS + LIEFERVERZUG VERSANDSTATUS + WIDERRUF WIDERRUF + RETOURE BESTANDSANFRAGE + SORTENBERATUNG
Kein Secondary Intent nur aufgrund eines beiläufig erwähnten Begriffs.
4. NEGATIVE / PROBLEM-TAGS
Versand / Lieferung
LIEFERVERZUG LIEFERDIENST_GLS LIEFERDIENST_DHL LIEFERDIENST_PROBLEM PAKET_VERLOREN PAKET_BESCHAEDIGT SCHLECHTVERPACKT ZUSTELLPROBLEM
Bestellung
BESTELLUNG_STORNIERT BESTELLUNG_FALSCH BESTELLUNG_UNVOLLSTAENDIG
Reklamation
QUALITAETSPROBLEM FALSCHLIEFERUNG FEHLMENGE BESCHAEDIGT PFLANZE_EINGEGANGEN_BESCHAEDIGT
Pflanzen
PFLANZENKRANKHEIT MEHLTAU STERNRUSSTAU PILZKRANKHEIT SCHÄDLINGE LAUSE DUENGER_FEHLT
Zahlung / Rechnung
ZAHLUNGSPROBLEM ZAHLUNG_FEHLGESCHLAGEN RECHNUNG_FEHLT RECHNUNG_FALSCH GUTSCHRIFT_FEHLT
5. POSITIVE / ABGESCHLOSSENE TAGS
Neu ausdrücklich in 3.2:
ZAHLUNG_ERFOLGT RECHNUNG_BEZAHLT BESTELLUNG_BESTAETIGT LIEFERUNG_ERFOLGT LIEFERUNG_ZUGESTELLT RETOURE_ANGEKOMMEN GUTSCHRIFT_ERFOLGT ERSATZ_GELIEFERT PROBLEM_GELÖST ADRESSE_KORREKT STORNIERUNG_BESTAETIGT WIDERRUF_BESTAETIGT ERSTATTUNG_ERFOLGT KUNDENANTWORT_POSITIV
Diese Tags dürfen auch zusammen mit einem Problem-Intent vorkommen.
Beispiel:
PRIMARY: REKLAMATION
SECONDARY: FEHLLIEFERUNG
TAGS: FALSCHLIEFERUNG ERSATZ_GELIEFERT PROBLEM_GELÖST
6. Produkt-/Sortiments-TAGS
PRODUKTGRUPPE_ROSE PRODUKTGRUPPE_CLEMATIS PRODUKTFORM_WURZELWARE PRODUKTFORM_CONTAINER PRODUKTFORM_TOPF
Weitere Produkt-Tags nach Auswertung des Produktionslaufs ergänzen.
7. Rabatt-TAGS
RABATTANFRAGE RABATT_GEFORDERT RABATT_SELBSSTAENDIG_ABGEZOGEN
RABATT_WIEDERHOLT wird NICHT als einzelner Ticket-Tag vergeben, sondern nur als Kontext-/Historieninformation verwendet.
8. RETOURE-TAGS
TEILRETOURE VOLLRETOURE RETOURE_ANGEKUENDIGT RETOURE_UNTERWEGS RETOURE_ANGEKOMMEN ERSTATTUNG_ERFOLGT
9. TAG-REGELN
Ein Tag beschreibt einen konkreten Sachverhalt.
Nicht aus jedem erwähnten Wort einen Tag erzeugen.
Beispiel:
"Vielen Dank, die Ersatzpflanze ist angekommen und alles ist jetzt in Ordnung."
Primary: REKLAMATION
Tags: ERSATZ_GELIEFERT PROBLEM_GELÖST
10. POSITIVE ZUSTÄNDE
Positive Zustände sind eigenständige Informationen und dürfen nicht automatisch durch den ursprünglichen Problem-Intent verdrängt werden.
Beispiel:
"Die Lieferung ist angekommen, danke."
Primary: VERSANDSTATUS
Tags: LIEFERUNG_ZUGESTELLT
11. WIDERRUF
Widerrufssignale umfassen insbesondere:
- Widerruf
- widerrufen
- vom Kauf zurücktreten
- Bestellung stornieren
- Bestellung abbrechen
- Bestellung nicht mehr wünschen
- Auftrag stornieren
- Bestellung rückgängig machen
Nicht jedes "storniert" ist automatisch WIDERRUF. Der Kontext entscheidet.
12. UNBEKANNTE TAGS
Das Modell darf keine eigenen Kategorien erfinden.
Beispiele für problematische freie Tags:
KUNDENSERVICE ALLGEMEIN KUNDENANFRAGE
Diese sind keine gültigen Tags, sofern sie nicht ausdrücklich in dieser Taxonomie definiert sind.
Unbekannte Tags werden nicht stillschweigend als neue Taxonomieelemente akzeptiert.
13. UMLAUT / UNICODE
Die Taxonomie verwendet eine kanonische Schreibweise.
Beispiel:
DÜNGER_FEHLT
DUENGER_FEHLT ist nur eine mögliche Eingabe-/Normalisierungsvariante, aber kein zweiter Tag.
Die Validierung muss Unicode-normalisiert erfolgen und insbesondere Ä/Ö/Ü/ä/ö/ü/ß korrekt behandeln.
14. TAXONOMY_FIT
Erlaubte Werte:
GOOD PARTIAL POOR
Keine freien Werte.
15. CONFIDENCE
confidence ist numerisch und liegt zwischen 0 und 1.
Ungültige Modellwerte dürfen nicht als gültige Klassifikation gespeichert werden.
16. WICHTIGE REGEL
Primary Intent niemals durch eine frei erfundene Modellkategorie ersetzen.
Wenn kein passender Intent existiert:
SONSTIGES
17. OFFENE PUNKTE FÜR FINAL 3.2
Nach Abschluss des aktuellen Produktionslaufs prüfen:
[ ] reale Secondary-Intent-Quote [ ] reale Tag-Verteilung [ ] häufigste unbekannte Tags [ ] positive Zustände [ ] weitere positive Tags [ ] weitere Versand-Tags [ ] weitere Zahlungs-Tags [ ] weitere Reklamations-Tags [ ] Pflanzenkrankheiten / Schädlinge [ ] Produkt-/Form-Tags [ ] Umlaut-/Normalisierungsfälle [ ] WIDERRUF-Falschklassifikationen [ ] SONSTIGES-Quote [ ] ungültige Modell-Intents [ ] ungültige Modell-Tags
18. VERSIONIERUNG
3.2-DRAFT
↓
3.2-CANDIDATE
↓
3.2-FINAL
Die laufende Klassifikation wird NICHT rückwirkend verändert, bevor 3.2-FINAL fachlich geprüft und freigegeben wurde.