Ticket Management
Basics
Numerous processes can be mapped with the CURSOR ticket management module. The best examples are clarification of commercial or technical questions, elimination of faults or processing of complaints. Numerous functions for delegation, escalation and documentation allow prompt processing of service requests, concerns and enable simple communication with all parties involved. The communication is represented by tickets, which can be named as desired depending on the process flow (e.g. "complaint" or "request”). A ticket can optionally cover several requests.
Use case: Ticket processing
Processing (creation, modification, delegation, escalation) of service requests
Integration of mail and portal systems
Use case: Complaint processing
Processing (creation, modification, delegation, escalation) of complaint processes
Assignment and pursuit of minor complaints
Extensive evaluation options for cause analysis
Tickets can be of different type. These differ in the deposited process.
Requests make it possible to process several requests separately in one ticket.
Activities are used to accurately record the communication flow and thus work towards a targeted result.
Technical requirements
The following paragraphs describe the notes and changes for systems that used the customer service module before version 23.1.
Changes in default
New number range for tickets and requests
On the ticket: Ticket No. (TicketNo.Ticket)
Field property "Unique Field" has been activated in the default setting
Changing memo fields
On the ticket: Description (Description.Ticket)
Here a conversion from EditorPane to HTML has been made
In the course of this, the Description2.Ticket field was also changed
Conclusion.Ticket was also converted to HTML
On the request: Description (Description.TicketRequest)
Here a conversion from EditorPane to HTML has been made
In the course of this, the Description2.TicketRequest field was also changed
Conclusion.TicketRequest was also converted to HTML
The Desription2.Ticket and Desription2.TicketRequest fields have been removed from the masks
Notifications
A notification is sent to the user "Delegated to" (Delegated to group).
This occurs when exceeding the date reminder date (on the ticket and request)
This occurs when exceeding the date due date (on the ticket and request)
If both occurred only one notification (due date) will be sent.
Notification is updated only (Only one notification for reminder and due date - even if they are the same)
New timer for sending notifications after date has passed
A new timer "Check escalation date" has been created in the default, which checks every minute if a ticket or request date (due date and reminder date) has been exceeded and then sends a notification in the notification system.
Inclusion of new date fields on the ticket and on the request
While new creating a ticket, the values of the reminder date and due date are preset as follows:
Due date (by default +14 days preassigned)
Remind date (by default +7 days preassigned)
If the stored data was exceeded, the person who was stored in the "Delegated to" field receives a notification
When a new request is created, the values from the reminder and due date of the parent request are transferred
In addition to this:
The due date of the request must not be later than the due date of the parent ticket
Testing: Storage of the dataset may not take place if this is not ensured
If by a manual change by saving the due date of the ticket is before the due date of the request, the due date of the request is automatically set to be the same as the due date of the ticket.
If by a manual change the due date of the request is behind the due date of the ticket, the manual change and saving should be prevented. Instead, the last valid value for the due date of the request is used → Reset to last value
New field Contact person on the request
There is a new Contact person field on the request, which is preset with the contact person from the parent ticket during new creation.
Changes to the SC0TicketUtils script library
The following adjustments have been made in the SC0TicketUtils script library:
Method | Status | Changes |
---|---|---|
createTicketFromActivity() | Changed | CoPeKey.Ticket field is filled only if DefaultContactPerson.Activity field is not empty |
generateTicketNoFromActivity() | Changed | Modification of the RegEx so that the new ticket number format is recognized during mail import |
getRemindDateDuration() | New | Sets the interval between the due date and the reminder date in days |
handleRequestBbetterTabs() | New | Controls the visibility of the bbetter and ticket specific elements on the request mask |
handleTicketBbetterTabs() | New | Controls the visibility of the bbetter and ticket specific elements on the ticket mask |
isWeekend() | New | Checks if the passed date is on a weekend |
reqEntryInserted() | Changed | Transfer data from ticket and added call of handleRequestBbetterTabs(). |
reqEntryLoaded() | Changed | Call of handleRequestBbetterTabs added. |
reqFieldValueChanged() | Changed | Adding the due date and reminder date logic |
ticketEntryInserted() | New | Call of handleTicketBbetterTabs() added. Calling the initial due date and reminder date logic |
ticketEntryLoaded() | Changed | Call of handleTicketBbetterTabs() added. |
ticketFieldValueChanged() | Changed | Call of handleTicketBbetterTabs added. Calling the due date and reminder date logic |
Optional: Individualize classifications for individual departments.
It is possible to store different keys in the classification and sub classification depending on the ticket type. This can thus be configured in three steps: Ticket type - Classification - Sub classification. If general keys (for all persons) are to be stored in these key ranges, this configuration does not have to be carried out, only if, for example, department-specific keys are to be stored, which other departments are not to see or select.
Field property in the Sub classification field (Classification2.Ticket):
Lookup search:
LookupEntityS_KeytabKeyMappings
Preselection during validation:
MasterKey.KeyMappings.EQUAL={Classification.Ticket}
MasterKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION
SlaveKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION2
Active.KeyMappings.EQUAL=1
Field property in the Classification field (Classification.Ticket):
Lookup search:
LookupEntityS_KeytabKeyMappings
Preselection during validation:
MasterKey.KeyMappings.EQUAL={TicketType.Ticket}
MasterKeyRange.KeyMappings.EQUAL=C0TICKET_TYPE
SlaveKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION
Active.KeyMappings.EQUAL=1
Migration for existing customers
For customers who have licensed the customer service module and changed it via customizing, it must be checked within the project what effects the adjustments have in default. A project-specific solution must be found here.
Changing the language variables
The language variables have been moved from the module-specific internationalization to the language variables script library (script class SC0TICKETUTILS). This has changed the default script call String I18nUtils.i18nModule(String moduleID, String key, Locale language, Object... parameter)
to the script call String I18nUtils.i18nCustom(String key, Locale language, Object... parameter)
. This must be followed up with all overridden processes in the area of ticket management.
The following processes have moved their I18n from the module to the language variables in C0. This is to be made up in higher layers if one of them has been overridden:
C0TicketAddActivity
C0TicketCompletion
C0TicketCompletionSub
C0TicketCreation
C0TicketMailSending
C0TicketReopen
C0TicketRequestCompletion
C0TicketRequestCreation
The following processes have no i18n included in C0, but would still have to be checked if something was installed there in case of an override.
C0TicketCreateActivityFromNotesField
C0TicketLinkActivity
C0TicketRequestCreateActivityFromNotesField
C0TicketDelegateToGroup
C0TicketLinkComment
C0IB_CreateRequestTicket
Replace each call like
I18nUtils.i18nModule("TICKET", "<key>", SessionConstants.LOCALE);
through
I18nUtils.i18nCustom("<key>", SessionConstants.LOCALE);
b.better
b.better is now a separate module. During the update to version 23.1. it is checked if there are b.better specific datasets. This is done as follows:
If there are datasets in the TicketReason and TicketClassify entities , then the complaint management module (b.better) will NOT be removed
The deleting update will NOT be executed if there are datasets in ticket classification / reason
If there are NO datasets in the TicketReason and TicketClassify entities, then the complaint management module (b.better) will be removed
The deleting update will be executed if there are NO datasets in ticket classification / reason
Important: The default masks TicketBbetter and TicketRequestBbetter have been deleted. If these are still to be used after the update to version 23.1, they must be overridden BEFORE the update.
Renaming customer service module to complaint management
Ticket and Ticket request entities have been renamed to Ticket and Request and resolved from within the module
Default ticket management logics have also been removed from the module and now work without the module installed
Individual fields and infoboards of ticket and request, which are used specifically for the complaint management b.better, remain in the module
A new key BB - bbetter controls the new mask logic and shows the b.better specific maps (and thus fields) after selection
Thus, it may be necessary to change the mask script or the mask
The masks TicketBbetter and TicketRequestBbetter have been deleted
If a customer has selected one of the masks but has not overridden it, the customer is automatically switched to the new mask. There the b.better fields (or maps) are shown and hidden via the new logic
If a customer has overridden and adjusted the masks, only the C0 masks are deleted. The C2 variants remain, so there is no difference for the customer
Caution
If the customer does NOT want the masks to be adapted to the new design before the update, the old masks must be overridden in the customer layer (C2 layer).
Description of the ticket process
Process start
The customer service process can be started via different areas:
Business partner (using an action box)
Contact person (using an action box)
Activities (using an action box)
Tickets (direct new creation)
Alternatively, tickets, requests and other associated data can be viewed via preconfigured default or sales boards (with the "Scores" tile). For this purpose, the boards are to be placed on the cockpit.
Access via business partner or contact person
The customer service process can be started via business partners or contact persons using an action box (Ticket management → Create ticket). After the new creation of the ticket, the business partner and/or contact person is preassigned and a direct link is established.
New creation of tickets and field pre-allocation
The new creation is started via entry points. The layout of ticket status and the activity protocol are displayed by info tiles.
Required fields:
Subject
Type
General
bbetter (only selectable for b.better customers, this key controls the visibility of the b.better fields)
Ticket
Contact person
Business partner (will be prefilled automatically after selecting the contact person)
Further fields:
Status, priority and description are self-explanatory
Initiator = Create user
Delegated to - the ticket can be delegated to a specific person
Delegated to group - the ticket can be delegated to a group (e.g. department).
Due date (by default +14 days prefilled)
Remind date (by default +7 days prefilled)
Both values can be adjusted. The logics ensure that the reminder date is not set after the due date. The person defined in the "Delegated to" field will then always be notified of the defined dates.Input and Input type fields are self-explanatory
Classification and Subclassification
Two-level dependency that allows key selection in the sub classification.
The first dependency is preset by the ticket type, which keys are selectable in the classification. In the second stage, the keys of the sub classification depend on the keys of the classification.
When saving, the system generates the ticket number. This is composed of the type and an incremented seven-digit number. In addition, associated actions are offered in the action box.
Inactive actions are grayed out.
Delegation of tickets (forwarding)
It is possible to delegate tickets to another employee via a text message on the processing tile. This is how it works:
Delegated to = <token of the relevant colleague>
Create a new comment
When saving, the ticket opens in the todo list of the delegated colleague:
Quick launch bar under "Remaining tasks"
The process flow is recorded in the activity protocol.
Group delegation
Here a logic is stored in such a way that either the field Delegated to or Delegated to group can be filled. Both fields cannot be filled at the same time, so that when one field is filled, the other is emptied.
Ticket delegated to a group reacts to processes
When a ticket is delegated to a group and you start a process, you expect the ticket to delegated to the person who started the process. The group delegation is thus removed and the ticket is delegated to an employee.
Types of tickets
A ticket can have three different types:
General
bbetter (only selectable for b.better customers, this key controls the visibility of the b.better fields)
Ticket
By the ticket type masks for tickets can be configured differently. Both fields and entire tiles can be assigned differently depending on the department, for example.
Furthermore, subordinate requests can also look different, this is controlled by the Type key on the ticket as well.
After initial saving, the ticket type becomes read-only and can no longer be changed.
Access via activities
Via activities, the ticket process can also be started using the action box (Ticket management → Create ticket), here the ticket is preset with either the TICKET or GENERAL key. After the new creation of the ticket, various fields can be pre-assigned as follows:
Field on the activity | Field on the ticket |
---|---|
DefaultContactPerson | ContactPerson, Customer |
Subject | Subject |
Text (memo field) | Description |
DelegatedTo | DelegatedTo |
Currently logged in user | DelegatedFrom |
Processing tickets
A mapping of several requests to one ticket is possible via the action box. A progress bar and the activity log provide an overview of the current status of the ticket at all times.
The following processes are implemented in the action box:
Create activity (creates an activity for the current ticket)
Close request (creates a close activity that records the result both in the ticket and on the activity)
Close ticket (creates a close activity that records the result both in the ticket and on the activity)
Query to customer (creates an activity with pre-defined values)
Reopen ticket (Reopens a ticket that has already been closed)
Assignment of several requests to one ticket
Requests are functional extensions of the tickets to store even more detailed information, or to handle several requests individually and still run under one ticket (collector). The completion of tickets and requests is processed in a guided manner for the user.
Several requests can be recorded for a ticket. The following fields are automatically copied from the parent incident:
Contact person
Business partner
Start User
Priority
Due date (refers to appointments of the parent ticket and must not exceed them)
Reminder date (refers to appointments of the parent ticket and must not exceed them)
With the new creation of requests, the ticket request numbers are generated via a script. This is always to be seen in the context of the higher-level ticket and starts with 001.
An adjustment of the pattern value should therefore be done via the script class method: SC0TicketUtils.applyTicketRequestNumber
Delegated to = Creator
The required field Subject must be filled manually.
Request number is automatically generated
Status is set to Open
Activities
Activities are used to log everything that was done in the process. The content is then displayed on the infoboards on the Comments tab.
Ticket-related customer enquiries and other activities
If there is a saved ticket, communication with the customer can take place. In addition, more information about activities can be added in the activity box Create activity. An activity with default values or text opens.
Automatic assignment of activities
An query to the customer can be called up directly by the action box query to customer.
It is also possible to link activities imported into the system (e.g. manually or via the BCC importer) directly to a ticket and the request.
If the process Query to customer is started on the ticket (or request) via the action box, a 7-digit number with a # in front of it is assigned in the subject field. This number is used to uniquely identify the ticket. At the request level, a three-digit ticket request number is generated after the ticket number. The email address is taken from the Contact person field in the ticket (request) as the reply address.
If this activity is sent by mail and then a response is returned, the 7-digit number with the # is checked before it is imported into the system and assigned accordingly.
It is also possible to assign an individual naming convention. This can be adjusted in the script class SC0TicketUtils
and the script method generateTicketNoFromActivity
.
Closing processes
Process "Complete ticket request"
The process can be completed under the following conditions:
when a pending request is closed, the user can jump to this pending request via the Kanban tab
first all requests and then the ticket is closed
after the last request, the ticket is also closed directly
when closing the last ticket request, the ticket will also be closed with a query
Process "Close ticket"
The process can be completed under the following conditions:
A ticket can only be terminated when all associated requests have also been terminated
(1st possibility) Via the tab Request you can search for open requests in the tile, display them and close them individually.
If the last request is closed, a query appears asking if the ticket should also be closed(2nd possibility) When changing the ticket status or by clicking in the action box (Close ticket). When closing a ticket, a query appears asking whether all ticket requests should also be closed. (After confirmation the ticket requests will be closed).
Here you jump directly to the unfinished requests to close them. Sequentially, request and ticket are then documented and closed in the Result field.
In comments, the person who closed the respective request or ticket is recorded.The result of the ticket can be recorded in an individual text.
Figure: Query for the completion of a ticket
Reopen tickets
Opening of already closed tickets is possible via the action box entry Reopen ticket. After that the ticket status is set to Open again. Now further requests can be created and processed.
Reopen requests
Opening of already closed requests is possible via the action box entry Reopen request. After that the request status is set to Open again. The parent ticket is also reopened.