# 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.