I have worked on archived tickets for a quite a bit. We setup a Closed GOAL Procedure (You could also use an escalation procedure to auto archive the tickets) to set the archive flag to Y once it has been in the closed stage for more than 48 Hours. This automatically archives the tickets. Once the ticket is archived we can view all information as if it is was a live ticket without any editing options.
Why archive tickets? Why after 48 hours?
Well one of the reasons for this client was to clean up their Ticket INBOX if I could call it that. When a ticket went into the RESOLVED stage an ENTRY procedure would be executed to send the END USER an email informing them of the ticket being resolved. If they REPLY to the email the ticket will be reopend. If they didnt reply within 48 hours the ticket will then move to the CLOSED stage. Thus the ticket being closed.
We then had the ticket sitting in the CLOSED stage for 2 days (You can set this to any number of days) thus nothing really happening to that ticket, and also giving the Engineers/Technicians 2 days to update the ticket if they had to. After 48 hours the ARCHIVE flag would be set to "Y" to move it to the ARCHIVE.
This keeps the Service Desk inbox clean and also speeds up the VIEW of all tickets. Instead of viewing thousands of tickets with a STATUS and STAGE of closed, you are only viewing the tickets that are currently open and being worked on. In the ARCHIVED section you would have the ability to bring a ticket back into the Service Desk MAIN view to work or add more information to it.
Thanks for your reply, Jacques. We're doing everything you're doing minus the final archive. We either use the Filter Bar or build a *View* that will hide CLOSED tickets. Many of our techs don't even want to see PENDING CLOSURE tickets in their grid (our version of your RESOLVED stage) and will filter them out as well (a Ticket Change procedure marks them to Previous Stage if the submitter replies).
I like the idea of setting up an escalation procedure on CLOSED to flag a ticket archived; the only problem is I currently have 13,000 tickets closed and not archived and its only letting me archive 100 at a time. This is going to take a while...
Actually I have another question. Do your end users submit tickets via the KLC portal? Or only through email/phone? When you archive a ticket it disappears from their ticket grid in the KLC portal as well so they wont be able to look up their own old tickets.
After several thousand tickets, the system does begin to slow down and creates extra work trying to filter and sort tickets. So as part of our billing process, we create a ticket report for our customer and archive all closed tickets every month.
This does leave a bit of an issue to review past issues, so for that we created a simple ASP page that allows us to search both current and archived tickets and display the contents of the tickets. This provides a better search facility and faster view across tickets. All the ticket information for current and archived tickets are available through Kaseya database views.
Doesnt the "Search All" feature search through active and archived tickets? Or does ticketing archive and service desk archive work differently?
EDIT: And i suppose I could blow through the database with a SQL statement to set the archive flag on tickets older than XX/XX/XXXX, though I'm sure thats not supported ;)
We setup a mix of both, the agent portal is definitely the best way of loggin tickets. You cut out SPAM and other bogus emails. Also, when logging tickets from the Agent Portal you are forcing the Customer to submit detailed information before submitting the ticket. The more accurate the information, the more accurate the Procedures can Qualify and Categorize a ticket.
We had a few discussions regarding the Submitter and the Contact when it comes to tickets, also who was responsible for the ticket once logged. We settled on the communicating with the submitter always. Usually in this case the submitter and the contact is the same person in the company. BUT, when a use logs a ticket on behalf of someone , the actual customer user logging the ticket will take responsibility for the CONTACTS service request.
We also have an entire team running the ID stage, thus also taking ownership of all tickets, they would then assign it to a POOL (Stage/Team) or to a specific Assignee. Thus the Call Logger in the ID stage will always be responsible for following up with the engineer and the submitter. This creates a nice dynamic whereby you actually have some ownership in the process.
When loggin tickets via email the submitter field will be automatically populated, when the Customer phones in, the ID team types in the customers info in the submitter field seeing that the submitter is the one we will be keeping contact with.
You are right in saying that the customer will not be able to view their tickets once archived but I usually find that the customer is most concerned about the current open/in progress tickets.
They would also receive a report at the end of the month on all tickets logged. So this allows the customer to have a full overview of their support requests.
You are correct, you can use the SEARCH ALL feature to search for tickets in SD. You can perhaps do the following for the CLOSED stage. Create a CHANGE procedure for the CLOSED stage to set the ESCALATION or GOAL time to 5 minutes or so. Use group updates to update all the tickets. Once updated the CHANGE procedure would execute and update the ESCALATION/GOAL TIMES. Just make sure that your ESCALATION or GOAL Procedure sets the ARCHIVE flag to Y. You could also use the change procedure to set the ARCHIVE flag.
I have used the SD views in the DB to display all information about tickets as well. I used a specific AJAX library to graph the ARRAY data I pulled using a specific SQL SELECT query.
You could also create specific filters in the SD so that customers can log in remotely with a specific ROLE whereby they can view all their Open Tickets. Very similar to the way Kaseya allows you to log in via the customer portal to view all your tickets.
We planned to use the KLC portal exclusively for the control over required entries in certain fields, as well as linking the ticket with the machine from which it was entered. There were other parts of Live Connect we hadn't started playing with yet but were looking into as well. In our environment it turned out that the SD interface, and really the KLC portal overall, was far too slow and the end users preferred to ignore it entirely and report issues via "Drive by" (Hey there you are! I'm having this problem....). Ultimately we had Kaseya proservices build us a custom interface utilizing their APIs for entering tickets. Its "almost" as functional as using the regular SD (and buggy as hell) but unfortunately it excludes other KLC features entirely. Our entire agent portal is effectively just an incident reporting system.
I agree with you that customers/users probably won't miss seeing their closed tickets; they will be more concerned with open incidents. Being an EE customer our end-users will not recieve reports on their closed tickets though I can't imagine they'd want one either.
Your solution for archiving tickets en masse is interesting, though it still doesn't get around the fact that I can only select as many tickets at a time as I can view on screen (100). I'd still have to do Group Updates 100 at a time and at that point might as well just be Archiving 100 at a time.
You mention that you archive all closed tickets every month. We are trying to find a way to do this automatically on the first of every month, for the previous month's closed tickets. Do you do this now or do you do it manually?