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 IC1200be 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 IC2536accepted 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 IC2696It 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.