Vorgangsmanagement
Grundlagen
Mit dem CURSOR-Vorgangsmanagement-Modul können zahlreiche Prozesse abgebildet werden. Beste Beispiele sind Klärung von kaufmännischen oder technischen Fragen, Beseitigung von Störungen oder Bearbeitung von Beschwerden. Zahlreiche Funktionen zur Delegation, Eskalation und Dokumentation erlauben die zeitnahe Bearbeitung von Serviceanfragen, Anliegen und ermöglichen die einfache Kommunikation mit allen Beteiligten. Die Kommunikation wird über Vorgänge abgebildet, die je nach Prozessablauf beliebig benannt werden können (z.B. "Beschwerde" oder "Anfrage"). Ein Vorgang kann optional mehrere Anliegen umfassen.
Anwendungsfall: Ticketbearbeitung
Bearbeitung (Anlage, Änderung, Delegation, Eskalation) von Serviceanfragen
Integration von Mail- und Portalsystemen
Anwendungsfall: Beschwerdebearbeitung
Bearbeitung (Anlage, Änderung, Delegation, Eskalation) von Beschwerdevorgängen
Zuordnung und Verfolgung untergeordneter Beschwerdeanliegen
Umfangreiche Auswertungsmöglichkeiten zur Ursachenanalyse
Vorgänge können vom unterschiedlichen Typ sein. Diese unterscheiden sich durch den hinterlegten Prozess.
Anliegen bilden die Möglichkeit, mehrere Anliegen in einem Vorgang separat zu bearbeiten.
Aktivitäten dienen dazu, den Kommunikationsablauf genau festzuhalten und somit auf ein gezieltes Ergebnis hinzuarbeiten.
Technische Voraussetzungen
Die folgenden Absätze beschreiben die Hinweise und Änderungen für Systeme, die vor der Version 23.1 das Kundenservice-Modul im Einsatz hatten.
Änderungen im Standard
Neuer Nummernkreis bei Vorgängen und Anliegen
Auf dem Vorgang: Vorgangs-Nr. (TicketNo.Ticket)
Feldeigenschaft "Doppelte Feldwerte verhindern" wurde im Standard aktiviert
Änderung von Memofeldern
Auf dem Vorgang: Beschreibung (Description.Ticket)
Hier ist eine Umwandlung von EditorPane auf HTML erfolgt
In dem Zuge wurde auch das Feld Description2.Ticket umgestellt
Conclusion.Ticket wurde ebenfalls in HTML umwandelt
Auf dem Anliegen: Beschreibung (Description.TicketRequest)
Hier istl eine Umwandlung von EditorPane auf HTML erfolgt
In dem Zuge wurde auch das Feld Description2.TicketRequest umgestellt
Conclusion.TicketRequest wurde ebenfalls in HTML umwandelt
Die Felder Desription2.Ticket und Desription2.TicketRequest wurden von den Masken entfernt
Benachrichtigungen
Es wird eine Benachrichtigung an den User "Delegiert an" (Delegiert an Gruppe) versendet.
Dies erfolgt bei Überschreitung des Datum Erinnerungsdatum (auf dem Vorgang und Anliegen)
Dies erfolgt bei Überschreitung des Datum Fälligkeitsdatum (auf dem Vorgang und Anliegen)
Wenn beide eingetreten wird nur eine Benachrichtigung (Fälligkeitsdatum) versendet.
Die Benachrichtigung wird nur aktualisiert (Nur eine Benachrichtigung für Erinnerung und Fälligkeitsdatum - auch wenn diese gleich sind)
Neuer Timer zum Versand von Benachrichtigungen nach überschrittenem Datum
Es wurde ein neuer Timer "Eskalationsdatum prüfen" im Standard erstellt, welcher jede Minute prüft, ob ein Vorgang oder Anliegen Datum (Fälligkeits- und Erinnerungsdatum) überschritten wurde und versendet anschließend eine Benachrichtigung im Benachrichtigungssystem.
Aufnahme von neuen Datumsfeldern auf dem Vorgang und auf dem Anliegen
Bei der Neuanlage eines Vorgang werden die Werte vom Erinnerungs- und Fälligkeitsdatum wie folgt vorbelegt:
Fälligkeitsdatum (standardmäßig +14 Tage vorbelegt)
Erinnerungsdatum (standardmäßig +7 Tage vorbelegt)
Wurden die hinterlegten Daten überschritten erhält die Person, welche in dem Feld "Delegiert an" hinterlegt wurde eine Benachrichtigung
Bei der Neuanlage eines Anliegens werden die Werte vom Erinnerungs- und Fälligkeitsdatum des übergeordneten Vorgang übernommen
Zusätzlich dazu gilt:
Das Fälligkeitsdatum des Anliegens darf nicht hinter dem Fälligkeitsdatum des übergeordneten Vorgang liegen
Prüfung: Eine Speicherung des Datensatzes darf nicht erfolgen, wenn dies nicht gewährleistet ist
Wenn durch eine manuelle Änderung durch Speichern das Fälligkeitsdatum des Vorgang vor dem Fälligkeitsdatum des Anliegen liegt, so wird automatisch das Fälligkeitsdatum des Anliegen mit dem Fälligkeitsdatum des Vorgang gleichgesetzt
Wenn durch eine manuelle Änderung das Fälligkeitsdatum des Anliegen hinter dem Fälligkeitsdatum des Vorgang liegt, so soll die manuelle Änderung und die Abspeicherung verhindert werden. Stattdessen wird der letzte gültige Wert für das Fälligkeitsdatum es Anliegens verwendet → Zurücksetzen auf letzten Wert
Neues Feld Ansprechpartner auf dem Anliegen
Es gibt ein neues Feld Ansprechpartner auf dem Anliegen, welches bei der Neuanlage mit dem Ansprechpartner aus dem übergeordneten Vorgang vorbelegt wird.
Änderungen an der Skriptbibliothek SC0TicketUtils
Folgende Anpassungen sind in der Skriptbibliothek SC0TicketUtils erfolgt:
Methode | Status | Änderungen |
---|---|---|
createTicketFromActivity() | Geändert | Feld CoPeKey.Ticket wird nur gefüllt, wenn Feld DefaultContactPerson.Activity nicht leer ist |
generateTicketNoFromActivity() | Geändert | Änderung des RegEx, sodass das neue Vorgangsnummerformat beim Mailimport erkannt wird |
getRemindDateDuration() | Neu | Setzt den Abstand zwischen dem Fälligkeitsdatum und dem Erinnerungsdatum in Tagen |
handleRequestBbetterTabs() | Neu | Steuert die Sichtbarkeit der Bbetter und Ticket spezifichen Elemente auf der Anliegen-Maske |
handleTicketBbetterTabs() | Neu | Steuert die Sichtbarkeit der Bbetter und Ticket spezifichen Elemente auf der Vorgangs-Maske |
isWeekend() | Neu | Überprüft, ob das übergebene Datum an einem Wochenende liegt |
reqEntryInserted() | Geändert | Daten aus dem Vorgang übertragen und Aufruf von handleRequestBbetterTabs() hinzugefügt |
reqEntryLoaded() | Geändert | Aufruf von handleRequestBbetterTabs hinzugefügt |
reqFieldValueChanged() | Geändert | Hinzufügen der Fäligkeitsdatums- und Erinnerungsdatums-Logik |
ticketEntryInserted() | Neu | Aufruf von handleTicketBbetterTabs() hinzugefügt. Aufruf der initialen Fäligkeitsdatums- und Erinnerungsdatums-Logik |
ticketEntryLoaded() | Geändert | Aufruf von handleTicketBbetterTabs() hinzugefügt |
ticketFieldValueChanged() | Geändert | Aufruf von handleTicketBbetterTabsHinzugefügt. Aufruf der Fäligkeitsdatums- und Erinnerungsdatums-Logik |
Optional: Klassifikationen für einzelne Abteilungen individualisieren.
Es besteht die Möglichkeit abhängig vom Tickettyp unterschiedliche Schlüssel in der Klassifikation und Unterklassifikation zu hinterlegen. Dies kann somit in drei Stufen konfiguriert werden: Tickettyp - Klassifikation - Unterklassifikation. Sollen in diesen Schlüsselbereichen allgemeine Schlüssel (für alle Personen) hinterlegt werden, muss diese Konfiguration nicht durchgeführt werden, nur wenn beispielsweise abteilungsindividuelle Schlüssel hinterlegt werden sollen, welche andere Abteilungen nicht sehen oder auswählen sollen.
Feldeigenschaft in dem Feld Unterklassifikation (Classification2.Ticket):
Nachschlagesuche:
LookupEntityS_KeytabKeyMappings
Vorselektion beim Validieren:
MasterKey.KeyMappings.EQUAL={Classification.Ticket}
MasterKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION
SlaveKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION2
Active.KeyMappings.EQUAL=1
Feldeigenschaft in dem Feld Klassifikation (Classification.Ticket):
Nachschlagesuche:
LookupEntityS_KeytabKeyMappings
Vorselektion beim Validieren:
MasterKey.KeyMappings.EQUAL={TicketType.Ticket}
MasterKeyRange.KeyMappings.EQUAL=C0TICKET_TYPE
SlaveKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION
Active.KeyMappings.EQUAL=1
Migration für Bestandskunden
Bei Kunden, welche das Kundenservice-Modul lizenziert und über Customizing verändert haben, muss innerhalb des Projekts geprüft werden, welche Auswirkungen die Anpassungen im Standard haben. Hier muss eine projektindividuelle Lösung gefunden werden.
Änderung der Sprachvariablen
Die Sprachvariablen wurden von der modulspezifischen Internationalisierung in die Skriptbibliothek (Skript-Klasse SC0TICKETUTILS) Sprachvariablen verschoben. Hierdurch hat sich auf der Skript Aufruf String I18nUtils.i18nModule(String moduleID, String key, Locale language, Object... parameter)
in den Skript Aufruf String I18nUtils.i18nCustom(String key, Locale language, Object... parameter)
im Standard geändert. Dies muss bei allen übersteuerten Prozessen im Bereich des Vorgangsmanagement nachgezogen werden.
Folgende Prozesse haben in C0 ihr I18n vom Modul in die Sprachvariablen verschoben. Dies ist in höheren Schichten nachzuholen, sofern einer davon übersteuert wurde:
C0TicketAddActivity
C0TicketCompletion
C0TicketCompletionSub
C0TicketCreation
C0TicketMailSending
C0TicketReopen
C0TicketRequestCompletion
C0TicketRequestCreation
Folgende Prozesse haben in C0 kein i18n enthalten, müssten aber im Falle einer Übersteuerung trotzdem geprüft werden ob dort etwas eingebaut wurde.
C0TicketCreateActivityFromNotesField
C0TicketLinkActivity
C0TicketRequestCreateActivityFromNotesField
C0TicketDelegateToGroup
C0TicketLinkComment
C0IB_CreateRequestTicket
Ersetzt werden muss jeder Aufruf wie
I18nUtils.i18nModule("TICKET", "<key>", SessionConstants.LOCALE);
durch
I18nUtils.i18nCustom("<key>", SessionConstants.LOCALE);
b.better
b.better ist nun ein eigenes Modul. Bei dem Update auf die Version 23.1. wird geprüft, ob es b.better spezifische Datensätze gibt. Dies erfolgt wie folgt:
Sind in den Entitäten Ticket-Begründung (TicketReason) und Ticket-Klassifizierung (TicketClassify) Datensätze vorhanden, dann wird das Beschwerdemanagement Modul (b.better) NICHT entfernt
Das löschende Update wird NICHT ausgeführt, wenn in Ticket-Klassifizierung / Begründung Datensätze vorhanden sind
Sind in den Entitäten Ticket-Begründung (TicketReason) und Ticket-Klassifizierung (TicketClassify) KEINE Datensätze vorhanden, dann wird das Beschwerdemanagement Modul (b.better) entfernt
Das löschende Update wird ausgeführt, wenn in Ticket-Klassifizierung / Begründung KEINE Datensätze vorhanden sind
Wichtig: Die Standardmasken TicketBbetter und TicketRequestBbetter wurden gelöscht. Sollen diese nach dem Update auf die Version 23.1. noch verwendet werden, müssen diese VOR dem Update übersteuert werden.
Umbenennung Kundenservicemodul in Beschwerdemanagement
Entitäten Ticket und Ticket-Anliegen wurden in Vorgang und Anliegen umbenannt und aus dem Modul heraus gelöst
Standard Vorgangsmanagement-Logiken wurden ebenfalls aus den Modul heraus gelöst und funktionieren nun ohne eingespieltes Modul
Einzelne Felder und Infoboards von Vorgang und Anliegen, welche speziell für das Beschwerdemanagement b.better verwendet werden, bleiben im Modul bestehen
Ein neuer Schlüssel BB - bbetter steuert die neue Maskenlogik und blendet nach der Auswahl die b.better spezifischen Karten (und somit Felder) ein
Es ist somit ggf. eine Umstellung des Maskenskript oder der Maske notwendig
Die Masken TicketBbetter und TicketRequestBbetter wurden gelöscht
Hat ein Kunde eine der Masken ausgewählt, aber nicht übersteuert, wird er automatisch auf die neue Maske umgestellt. Dort werden die b.better Felder (bzw. Karten) über die neue Logik ein und ausgeblendet
Hat ein Kunde die Masken übersteuert und angepasst, so werden nur die C0 Masken gelöscht. Die C2 Varianten bleiben bestehen, sodass für den Kunden kein Unterschied entsteht
Achtung
Wenn der Kunde vor dem Update das Anpassen der Masken auf das neue Design NICHT wünscht, so müssen die alten Masken in der Kundenschicht (C2-Schicht) übersteuert werden.
Beschreibung des Vorgangs-Prozesses
Prozessstart
Der Kundenservice-Prozess kann über verschiedene Bereiche gestartet werden:
Geschäftspartner (mittels Aktionsbox)
Ansprechpartner (mittels Aktionsbox)
Aktivitäten (mittels Aktionsbox)
Vorgänge (direkte Neuanlage)
Alternativ können die Vorgänge, Anliegen und andere verknüpfte Daten über vorkonfigurierte Standard- oder Vertiebs-Boards (mit der Kachel "Scores") eingesehen werden. Hierzu sollen die Boards auf dem Cockpit platziert werden.
![](../../../__attachments/14629484/image2022-7-7_23-47-38.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Kachel “Scores” mit Daten des Vorgangsmanagements
Einstieg über Geschäftspartner oder Ansprechpartner
Über Geschäftspartner oder Ansprechpartner kann der Kundenservice-Prozess mittels Aktionsbox (Vorgangsmanagement → Ticket anlegen) gestartet werden. Nach der Neuanlage des Tickets wird der Geschäftspartner und/ oder Ansprechpartner mit vorbelegt und somit eine direkte Verknüpfung hergestellt.
![](../../../__attachments/14629484/image2022-7-10_19-56-7.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Neuanlage über die Aktionsbox im Geschäftspartner
Neuanlage von Vorgängen und Felder-Vorbelegung
Die Neuanlage wird über Einstiegspunkte gestartet. Die Darstellung des Vorgang-Status und das Aktivitäten-Protokoll sind über Infokacheln abgebildet.
![](../../../__attachments/14629484/image2022-7-7_23-54-19.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Direkte Neuanlage eines Vorgangs
Pflichtfelder:
Betreff
Typ
Allgemein
bbetter (nur bei b.better Kunden auswählbar, dieser Schlüssel steuert die Sichtbarkeit der b.better Felder)
Ticket
Ansprechpartner
Geschäftspartner (wird nach der Auswahl des Ansprechpartner automatisch vorbefüllt)
Weitere Felder:
Status, Priorität und Beschreibung sind selbsterklärend
Initiator = Anlageuser
Delegiert an - der Vorgang kann an eine bestimmte Person delegiert werden
Delegiert an Gruppe - der Vorgang kann an eine Gruppe (z.B. Abteilung) delegiert werden.
Fälligkeitsdatum (standardmäßig +14 Tage vorbefüllt)
Erinnerungsdatum (standardmäßig +7 Tage vorbefüllt)
Beide Werte können angepasst werden. Die Logiken sorgen dafür, dass das Erinnerungsdatum nicht nach dem Fälligkeitsdatum gesetzt wird. Zu den definierten Terminen wird dann immer die Person per Benachrichtigung informiert, die im Feld "Delegiert an" hinterlegt wurde.Felder Eingang und Eingangsart sind selbsterklärend
Klassifikation und Unterklassifikation
Zweisstufige Abhängigkeit, die eine Schlüsselauswahl in der Unterklassifikation erlaubt.
Die erste Abhängigkeit wird vom Vorgangs-Typ vorbestimmt, welche Schlüssel in der Klassifikation wählbar sind. In der zweiten Stufe hängen die Schlüssel der Unterklassifikation von den Schlüsseln der Klassifikation ab.
Beim Speichern wird vom System die Vorgangsnummer generiert. Diese setzt sich aus dem Typ und einer hochgezählten siebenstelligen Zahl zusammen. Zusätzlich werden in der Aktionsbox dazugehörige Aktionen angeboten.
Nicht aktive Aktionen werden ausgegraut.
![](../../../__attachments/14629484/image2022-7-8_0-27-52.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Neu angelegter Vorgang
Delegation von Vorgängen (Weiterleitung)
Es gibt die Möglichkeit, Vorgänge über einen Hinweistext auf der Bearbeitungskachel an einen anderen Mitarbeiter zu delegieren. Das geschieht wie folgt:
Delegiert an = <Kürzel des betreffenden Kollegen>
Neuen Kommentar erstellen
Beim Speichern schlägt das Ticket in der ToDo-Liste des delegierten Kollegen auf:
Schnellstartleiste unter "Offene Aktionen“
Der Ablauf wird im Aktivitäten-Protokoll festgehalten.
Gruppendelegation
Hier ist eine Logik derart hinterlegt, dass entweder das Feld Delegiert an oder Delegiert an Gruppe gefüllt sein kann. Beide Felder können nicht gleichzeitig gefüllt sein, so dass beim Befüllen eines Feldes das andere geleert wird.
An eine Gruppe delegiertes Ticket reagiert auf Prozesse
Wenn ein Ticket an eine Gruppe delegiert wurde und man einen Prozess startet, erwartet man, dass das Ticket an denjenigen delegiert, der den Prozess gestartet hat. Die Gruppendelegation wird somit entfernt und das Ticket ist an einen Mitarbeiter delegiert.
Typen von Vorgängen
Ein Vorgang kann drei verschiedene Typen haben:
Allgemein
bbetter (nur bei b.better Kunden auswählbar, dieser Schlüssel steuert die Sichtbarkeit der b.better Felder)
Ticket
Durch den Vorgangs-Typ können Masken für Vorgänge unterschiedlich konfiguriert werden. Sowohl Felder als auch ganze Kacheln können z.B. je nach Abteilung unterschiedlich belegt werden.
Des Weiteren können auch untergeordnete Anliegen unterschiedlich aussehen, dies wird ebenfalls über den Schlüssel Typ auf dem Vorgang gesteuert.
Nach dem initialen Speichern wird der Vorgangs-Typ schreibgeschützt und kann nicht mehr verändert werden.
![](../../../__attachments/14629484/image2022-7-8_1-33-34.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Vorgang vom Typ “Allgemein”
![](../../../__attachments/14629484/image2022-7-8_1-36-21.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Vorgang vom Typ “bbetter”
Einstieg über Aktivitäten
Über Aktivitäten kann der Vorgangs-Prozess ebenfalls mittels Aktionsbox (Vorgangsmanagement → Ticket oder Vorgang anlegen ) gestartet werden, hier wird der Vorgang entweder mit dem Schlüssel TICKET oder ALLGEMEIN vorbelegt. Nach der Neuanlage des Tickets können diverse Felder wie folgt mit vorbelegt werden:
Feld auf der Aktivität | Feld auf dem Vorgang |
---|---|
DefaultContactPerson | ContactPerson, Customer |
Subject | Subject |
Text (Memofeld) | Description |
DelegatedTo | DelegatedTo |
Aktuell angemeldeter Anwender | DelegatedFrom |
![](../../../__attachments/14629484/image2022-7-10_22-2-22.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Aktivitätenmaske
Bearbeitung von Vorgängen
Eine Abbildung von mehreren Anliegen zu einem Vorgang ist über die Aktionsbox möglich. Eine Fortschrittsanzeige und das Aktivitäten-Protokoll geben jederzeit eine Übersicht zum aktuellen Status des Vorgangs.
In der Aktionsbox sind folgende Prozesse implementiert:
Aktivität anlegen (Erzeugt eine Aktivität zum aktuellen Ticket)
Anliegen abschließen (Erzeugt eine Abschlussaktivität, in der das Ergebnis sowohl im Ticket, als auch auf der Aktivität festgehalten wird)
Vorgang abschließen (Erzeugt eine Abschlussaktivität, in der das Ergebnis sowohl im Ticket, als auch auf der Aktivität festgehalten wird)
Rückfrage an Kunde (Erzeugt eine Aktivität mit vorgefertigten Werten)
Vorgang wieder eröffnen (Eröffnet einen bereits geschlossenen Vorgang)
Zuordnung mehrerer Anliegen zu einem Vorgang
Anliegen sind funktionale Erweiterungen der Vorgänge, um noch detailliertere Informationen zu hinterlegen, bzw. um mehrere Anliegen einzeln zu behandeln und trotzdem unter einem Vorgang (Sammler) laufen zu lassen. Der Abschluss von Vorgängen und Anliegen wird für den Anwender geführt abgearbeitet.
Zu einem Vorgang können mehrere Anliegen erfasst werden. Folgende Felder werden automatisch aus dem übergeordneten Vorgang übernommen:
Ansprechpartner
Geschäftspartner
Initiator
Priorität
Fälligkeitsdatum (bezieht sich auf Termine des übergeordneten Vorgangs und darf diese nicht übersteigen)
Erinnerungsdatum (bezieht sich auf Termine des übergeordneten Vorgangs und darf diese nicht übersteigen)
![](../../../__attachments/14629484/image2022-7-8_1-14-10.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Validierung des Anliegen-Termins
Bei der Neuanlage von Anliegen werden die Ticket-Anliegen-Nummern über ein Skript generiert. Dies ist immer im Kontext zu dem übergeordneten Ticket zu sehen und beginnt mit 001.
Ein Anpassen des Pattern-Wert sollte daher über die Skript-Klassen-Methode erfolgen: SC0TicketUtils.applyTicketRequestNumber
Delegiert an = Anlageuser
Das Pflichtfeld Betreff muss manuell gefüllt werden.
Anliegennummer wird automatisch generiert
Status wird auf Offen gesetzt
![](../../../__attachments/14629484/image2022-7-8_0-53-36.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Neuanalge von einem Anliegen
![](../../../__attachments/14629484/image2022-7-8_1-18-0.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Kanban-Darstellung zugeordneter Anliegen
Aktivitäten
Aktivitäten dienen dazu, alles, was in dem Prozess gemacht wurde, zu protokollieren. Die Inhalte werden dann auf den Infoboards auf dem Tab Kommentare dargestellt.
![](../../../__attachments/14629484/image2022-7-10_20-29-2.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Alle Aktivitäten in Kommentaren auf der Kachel des Vorgangs
Vorgangbezogene Kundenrückfragen und weitere Aktivitäten
Liegt ein gespeicherter Vorgang vor, kann die Kommunikation mit dem Kunden stattfinden. Außerdem können weitere Informationen über Aktivitäten in der Aktionsbox Aktivität anlegen hinzugefügt werden. Es öffnet sich eine Aktivität mit vorbelegten Werten bzw. Text.
![](../../../__attachments/14629484/KSM-AutomImport.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Aus einem Vorgang generierte Aktivität
Automatische Zuordnung von Aktivitäten
Eine Rückfrage an den Kunden kann über die Aktionsbox Rückfrage an Kunde direkt aufgerufen werden.
Es besteht auch die Möglichkeit, ins System importierte Aktivitäten (z.B. manuell oder über den BCC-Importer) direkt mit einem Vorgang und dem Anliegen zu verknüpfen.
Wird auf dem Vorgang (oder Anliegen) über die Aktionsbox der Prozess Rückfrage an Kunde gestartet, wird im Betreff-Feld eine 7-stellige Nummer mit einem # davor vergeben. Diese Nummer dient der eindeutigen Zuordnung zum Vorgang. Auf der Anliegen-Ebene wird hinter der Ticket-Nummer noch eine dreistellige Ticket-Anliegennummer generiert. Aus dem Feld Ansprechpartner im Vorgang (Anliegen) wird die E-Mail-Adresse als Antwortadresse übernommen.
Wenn diese Aktivität also per Mail versendet wird und anschließend eine Antwort zurückkommt, so wird beim Import in das System die 7-stellige Nummer mit dem # davor überprüft und entsprechend zugeordnet.
![](../../../__attachments/14629484/image2022-7-10_22-10-38.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Generierte Mail über “Rückfrage an Kunde”
Es besteht die Möglichkeit, auch eine individuelle Namenskonvention zu vergeben. Diese kann in der Skript-Klasse SC0TicketUtils
und der Skript-Methode generateTicketNoFromActivity
angepasst werden.
Abschließen von Prozessen
Prozess "Anliegen abschließen"
Der Prozess kann unter folgenden Bedingungen abgeschlossen werden:
bei Abschluss eines noch offenen Anliegens kann der der Anwender in diese offenen Anliegen über das Kanban-Tab springen
zunächst werden alle Anliegen und dann der Vorgang abgeschlossen
nach dem letzten Anliegen wird auch der Vorgang direkt abgeschlossen
beim Abschließen des letzten Ticket-Anliegens wird auch das Ticket mit einer Rückfrage geschlossen
Prozess "Vorgang abschließen"
Der Prozess kann unter folgenden Bedingungen abgeschlossen werden:
Ein Vorgang kann erst beendet werden, wenn alle zugehörigen Anliegen ebenfalls beendet wurden
(1. Möglichkeit) Über das Tab Anliegen kann man noch offene Anliegen in der Kachel suchen, anzeigen und einzeln abschließen.
Wird das letzte Anliegen geschlossen, kommt eine Abfrage, ob der Vorgang ebenfalls abgeschlossen werden soll(2. Möglichkeit) Bei der Änderung des Vorgangs-Status oder über den Klick in der Aktionsbox (Vorgang abschließen) Beim Abschließen eines Vorgangs kommt eine Abfrage, ob auch alle Ticket-Anliegen abgeschlossen werden sollen. (Nach Bestätigung werden die Ticket-Anliegen dann auch abgeschlossen).
Hier springt man direkt die noch nicht erledigten Anliegen an, um sie zu schließen. Seqventiell werden dann Anliegen und Vorgang im Feld Ergebnis dokumentiert und abgeschlossen.
In Kommentaren wird die Person erfasst, die das jeweilige Anliegen oder den Vorgang geschlossen hat.Das Ergebnis des Vorgangs kann durch einen individuellen Text erfasst werden.
![](../../../__attachments/14629484/image2022-7-10_20-34-7.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
Wiedereröffnen von Vorgängen
Öffnen von bereits geschlossenen Vorgängen ist über den Aktionsboxeintrag Vorgang wiedereröffnen möglich. Danach wird der Vorgangs-Status wieder auf Offen gesetzt. Nun können weitere Anliegen angelegt und abgearbeitet werden.
Wiedereröffnen von Anliegen
Öffnen von bereits geschlossenen Anliegen ist über den Aktionsboxeintrag Anliegen wiedereröffnen möglich. Danach wird der Anliegen-Status wieder auf Offen gesetzt. Der übergeordnete Vorgang wird ebenfalls wieder eröffnet.