Workflow mechanism with OTRS? (question+idea)
Hello We're currently using the RUST ticket system and would like to switch to something else which offers a kind of workflow-ticket classes. What I mean is that a ticket can be of a specific class which has some predefined points which when reached activate some actions like assigning another group, altering the priority or state etc. To make it clearer an example: * A ticket of class "Installation" is opened by an employee. * He enters the customer's address etc and clicks on "stage1 reached" or similar. * The ticket gets automatically assigned to the tech group with a medium priority. * They install whatever and click on "stage2 reched". * The ticket then gets automatically back to the account manager who checks that everything was ok and writes the bill and closes the ticket. I know from the docs that there are some hooks for little robot scripts but I wonder if anybody has ever implemented the above idea? If not I have some ideas with special keywords like X-Checkpoint: 1,2,3 X-Assign 1 tech@example.com X-Priority 1 medium X-Priority 2 important X-Tags 3 + billing and X-Reached 2 The robot would then check the mail of a thread from top to bottom, parses the first set of commands and look if it finds some "reached" lines. The could e.g. be hidden by the web frontend and be displayed in form of a little checkbox field on the side so that every collegue is able to easyly use them. Any comments? bye, -christian- -- Christian Hammers WESTEND GmbH | Internet-Business-Provider Technik CISCO Systems Partner - Authorized Reseller Lütticher Straße 10 Tel 0241/701333-11 ch@westend.com D-52064 Aachen Fax 0241/911879
Hi Christian, On Fri, May 16, 2003 at 09:26:38AM +0200, Christian Hammers wrote:
We're currently using the RUST ticket system and would like to switch to something else which offers a kind of workflow-ticket classes. What I mean is that a ticket can be of a specific class which has some predefined points which when reached activate some actions like assigning another group, altering the priority or state etc.
To make it clearer an example: * A ticket of class "Installation" is opened by an employee. * He enters the customer's address etc and clicks on "stage1 reached" or similar. * The ticket gets automatically assigned to the tech group with a medium priority. * They install whatever and click on "stage2 reched". * The ticket then gets automatically back to the account manager who checks that everything was ok and writes the bill and closes the ticket.
I know from the docs that there are some hooks for little robot scripts but I wonder if anybody has ever implemented the above idea?
If not I have some ideas with special keywords like X-Checkpoint: 1,2,3 X-Assign 1 tech@example.com X-Priority 1 medium X-Priority 2 important X-Tags 3 + billing and X-Reached 2 The robot would then check the mail of a thread from top to bottom, parses the first set of commands and look if it finds some "reached" lines. The could e.g. be hidden by the web frontend and be displayed in form of a little checkbox field on the side so that every collegue is able to easyly use them. Any comments?
Why so complicated. I would use the queues to manage this. * A ticket is opened (with customer's address etc) by an employee and is in queue 'Installation-Tech' (assigned to a group of people). * They install whatever and move the ticket into queue 'Installation-Account-Manager' (to an other group of people). * The account manager who checks that everything was ok and writes the bill and closes the ticket. -=> I also would write the bill (automatically! or the most parts) by an OTRS module. So you can take the customers address, the accounted time, the ticket number, the create and close time, ... (of course this would be a custom module).
bye,
-christian-
-Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ --
On Tue, May 20, 2003 at 07:04:32PM +0200, Martin Edenhofer wrote:
We're currently using the RUST ticket system and would like to switch to something else which offers a kind of workflow-ticket classes. What I mean is that a ticket can be of a specific class which has some predefined points which when reached activate some actions like assigning another group, altering the priority or state etc. ...
Why so complicated.
I would use the queues to manage this.
* A ticket is opened (with customer's address etc) by an employee and is in queue 'Installation-Tech' (assigned to a group of people). * They install whatever and move the ticket into queue 'Installation-Account-Manager' (to an other group of people). * The account manager who checks that everything was ok and writes the bill and closes the ticket.
This has the disadvantage that I would have to use many queues and that the personnel would have to know/remember which queue is the next for this specific task. But exactly this is what I try to circumvent - some robot should remind everybody what to do next.
-Martin bye,
-christian-
On Wed, May 21, 2003 at 02:15:23AM +0200, Christian Hammers wrote:
[...] This has the disadvantage that I would have to use many queues and that the personnel would have to know/remember which queue is the next for this specific task. But exactly this is what I try to circumvent - some robot should remind everybody what to do next.
Hmmm.... I don't know your environment exactly. But I would try to use queues for it... so the workflow would be faster (not need to remind everybody...). (IMO)
-christian-
-Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ --
Hello On Wed, May 21, 2003 at 09:12:07PM +0200, Martin Edenhofer wrote:
This has the disadvantage that I would have to use many queues and that the personnel would have to know/remember which queue is the next for this specific task. But exactly this is what I try to circumvent - some robot should remind everybody what to do next.
Hmmm.... I don't know your environment exactly. But I would try to use queues for it... so the workflow would be faster (not need to remind everybody...).
I guess I wasn't clear or simplified the example too much. What I need is a way of incorporating a TODO List of say 15 items that are splitted to up to 4 groups into the ticket system. And such TODO list for e.g. 20 to 30 different tasks (registering a domain, installing a server..). Then it gets clearer why I wouldn't want to use queues as queues should be some more general (tech, marketing, management, contacts etc). I'm not so much focussed on the dispatching of the ticket to different people (what you proposed with queues) as to have a permanent TODO list that is automatically written on top of every mail. E.g. if you write a comment then the mail is prefixed with [x] do that [ ] check this [x] do that [x] do another thing And everybody would see how far (in terms of the specified workflow) a ticket is. Apropos state, what I need resembles the common states (open, active, pending, close) very much, only that I need a) specific states for some kinds of tickets (example above) b) multiple of this "states" should be checkable (like a checkbox I mean) in random order c) checking this checkboxes should be able to trigger an self defined action. d) these checkboxes that were defined for the different ticket "kinds"/"templates" should be displayed in HTML on the web frontent (maybe checkable per email, too?) This just to make my idea clear in case of anybody likes it too and has much spare time to implement it before I will do somewhen... bye, -christian-
participants (2)
-
Christian Hammers -
Martin Edenhofer