The workflow of eTASK.Serviceticket

This article discusses the structure of the eTASK.Serviceticket best-practice workflow. This is the standard workflow that is provided upon installation of eTASK.Serviceticket, unless otherwise agreed.

Note: If your workflow differs from this best-practice workflow, your company has its own workflow. Consult your CAFM department if you would like to learn more about its structure.

General Overview

• General workflow

Explanation of Basic Functions

All users can create a service ticket. Based on specific default settings, it is then assigned to the reviewing group. See 📄 Hinweise zum Workflow von eTASK.Serviceticket IC1303

The reviewer then has several options for handling the received ticket. The ticket can:

• be forwarded to another group if it was not sent to the correct destination,
  📄 Ein Serviceticket einer anderen Servicegruppe zuweisen IC1200

• be returned if important key data has not been entered,

• be marked as a duplicate if a ticket already exists for the issue,
  📄 Serviceticket als Duplikat markieren IC2536

• accepted and

• rejected.
  📄 Serviceticket ablehnen IC2518

In addition, there is a link to the maintenance workflow here. In this regard, the ticket:
📄 Der Instandhaltungsworkflow IC1185

• be converted into a maintenance order.
  📄 Serviceticket in einen Instandhaltungsauftrag umwandeln IC2696

• It can be assigned to an existing maintenance order, or

• a new maintenance order is created.

• The person who accepts the service ticket for processing can

• mark as completed once they have processed it, or

• if the work is delayed, postpone the completion date by entering a comment.
  📄 Termin verschieben IC2523

In addition, depending on the default settings, escalation emails are sent when processing deadlines have passed to remind users of the unresolved ticket.