SimpleTicket Workflow Part I
SimpleTicket was written specifically for one company (Architel) who has very specific needs. I thought it might be helpful to describe our workflow to help you understand how SimpleTicket was designed. Agree?
First, it is important to realize that we have help desk technicians who can remotely resolve 3-10 issues for end-users per day. Endusers contact us by creating a trouble ticket in our system and our help desk technicians see these new ‘PENDING’ tickets. Our objective is to have each ticket addressed within 15 and 20 minutes. To address a ticket an engineer changes that status to ‘OPEN’ and determines how to proceed. If the ticket requires additional information from an end-user that ticket is placed back in the ‘PENDING’ que, but is identified as ‘CONTACTED’
In the meantime end-users are receiving emails indicating that we have opened their ticket and that we are working on the issue. Assuming we had to leave you a voicemail, we send you another email indicating we called and asked you to update the ticket yourself with the required information or to simply call us back.
Second, assuming that our ‘contacted’ end-user was able to reach the instigating engineer he could detail the various issues that face the him. If possible he attempts to resolve the issue immediately from his nice cosy chair in the NOC. If he can, he notes this in the ticketing system and closes the ticket. Next the enduser recieves an email indicating that their issue as been resolved and that their ticket is now closed (giving instructions for reopening it if necessary). 80% of the time this is the workflow. But in 20% of the cases we must dispatch an engineer to the client location to resolve the issue. The ticket is then moved into the ‘SCHEDULE ON-SITE’ que. Our engineers then visit the site, resolve the issue and then close the ticket.
Workflow Part I Diagram:
July 10th, 2006 at 12:52 am
lovly software