Using K1000 for non-IT departments - what's your experience?
Bit of advice would be appreciated, from anyone who's experienced a similar situation, or even just has ideas.
We've got a few departments expressing interest in utilising the K1000 purely as a Helpdesk, some of whom are involved already, some who are just end users at the moment. If it goes through, they'll be using Queues/Processes in Kace for things like external customer interaction (eep!), internal work/process tracking etc.
Thoughts around this currently are based on a 'Queue for each department' type setup, with customised Queues with custom rules for each particular Department's needs. The concept of managing all this is starting to make my head spin a little, so I thought I'd see if any of you clever bunch have had similar experiences.
Whilst it's obstensibly built as IT systems management and Helpdesk, anyone else utilising the Queues in K1000 for 'external' departments to IT? Any advice? Anything you wished you'd never done? Anything you wish you'd done from the start?
We've got a few departments expressing interest in utilising the K1000 purely as a Helpdesk, some of whom are involved already, some who are just end users at the moment. If it goes through, they'll be using Queues/Processes in Kace for things like external customer interaction (eep!), internal work/process tracking etc.
Thoughts around this currently are based on a 'Queue for each department' type setup, with customised Queues with custom rules for each particular Department's needs. The concept of managing all this is starting to make my head spin a little, so I thought I'd see if any of you clever bunch have had similar experiences.
Whilst it's obstensibly built as IT systems management and Helpdesk, anyone else utilising the Queues in K1000 for 'external' departments to IT? Any advice? Anything you wished you'd never done? Anything you wish you'd done from the start?
2 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
ondrar
6 years ago
We actually have four active non-IT queues right now, with two or three more in consideration. Two of them are for remote support of clients we consult for, and the other two are for process management in our manufacturing locations. They're all working well, and I manage them from a KACE administrator standpoint (adding and removing ticket owners, categories, etc.), but they manage their own day-to-day usage.
When another department expresses interest in having a queue, we have a meeting and I give them a sort of sales pitch praising KACE's abilities, etc. I'll answer any questions they have, and explain that while KACE is pretty flexible, they may need to adjust their procedures to make things work. We'll choose an administrator/champion who will lead the project from that department's end, and schedule another meeting to go into detail. At that point, they will explain their procedure and we'll translate it into a ticket life cycle. I give them a sheet to fill out, which is basically all the fields from the queue configuration pages, and once they do that, I can create their queue.
The most important thing for me is that they have everything in place procedure-wise before we start, and to set the expectation that once the queue is built and in place/in use, we're not going back and making major changes. Little things are ok, (like I said before, adding and removing ticket owners, etc., things I'm not giving them rights to do), or if we run into a technical limitation and have to reconfigure something, but no redoing the whole queue. That, and once the queue is in place, they're responsible for managing their own tickets. I'm not watching their queue, assigning their tickets, etc.
The one annoyance I have right now is that there is only one KB. While I can limit the articles that can be seen by anyone when they go directly to the KB, any ticket owner in any queue can append any KB article to their tickets. So since the limitations are not in effect there, I can't put things that are for IT eyes only, so it becomes less useful to us.
We've been very successful overall with our queues, and with procedures and expectations in place, you can be, too.
Comments:
-
Thanks! I'm putting together a Spec Sheet already for the Queue, but it's good to have some encouragement from someone who's already done it!
For us it's the appeal of 'owning' the data internally on a SQL database which we can do whatever we'd like with, over an external system like Freshdesk et al which we don't have that kind of control over. - Honkytonk 6 years ago
Posted by:
Tea_monkey
6 years ago
Hello, we have tried to set up two non-IT queues, one for an admin department who handle public enquiries (not IT ones) and one for Estates for staff to report the usual day to day stuff that happens (wobbly desk, loo blocked etc). In both cases the people who were going to use the queues found them too difficult to use. We tried several iterations of the layout, cutting down fields etc., but the general response was that it was too clunky for what they wanted. So that project fell by the wayside.
Comments:
-
Hey Tea_monkey, thanks!
One of the departments who want to use the helpdesk is similar to your Estates department, as it's combined Facilities/Health and Safety, so wobbly desks/blocked loos are their stock in trade!
It's interesting they didn't like it. I suppose there's always a fine line to tread. We're going to try using the Kace GO app for our facilities guys, as the idea of being able to upload their own asset barcodes and scan them to raise tickets or edit info is appealing to them for tracking maintenance/testing etc. - Honkytonk 6 years ago
Charles. - AltCharles 6 years ago