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:

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:

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.

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.